From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,27e56580ae0c3b7d X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-24 18:38:58 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!nntp-server.caltech.edu!not-for-mail From: George Shapovalov Newsgroups: comp.lang.ada Subject: Re: GNAT for Debian Date: Thu, 24 Jul 2003 18:39:20 -0700 Organization: Caltech Message-ID: References: <404ee0af.0307211056.15324da@posting.google.com> <20030722021229.15da08ae.david@realityrift.com> <20030722135518.32888aaa.david@realityrift.com> <20030722165245.15f880a2.david@realityrift.com> <20030723125549.1336a07f.david@realityrift.com> <20030723134949.7badd43c.david@realityrift.com> <3f1f9c07.90089321@news.greenlnk.net> <3f1fc2d7.100025238@news.greenlnk.net> <3f1ffea7.115337085@news.greenlnk.net> NNTP-Posting-Host: dhcp-38-150.caltech.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: naig.caltech.edu 1059097138 15204 131.215.38.150 (25 Jul 2003 01:38:58 GMT) X-Complaints-To: abuse@caltech.edu NNTP-Posting-Date: Fri, 25 Jul 2003 01:38:58 +0000 (UTC) User-Agent: KNode/0.7.2 Xref: archiver1.google.com comp.lang.ada:40787 Date: 2003-07-24T18:39:20-07:00 List-Id: 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 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