On Aug 31, 2007, at 03:36, Vincent Lefevre wrote:
On 2007-08-29 20:28:30 -0500, Ryan Schmidt wrote:
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.
Does MacPorts ensures that Xcode gcc is used?
I don't know. Several hundred ports do, though, and it's my belief
(see thread "[28325] trunk/dports/graphics/wxWidgets-devel/Portfile"
on macports-dev) that MacPorts base should ensure that all ports use
Apple's gcc, unless the port specifies otherwise.
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.
Then that's a user-side problem. The best fix is to remove/replace
this
incredibly old version of readline.
Of course. But if MacPorts *seems* to build correctly against this
old readline, and several ports *seem* to build correctly against the
old readline, and the user doesn't even know the old readline is
there because some other 3rd-party software they wanted installed it
there for them, and then one day they want to build db44 and it
throws bizarre errors that nobody figures out how to fix for months
[1], then this gives the impression that MacPorts is unreliable. So
it *becomes* our problem to ensure the user doesn't make these kinds
of mistakes. It is documented that we want MacPorts to use only its
own software, or Apple software in if required in a pinch, so we
should make MacPorts behave in accordance with that documentation.
[1] http://trac.macosforge.org/projects/macports/ticket/12040
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.
But Apple software has bugs. For instance, its readline doesn't
support
UTF-8. I don't know if it can be useful, but anyway the user could
type
non-ASCII characters by mistake, try to remove them, leading to wrong
commands.
Well I have no idea about that but if it's important, then MacPorts
should include an updated readline and use that exclusively. And if
it's not important, then it should use Apple's readline. The point
remains that MacPorts should *not* use some arbitrary readline in /
usr/local.
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
