[47283] trunk/dports/lang/gnat-gcc/Portfile

[Ryan Schmidt]

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.