[51027] trunk/dports/devel

[Toby Peterson]

On Jul 30, 2009, at 12:05 AM, Ryan Schmidt wrote:

> On Jul 29, 2009, at 15:38, Toby Peterson wrote:
>
>> On Jul 29, 2009, at 1:30 PM, Ryan Schmidt wrote:
>>
>>> On Jul 29, 2009, at 11:35, Toby Peterson wrote:
>>>
>>>> If you say setting CPP is not necessary, and will not result in  
>>>> more ports trying to use "cpp" or "gcc", then how about we just  
>>>> rename configure.cpp to configure.rawcpp (so MacPorts sets RAWCPP  
>>>> and not CPP)? We would need to handle the existing ports that use  
>>>> configure.cpp carefully but long-term does this sound like an ok  
>>>> plan?
>>
>> I'd be in favor of not setting CPP at all, and setting RAWCPP makes  
>> even less sense considering that only a few ports use it.
>>
>> If we want to make sure the configure.cpp variable is set, we can  
>> keep it set (to "${configure.cc} -E") and just not set the  
>> environment variable.
>
> I don't care what variables are set to what; I care that a port that  
> needs to know where cpp is will be able to find it. If we don't set  
> CPP or RAWCPP, how will we tell e.g. the xorg ports where cpp is?
>
> To take an example, edit the xorg-server port and replace
>
> configure.env-append \
> 	RAWCPP=${configure.cpp}
>
> with
>
> configure.env-append \
> 	RAWCPP="${configure.cc} -E"
>
> and it will no longer work. As far as I can tell xorg-server and  
> other xorg ports need access to cpp, not $CC -E, and for the reasons  
> outlined in UsingTheRightCompiler we don't want them to use  
> "cpp" (which is what they will use if we do not set RAWCPP as we do  
> in the port); we want them to use the correct version of cpp that  
> matches configure.compiler, e.g. the path we currently define in  
> configure.cpp and which I'm proposing we move to configure.rawcpp.

Just use ${configure.cpp} - see fix in http://trac.macports.org/changeset/54609

- Toby