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-Thread: 103376,ab5f27c42c253ac5 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!proxad.net!newsfeed1.ip.tiscali.net!tiscali!transit1.news.tiscali.nl!dreader2.news.tiscali.nl!not-for-mail Newsgroups: comp.lang.ada Subject: Re: GNAT and GNU build system References: From: Ludovic Brenta Date: Sun, 08 Aug 2004 16:45:15 +0200 Message-ID: <87n0157kp0.fsf@insalien.org> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) Cancel-Lock: sha1:VVb0JwoHZm55W2NcosddYIDzeGk= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Tiscali bv NNTP-Posting-Date: 08 Aug 2004 16:45:22 CEST NNTP-Posting-Host: 83.134.238.71 X-Trace: 1091976322 dreader2.news.tiscali.nl 62352 83.134.238.71:32771 X-Complaints-To: abuse@tiscali.nl Xref: g2news1.google.com comp.lang.ada:2628 Date: 2004-08-08T16:45:22+02:00 List-Id: Tapio Kelloniemi writes: >>Ludovic Brenta writes: >> >>> Tapio Kelloniemi writes: >>> > I would really prefer typing: >>> > ./configure --prefix=/usr --enable-goldobj >>> >>> I understand your concern completely. My concern, though, is the >>> sheer complecity of the ./configure script itself, and that of the >>> Makefile it generates. Most of that complexity is unnecessary with >>> Ada programs, and in fact really gets in the way. With Ada, you would >>> normally want to take full advantage of GNAT project files. The only >>> places where ./configure may be of help are for the installation >>> target (--prefix), and finding any Ada libraries you depend on. > > There are still things that cannot be solved with Ada, consider such > a real time programming need as memory mapped IO, which is very > non-portable. The usual way to do configuration management in Ada in these situations is to have several bodies for a single spec, and choose one body when configuring. This can be done in several ways. The GNAT way is to symlink the file containing the particular body to the canonical name. For example, one body is "5msystem.ads" and it is symlinked to "system.ads" before building. This however is done from the Makefile and does not, per se, require a configure script. Another way is to have one target-dependent directory, and pass a variable to a GNAT project file to select which target-dependent directory should be added to the Source_Dirs. A third way, used by GPS, is to write a GNAT configuration file containing configuration pragmas. The compiler-specific pragma Souce_File_Name can associate a body with the selected file. A fourth way could be to use gnatprep (like Florist does). > Configure could perhaps generate a Makefile, which runs automake > with the appropriate GNAT project file (assuming that GNAT is the > only compiler to support). The project file used could be choosed by > configure (eg. if --enable-maintainer-mode is specified, choose > debug.gpr, instead super_optimise.gpr). I would probably be better to use a single project file, and pass variables on the command line (you can have a case statement in a project file). As you can see, there is a lot you can do to influence the build. Some of this has to be done at configure time; some can be done from within the Makefile. I think that the general idea is to have a minimal configure script that only does what is strictly necessary, i.e. generates the Makefile. I do not like GNU configure because it tries to be everything to all developers, and ends up in unmaintainable and unnecessary complexity. If the Makefile can be written in a portable way, then I would prefer not to have a configure script at all (or a no-op configure script, to please people with pavlovian reflexes). -- Ludovic Brenta.