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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
