httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: How to build 2.0 with autoconf
Date Fri, 21 Jan 2000 14:58:25 GMT
In a recent note, David Reid said:

> Date: Fri, 21 Jan 2000 13:50:53 -0000
> I have to say that I agree with Ryan on this.  Having some platforms using
> one mechanism and other using something "home-grown" is a recipe for
> disaster.  Windows is a different case and we should essentially ignore it.
I agree with the desirablity of uniformity.  And It's my personal choice
to ignore Windows.  YMMV.  :-)

> Autoconf seems to work OK, it just needs some fiddling to get it working as
> it needs to for other non-unix platforms, and I suspect the same will be
> true of some of the more exotic unix platforms out there.
> Libtool?  If it's going to produce more problems than it solves then lets
> find something else.  If a home grown solution is going to work then lets do
> that.
Let me give my consumer-side view of installing a typical GNU product.
I do:

    gunzip <product.tar.gz | tar -xvf -
    {   mkdir OS
        cd    OS;  }   # Optional, if multiple platforms
    ../product/configure --prefix=/pub/unsup --exec-prefix=/pub/unsup/OS
    make install

The only non-POSIX tool required is gunzip.  All this works because
"configure" is a highly portable Bourne Shell script which invokes
highly portable POSIX utilities to perform environmental tests then
filter the templates:

    ../product/ -> Makefile
    ../product/cfg.hin     -> cfg.h

The supplier side is more complex.  The supplier is required to use a
wider variety of tools such as autoconf, m4, and now libtool, to create
"configure" from such templates as and aclocal.m4.  Since
the product of this process is the portable "configure", this can be
done on any platform, and does not require that autoconf be supported
on all target platforms.

So my questions:

o Is the ultimate target a product close to the GNU model, which requires
  only a minimum of non-POSIX utility support of the consumer, and
  specifically doesn't require the consumer to support autoconf, m4, and

o is it possible, even early in development, to supply a consumer-image
  tarball, so testers can operate in consumer mode without the need
  for autoconf, m4, etc.?  I glean from an earlier posting on this list
  that CVS creates an obstacle to including a generated object such as
  "configure" in the distribution.  If this is true, shame on CVS!

o Is it possible for me to run autoconf only on Solaris, where it's
  relatively well supported, and use its purportedly portable
  output on both Solaris and OS/390?

I note that I ported Lynx to OS/390 without ever operating in supplier
mode: I never did an autoconf.  Admittedly this was possible only because
of the generous assistance of a senior developer who accepted my diffs to
"configure" and kindly translated them to patches to

My wish is that things remain easy for fringe developers; that they not
be required to become core developers.  I'd like to be able to make a
change to a C source file and submit a patch without the need to become
competent in autoconf, m4, and libtool.  (What's libtool, anyway? :-)

-- gil

View raw message