On May 16, 2009, at 02:57, Toby Peterson wrote:
On Fri, May 15, 2009 at 14:03, Ryan Schmidt wrote:
On May 15, 2009, at 13:55, [email protected] wrote:
Revision: 51027
http://trac.macports.org/changeset/51027
Author: [email protected]
Date: 2009-05-15 11:55:33 -0700 (Fri, 15 May 2009)
Log Message:
-----------
libmowgli 0.7.0
[snip]
+# Why do we set a bogus CPP value, anyway?
+configure.cpp
What is bogus about it? [snip]
It should be "gcc -E". To illustrate the problem:
% touch foo.c bar.c
% gcc -E foo.c bar.c
# 1 "foo.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "foo.c"
# 1 "bar.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "bar.c"
% cpp foo.c bar.c
%
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.
Interesting. I can't offer much input as all I know about compiling
software comes from maintaining ports in MacPorts; I haven't written
compiled software myself and I'm not fluent on what a preprocessor is
supposed to do or how it's supposed to work. But now I'm curious why
there is an executable called "cpp" whose manpage says it is "The C
Preprocessor" if that's not in fact the C preprocessor one is meant
to use.
After some Googling, I think I'm understanding that "gcc -E"
internally calls "cpp"? They just appear to handle output
differently. For example, I see that "gcc -E foo.c bar.c" causes the
output to appear as you showed, and foo.c and bar.c remain empty,
whereas "cpp foo.c bar.c" causes no output to appear, and modifies
bar.c to contain the foo-related lines you showed, and the bar-
related lines don't seem to be anywhere. This appears to match the
usage explanation from the cpp manpage, "cpp infile outfile". In
contrast, gcc appears to take a bunch of input files and print output
to stdout.
MacPorts has set CPP to /usr/bin/cpp-4.0 since r27018 was committed
on 2007-07-15, and this was released as part of MacPorts 1.5.1 in
August 2007. And I haven't heard any mention of a problems with this
approach until now. So my first instinct is to wonder if this is less
a general problem and more an issue in the particular software you're
porting. I'm not opposed to changing this in MacPorts base if that
can be demonstrated to be more correct and to help more ports than it
harms. But the fact that AFAIK no prior problems were reported with
this method in 22 months speaks to the method not being totally
crazy. I certainly wouldn't call it "bogus."
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
