Re: GNAT for Debian

[George Shapovalov <georges@its.caltech.edu>]

Hi Simon.

Thanks for the insights!
(It is a coincidense, but I was just reading through your page on BC
components :). I am quite new to Ada, but I really liked it this second
time when I decided to take seriously at it. Let me thank you for a nice
work!)

Simon Wright wrote:
> George Shapovalov <georges@its.caltech.edu> writes:
>> Chris M. Moore wrote:
> 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.
Yes, these are all very valid concerns. Fortunately, being a source based
distribution aimed at providing maximum possible versatility we already
faced a problem of making various versions of gcc coexist peacefully. This
forced us to do some path mangling in order to ensure that different gcc
versions do not overwrite each other and provide gcc-config utility for
users to switch the active compiler. Thus gnat peacefully enters into this
picture - users can have gnat* on their path and simultaneously have
gcc-3.x as their active compiler.

However since we are aiming at adding more ada compilers, namely cvs
snapshot of ACT tree and more may be coming, we will probably need a
similar system in place for ada compilers which will partially plug into
existing gcc versioning system we already have.


> 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.
Well, having faced FHS on many occasions :), I would say that
/usr/lib/gnat/${PV} would probably be the most compliant place (however
configure script should default to /usr/local/lib/gnat/${PV}, since local
admins are supposed to put stuff under /usr/local. Package builders can
always supply --prefix to ./configure ). The /usr/local/lib/gnat-${PV} will
also do, however if you plan on keeping multiple versions installed it
looks cleaner to separate package name and version.


> 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.
Sure, and your work is greatly appreciated!

You might also want to take a look at Gentoo build process: the package is
unpacked into a separate place (/var/tmp/portage/${pkgName-pkgVer} by
default) where all the necessary patches/sed's are applied, it is
configured and built (and installed after which it gets merged to a live
system). This is quite convenient for the developement and system
maintaince. Developer can have his isolation in a separate place, while
being able to link against live system (bundled libraries/components can
require additional flags, although most often things are split into
separate packages then). Packagers enjoy the same isolation which provides
an ability to layout package in a "right way" (TM), before actually merging
it onto a live tree.

Well, I gues my point was that you might even ease your life by having an
appropriate ebuild by your side ;). However since you need to package the
source for a wider audience I quite agree that your present approach is
simpler for a generic situation.
In any case, if you would have any questions or an idea on how we can help
each other, please do not hesitate to contact David, (who is becoming our
ada-related stuff maintainer) or me (I am overseing dev-lang in general
(mostly "alternative" stuff, i.e. no C/C++/Java :))).


> 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!
Yup, that's pretty much the idea :).

George