interesting ccc issue

Clang Frontend
1

I've run into an interesting problem with messing with ccc. I was trying to
compile libarchive as integrated into the FreeBSD build system. It has some
interesting hacks where it avoids the use of the autoconf bits entirely since
we keep those out of the tree as a rule. One of them does:

#if defined(PLATFORM_CONFIG_H)
/* Use hand-built config.h in environments that need it. */
#include PLATFORM_CONFIG_H
#elif defined(HAVE_CONFIG_H)
/* Most POSIX platforms use the 'configure' script to build config.h */
#include "../config.h"
#else
/* Warn if the library hasn't been (automatically or manually) configured. */
#error Oops: No config.h and no pre-built configuration in archive_platform.h.
#endif

This is integrated into the build system by having CFLAGS include

-DPLATFORM_CONFIG_H=\"config_freebsd.h\"

The \" bits are key because when substituted the #include works. With
ccc the \'s get removed and thus the "s don't make it all the way to clang's
preprocessor resulting in this error:

ccc -O2 -fno-strict-aliasing -pipe -DPACKAGE_VERSION=\"2.2.5\" -DPLATFORM_CONFIG_H=\"config_freebsd.h\" -I/usr/src/usr.bin/tar -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-pointer-sign -c bsdtar.c
bsdtar.c
clang -emit-llvm-bc -x c -o bsdtar.o bsdtar.c -DPACKAGE_VERSION="2.2.5" -DPLATFORM_CONFIG_H="config_freebsd.h" -I/usr/src/usr.bin/tar
In file included from bsdtar.c:26:
/usr/src/usr.bin/tar/bsdtar_platform.h:39:10: error: expected "FILENAME" or <FILENAME>
#include PLATFORM_CONFIG_H
         ^

I'm not sure what all issues involved in re-escaping the '"' characters
would be would be, but hopefully someone with stronger python-foo that
mine will have some ideas.

-- Brooks

2

5 feb 2008 kl. 16.16 skrev Brooks Davis:

I'm not sure what all issues involved in re-escaping the '"' characters
would be would be, but hopefully someone with stronger python-foo that
mine will have some ideas.

I have

Index: utils/ccc

3

Double quotes, unfortunately, are just the tip of the iceberg. Consider
-DCMD_STRING='"echo $(ls)"' or -DNOP='do { } while (0)', for example.

This is my fault. When I proposed the subprocess.call() -> os.system()
conversion, I didn't consider the -D option and that its arguments can be
nearly anything.

I think that we will be happiest long term if we go back to using the
subprocess module and requiring a 2.4+ version of Python. We'll probably
end up wanting other 2.4+ features anyway.

The attached patch reverts the subprocess.call() -> os.system() conversion.
A close review, of course, is welcome. :slight_smile:

Sincerely,
Sam Bishop

ccc-use-subprocess-module.patch (1.01 KB)

4

6 feb 2008 kl. 08.11 skrev Sam Bishop:

def run(args):
- cmd = ' '.join(args)
+ cmd = ' '.join(args).replace("\"", "\\\"");
     print >> sys.stderr, cmd
     code = os.system(cmd)

Double quotes, unfortunately, are just the tip of the iceberg. Consider
-DCMD_STRING='"echo $(ls)"' or -DNOP='do { } while (0)', for example.

Right.

This is my fault. When I proposed the subprocess.call() -> os.system()
conversion, I didn't consider the -D option and that its arguments can be
nearly anything.

I think that we will be happiest long term if we go back to using the
subprocess module and requiring a 2.4+ version of Python. We'll probably
end up wanting other 2.4+ features anyway.

Given that Python 2.4 was released in late 2004, more than 3 years ago, I think it's safe to require 24..

The attached patch reverts the subprocess.call() -> os.system() conversion.
A close review, of course, is welcome. :slight_smile:

Cool. I'll have a look and commit it.

Thanks!
Anders