[51027] trunk/dports/devel

[Ryan Schmidt]

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."