m4-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Can m4 be built without automake?


From: Eric Blake
Subject: Re: Can m4 be built without automake?
Date: Mon, 15 Jun 2015 14:09:17 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

On 06/15/2015 12:34 PM, Gang Chen wrote:
> Hi,
> 
> I'm trying to build m4 on my zos-uss system, but run into the error below
> after I run './configure' and started 'make'. It seems that automake is
> required to build m4, while automake requires autoconf and autoconf
> requires m4. Is that a deadlock?

No, but it is a common misconception about proper bootstrapping.

m4 tarballs do not require m4, autoconf nor automake to be installed.

autoconf tarballs require m4 to be installed, but do not require
autoconf or automake to be installed.

automake tarballs require m4 and autoconf to be installed, but do not
require automake to be installed.

Meanwhile, all three of m4.git, autoconf.git, and automake.git each
requires that all of m4, autoconf, and automake be installed (although
the installed version can be older than the version you are trying to
build from git).

You only need the .git development trees if you plan on patching one of
the three projects.  Remember, the point of the autotools is to provide
the tooling so that a developer can then build portable packages that no
longer depend on the autotools on the end user machine.

So, here are several levels of choices on what you need for the autotools:

0.  Don't bother [your focus is on using packages, not developing them].
 Be an end user that only ever _runs_ ./configure (and doesn't need to
create them).  You don't need autotools for this, at least for most
packages.  However, this often limits you to using pre-built tarballs
(many .git repos intentionally omit generated files, so developing in a
random package may not be possible at this level).

1.  Take it easy [your focus is in developing or shipping your package
for use by level 0 consumers, not on autotools vagaries].  Install a
distro that has pre-built the tools for you from tarballs, and you don't
need to do anything else.  You are limited to the versions that your
distro chose to package, and the location they chose to package for; but
now you can write configure.ac for your package, and create tarballs
that no longer depend on autotools (and in .git repos that intentionally
omit generated files, you can let others in the project worry about
configure.ac while you worry about contributing patches in areas that
you care about).

2.  Medium [your focus is on ensuring your package is portable across
multiple released versions of autotools, but not on autotools proper].
Grab the latest release tarballs of m4, autoconf, and automake, then
build/install m4, build/install autoconf, and build/install automake.
Now you are in full control of which versions you use, as well as what
path they are installed in (on large projects, this level of involvement
is often limited to one or two developers working on configure.ac
proper, while other developers don't need to care).

3.  Hard [your focus is on developing autotools proper]. Start with step
1 or 2 to bootstrap your system, then download the .git repository(s)
that you are interested in hacking.  As part of your hacking, you can
now install the intermediate release versions (ones that are not
necessarily stable enough to be worth having as a release tarball), and
you are assumed to be competent enough to debug your own problems and
contribute patches (the set of autotools developers is fairly small, but
you are welcome to join our ranks).

4.  Insane [your focus is on releasing autotools tarballs, for use by
level 1 users]. Get steps 2 and 3 mastered, then repeat them through a
configure/install/configure loop until the generated files are all
attributed to the same version as the tarball you are about to create
(yes, when I build the official autoconf 2.69 tarball a couple years
ago, I made sure that the generated 'configure' file bundled in the
tarball states "Generated by GNU Autoconf 2.69 for GNU Autoconf 2.69."
as a result of my repeated bootstrapping).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]