[51027] trunk/dports/devel

[Toby Peterson]

On Jul 29, 2009, at 5:38 AM, Ryan Schmidt wrote:

> On May 16, 2009, at 14:40, Toby Peterson wrote:
>
>>>> On May 16, 2009, at 02:57, Toby Peterson wrote:
>>>>
>>>>> 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.
>>
>> 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
>
> Ok, I didn't realize. r40070 clears configure.cpp for sdcc.
>
> In r51272 I see you removed setting CPP in base for gcc 4.2 only.  
> This surprised me because we never talked about removing this for  
> gcc 4.2 only; I thought we were talking about making or not making  
> general changes to MacPorts. And I'm worried r51272 will break ports  
> that try to use ${configure.cpp} -- we currently have a few that do,  
> in an effort to ensure they are using the right compiler:
>
> http://trac.macports.org/wiki/UsingTheRightCompiler
>
> We were pondering recently why Xorg software looks for the variable  
> RAWCPP instead of CPP:
>
> http://trac.macports.org/ticket/20190
>
> It dawned on me that this probably is related to what you were  
> saying. What if MacPorts were to grow a new variable,  
> configure.rawcpp, containing the path to cpp (i.e. what  
> configure.cpp has been thus far), and change configure.cpp to be "$ 
> {configure.cc} -E"? Would that be consistent with the intended use  
> of these environment variables?

Setting CPP explicitly qualifies as "trying too hard". Nearly every  
port in existence will use "$(CC) -E", so setting CC is sufficient.  
The intended use of the CPP environment variable is to not set it at  
all. :)

I changed it for gcc-4.2 only, so as to not affect current behavior on  
older OS releases.

- Toby