From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ab5f27c42c253ac5 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!proxad.net!freenix!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: GNAT and GNU build system Date: 06 Aug 2004 06:26:03 -0400 Organization: Cuivre, Argent, Or Message-ID: References: NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: melchior.cuivre.fr.eu.org 1091787980 89006 212.85.156.195 (6 Aug 2004 10:26:20 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Fri, 6 Aug 2004 10:26:20 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: In-Reply-To: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Gateway to the comp.lang.ada Usenet newsgroup" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: g2news1.google.com comp.lang.ada:2601 Date: 2004-08-06T06:26:03-04:00 Georg Bauhaus writes: > Tapio Kelloniemi 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