On Sat, May 16, 2009 at 02:05, Joshua Root <[email protected]> wrote: > 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.)
Many/most ports that do use $CPP probably only run it on one file, in which case it will behave as expected. Also, I have run into this before: http://trac.macports.org/changeset/40070 - Toby _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
