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=-0.9 required=5.0 tests=BAYES_00,SYSADMIN autolearn=no 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!news1.google.com!news.glorb.com!tiscali!newsfeed1.ip.tiscali.net!feed.news.tiscali.de!eusc.inter.net!cs.tu-berlin.de!uni-duisburg.de!not-for-mail From: Georg Bauhaus Newsgroups: comp.lang.ada Subject: Re: GNAT and GNU build system Date: Fri, 6 Aug 2004 15:36:57 +0000 (UTC) Organization: GMUGHDU Message-ID: References: NNTP-Posting-Host: l1-hrz.uni-duisburg.de X-Trace: a1-hrz.uni-duisburg.de 1091806617 2756 134.91.1.34 (6 Aug 2004 15:36:57 GMT) X-Complaints-To: usenet@news.uni-duisburg.de NNTP-Posting-Date: Fri, 6 Aug 2004 15:36:57 +0000 (UTC) User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (HP-UX/B.11.00 (9000/800)) Xref: g2news1.google.com comp.lang.ada:2610 Date: 2004-08-06T15:36:57+00:00 List-Id: Stephen Leake wrote: : 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. 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