[51027] trunk/dports/devel

Ryan Schmidt ryandesign at macports.org
Thu Jul 30 00:05:38 PDT 2009


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.




More information about the macports-dev mailing list