On Feb 25, 2009, at 13:27, Martin Krischik wrote:
Ryan Schmidt schrieb:
What is the difference between the ada and gnuada variants?
sudo port install gnat-gcc +ada
vs.
sudo port dmg gnat-gcc +ada
;-)
It looks
like the ada variant uses an ada compiler provided by MacPorts (if
so,
there should be a dependency on a MacPorts port in that variant),
As with all self hosting compiler: They depend on them-self. You
use an
older version to create a new version.
and
the gnuada variant uses an ada compiler provided by someone else in
binary form which installs into /opt/local?
Not someone else - by me. I created that version using "port dmg" as a
one way to break the recursive dependency.
And how were you able to build the port in order to create the dmg?
Did you have a compiler in /usr/local for this?
If that's correct, then
that's very disconcerting; we should not be encouraging users to
install
something that puts files into /opt/local without using MacPorts
to do
so. And the gnuada folks should not be distributing binaries that
install things into the MacPorts /opt/local prefix.
Well, as I said: I am the "gnuada folks". Note that already
consider to
use a different prefix for the "port dmg" installation but I am not
yet
sure which disadvantage that would bring. And any gcc related test
takes
several hours - even on my MacPro - even with setting --jobs to
make use
of the 8 cores.
I would prefer if the port handled everything itself, like other
ports do.
I acknowledge that the need for a bootstrap compiler complicates
things. But a port should not depend on a previous version of itself
being installed. And a port should not use a previous version of
itself if installed. A port should work the same on every user's
system, regardless what ports they already have installed (modulo Mac
OS X version and processor architecture).
You could have the port download a compiler binary to use for
bootstrapping (either the one you made, or the one that installs in /
usr/local that you used to make yours.) Put that binary somewhere in
the work directory and use it to build the real compiler. Possibly
you would need to use DYLD_FALLBACK_LIBRARY_PATH to help it find its
libraries in their unusual location in the work directory. You
probably wouldn't need to update the version of the bootstrap
compiler very often so it's just a one-time extra download for users,
one which they would need to do manually anyway in your current setup.
The incomplete port for minivmac 3 does something like this. minivmac
is a Mac Plus emulator. As of version 3, minivmac's configure phase
has been replaced by a program (called "Build") that needs to be run
from within minivmac 3. (Brilliant!) So the port needs to download a
binary of minivmac 3, and a disk image with "Build" on it, and a disk
image with the operating system on it, and set up the disks to auto-
run "Build" when the OS is booted (this is the part that's still
incomplete).
http://trac.macports.org/browser/users/ryandesign/minivmac/Portfile
The port is very nasty but it does demonstrate the bootstrap compiler
situation. Another (more traditional) example would be ghc. It has
the unenviable problem of having to deal with four different
bootstrap compilers -- one each for Tiger PPC, Tiger Intel, Leopard
PPC and Leopard Intel. With minivmac fortunately I was able to use
just a single universal version.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
