[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