[51027] trunk/dports/devel

[Toby Peterson]

On Sat, May 16, 2009 at 02:05, Joshua Root <jmr at macports.org> 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, 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.)

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