Re: GNAT and GNU build system

[Tapio Kelloniemi <spam13@thack.org>]

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