[51027] trunk/dports/devel

[Joshua Root]

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, toby at macports.org wrote:
>>>
>>>> Revision: 51027
>>>>          http://trac.macports.org/changeset/51027
>>>> Author:   toby at macports.org
>>>> 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