Re: GNAT and GNU build system

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

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