GNAT and GNU build system

GNAT and GNU build system

[Tapio Kelloniemi]

Hi

I'm planning to seriously develop free software packages in Ada. The
problem I have is GNTA's fitness for GNU program building standards.
I would like to autoconfize my project (not very bad, some M4 macros
can be found in GtkAda). But I would like to use automake (my projects
are in Ada and C, because almost every free software library is written 
in C). I also want than configure creates config.h and a gnatprep
definition file with almost the same values. And what about GNU
gettext support. I'm not an autotools expert and this might be a
wrong place to discuss this subject, but I choose CLA, because
folks here know GNAT, which autotools mailing list readers probably
don't know. If anyone has had any experience or interest regarding
this, please drop a line.

-- 
Tapio

Re: GNAT and GNU build system

[Jerome Hugues]

In article <jPRPc.888$xV7.729@reader1.news.jippii.net>, Tapio Kelloniemi wrote:
> Hi
> 
> I'm planning to seriously develop free software packages in Ada. The
> problem I have is GNTA's fitness for GNU program building standards.
> I would like to autoconfize my project (not very bad, some M4 macros
> can be found in GtkAda). But I would like to use automake (my projects
> are in Ada and C, because almost every free software library is written 
> in C). I also want than configure creates config.h and a gnatprep
> definition file with almost the same values. And what about GNU
> gettext support. I'm not an autotools expert and this might be a
> wrong place to discuss this subject, but I choose CLA, because
> folks here know GNAT, which autotools mailing list readers probably
> don't know. If anyone has had any experience or interest regarding
> this, please drop a line.

You may also give a look at AdaSockets and PolyORB. These two projects
use autoconf/automake to build their libraries. PolyORB also uses
autoconf/automake to build binaries (I don't know for AdaSockets)

AdaSockets use multiple macros to get constants from the build system,
this may help.

-- 
Jerome

Re: GNAT and GNU build system

[Lutz Donnerhacke]

* Tapio Kelloniemi wrote:
> I'm planning to seriously develop free software packages in Ada. The
> problem I have is GNTA's fitness for GNU program building standards.

You don't need that. Ada comes with portable interface definition
capabilities.

> I would like to autoconfize my project (not very bad, some M4 macros
> can be found in GtkAda). But I would like to use automake (my projects
> are in Ada and C, because almost every free software library is written
> in C).

The monkey argument is no argument f�r C.
You do not need autoconfig for Ada.

> If anyone has had any experience or interest regarding this, please drop
> a line.

I prefer redefining the standard C-header in Ada. This is necessary, but
nearly impossible, because the C-library and kernel-call interface
generated depends on the C-compiler version and flags used when compiling
the kernel and the libs.

That's why there is no generic way to automatically determine the interface
for Ada. In order to do it in a portable way you have to study the interface
deeply and redefine it in Ada yourself. Luckily the ABI does not change this
hard, but depends on CPU and OS-version.

I'd recommend a libportable written in C, generated with autoconfigure and
all those nifty workarounds about a missing interface definition. This
libportable should convert the CPP-headers into C-headers, so that
preprocessor definitions become linkable. The Ada code will be constant and
portable, because the value of the day for a system constant can be linked.

Re: GNAT and GNU build system

[Tapio Kelloniemi]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]

Lutz Donnerhacke <lutz@iks-jena.de> wrote:
>* Tapio Kelloniemi wrote:
>> I'm planning to seriously develop free software packages in Ada. The
>> problem I have is GNTA's fitness for GNU program building standards.
>
>You don't need that. Ada comes with portable interface definition
>capabilities.

Ada makes the goal of portability far less difficult than C, but 
autoconf can help detecting some portability issues on the build
system and it has other advantages as well:
Configure is easy for users and autoconf is easier for programmers 
than writing some huge scripts which do many things exactly like 
configure. It is just waste of time. Implementing all those --prefix, 
--*dir arguments in portable sh so that users can install stuff where 
they want to and writing the million makefile targets which GNU Coding 
Standards require is of course possible, but easier with autotools.

>> I would like to autoconfize my project (not very bad, some M4 macros
>> can be found in GtkAda). But I would like to use automake (my projects
>> are in Ada and C, because almost every free software library is written
>> in C).
>
>The monkey argument is no argument f�r C.

It is not nice at all to translate dozens of headers into Ada, just
to notice, that the implementation has changed for those external 
libraries in next version. Unfortunately C is not very portable and
people heavily use preprocessor (even to implement inline functions).
So C headers are not purely interface definitions.

>You do not need autoconfig for Ada.
It is a de facto standard in free software.

-- 
Tapio

Re: GNAT and GNU build system

[Mark H Johnson]

Tapio Kelloniemi wrote:
> Lutz Donnerhacke <lutz@iks-jena.de> wrote:
[snip]

>>You do not need autoconfig for Ada.
> 
> It is a de facto standard in free software.
> 
I respectively disagree and provide a few examples:
  Nethack - http://www.nethack.org/
Nethack has been around for a long time as a free software product and 
does not use autoconf or similar tools. The software is portable to a 
number of platforms (including several non-Unix platforms). A few have 
generated autoconf files and offered them to the development team, but 
they have not been accepted into the baseline.

   X applications - http://www.x.org/
X has had its own configuration system for a long time as well. The 
principle of using "make World" to build applications goes pretty deep 
and across a number of platforms.

   Apache - http://www.apacheweek.com/issues/98-04-03
Somewhat of a surprise to me, but it states about half way down that 
Apache does not use autoconf to configure the build process. Not quite 
sure what that means in detail, but an interesting note.

Just because autoconf / automake are popular with some free software 
products does not make it a "defacto standard". You may also find the 
issue of portability in Ada can be handled in a more straight forward 
manner as well. Certainly, the people at ACT who maintain GNAT have 
given this careful consideration since they are the ones supporting GNAT 
on a wide range of platforms. If they (or their customers paying the 
bills) thought it was necessary to provide autoconf support, they would 
have done so.

   --Mark

Re: GNAT and GNU build system

[Georg Bauhaus]

Mark H Johnson <mark_h_johnson@raytheon.com> wrote:
: Just because autoconf / automake are popular with some free software 
: products does not make it a "defacto standard".

Yea. In addition, the moment you have to deviate only slightly
from what the automake users have thought of in advance, it becomes
an automess. (BTDT many times, auto*/configure has a very low
threshold for the arousal of anger in non-standard(!) environments.
All the more when a bunch of dependences is unnecessary
and only caused be a miminal-effort lazy automake setup.)

GNAT, or IOW the Ada part of GCC, has a way of automatically knowing
about Ada libraries, through the contents of ada_*_path files in the
installation directories.

In my view the automake phenomenon (a euphemism) works very similar
to a selffulfilling prophecy. ("Just install GNU and a number of
scripting languages on your system, the latest versions, please,
and then run autoxyz, you can then compile the software. See how
nice it works? Oh, there is no GNU on your system? Well... uhm,
you can also have a prebuilt hassle-free binary...")

If a multitude of C libraries cannot be built without
autotools, I don't see many reasons why this should be made
true of Ada libraries as well. 
(Another example of a configure-free C library is the RXP
validating XML parser.)

On a related issue, many (young?) programmers seem to think
that #ifdef _THIS_HEADER_ is a good thing. OTOH, the UNIX gurus
who have also made Plan 9 and related programs have avoided this
style of programming.
I think that working on removing #ifdefs from C files will
do good to almost every C program. The same is true if you
put some effort into a program that can be easily configured
without autotools. The time needed will come back later, many
times. (At least this has been my experience.)

GNU Make is a useful tool, even more so if the Makefile (singular)
is small.


-- Georg

Re: GNAT and GNU build system

[Ludovic Brenta]

I also tend to think that autoconf and automake are poor hacks meant
to circumvent the deficiencies of C; just like make in fact.  However,
I see one situation where it makes sense to use them in Ada, and that
is when you want to build a binding to a C library that has
platform-dependent parts.  This is best illustrated by Florist, which
has a rather convoluted build process:

1) It uses configure to generate a Makefile and a config.h
2) The Makefile compiles a number of C source files, and links them into
   an executable, named c-posix
3) The Makefile executes c-posix, which writes a gnatprep configuration
   file and a C file, c-posix-signals.c
4) The Makefile runs gnatprep, with the configuration file, to generate
   several Ada files
5) The Makefile compiles and links c-posix-signals.c
6) Executes c-posix-signals, which creates posix_signals.ads
7) Compiles all the Ada files
8) Links the compiled files into a library

See http://buildd.debian.org/fetch.php?&pkg=libflorist-3.15p-1&ver=3.15p-3&arch=sparc&stamp=1069154570&file=log&as=raw

But the conclusion I draw from all this is: do your very best to avoid
such a complicated build process if possible!  Unless you are
interfacing to the operating system, there is very little reason to
use the autotools.  GNAT and Florist together should provide you all
the portability you need (and yes, GNAT does use autoconf/automake,
because GCC does).

-- 
Ludovic Brenta.

Re: GNAT and GNU build system

[Tapio Kelloniemi]

Mark H Johnson <mark_h_johnson@raytheon.com> wrote:
>Tapio Kelloniemi wrote:
>> Lutz Donnerhacke <lutz@iks-jena.de> wrote:
>[snip]
>
>>>You do not need autoconfig for Ada.
>>
>> It is a de facto standard in free software.
>>
>I respectively disagree and provide a few examples:
>  Nethack - http://www.nethack.org/
>Nethack has been around for a long time as a free software product and
>does not use autoconf or similar tools. The software is portable to a
>number of platforms (including several non-Unix platforms). A few have
>generated autoconf files and offered them to the development team, but
>they have not been accepted into the baseline.

And they really should accept even the poorest one. Almost the first
thing that I install on new systems is NetHack and I have to say that it 
is the most horrible thing to configure I have ever found. To build it, 
one must first edit two or three header files. One must know if their C 
compiler has some particular bugs and specify installation directories 
in multiple places (and making a mistake and put a different directory 
somewhere results in disaster). Then is the job of editing three 
Makefiles which contain a huge list of which one must choose the 
compiler to use, flags for the compiler and linker, libraries to link 
against... And all this twice plus the top-level makefile with the same 
directories again... This all takes sometimes an hour, I would really 
prefer typing:
./configure --prefix=/usr --enable-goldobj

>Just because autoconf / automake are popular with some free software
>products does not make it a "defacto standard". You may also find the
>issue of portability in Ada can be handled in a more straight forward
>manner as well.

If this is that I have to tell in Makefile or in Ada project file or 
anything, that my version of non-blocking spawn in gnat library really 
is non-blocking and is not just a portability wrapper, well, it would
take a lot of time.
If all packages were configured differently (like NetHack and X) 
building
an operating system from source code (http://www.linuxfromscratch.org) 
would take a month instead of few days.

>Certainly, the people at ACT who maintain GNAT have given this careful 
>consideration since they are the ones supporting GNAT
>on a wide range of platforms. If they (or their customers paying the
>bills) thought it was necessary to provide autoconf support, they would
>have done so.

Customer who pay such a big bills don't _generally_ share their source 
code on Internet.

-- 
Tapio

Re: GNAT and GNU build system

[Tapio Kelloniemi]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:
>Mark H Johnson <mark_h_johnson@raytheon.com> wrote:
>: Just because autoconf / automake are popular with some free software
>: products does not make it a "defacto standard".
>
>Yea. In addition, the moment you have to deviate only slightly
>from what the automake users have thought of in advance, it becomes
>an automess. (BTDT many times, auto*/configure has a very low
>threshold for the arousal of anger in non-standard(!) environments.

Building some non-autoconfized projects with custom compiler flags 
almost requires a full rewrite of their huge Makefile suites.

>All the more when a bunch of dependences is unnecessary
>and only caused be a miminal-effort lazy automake setup.)
>
>GNAT, or IOW the Ada part of GCC, has a way of automatically knowing
>about Ada libraries, through the contents of ada_*_path files in the
>installation directories.

GCC itself has a specs file which contains default include directories 
and ld has /etc/ld.so.conf file on Unix.
If GNAT would use these, writing these extra files (and changing them 
whenever GCC is updated) is just more silly effort.

>In my view the automake phenomenon (a euphemism) works very similar
>to a selffulfilling prophecy. ("Just install GNU and a number of
>scripting languages on your system, the latest versions, please,
>and then run autoxyz, you can then compile the software. See how
>nice it works? Oh, there is no GNU on your system? Well... uhm,
>you can also have a prebuilt hassle-free binary...")

First, building software does not require these autotools to be 
installed, it is the whole point of them. Secondly configure and 
automake generated Makefiles only use the tools that are the most common 
(they don't even suppose that mkdir -p works correctly). When GNU 
programs are required are the situations were all other implementations 
are silly or just incompatible with each others in way that cannot be 
resolved easily. It is the responsib9ility of the package provider, not 
to generate dependicies to the scripting languages you mentioned. The 
ones which are sometimes needed are awk and Perl and sh of course.

>If a multitude of C libraries cannot be built without
>autotools, I don't see many reasons why this should be made
>true of Ada libraries as well.

I can't see why the aproach, "install this to /usr/ADALIBRARY and adjust 
your ada_*_paths and environment variables, or copy your files by hand 
and oops, the paths were hardwired", would be better than running 
configure.

>On a related issue, many (young?) programmers seem to think
>that #ifdef _THIS_HEADER_ is a good thing. OTOH, the UNIX gurus
>who have also made Plan 9 and related programs have avoided this
>style of programming.
>I think that working on removing #ifdefs from C files will
>do good to almost every C program. The same is true if you
>put some effort into a program that can be easily configured
>without autotools. The time needed will come back later, many
>times.

Perhaps, but learning a separate configuration method for each lib and 
app is a hell to a system administrator. Somebody might like a GUI 
configuration tool and developer will use weeks to get it working on 
every platform, but somebody would like to run a script and see their
system built.

-- 
Tapio

Re: GNAT and GNU build system

[Ludovic Brenta]

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.

<plug mode=shameless>

This problem is solved nicely in Debian GNU/Linux.  Each library has a
GNAT project file in a well-known location
(/usr/share/ada/adalib/library.gpr).  Your program just "withs" them
as required.

</plug>

Furthermore, on non-Debian systems, the GNU Ada Environment
Specification[1] says where library files should be installed.  Here
again, you would not need a ./configure at all; just use -aI and -aO
as necessary.

<plug mode="really_shameless">

Since Debian follows the GNAE, your GNAT project file can be portable
without the need for ./configure.

</plug>

[1] http://cert.uni-stuttgart.de/projects/ada/gnae.php

So, you could consider writing a ./configure script by hand, which
would generate a minimal Makefile containing only the value of
--prefix.  Something along the lines of:

PREFIX=/usr

all: my_program

my_program:
        gnatmake -Pmy_program.gpr

install: my_program
        cp my_program $(PREFIX)/bin

If you need package-specific options (e.g. --enable-gold-objects),
then you can extend the ./configure and generate something like:

PREFIX=/usr
GOLD_OBJECTS=false

all: my_program

my_program:
        gnatmake -Pmy_program.gpr -XGOLD_OBJECTS=$(GOLD_OBJECTS)

install: my_program
        cp my_program $(PREFIX)/bin

-- 
Ludovic Brenta.

Re: GNAT and GNU build system

[Stephen Leake]

Tapio Kelloniemi <spam12@thack.org> writes:

> Hi
> 
> I'm planning to seriously develop free software packages in Ada. The
> problem I have is GNTA's fitness for GNU program building standards.
> I would like to autoconfize my project (not very bad, some M4 macros
> can be found in GtkAda). But I would like to use automake (my projects
> are in Ada and C, because almost every free software library is written 
> in C). 

Sounds reasonable. Others have said "you don't need autmake with Ada".
That's almost true, but any _real_ project also has tests,
documentation, and distribution needs which are beyond Ada's scope.
autoconf/automake help with those tasks, and Ada needs to at least
cooperate.

I'm using automake in an Ada project (a GtkAda interface to a books
database). It's not ready for prime time yet, but I'd be happy to
exchange notes about autoconf use.

-- 
-- Stephe

Re: GNAT and GNU build system

[Stephen Leake]

Ludovic Brenta <ludovic.brenta@insalien.org> 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.

This is true. So we need to start generating patches to auto* that
take advantage of Ada's simplicity. Not an easy task, but in the long
run it is the right solution.

Hmm. Maybe rewriting auto* in Ada first would be easier; I'm not
sure :).

> <plug mode=shameless>
> 
> This problem is solved nicely in Debian GNU/Linux.  Each library has a
> GNAT project file in a well-known location
> (/usr/share/ada/adalib/library.gpr).  Your program just "withs" them
> as required.

That sounds good. But Ada still needs to cooperate with autoconf.

> Furthermore, on non-Debian systems, the GNU Ada Environment
> Specification[1] says where library files should be installed.  Here
> again, you would not need a ./configure at all; just use -aI and -aO
> as necessary.

Only if you have a pure Ada project. I find this unlikely; I like
LaTeX or Texinfo for documentation, and I want my makefiles to run
test drivers.

> Since Debian follows the GNAE, your GNAT project file can be portable
> without the need for ./configure.

That's good.

-- 
-- Stephe

Re: GNAT and GNU build system

[Georg Bauhaus]

Tapio Kelloniemi <spam12@thack.org> wrote:
 
: Building some non-autoconfized projects with custom compiler flags 
: almost requires a full rewrite of their huge Makefile suites.

If you look at a program like RXP, there is very little in
the Makefile that needs to be adjusted, if anything at all.
If an Ada library isn't very system-specific, I wonder why it
should test all sorts of things using quite a few Unix-centric
testing tools?

If it is a library for mass computers, I find it very likely
that requirements like
"we need a C90 compiler and integer size of 32 bits"
"we need an Ada 95 compiler"
are a lot more helpful than test programs that try to find
out whether some vintage C issue can be handled.

Is it helpful to write software that runs a large configure
job in order to find out things like whether some non-ANSI C
Unix function works properly? (Hey, it is 5% faster than the
ANSI C function so we want to use it even in outer loops,
or for our infrequent disk access.)

 
: GCC itself has a specs file which contains default include directories 
: and ld has /etc/ld.so.conf file on Unix.
: If GNAT would use these, writing these extra files (and changing them 
: whenever GCC is updated) is just more silly effort.

But ld.so.conf is not about sources? Some Ada libraries
are built so they can be used for dynamic linking.

The standard include paths for the Ada part needs not be
adjusted. Same as C.
 But if you want to, or have to, use two different
versions of a non-standard library? I wouldn't want to create a
mess using GCC's spec files.

configure is very convenient then, if it works.
How does it work in non-standard situations?
Am I right in assuming that the average Free Software developer
tries to delegate software configuration efforts to autotools
instead of trying to make the design more amenable to platform
changes?


: First, building software does not require these autotools to be 
: installed, it is the whole point of them.

I have come across more than one configure script
that was just wrong because it had been built around assumptions
(For example assuming that a command is just one word).
And the point you mention is sometimes neglected. Some things
wont work with just configure.


: Secondly configure and 
: automake generated Makefiles only use the tools that are the most common 
: (they don't even suppose that mkdir -p works correctly).

Why do configure scripts use so many sh features in the first place?
A construct like
var=`cmd | sed rx`
when a simple expr would do. Pipes in the background (requires
a shell with job control and Unix process creation) when simple
file redirections and simple piping would do?

Or if you look at the huge config.guess, why all this, why so many
Unix specific processes and pipes just to guess a string like
"i123-pc-linol-gna"?  When I tried to compile some Unix program
on a very Non-Unix system, the best thing I could do with
config.guess was to replace it with a 1-liner that just
echo "i123-pc-linol-gna".


: When GNU 
: programs are required are the situations were all other implementations 
: are silly or just incompatible with each others in way that cannot be 
: resolved easily. It is the responsib9ility of the package provider, not 
: to generate dependicies to the scripting languages you mentioned.

I wish there were more traces of responsibility in packaging.
My impression is that many package providers don't strive for
minimal dependence.

One example is Gtk(Ada) on Debian testing (I'm not speaking about
Ludovic's efforts to provide a very good Ada developement platform).
Some pixel oriented stuff in Gtk seems to require that a lot of GNOME
be installed, somewhat more than the infrastructure
including a broker. If you want just the GUI portion of Gtk,
bad luck.

 Speaking of de facto, the current Debian testing build
dependences of a font transformation program written in C indirectly
drag in Python and OCaml via a specific version of autoconf's build
dependeces (iirc).
Nice languages, but the specific versions are not easy to compile
if you have a Debian stable and not a testing. (No backport available.)
This is not because the font transformation program's source code
requires that the compiler be checked. But the number of libraries
needed is high, and there is a new Debian build system that is
assumed by the tools that the maintainer of the font program
has used, and recursively so.
This accumulates the transitive closure of dependences. Which is
rarely noticed because the developers usually work with their own
machine with everything installed it seems.

On what basis do developers specify the version number of
libraries needed? For example, GNU awk currently
depends on the GNU C library >= 2.3.2 on Debian. And the GNU C
library depends on the Berkeley DB routines for compatibility
reasons (this alone is interesting).  The DB routines again
depend on the GNU C library >= 2.2.5...
But does this mean that GNU awk cannot be built with the GNU C
library version 2? What good is the ANSI C library if text
processing tool maintainers specify, possibly not knowing that
they do, that a recent version of a huge C library is needed?

Can configure assist in avoiding this kind of version number
and tools dependence?



:>If a multitude of C libraries cannot be built without
:>autotools, I don't see many reasons why this should be made
:>true of Ada libraries as well.
: 
: I can't see why the aproach, "install this to /usr/ADALIBRARY and adjust 
: your ada_*_paths and environment variables, or copy your files by hand 
: and oops, the paths were hardwired", would be better than running 
: configure.

Can configure figure out which of the two versions of the
X library and which configuration of the Y library I wish
to use for this build? After all, if I use a standard setup,
I can as well use carefully built trusted binaries.

I guess configure is popular because it makes people think they
have configured their software easily. They haven't at all, they
have trusted others who before them have tried to put lots of
effort into assuming and checking. Luckily, it works on their
system too. Hmmm.
The "It works" is sometimes rephrased "We are pragmatic"
to cover an adventurous development strategy...

Just imagine there were not thousands of people trying to
configure some piece of Free Software. Would a handful of
programmers succeed in porting the software?


 
: learning a separate configuration method for each lib and 
: app is a hell to a system administrator.

BTDT. OTOH why do system administrators build software at all
and do not install prebuilt binary with heavenly ease?
For example because there is a company style of administering
software. But then, can a library maintainer anticipate this
company's style when collecting information for auto/conf/igure?

: Somebody might like a GUI 
: configuration tool and developer will use weeks to get it working on 
: every platform,

This I think is a dream. A configuration tool that works on
every platform has not seen many platforms I guess :-)


-- Georg

Re: GNAT and GNU build system

[Tapio Kelloniemi]

Stephen Leake <stephen_leake@acm.org> wrote:
From: Tapio Kelloniemi <spam12@thack.org>
Subject: Re: GNAT and GNU build system
Organization: 
References: <mailman.65.1091657194.416.comp.lang.ada@ada-france.org>
Newsgroups: comp.lang.ada
Summary: 
Keywords: 

Stephen Leake <stephen_leake@acm.org> wrote:
>Tapio Kelloniemi <spam12@thack.org> writes:
>
>> Hi
>>
>> I'm planning to seriously develop free software packages in Ada. The
>> problem I have is GNTA's fitness for GNU program building standards.
>> I would like to autoconfize my project (not very bad, some M4 macros
>> can be found in GtkAda). But I would like to use automake (my projects
>> are in Ada and C, because almost every free software library is written
>> in C).
>
>Sounds reasonable. Others have said "you don't need autmake with Ada".
>That's almost true, but any _real_ project also has tests,
>documentation, and distribution needs which are beyond Ada's scope.
>autoconf/automake help with those tasks, and Ada needs to at least
>cooperate.

And I think that autotools should also cooperate. FSF says that free 
software packages in GNU system should cooperate with others. Luckily 
GNAT is part of GNU project and I think autotools writers could very 
well take a step towards Ada from the complete C centricism. (This C 
centricism is unfortunately accepted by GNU projet and very 
unfortunately even required by the GNU coding standards.)

>Ludovic Brenta <ludovic.brenta@insalien.org> 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.

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).

>This is true. So we need to start generating patches to auto* that
>take advantage of Ada's simplicity. Not an easy task, but in the long
>run it is the right solution.

Note that auto* maintainers are not allowed to accept our patches (if 
longer than few lines), if writer doesn't sign a paper that he doesn't 
own the code (this is the FSF's requirement). I really think that this 
should be doen in tight cooperation with the GNU developers, because 
they have deep knowledge of their tools and we have that of ours.

>Hmm. Maybe rewriting auto* in Ada first would be easier; I'm not
>sure :).

I think that using GNU tools is a good idea not to couple efforts. Pure 
Ada version would of course be easier, but in mixed language projects, 
tools such as autoscan, autoheader and others are also needed.

Things that think should be done to auto* are:
- Autoconf should be able to generat egnatprep definition files, perhaps 
from template like config.adp.in:
-- Define this to the full package name.
PACKAGE := @PACKAGE@

-- Define this to true, if libfoo support should be included.
HAVE_libFOO := @LIBFOO_SUPPORT@

Better even could be that configure would generate this from scratch.

- Automake should be able to compile ada programs (in a way or another).
- Automake should know how to install Ada libraries (unfortunately 
  installing .so and header is not enough.)
- Libtool (never used, don't know what  should be done to it)
- Gettext and autopoint (gettext should be able to scan Ada sources for 
  strings)

>Only if you have a pure Ada project. I find this unlikely; I like
>LaTeX or Texinfo for documentation, and I want my makefiles to run
>test drivers.

You speak truly. Because almost every library is written in C,
C interfacing is required, as ugly and unwanted as it is. It is very often
better to share than write giant size programs which introduce bugs,
because somebody understood something incorrectly.

-- 
Tapio

Re: GNAT and GNU build system

[Stephen Leake]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Tapio Kelloniemi <spam12@thack.org> wrote:
>  
> : Building some non-autoconfized projects with custom compiler flags 
> : almost requires a full rewrite of their huge Makefile suites.
> 
> If you look at a program like RXP, there is very little in
> the Makefile that needs to be adjusted, if anything at all.

That's good.

> If an Ada library isn't very system-specific, I wonder why it should
> test all sorts of things using quite a few Unix-centric testing
> tools?

It shouldn't.

> If it is a library for mass computers, I find it very likely that
> requirements like "we need a C90 compiler and integer size of 32
> bits" "we need an Ada 95 compiler" are a lot more helpful than test
> programs that try to find out whether some vintage C issue can be
> handled.

That's true. But configure only runs the tests that you tell it to
run.

> Is it helpful to write software that runs a large configure job in
> order to find out things like whether some non-ANSI C Unix function
> works properly? (Hey, it is 5% faster than the ANSI C function so we
> want to use it even in outer loops, or for our infrequent disk
> access.)

No, it is not helpful. So in your configure script for your Ada
project, don't run those tests.

> : GCC itself has a specs file which contains default include
> : directories and ld has /etc/ld.so.conf file on Unix. If GNAT would
> : use these, writing these extra files (and changing them whenever
> : GCC is updated) is just more silly effort.
> 
> But ld.so.conf is not about sources? Some Ada libraries
> are built so they can be used for dynamic linking.
> 
> The standard include paths for the Ada part needs not be
> adjusted. Same as C.
>  But if you want to, or have to, use two different
> versions of a non-standard library? I wouldn't want to create a
> mess using GCC's spec files.

Right. Configure is a better solution.

> configure is very convenient then, if it works. How does it work in
> non-standard situations? 

You'll have to define what you mean by "standard" here.

> Am I right in assuming that the average Free Software developer
> tries to delegate software configuration efforts to autotools
> instead of trying to make the design more amenable to platform
> changes?

I have no idea about the "average" Free Software developer. I know I
try to stick to portable standards.

> : First, building software does not require these autotools to be
> : installed, it is the whole point of them.
> 
> I have come across more than one configure script
> that was just wrong because it had been built around assumptions
> (For example assuming that a command is just one word).
> And the point you mention is sometimes neglected. Some things
> wont work with just configure.

Then they are broken. People write broken software all the time. That
doesn't mean the idea of configure is wrong.

> : Secondly configure and automake generated Makefiles only use the
> : tools that are the most common (they don't even suppose that mkdir
> : -p works correctly).
> 
> Why do configure scripts use so many sh features in the first place?
> A construct like
> var=`cmd | sed rx`
> when a simple expr would do. Pipes in the background (requires
> a shell with job control and Unix process creation) when simple
> file redirections and simple piping would do?

Yes, Gnu configure assumes Gnu bash. You have to start somewhere!
Should configure work if the shell is VAX DCL?

> Or if you look at the huge config.guess, why all this, why so many
> Unix specific processes and pipes just to guess a string like
> "i123-pc-linol-gna"? When I tried to compile some Unix program on a
> very Non-Unix system, the best thing I could do with config.guess
> was to replace it with a 1-liner that just echo "i123-pc-linol-gna".

What is a better solution? Note that config.guess is a _guess_. The
user can always specify the correct host string on the configure
command line.

> : When GNU 
> : programs are required are the situations were all other implementations 
> : are silly or just incompatible with each others in way that cannot be 
> : resolved easily. It is the responsib9ility of the package provider, not 
> : to generate dependicies to the scripting languages you mentioned.
> 
> I wish there were more traces of responsibility in packaging.
> My impression is that many package providers don't strive for
> minimal dependence.
> 
> One example is Gtk(Ada) on Debian testing (I'm not speaking about
> Ludovic's efforts to provide a very good Ada developement platform).
> Some pixel oriented stuff in Gtk seems to require that a lot of GNOME
> be installed, somewhat more than the infrastructure
> including a broker. If you want just the GUI portion of Gtk,
> bad luck.

Hmm. I have not found that to be true, but maybe you are talking about
a more recent version of Gtk.

>  Speaking of de facto, the current Debian testing build dependences
> of a font transformation program written in C indirectly drag in
> Python and OCaml via a specific version of autoconf's build
> dependeces (iirc). Nice languages, but the specific versions are not
> easy to compile if you have a Debian stable and not a testing. (No
> backport available.) This is not because the font transformation
> program's source code requires that the compiler be checked. But the
> number of libraries needed is high, and there is a new Debian build
> system that is assumed by the tools that the maintainer of the font
> program has used, and recursively so. This accumulates the
> transitive closure of dependences. Which is rarely noticed because
> the developers usually work with their own machine with everything
> installed it seems.

Yes, maintaining complex systems is complex. What is a better solution?

> On what basis do developers specify the version number of libraries
> needed? For example, GNU awk currently depends on the GNU C library
> >= 2.3.2 on Debian. And the GNU C library depends on the Berkeley DB
> routines for compatibility reasons (this alone is interesting). The
> DB routines again depend on the GNU C library >= 2.2.5... But does
> this mean that GNU awk cannot be built with the GNU C library
> version 2? What good is the ANSI C library if text processing tool
> maintainers specify, possibly not knowing that they do, that a
> recent version of a huge C library is needed?
> 
> Can configure assist in avoiding this kind of version number
> and tools dependence?

Probably not; that's what the package management system is for.

Configure can specify what versions are needed by a particular build.

> :>If a multitude of C libraries cannot be built without autotools, I
> :>don't see many reasons why this should be made true of Ada
> :>libraries as well.
> : 
> : I can't see why the aproach, "install this to /usr/ADALIBRARY and adjust 
> : your ada_*_paths and environment variables, or copy your files by hand 
> : and oops, the paths were hardwired", would be better than running 
> : configure.
> 
> Can configure figure out which of the two versions of the
> X library and which configuration of the Y library I wish
> to use for this build? After all, if I use a standard setup,
> I can as well use carefully built trusted binaries.

Yes, configure can look for a specific version of a library.

> I guess configure is popular because it makes people think they
> have configured their software easily. 

Not true in my case. I use configure because it solves a very hard
problem, in a widely accepted and supported way.

> They haven't at all, they have trusted others who before them have
> tried to put lots of effort into assuming and checking. 

What is wrong with that? The same can be said of an Ada 95 compiler; I
use it because others have put a lot of work into it.

> Luckily, it works on their system too. Hmmm. The "It works" is
> sometimes rephrased "We are pragmatic" to cover an adventurous
> development strategy...

You are being overly pessimistic. 

> Just imagine there were not thousands of people trying to configure
> some piece of Free Software. Would a handful of programmers succeed
> in porting the software?

There are not thousands of people trying to configure my books package
(I have not released it yet). But I have succeeded in using configure
with it. What is your point?

> : learning a separate configuration method for each lib and app is a
> : hell to a system administrator.
> 
> BTDT. 

Good for you. Was it fun? Would you prefer a single standard configure
system?

> OTOH why do system administrators build software at all and do not
> install prebuilt binary with heavenly ease? 

That is not always possible. Source is far more flexible than binary.

> For example because there is a company style of administering
> software. But then, can a library maintainer anticipate this
> company's style when collecting information for auto/conf/igure?

Obviously not. That's why source is more flexible than binary.

> : Somebody might like a GUI 
> : configuration tool and developer will use weeks to get it working on 
> : every platform,
> 
> This I think is a dream. A configuration tool that works on
> every platform has not seen many platforms I guess :-)

Configure works on more platforms than any competing system I'm aware
of. 

Apparently you don't like Gnu configure. But you have not proposed an
actual replacement tool. Which configure tool do you think we should
use? Be sure it solves all of the problems that Gnu configure does!

-- 
-- Stephe

Re: GNAT and GNU build system

[Georg Bauhaus]

Stephen Leake <stephen_leake@acm.org> wrote:
: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
: 
:> Tapio Kelloniemi <spam12@thack.org> wrote:
:>  
:> : Building some non-autoconfized projects with custom compiler flags 
:> : almost requires a full rewrite of their huge Makefile suites.
:> 
:> If you look at a program like RXP, there is very little in
:> the Makefile that needs to be adjusted, if anything at all.
: 
: That's good.
: 
:> If an Ada library isn't very system-specific, I wonder why it should
:> test all sorts of things using quite a few Unix-centric testing
:> tools?
: 
: It shouldn't.
: 
:> If it is a library for mass computers, I find it very likely that
:> requirements like "we need a C90 compiler and integer size of 32
:> bits" "we need an Ada 95 compiler" are a lot more helpful than test
:> programs that try to find out whether some vintage C issue can be
:> handled.
: 
: That's true. But configure only runs the tests that you tell it to
: run.
: 
:> Is it helpful to write software that runs a large configure job in
:> order to find out things like whether some non-ANSI C Unix function
:> works properly? (Hey, it is 5% faster than the ANSI C function so we
:> want to use it even in outer loops, or for our infrequent disk
:> access.)
: 
: No, it is not helpful. So in your configure script for your Ada
: project, don't run those tests.
: 
:> : GCC itself has a specs file which contains default include
:> : directories and ld has /etc/ld.so.conf file on Unix. If GNAT would
:> : use these, writing these extra files (and changing them whenever
:> : GCC is updated) is just more silly effort.
:> 
:> But ld.so.conf is not about sources? Some Ada libraries
:> are built so they can be used for dynamic linking.
:> 
:> The standard include paths for the Ada part needs not be
:> adjusted. Same as C.
:>  But if you want to, or have to, use two different
:> versions of a non-standard library? I wouldn't want to create a
:> mess using GCC's spec files.
: 
: Right. Configure is a better solution.

Sometimes yes, but not always I think.
How would you specify a version of the library per build?
Maybe,

  --with-this-library=/path/to/library_version

creating a copy of "project.gpr" with this library path?
This can add a familiar configuration interface to the process,
provided GNAT project files are used. Or provided GNAT is used, for
that matter. If someone has an Aonix compiler installed,
GNAT project files are less helpful, so we'd have another decision,
to be made by configure.
2**--options, and an additional level of indirection caused by not
directly using the configuration tools provided by the producers
of the respective compilers.  Someone will have to work hard
to make this work. :-)


:> configure is very convenient then, if it works. How does it work in
:> non-standard situations? 
: 
: You'll have to define what you mean by "standard" here.

The configure tools have to assume a certain environment,
in addition to GNU. Gtk comes with a script that has been
set up with the typical GNU commandline interface in mind,
spitting out a number of command line options -- for GNU
build tools.
If I want some software library to be well integrated with
GNU tools, the GNU build process execises a slight social
pressure to provide facilities that have emerged with
configure. That is, configure becomes a social standard,
with technical consequences. (A la "If is works with the GNU
tools, it is configurable software.")


: Then they are broken. People write broken software all the time. That
: doesn't mean the idea of configure is wrong.

It is true that configure scripts are just programs, and programs can
fail. (They can for example fail to be the result of a requirements
analysis. :-) It might however be much more work to hunt bugs in
automatically created configure scripts than setting a few
variables in a Makefile.


: Yes, Gnu configure assumes Gnu bash. You have to start somewhere!
: Should configure work if the shell is VAX DCL?

Not only is bash assumed, but Unix sh features are used extensively
even where that is not needed. I find this OK in a Unix environment,
and it may also work in Unix emulations like cygwin. But I cannot
see how this is the best option for configuring software other than
Unix specific software.


:> Or if you look at the huge config.guess, why all this, why so many
:> Unix specific processes and pipes just to guess a string like
:> "i123-pc-linol-gna"? When I tried to compile some Unix program on a
:> very Non-Unix system, the best thing I could do with config.guess
:> was to replace it with a 1-liner that just echo "i123-pc-linol-gna".
: 
: What is a better solution?

An interactive one.
"What kind of processor do you have?
[1] Intel 386 or above
[2] Motorola 68030 or above
[3] Alpha 21xxx
[4] Power PC 604 or later

etc. This kind of user interaction is possible on very many
systems without the need to install a set of additional tools.


: Yes, maintaining complex systems is complex. What is a better solution?

What is it in autotools that results in so many build dependences?
Misuse? Laziness?
Some of complexitiy can be explained in terms of indirection.
I have found that in cases only a fraction of the funcitonality
provided by some tool was needed, but this tiny fraction drags
in a number of tools needed by the first tool, and then these
tools continue to add more needs. In sum you can end up installing
half of the dependence graph of the whole development system,
because that tool found a fraction of another tool helpful.



: Yes, configure can look for a specific version of a library.

In the sense that a specific version of a library is just some
library, iirc. How does it distinguish versions of AI302 translated
with different compiler options?



: I use configure because it solves a very hard
: problem, in a widely accepted and supported way.

Do you use it for Ada sources or for the C/LaTeX related parts?

:> They haven't at all, they have trusted others who before them have
:> tried to put lots of effort into assuming and checking. 
: 
: What is wrong with that? The same can be said of an Ada 95 compiler; I
: use it because others have put a lot of work into it.

Nothing wrong with trusting others' work.
However, in case of configure it leads to assumptions that in my
experience are far less justifiably than when you assume that
an Ada compiler is an Ada compiler.
What I meant was that people do not seem to be aware of what
they are doing when they run ./configure: they are not doing
the hard work that is needed to configure software.


:> Luckily, it works on their system too. Hmmm. The "It works" is
:> sometimes rephrased "We are pragmatic" to cover an adventurous
:> development strategy...
: 
: You are being overly pessimistic. 

This may be true, but someone has got to be pessimistic.
(In addition, this makes it easier to live with the usual
"surprises" :-)

 
:> : learning a separate configuration method for each lib and app is a
:> : hell to a system administrator.
:> 
:> BTDT. 
: 
: Good for you. Was it fun? Would you prefer a single standard configure
: system?

It has been a tedious job to read all sorts of makefiles, README file,
etc., then download library sources, install libraries, etc, in a
breadth first manner. So a system tool like Debian's would have been
helpful. But configure? I have had to use the configuration facilities
provided with the software. Installing sendmail for example required
m4, make, and some reading.  It wasn't much harder than colliction
the proper selection of --options for configure.

: Configure works on more platforms than any competing system I'm aware
: of. 

Yes.
 
: Apparently you don't like Gnu configure. But you have not proposed an
: actual replacement tool. Which configure tool do you think we should
: use? Be sure it solves all of the problems that Gnu configure does!

It is not GNU configure that I don't like.
What I do not like is the laziness of programmers producing the
configure programs. (My own software has a configure, too, for
two reasons:
1/  everyone expects configure to be present
2/  it needs to do very little.
The configure program is not "automatically" created. (The
one that comes with OCaml isn't either. :-)
As you have explained, it takes time and effort to produce
a good configure script. "Just don't run those tests" is excellent
advice, but it is work to achieve this valuable goal.


What I do not like is the sloppiness in stating dependences.
Does a video stream viewer need to list GNOME in the set of
things it depends on when in fact the viewer can be run from
the command line and GNOME support is just an option?
But somehow I think that many developers using autotools
do not try to make the number of things needed a small number.


-- Georg

Re: GNAT and GNU build system

[Ludovic Brenta]

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.

Re: GNAT and GNU build system

[Nick Roberts]

On Sun, 08 Aug 2004 16:45:15 +0200, Ludovic Brenta  
<ludovic.brenta@insalien.org> wrote:

> 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.

I think I might be repeating what someone has already said, but Ada
itself provides a way of doing this, via renamings (which is what
a symlink is, in essence).

If your program has a set of packages (say My.Foo, My.Bar, and My.Hum)
which all have different bodies corresponding to three different
configurations (say A, B, and C), then you could write nine packages
(My.Foo_for_A, My.Foo_for_B, ..., My.Hum_for_C), and put three
renamings into each of three files (named, say, "config_x.ada") as
part of the library for configuration x as follows:

    package My.Foo renames My.Foo_for_x;
    package My.Bar renames My.Bar_for_x;
    package My.Hum renames My.Hum_for_x;

and then all other source text in the program can simply refer to
My.Foo, My.Bar, and My.Hum.

To recompile with a different configuration, you only have to change
one file in the compilation. I'm sure a simple script could automate
this job.

Alternatively, a more sophisticated script could generate the
sequence of renamings according to a complicated set of configuration
requirements or environment characteristics). A Unix program called
'm4' could be useful for this purpose.

Note that this technique permits the package specifications to vary
between configurations, as well as the body. It is sometimes useful to
be able to do this (for example, there may be differences in the
private parts).

-- 
Nick Roberts

Re: GNAT and GNU build system

[Florian Weimer]

* Lutz Donnerhacke:

> You do not need autoconfig for Ada.

Some autoconf features are very helpful for writing bindings,
though--for instance, extracting constant from system header files.

Re: GNAT and GNU build system

[Lutz Donnerhacke]

* Florian Weimer wrote:
> * Lutz Donnerhacke:
>> You do not need autoconfig for Ada.
>
> Some autoconf features are very helpful for writing bindings,
> though--for instance, extracting constant from system header files.

They are a dirty hacks to dig data from a non progamming language (mostly C
preprocessor). It would be much more helpful to simply import the values of
constants using the linker.

Re: GNAT and GNU build system

[Tapio Kelloniemi]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:
>Stephen Leake <stephen_leake@acm.org> wrote:
>: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
>:
>:> Tapio Kelloniemi <spam12@thack.org> wrote:
>:>
>:> : Building some non-autoconfized projects with custom compiler flags
>:> : almost requires a full rewrite of their huge Makefile suites.
>:>
>:> If you look at a program like RXP, there is very little in
>:> the Makefile that needs to be adjusted, if anything at all.
>:
>: That's good.

But the configuration can't be done automatically, which is a 
requirement for those who build lots of software from source code.
Automatic building can also introduce problems, but so can
Makefile editing. Consider a project like Lynx, which configure has 
dozens of --enable options. The sed script that would adjust a Makefile
with dozens of options like these, would be very complex.

>:> If it is a library for mass computers, I find it very likely that
>:> requirements like "we need a C90 compiler and integer size of 32
>:> bits" "we need an Ada 95 compiler" are a lot more helpful than test
>:> programs that try to find out whether some vintage C issue can be
>:> handled.

Sometimes more tests are required For example, if a compiler has a 
well-known bug, a workaround may
be provided. I think that it is a much more portable solution than 
saying: "Install another compiler for $1.0e+12 and try again."
It might be also useful to figure out, if the C90 compiler and the
Ada95 compiler can co-operate.

>:> The standard include paths for the Ada part needs not be
>:> adjusted. Same as C.

Unfortunately, I always need to adjust Ada include paths, because GNAT
doesn't have any defaults, except /usr/lib/gcc/$MACHTYPE/adainclude.
I have to add /usr/lib/adainclude, ncurses Ada bingding is installed 
ther eby default. I'm not aware of any FHS compliant standards regarding 
ada include and library files, though it doesn't mean that such 
standards do not exist.

>Sometimes yes, but not always I think.
>How would you specify a version of the library per build?
>Maybe,
>
>  --with-this-library=/path/to/library_version
>
>creating a copy of "project.gpr" with this library path?
>This can add a familiar configuration interface to the process,
>provided GNAT project files are used. Or provided GNAT is used, for
>that matter. If someone has an Aonix compiler installed,
>GNAT project files are less helpful, so we'd have another decision,
>to be made by configure.
>2**--options, and an additional level of indirection caused by not
>directly using the configuration tools provided by the producers
>of the respective compilers.  Someone will have to work hard
>to make this work. :-)

It is the bill to be paid of portability.
Luckily there are no other free software compilers for Ada95 than GNAT,
so free software developers don't need to pay attention to this problem.

>:> configure is very convenient then, if it works. How does it work in
>:> non-standard situations?
>:
>: You'll have to define what you mean by "standard" here.
>
>The configure tools have to assume a certain environment,
>in addition to GNU. Gtk comes with a script that has been
>set up with the typical GNU commandline interface in mind,
>spitting out a number of command line options -- for GNU
>build tools.
>If I want some software library to be well integrated with
>GNU tools, the GNU build process execises a slight social
>pressure to provide facilities that have emerged with
>configure. That is, configure becomes a social standard,
>with technical consequences. (A la "If is works with the GNU
>tools, it is configurable software.")

GNU build tools are software development tools for the GNU system.
Their portability is an advantage, but the main goal is to support GNU 
and follow the GNU way of doing things.

>: Yes, Gnu configure assumes Gnu bash. You have to start somewhere!

GNU configure does not assume GNU bash. That is why code like
this can be found in them:
if [ x$FOO = xyes ] ...
instead of plain if [ $FOO = yes ] ...

>: Should configure work if the shell is VAX DCL?
>
>Not only is bash assumed, but Unix sh features are used extensively
>even where that is not needed. I find this OK in a Unix environment,
>and it may also work in Unix emulations like cygwin. But I cannot
>see how this is the best option for configuring software other than
>Unix specific software.

GNU is a Unix-like system. I would want to see a configuration script 
that can run without modifications under Unix sh and under M$-DOS 
COMMAND.COM. The first line is the first problem:
#! /bin/sh
vs.
@ECHO OFF

>:> Or if you look at the huge config.guess, why all this, why so many
>:> Unix specific processes and pipes just to guess a string like
>:> "i123-pc-linol-gna"? When I tried to compile some Unix program on a
>:> very Non-Unix system, the best thing I could do with config.guess
>:> was to replace it with a 1-liner that just echo "i123-pc-linol-gna".

If you had typed ./configure --help, you may have noticed, that you 
could have given the string on command line.

>: What is a better solution?
>
>An interactive one.
>"What kind of processor do you have?
>[1] Intel 386 or above
>[2] Motorola 68030 or above
>[3] Alpha 21xxx
>[4] Power PC 604 or later
>
>etc. This kind of user interaction is possible on very many
>systems without the need to install a set of additional tools.

So works config.guess on many systems with no additional tools. uname 
exists for example on many Unix systems. And what comes to 
interactivity. Building a whole operating system from source code and 
answering the same 100 questions 100 times may get boring. Interactive 
configuration methods have been used in free software, but nobody wanted 
to use them, after autoconf was born.

>: Yes, maintaining complex systems is complex. What is a better solution?
>
>What is it in autotools that results in so many build dependences?
>Misuse? Laziness?

SmartEiffel is an example which uses interactive configuration even 
today. Unfortunately, I have never managed to get it installed in FHS 
compliant directories, so I can't tell, what advantages this 
interactivity has. Interactive or not, it doesn't seem to make the 
design better or worse.

>Some of complexitiy can be explained in terms of indirection.
>I have found that in cases only a fraction of the funcitonality
>provided by some tool was needed, but this tiny fraction drags
>in a number of tools needed by the first tool, and then these
>tools continue to add more needs. In sum you can end up installing
>half of the dependence graph of the whole development system,
>because that tool found a fraction of another tool helpful.

Poor design. Autoconf does not encourage this kind of configuration 
aproach. But for example packages in GNOME desktop depend highly on each 
others, which should not be a problem, unless you want to use gnome 
software without gnome.

>: Yes, configure can look for a specific version of a library.
>
>In the sense that a specific version of a library is just some
>library, iirc. How does it distinguish versions of AI302 translated
>with different compiler options?

It is a headache of the configure.ac writer, not autoconf.

>: I use configure because it solves a very hard
>: problem, in a widely accepted and supported way.
>
>Do you use it for Ada sources or for the C/LaTeX related parts?
>
>:> They haven't at all, they have trusted others who before them have
>:> tried to put lots of effort into assuming and checking.
>:
>: What is wrong with that? The same can be said of an Ada 95 compiler; I
>: use it because others have put a lot of work into it.
>
>Nothing wrong with trusting others' work.
>However, in case of configure it leads to assumptions that in my
>experience are far less justifiably than when you assume that
>an Ada compiler is an Ada compiler.
>What I meant was that people do not seem to be aware of what
>they are doing when they run ./configure: they are not doing
>the hard work that is needed to configure software.

That is why autoconf was born. Let computers do the computers' job.

-- 
Tapio

Re: GNAT and GNU build system

[Ludovic Brenta]

Tapio Kelloniemi writes:
> Unfortunately, I always need to adjust Ada include paths, because
> GNAT doesn't have any defaults, except
> /usr/lib/gcc/$MACHTYPE/adainclude.  I have to add
> /usr/lib/adainclude, ncurses Ada bingding is installed ther eby
> default. I'm not aware of any FHS compliant standards regarding ada
> include and library files, though it doesn't mean that such
> standards do not exist.

I thought I'd mentioned it before, but there is a proposed standard by
Florian Weimer called the GNU Ada Environment Specification:

http://cert.uni-stuttgart.de/projects/ada/gnae.php

Debian packages follow this specification as far as the filesystem is
concerned.  They do not however provide the adainstall or adaconfig
commands.  The former is replaced with Debian's apt, and the latter
with GNAT project files.

-- 
Ludovic Brenta.

Re: GNAT and GNU build system

[Georg Bauhaus]

Tapio Kelloniemi <spam13@thack.org> wrote:

: I'm not aware of any FHS compliant standards regarding 
: ada include and library files, though it doesn't mean that such 
: standards do not exist.

OK, let it be FHS. I'm still comfortable with project files for
Ada programs. Another nice feature of project files is that
one can write and read them like other source code, with comments. 
No macro processing is necessary, no toolset other than
GNAT, no process creation.
GNAT has roots not only in Unix. This might explain
why the mechanisms used appear to be less dependent on the
Unix toolset, or file placing conventions, AFAICT.


:>2**--options, [...]
 
: It is the bill to be paid of portability.
: Luckily there are no other free software compilers for Ada95 than GNAT,
: so free software developers don't need to pay attention to this problem.

I disagree, because Free Software needs not be Free Software for Unix
like systems only.  So authors may have to pay attention to configuration
requirements on other operating systems, even if using GNAT only.
OTOH, you can write free Ada programs that can be compiled by any Ada
compiler.  And you can write free language X programs that can be
compiled by many language X compilers, free software or not.


: GNU build tools are software development tools for the GNU system.
: Their portability is an advantage, but the main goal is to support GNU 
: and follow the GNU way of doing things.

Well said. So "portability" has to be taken with a grain of salt.

: GNU is a Unix-like system. I would want to see a configuration script 
: that can run without modifications under Unix sh and under M$-DOS 
: COMMAND.COM.

It is the amount of shell features used that can become a problem.
How is job control implemented on Unix vs other systems? Can you
expect shell piping to work the same way on other OSs? The Unix shells
available for other OSs do not necessarily have all that. Not even
on Unix :-)
I think you are right, "the main goal is to support and follow the GNU
way of doing things." This can be useful.


: If you had typed ./configure --help, you may have noticed, that you 
: could have given the string on command line.

Whether there is an --option for that depends on the configure script.


:  Interactive 
: configuration methods have been used in free software, but nobody wanted 
: to use them, after autoconf was born.

That is the problem, laziness, boredom... The Linux kernel still comes
with interactive configuration programs, though. Why?

: SmartEiffel is an example which uses interactive configuration even 
: today. Unfortunately, I have never managed to get it installed in FHS 
: compliant directories, so I can't tell, what advantages this 
: interactivity has.

Another question to ask is whether the FHS is a general solution for
a most portable compiler (SmartEiffel runs on at least DOS, Windows,
Mac OSs, BeOS, Amiga, OS2, VMS.)


: It is a headache of the configure.ac writer, not autoconf.

And in the Ada case, why not use the configuration tools provided
by the producers of the compilers? For compiling Ada programs,
what is the advantage of using autotools when GNAT project files
can include other project files? If the ncurses bindings comes
with a project file, it is likely that all you have to do in
your project file is to "include" the ncurses project file.

 
: That is why autoconf was born. Let computers do the computers' job.

This is the goal.
Using O-Notation,  what is your estimate of the complexity of porting
an auto* configurable program to a non-Unix system?


-- Georg