On Aug 29, 2007, at 14:29, Vincent Lefevre wrote:
On 2007-08-28 22:58:16 +0200, N_Ox wrote:
Le 22 août 07 à 17:25, Vincent Lefevre a écrit :
On 2007-08-21 22:15:08 -0400, Jay Sachs wrote:
What about:
gcc -nostdinc \
-isystem /usr/lib/gcc/i686-apple-darwin8/4.0.1/include \
-isystem /usr/include \
-isystem /System/Library/Frameworks \
-isystem /Library/Frameworks
? It'd be nice not to hardcode this -- it could be determined
dynamically
by examining the output of `cpp -v` and filtering out /usr/local/
include.
Perhaps. But this is really a hack.
Why do you call it a hack? It just does what we want to.
For instance, it could fail if the user has a different gcc, with
different system paths.
But we always want users to compile MacPorts base using the gcc
provided with Apple Xcode. We don't want people attempting to use any
other version of gcc.
Couldn't MacPorts be made compatible with
the GNU readline API?
I thought it already was. I think the problem is not that MacPorts is
not compatible with GNU readline, but that users sometimes have
incredibly old versions of readline in /usr/local which are
(apparently) insufficient for MacPorts. We don't want to link against
incredibly old (or even up-to-date) versions of software the user has
installed themselves. We want to use software managed by MacPorts
where at all possible. ANnd for the bootstrapping process of of
initially getting MacPorts installed, it's reasonable to use just
Apple software.
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
