🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.misc.discuss
Article #72147

Re: About the GNU's project's path

#72147
From: K. Richard Pixley
Date: Wed, 18 Mar 1992 22:27
93 lines
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!rich
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>

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