[51027] trunk/dports/devel

[Ryan Schmidt]

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?