On 2009-5-16 18:40, Ryan Schmidt wrote: > > On May 16, 2009, at 02:57, Toby Peterson wrote: > >> On Fri, May 15, 2009 at 14:03, Ryan Schmidt wrote: >> >>> On May 15, 2009, at 13:55, [email protected] wrote: >>> >>>> Revision: 51027 >>>> http://trac.macports.org/changeset/51027 >>>> Author: [email protected] >>>> Date: 2009-05-15 11:55:33 -0700 (Fri, 15 May 2009) >>>> Log Message: >>>> ----------- >>>> libmowgli 0.7.0 >>> >>> [snip] >>> >>>> +# Why do we set a bogus CPP value, anyway? >>>> +configure.cpp >>> >>> What is bogus about it? [snip] >> >> It should be "gcc -E". To illustrate the problem: >> >> % touch foo.c bar.c >> % gcc -E foo.c bar.c >> # 1 "foo.c" >> # 1 "<built-in>" >> # 1 "<command line>" >> # 1 "foo.c" >> # 1 "bar.c" >> # 1 "<built-in>" >> # 1 "<command line>" >> # 1 "bar.c" >> % cpp foo.c bar.c >> % >> >> Most configure scripts will just use "$CC -E" if CPP isn't specified >> explicitly, which is what I'm taking advantage of there. And, if you >> run nearly any configure script with no special setup: >> >> checking how to run the C preprocessor... gcc -E >> >> I'd vote for just never setting CPP, but setting it to "$CC -E" would >> probably work too. > > Interesting. I can't offer much input as all I know about compiling > software comes from maintaining ports in MacPorts; I haven't written > compiled software myself and I'm not fluent on what a preprocessor is > supposed to do or how it's supposed to work. But now I'm curious why > there is an executable called "cpp" whose manpage says it is "The C > Preprocessor" if that's not in fact the C preprocessor one is meant to use. > > After some Googling, I think I'm understanding that "gcc -E" internally > calls "cpp"? They just appear to handle output differently. For example, > I see that "gcc -E foo.c bar.c" causes the output to appear as you > showed, and foo.c and bar.c remain empty, whereas "cpp foo.c bar.c" > causes no output to appear, and modifies bar.c to contain the > foo-related lines you showed, and the bar-related lines don't seem to be > anywhere. This appears to match the usage explanation from the cpp > manpage, "cpp infile outfile". In contrast, gcc appears to take a bunch > of input files and print output to stdout. > > MacPorts has set CPP to /usr/bin/cpp-4.0 since r27018 was committed on > 2007-07-15, and this was released as part of MacPorts 1.5.1 in August > 2007. And I haven't heard any mention of a problems with this approach > until now. So my first instinct is to wonder if this is less a general > problem and more an issue in the particular software you're porting. I'm > not opposed to changing this in MacPorts base if that can be > demonstrated to be more correct and to help more ports than it harms. > But the fact that AFAIK no prior problems were reported with this method > in 22 months speaks to the method not being totally crazy. I certainly > wouldn't call it "bogus."
That or most build systems don't actually use $CPP. (There's no reason to if you're just doing a normal compile.) - Josh _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
