Re: GNAT and GNU build system

[Ludovic Brenta <ludovic.brenta@insalien.org>]

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.