Article View: gnu.misc.discuss
Article #72147Re: About the GNU's project's path
From: K. Richard Pixley
Date: Wed, 18 Mar 1992 22:27
Date: Wed, 18 Mar 1992 22:27
93 lines
5247 bytes
5247 bytes
In article <CARLTON.92Mar17090828@husc8.harvard.edu> carlton@husc8.harvard.edu (david carlton) writes: In article <1992Mar17.004430.16266@uunet.uu.net>, ziegast@godzilla.UU.NET (Eric W. Ziegast) writes: > After fumbling with installing several GNU packages last weekend, I > asked myself repeatedly, why doesn't GNU use something similar to > Imakefiles and xmkmf? Call them Gmakefiles and gmkmf. In order to > take some of the guesswork out for programmers, have them follow a > set standard (like POSIX with GNU extensions) and make a > compatability library for each system architecture so that they > don't have to tweak anything to get their program to run across > different platforms. On the library issue, this has essentially already been done. The gnu tools in the past were written to the best standard available at the time, bsd unix, with emulation functions for missing host functionality. They are currently in migration toward ansi and posix facilities. The compatibility library you suggest has existed for some time. It has recently been released as a distribution in it's own right. This is glibc. I agree wholeheartedly. While GNU software is much easier to install than a lot of other software out there, after about the hundredth time you edit a Makefile to set 'man1dir' (or 'mandir', or...) to '$(prefix)/man/man1l' (or whatever), the excitement wears off. X software which is properly written and which has a properly written Imakefile is almost painless to compile and install; and writing Imakefiles is much much easier than writing Makefiles. Personally, I've never found this to be true. You are absolutely right that properly written anything should always work. Properly written Makefile.in's and configure scripts also work. In fact, autoconf generate scripts, (like the one currently distributed with bison), frequently work on machines for which it has NOT ever been set up to handle before. That is, it does a good job of inferring a configuration for a new system. Imake cannot do this. For the particular problem of setting mandir's, if you haven't already, please read configure.texi that comes with the gdb distribution. Look up site specific Makefile fragments and the -site= command line option to configure. I believe this addresses your need in almost precisely the same way as imake. Also read the gnu coding standards. There you should find a description of how gnu Makefile's and configure scripts should work. Deviations should be considered bugs. As with any other bugs, feel free to correct the problem and send a patch to the appropriate maintainer. As to why gnu does not use imake... There are several reasons. * with configure, I can cross configure. Eg, configure sun4 works whether you are on a sun4, sun3, or a foobox. Imake cannot do this. * with configure, I can configure source to build cross tools. configure sun4 -host=sun3 Imake cannot do this. * Imake uses a common database of host specific data. For X11, this makes sense because the distribution is made as a collection of tools, by one central authority who has control over the database. Gnu tools are not released this way. Each gnu tool has a maintainer. These maintainers are scattered across the world. Using a common database would be a maintenance nightmare. Autoconf may appear to be this kind of database, but in fact it is not. Instead of listing host dependencies, it lists program requirements * Imake is very special purpose. It is directed solely at building the X11 distribution. By comparison to the gnu tools, this is a simple problem. If you view the gnu suite as a collection of native tools, then yes, the problems are similar. But the gnu tools are much more powerful than that. The development tools can be configured as cross tools in almost any host+target permutation. All of these configurations can be installed concurrently. They can even be configured to share host independent files across hosts. Imake doesn't address these issues. * Imake templates are a form of standardization. In the gnu world, the gnu coding standards address the same issues without necessarily imposing the same restrictions.
Technical Details
Message-ID:
<RICH.92Mar18172716@cygnus.cygnus.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!kithrup!kithrup!richReferences:
<1853@tansei1.tansei.cc.u-tokyo.ac.jp> <CARLTON.92Mar16121319@husc8.harvard.edu> <1992Mar17.004430.16266@uunet.uu.net> <CARLTON.92Mar17090828@husc8.harvard.edu>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1025b4,5777663c09aadc80 X-Google-Attributes: gid1025b4,public X-Google-ArrivalTime: 1992-03-21 02:27:01 PST Newsgroups: gnu.misc.discuss Path: arc1-ca.pugleaf.net!sparky!uunet!kithrup!kithrup!rich From: rich@cygnus.cygnus.com (K. Richard Pixley) Subject: Re: About the GNU's project's path Reply-To: rich@cygnus.com Organization: Cygnus Support - Palo Alto, CA +1 415 322 3811 Distribution: gnu Date: Wed, 18 Mar 1992 22:27:16 GMT Message-ID: <RICH.92Mar18172716@cygnus.cygnus.com> In-Reply-To: carlton@husc8.harvard.edu's message of 17 Mar 92 17: 08:28 GMT References: <1853@tansei1.tansei.cc.u-tokyo.ac.jp> <CARLTON.92Mar16121319@husc8.harvard.edu> <1992Mar17.004430.16266@uunet.uu.net> <CARLTON.92Mar17090828@husc8.harvard.edu> Sender: news@kithrup.COM (Network News) Nntp-Posting-Host: cygnus.com