* GNAT and GNU build system @ 2004-08-03 19:36 Tapio Kelloniemi 2004-08-03 20:12 ` Jerome Hugues ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Tapio Kelloniemi @ 2004-08-03 19:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-03 19:36 GNAT and GNU build system Tapio Kelloniemi @ 2004-08-03 20:12 ` Jerome Hugues 2004-08-04 2:05 ` Lutz Donnerhacke 2004-08-04 22:06 ` Stephen Leake 2 siblings, 0 replies; 23+ messages in thread From: Jerome Hugues @ 2004-08-03 20:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-03 19:36 GNAT and GNU build system Tapio Kelloniemi 2004-08-03 20:12 ` Jerome Hugues @ 2004-08-04 2:05 ` Lutz Donnerhacke 2004-08-04 7:49 ` Tapio Kelloniemi 2004-08-12 13:56 ` Florian Weimer 2004-08-04 22:06 ` Stephen Leake 2 siblings, 2 replies; 23+ messages in thread From: Lutz Donnerhacke @ 2004-08-04 2:05 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-04 2:05 ` Lutz Donnerhacke @ 2004-08-04 7:49 ` Tapio Kelloniemi 2004-08-04 13:33 ` Mark H Johnson 2004-08-12 13:56 ` Florian Weimer 1 sibling, 1 reply; 23+ messages in thread From: Tapio Kelloniemi @ 2004-08-04 7:49 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-04 7:49 ` Tapio Kelloniemi @ 2004-08-04 13:33 ` Mark H Johnson 2004-08-04 16:04 ` Georg Bauhaus 2004-08-04 20:06 ` Tapio Kelloniemi 0 siblings, 2 replies; 23+ messages in thread From: Mark H Johnson @ 2004-08-04 13:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-04 13:33 ` Mark H Johnson @ 2004-08-04 16:04 ` Georg Bauhaus 2004-08-04 19:21 ` Ludovic Brenta 2004-08-04 20:29 ` Tapio Kelloniemi 2004-08-04 20:06 ` Tapio Kelloniemi 1 sibling, 2 replies; 23+ messages in thread From: Georg Bauhaus @ 2004-08-04 16:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-04 16:04 ` Georg Bauhaus @ 2004-08-04 19:21 ` Ludovic Brenta 2004-08-04 20:29 ` Tapio Kelloniemi 1 sibling, 0 replies; 23+ messages in thread From: Ludovic Brenta @ 2004-08-04 19:21 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-04 16:04 ` Georg Bauhaus 2004-08-04 19:21 ` Ludovic Brenta @ 2004-08-04 20:29 ` Tapio Kelloniemi 2004-08-05 2:15 ` Georg Bauhaus 1 sibling, 1 reply; 23+ messages in thread From: Tapio Kelloniemi @ 2004-08-04 20:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-04 20:29 ` Tapio Kelloniemi @ 2004-08-05 2:15 ` Georg Bauhaus 2004-08-06 10:26 ` Stephen Leake 0 siblings, 1 reply; 23+ messages in thread From: Georg Bauhaus @ 2004-08-05 2:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-05 2:15 ` Georg Bauhaus @ 2004-08-06 10:26 ` Stephen Leake 2004-08-06 15:36 ` Georg Bauhaus 0 siblings, 1 reply; 23+ messages in thread From: Stephen Leake @ 2004-08-06 10:26 UTC (permalink / raw) To: comp.lang.ada 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-06 10:26 ` Stephen Leake @ 2004-08-06 15:36 ` Georg Bauhaus 2004-08-14 6:00 ` Tapio Kelloniemi 0 siblings, 1 reply; 23+ messages in thread From: Georg Bauhaus @ 2004-08-06 15:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-06 15:36 ` Georg Bauhaus @ 2004-08-14 6:00 ` Tapio Kelloniemi 2004-08-14 11:32 ` Ludovic Brenta 2004-08-14 14:41 ` Georg Bauhaus 0 siblings, 2 replies; 23+ messages in thread From: Tapio Kelloniemi @ 2004-08-14 6:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-14 6:00 ` Tapio Kelloniemi @ 2004-08-14 11:32 ` Ludovic Brenta 2004-08-14 14:41 ` Georg Bauhaus 1 sibling, 0 replies; 23+ messages in thread From: Ludovic Brenta @ 2004-08-14 11:32 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-14 6:00 ` Tapio Kelloniemi 2004-08-14 11:32 ` Ludovic Brenta @ 2004-08-14 14:41 ` Georg Bauhaus 1 sibling, 0 replies; 23+ messages in thread From: Georg Bauhaus @ 2004-08-14 14:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-04 13:33 ` Mark H Johnson 2004-08-04 16:04 ` Georg Bauhaus @ 2004-08-04 20:06 ` Tapio Kelloniemi 2004-08-04 20:34 ` Ludovic Brenta 1 sibling, 1 reply; 23+ messages in thread From: Tapio Kelloniemi @ 2004-08-04 20:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-04 20:06 ` Tapio Kelloniemi @ 2004-08-04 20:34 ` Ludovic Brenta 2004-08-04 22:11 ` Stephen Leake 0 siblings, 1 reply; 23+ messages in thread From: Ludovic Brenta @ 2004-08-04 20:34 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-04 20:34 ` Ludovic Brenta @ 2004-08-04 22:11 ` Stephen Leake 2004-08-05 8:50 ` Tapio Kelloniemi 0 siblings, 1 reply; 23+ messages in thread From: Stephen Leake @ 2004-08-04 22:11 UTC (permalink / raw) To: comp.lang.ada 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-04 22:11 ` Stephen Leake @ 2004-08-05 8:50 ` Tapio Kelloniemi 2004-08-08 14:45 ` Ludovic Brenta 0 siblings, 1 reply; 23+ messages in thread From: Tapio Kelloniemi @ 2004-08-05 8:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-05 8:50 ` Tapio Kelloniemi @ 2004-08-08 14:45 ` Ludovic Brenta 2004-08-10 16:18 ` Nick Roberts 0 siblings, 1 reply; 23+ messages in thread From: Ludovic Brenta @ 2004-08-08 14:45 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-08 14:45 ` Ludovic Brenta @ 2004-08-10 16:18 ` Nick Roberts 0 siblings, 0 replies; 23+ messages in thread From: Nick Roberts @ 2004-08-10 16:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-04 2:05 ` Lutz Donnerhacke 2004-08-04 7:49 ` Tapio Kelloniemi @ 2004-08-12 13:56 ` Florian Weimer 2004-08-13 15:52 ` Lutz Donnerhacke 1 sibling, 1 reply; 23+ messages in thread From: Florian Weimer @ 2004-08-12 13:56 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-12 13:56 ` Florian Weimer @ 2004-08-13 15:52 ` Lutz Donnerhacke 0 siblings, 0 replies; 23+ messages in thread From: Lutz Donnerhacke @ 2004-08-13 15:52 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GNAT and GNU build system 2004-08-03 19:36 GNAT and GNU build system Tapio Kelloniemi 2004-08-03 20:12 ` Jerome Hugues 2004-08-04 2:05 ` Lutz Donnerhacke @ 2004-08-04 22:06 ` Stephen Leake 2 siblings, 0 replies; 23+ messages in thread From: Stephen Leake @ 2004-08-04 22:06 UTC (permalink / raw) To: comp.lang.ada 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2004-08-14 14:41 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-08-03 19:36 GNAT and GNU build system Tapio Kelloniemi 2004-08-03 20:12 ` Jerome Hugues 2004-08-04 2:05 ` Lutz Donnerhacke 2004-08-04 7:49 ` Tapio Kelloniemi 2004-08-04 13:33 ` Mark H Johnson 2004-08-04 16:04 ` Georg Bauhaus 2004-08-04 19:21 ` Ludovic Brenta 2004-08-04 20:29 ` Tapio Kelloniemi 2004-08-05 2:15 ` Georg Bauhaus 2004-08-06 10:26 ` Stephen Leake 2004-08-06 15:36 ` Georg Bauhaus 2004-08-14 6:00 ` Tapio Kelloniemi 2004-08-14 11:32 ` Ludovic Brenta 2004-08-14 14:41 ` Georg Bauhaus 2004-08-04 20:06 ` Tapio Kelloniemi 2004-08-04 20:34 ` Ludovic Brenta 2004-08-04 22:11 ` Stephen Leake 2004-08-05 8:50 ` Tapio Kelloniemi 2004-08-08 14:45 ` Ludovic Brenta 2004-08-10 16:18 ` Nick Roberts 2004-08-12 13:56 ` Florian Weimer 2004-08-13 15:52 ` Lutz Donnerhacke 2004-08-04 22:06 ` Stephen Leake
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox