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
signature.asc
Description: OpenPGP digital signature
