I mean, those C or C++ projects that you build from source on Linux and UNIX systems, usually by issuing those commands:
./configure
make
sudo make install
And they also have files like ./configure, ./configure.ac, ./configure.in at the top directory.
I've heard them variously called autotools projects, or autoconf projects, or automake projects, but I'm not sure which name is the correct one. Is there even a consensus on what they should be called?
Autoconf and automake are collectively called the GNU autotools (and libtool may be included in that category as well), so autotools is the most general name.
Note that not all programs that have a configure script to generate a makefile are necessarily using the autotools, or not all of them.
According to GNU it's officially called the GNU Build System, which is where you find it on Wikipedia. But most people (er, almost everyone?) calls it "the GNU autotools" or "autotools". As stated by #larsmans and others in his answer, none of these tools are required. To quote the last paragraph of the link:
The Autotools are tools that will create a GNU Build System for your package. Autoconf mostly focuses on configure and Automake on Makefiles. It is entirely possible to create a GNU Build System without the help of these tools....
The first page of the autoconf info page refers to the packages as "autoconfiscated".
Related
I found a package on github (https://github.com/okbob/ncurses-st-menu) and am having trouble compile it for BSD platforms like NetBSD or OpenBSD. The instructions say to do ./autogen.sh, ./configure, and then make. So I install the autoconf, autotools, libtool, gettext, and any other necessary packages and run ./autogen.sh. It works without spitting out any errors. But ./configure says it doesn't support "OS x86_64-unknown-netbsd9.0" if for example on NetBSD. Can someone else try to compile this program? Because if this was done by autotools, it certainly should support any of the four major BSD operating systems.
I created a port for FreeBSD here, maybe it will help you get it running on NetBSD. The most important part is the removal of the AC_MSG_ERROR(["OS $host_os is not supported"]) line from tools/ax_pdcurses.m4, then touching config.make, calling autogen.sh to re-generate the configure script. It's also important to set CFLAGS properly and have the appropriate dependencies installed. Also, I used gmake rather than patch the Makefile since I didn't feel motivated to fix it completely.
I don't know the autogen/config tools,
but if you look the configure file:
https://github.com/okbob/ncurses-st-menu/blob/master/configure
lines 4245-4269 only checks for linux,cygwin,mingw.
For other OS gives the error: OS $host_os is not supported
I'm currently working on a Linux project using autotools. The code is submitted in SCM (Perforce) and we have the configure script, Makefile.am, Makefile.in - the usual autotools boilerplate. Recently, somebody has changed Makefile.am, but forgot to regenerate Makefile.in; when I tried to build, I got this error:
WARNING: `automake-1.11' is missing on your system. You should only need it if
you modified `Makefile.am', `acinclude.m4' or `configure.ac'.
You might want to install the `Automake' and `Perl' packages.
Grab them from any GNU archive site.
cd . && /bin/bash ./config.status Makefile depfiles
I see the automake version is hardcoded in the configure script (and seems to come from aclocal.m4):
am__api_version='1.11'
So I guess I need automake-1.11 (not 1.10, not anything newer) to regenerate the Makefile.in file.
Why is that? Why should we be tied to a specific automake version? We're mostly building on Ubuntu 14.04, where 1.14 is the default version installed. Is there a way to tell the build system to simply use whatever version of automake is installed? Or is it safe to maybe remove the am__api_version definition from aclocal.m4?
The problem is that you are trying to recreate Makefile.in with other version of autotools. It would lead to version mismatch as aclocal.m4 was built with different version and it is used to generate the remaining files.
Instead of recreating only Makefile.in, try to also recreate aclocal.m4 and all remaining autotools generated files:
autoreconf --force --install
The important question is why would someone fix am__api_versions.
The most probable answer is: Because automake tends to alter the macro's arguments or even remove entirely macros of previous release. In each release announcement of automake there is a section called
WARNING: Future backward-incompatibilities!
and an other one called
Obsolete features removed
You can refer to releases 1.12, 1.13, 1.14
So the configure.ac or Makefile.am might contain some macros which have become obsolete in later releases. When encountering this problem you have two possibilities. Either find out which feature replaced the obsolete one or stick to one version of automake. Most developers do not feel that autotools files are part of the projects source code. They just wish to keep the working version running and stick to the current am version.
Note that all distributions support older versions of automake. In ubuntu you can find:
$ apt-cache search automake | grep automake
automake - Tool for generating GNU Standards-compliant Makefiles
automake1.4 - A tool for generating GNU Standards-compliant Makefiles
automake1.9 - A tool for generating GNU Standards-compliant Makefiles
automake1.10 - Tool for generating GNU Standards-compliant Makefiles
automake1.11 - Tool for generating GNU Standards-compliant Makefiles
Meaning that you can install the requested version of automake.
So, you could remove the line am__api_version='1.11' and find out which macro is obsolete. Then you will have to decide which of the above two solutions you will follow.
I build Fedora Linux kernel (rpmbuild -bb --target=`uname -m` kernel.spec) according to this guide, and now I have among others:
kernel-debug-debuginfo-3.18.6-100.myself.fc20.x86_64.rpm (~360MB)
kernel-debuginfo-3.18.6-100.myself.fc20.x86_64.rpm (~360MB)
kernel-debuginfo-common-x86_64-3.18.6-100.myself.fc20.x86_64.rpm (~51MB)
kernel-debug-3.18.6-100.myself.fc20.x86_64.rpm (~67MB)
kernel-debug-devel-3.18.6-100.pae_sw_tal.fc20.x86_64.rpm (~10MB)
some others...
What's the difference between them and which one should I install if I want a development (debug-able build) version?
Basically you can find following information on rpmfind.net
just put kernel-debug-debuginfo in the search and it will tell you what it is.
Similarly for other packages.
for e.g.
kernel-debug-debuginfo-3.18.6-100.myself.fc20.x86_64.rpm
This package provides debug information for package kernel-debug. This is required to use SystemTap with kernel-debug-3.18.6-100.myself.fc20.x86_64.rpm
And I think you need kernel-debug-3.18.6-100.myself.fc20.x86_64.rpm (~67MB)
look at the options of rpmbuild for creating less files. Options like --without devel --without debuginfo
I am trying to build Guile 1.8.8 from source. I am stuck at the point where the build system is looking for libtool. I have installed it in a non-standard location.
I have already built Guile 2.0.11. In 2.0.11 build system, there is an explicit flag to configure --with-libltdl-prefix, which I think tells the build system where libtool is installed.
For Guile 1.8.8, I have Libtool installed in a non-standard location. How do I tell the build system where it is installed?
I am specifically getting error messages like:
libguile/Makefile.am:40: Libtool library used but `LIBTOOL' is undefined
libguile/Makefile.am:40: The usual way to define `LIBTOOL' is to add `LT_INIT'
I think in general this is a question regarding one or more of the autotools and how the build system finds programs / headers / libraries in non-standard locations.
This link is informative: How to point autoconf/automake to non-standard packages
Find the directory where *.m4 exists, which corresponds to libtool, or package which is in non-standard location.
export ACLOCAL_PATH=/path/to/m4/file
cd /path/to/configure.[in,ac]
autoreconf -if
./configure
I want to build XZ Utils with MSVC++, but xz utils uses a Gnu Autoconf Script. Is there a way to import a whole autoconfed project into MSVC++, then build it? If not, is there a way to run the Gnu Autoconf script for MSVC++, then after that, just take all the source files, as well as config.h, then build it?
FYI XZutils is written in C99 and will not compile under MSVC without massive changes. Just build in MINGW and link to the static lib or dll.
As far as I know, not really. You could try installing MSYS and seeing what the support for cl.exe is like in the configure script:
./configure CC=c:/path/to/cl.exe CXX=c:/path/to/cl.exe
Last time I checked, the support was rather immature, but it could be worth a shot. On the other hand, since xz-utils is written in straight C, what does it matter which compiler you use? Build it with MinGW and link against it with visual studio.