Re: GNAT and GNU build system

[Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de>]

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