Re: GNAT for Debian

[Simon Wright <simon@pushface.org>]

George Shapovalov <georges@its.caltech.edu> writes:

> Chris M. Moore wrote:
> > It seems cleaner, less work and more maintainable to build gnat as
> 
> Well, this seems all nice and sound, but there are such things as FHS and
> LSB, and in this case GNAE, which pretty much define what goes where. Of
> course when you build it on your own you are free to screw your system as
> you wish ;) (even then FHS says you should put it under /usr/local).
> However if we are talking about a package for a respectable distribution
> (such as Gentoo or Debian ;)) placing this stuff under /opt is
> inappropriate (this one is reserved for biary packages). Sometimes there is
> really no easy way around and one is forced to bundle a package in a way it
> is built, however even then it should go under /usr/lib/$PkgName and proper
> symlinks should be created (and possibly docs moved to proper place.., well
> may be there will be something else as well :)).
> Randhol is definitely free to do as he wishes, however I would expect Debian
> devs to take the position similar to what he demonstrated just now. And
> finally, wouldn't you like to use a properly built and installed package
> ;)?

It used to be most inadvisable to let GNAT installations anywhere near
your standard path (if you wanted to be able to rebuild your kernel,
for example). Not good if gcc turns out to be 2.8.1!

So you clearly need something like gnatgcc.

But you must be very careful where the gcc-lib/i686-whatever-linux
stuff goes -- not on top of your working standard compiler.

So you need a clean way of putting the GNAT builds (especially if you
have more than one) in places where they can't be mistaken and will
never end up on your path.

I choose /opt because if didn't seem like a bad idea; if it was, I am
very sorry. /usr/lib/gnat-3.15p (for example) would be a perfectly
good place, or /usr/local/gnat-3.15p.

You could easily then install gnatgcc and friends by symlinks in
/usr/local/bin (say).

The point of my gnatfe is to do effectively just that but in a way
that you can alter the compiler actually used by changing an
environment variable, which is effectively the prefix you built the
compiler with.

From my point of view, it means that I get the standard source tree,
apply the standard patches, configure --prefix=/opt/3.15p (say), build
& install.

I quite realize that if you're building a package for people to
install & use on the other side of the world without handholding,
things may look different!