[Gs-devel] Re: autotools for building Ghostscript

[L. Peter Deutsch]

> Most projects I'm familiar with either use compatibility environments
> (i.e.  cygwin or ming32) or maintain separate project files, and it's not
> necessary more work than the current system.

It is a lot more work, because it requires keeping two large, complex data
sets consistent by hand.

> Make is hardly universal either.

I have to differ with you about this.  It is available in sufficiently
compatible form on every system that hasn't completely abandoned the concept
of a shell: Unix/Linux, MS Windows (3 different toolsets), OS/2, OpenVMS,
....  In all cases we use the native 'make' or equivalent: we don't force
the use of GNU make.  Not supporting this would be a show-stopper for
Artifex's customers.

> You may well be right about embedded environments. Can you give examples
> or rough numbers on how many of these support make (and sh?) but not
> autotools? The goal of course is to have a shared compatibility layer,
> rather than a private one, as much as possible. I'd agree that's GNU/*nix
> centrism.

Miles would have to answer this.  In general, my impression is that
industrial licensees use the platform's native toolset and consider being
required to do or import anything else a major imposition.  Requiring the
use of a "shared compatibility layer" is not acceptable: for example, one of
Artifex's engineers just lost several days discovering that simply
installing the MKS Toolkit breaks other things in Windows 2000.

> I'm confused by these objections. The idea is to make configuration as
> *automatic* as possible; the resulting decisions are of course recorded in
> Makefiles and/or generated header files; usually that's what matters.

That imposes an unacceptable change to the development process: if
configuration information about the build is captured only in
machine-generated files, one loses the extremely desirable property of being
able to blow away all machine-generated files at any time and recreate a
program solely from its sources.

> There are log files and intermediate results one can reference in
> debugging the configure script. How is 'mail us config.log' any different
> from 'mail us your makefile'? If you do want the specific invocation, we
> can record that too.

See above.  "Recording" is not equivalent to making something part of the
sources.

> Configure and the other generated files are object code; you don't edit
> them and usually don't need to understand them.

They're object code for a poorly defined, cross-platform-incompatible
virtual machine.  When they break -- and I have seen configure-based build
scripts break more than once on a stock Linux installation -- they are
impossible to debug.

> Documentation resides along with the logic in the autotool source files,
> and as much of it as you like can be copied into the generated versions.

Relying on the generated versions is a bug, not a feature.

> I'd think the autotools maintainers would treat that as a bug, though
> certainly some of their features depend on gcc and gmake.

Being required to install such things is not acceptable to industrial users
who aren't using them already.  Artifex can be more specific about this.

>> 	- Quite possibly, destroy or cripple Ghostscript's flexible
>> 	  configuration architecture (using .dev files and genconf) due to
>> 	  makefile restrictions imposed by automake.
> 
> Can you be more specific here?

>From the automake documentation:

   Automake does constrain a project in certain ways; for instance it
   assumes that the project uses Autoconf (*note The Autoconf Manual:
   (autoconf)Top.), and enforces certain restrictions on the `configure.in'
   contents.

As I've already observed, autoconf simply gets in the way: it doesn't handle
the majority of Ghostscript's portability issues across compilers, so it's
just another piece of mechanism to deal with.

   `automake' supports three kinds of directory hierarchy: "flat",
   "shallow", and "deep".

None of these match the Ghostscript model, in which source code lies in
subdirectories and NOTHING is in the top-level directory.

   ... The name comes from the fact that Automake is intended to be used for
   GNU programs; these relaxed rules are not the standard mode of operation.

There is a long list of GNU standards, which automake will try to enforce,
whether or not we (or Artifex's customers) want to follow them.

   SUBDIRS = doc intl po src tests

The discussion of subdirectories makes it clear that automake is intended
for environments in which source and generated files are mixed together in
various directories.  Another example of unacceptable dictation of
development procedures.

   `@LIBOBJS@' and `@ALLOCA@' are specially recognized in any `_LDADD'
   or `_LIBADD' variable.

More special hacks for the GNU world.

   Building shared libraries is a relatively complex matter.

Which automake supports only in the context of Unix-like systems.

   As a developer it is often painful to continually update the
   `Makefile.in' whenever the include-file dependencies change in a project.
   `automake' supplies a way to automatically track dependency changes, and
   distribute the dependencies in the generated `Makefile.in'.

This is one of the main arguments for using automake ...

   Currently this support requires the use of GNU `make' and `gcc'.

... and it requires dragging along these other GNU tools.

   Script objects can be installed in `bindir', `sbindir',
   `libexecdir', or `pkgdatadir'.

Just one example of automake's a priori decisions about how files are
classified and divided into directories.

The bottom line, as far as I'm concerned, is that automake is a tool
designed to make life easier for people who are maintaining programs in the
circumscribed GNU universe, by encapsulating many of the assumptions,
requirements, and conventions of that universe.  It does not seem to care
about being particularly useful to anyone who wants to make any of their own
decisions about how to structure directories, makefiles, development
processes, configuration management, etc. in a way that might not match the
GNU conventions.

-- 

L. Peter Deutsch        |               Aladdin Enterprises
ghost@aladdin.com       | http://www.aladdin.com | 203 Santa Margarita Ave.
                        | fax +1-650-322-1734    | Menlo Park, CA 94025
	The future of software is at http://www.opensource.org