Has anyone seen something like this:
when running make in a project using autotools, it always rebuils everyhing. Running with make -d, shows that make looks for foo.lo files and because they are not found, always recompiles foo.c.
It seems to be related to builddir != srcdir.
The .lo files are of course in the builddir. But apparently make or libtool are expecting them somewhere else:
Debug output lookgs like this:
Prerequisite /path/to/srcdir/foo.h' is older than targetfoo.lo'.
/path/to/builddir/.deps/foo.Plo:1 Must remake target `foo.lo'.
Update It seems the problem is caused by AC_PROG_LIBTOOL. According to the documentation it expects a variable called top_builddir to be set to the builddirectory. What is the standard way to set it? Is there a autoconf macro for this?
A libtool update solved this problem
Related
A user of xnec2c was trying to build on OSX and had autoconf issues because PKG_CHECK_MODULES could not be found since MacPorts puts it in a funny spot.
The user made autoconf work like so:
ACLOCAL_PATH=/opt/local/share/aclocal ./autogen.sh
ACLOCAL_PATH=/opt/local/share/aclocal ./configure
I would like to make it build on OSX without special user path hacks for ACLOCAL_PATH. Can that be done?
I started writing a possible fix below and realized it could an xyproblem so posed the question just above. However, if this starts any gears turning, then I would be open to a bit of special-casing for OSX:
For example, would it be possible (if not advisable) to detect:
Is PKG_CHECK_MODULES missing?
If so:
is it OSX?
Is [ -d /opt/local/share/aclocal ] true?
Does the macro exist there?
While aclocal has a few ways of appending to its search path (see https://www.gnu.org/software/automake/manual/html_node/Macro-Search-Path.html), you cannot modify that macro search path using code in configure.ac:
When the shell code in configure is run, it is too late, as the available macros have already been expanded. When autoconf (is it autoconf or something else? anyway, m4 called from autoreconf) generates configure from configure.ac by having m4 expand the macros it is also too late: aclocal has already collected the m4 macros it could find.
So what you would need is a step before the autoreconf run - which is beyond what I would consider a buildsystem needs to do.
What you can do: Put static strings into the top level Makefile.am file like e.g.
ACLOCAL_AMFLAGS = -I auto-m4 -I project-m4 -I /opt/local/share/aclocal
(this example uses auto-m4/ with AC_CONFIG_MACRO_DIR([auto-m4]) for the *.m4 files automatically put there by autoreconf/autopoint/libtoolize and project-m4/ for the project specific *.m4 files).
Of course, you should already have
m4_pattern_forbid([PKG_CHECK_MODULES])dnl
before invoking PKG_CHECK_MODULES for the first time so that the problem of the missing *.m4 file will be detected at the earliest possible time, i.e. when autoconf is about to generate a configure file with PKG_CHECK_MODULES unexpanded.
You could use some m4 code to print a lengthy error message if PKG_CHECK_MODULES is not defined. Something along the lines of (untested)
m4_ifndef([PKG_CHECK_MODULES], [dnl
m4_fatal([Could not find the PKG_CHECK_MODULES macro. Check that the pkg.m4 file is available and aclocal finds it (e.g. set ACLOCAL_PATH=/opt/local/share/aclocal).
])dnl
PKG_CHECK_MODULES([FOO], [foo])
Personally, I would go with m4_pattern_forbid and make sure OSX builds with homebrew work OOTB, and then document idiosyncrasies for building on rare and buggy systems like OSX with macports or SunOS without GNU tools in the INSTALL file.
Isn't it a bug in macports/OSX that aclocal there cannot find its *.m4 files? Shouldn't there be a dirlist file pointing to /opt/local/share/aclocal? Or perhaps they macports users should have an aclocal in their PATH which actually finds the macports macro files?
In any case, I would not consider it my build systems's job to fix a buggy system. You need to draw the line somewhere.
I'm trying to ensure that some non-source files are generated when make dist is executed. The files are an info file and an index which is constructed from the info file. I find that the files are generated when I execute make install but not when I execute make dist.
Here is the Makefile.am. (This is share/logic/Makefile.am in the Maxima project, if anybody cares.)
all-local: info
info: logic.info logic-index.lisp
logic.info: logic.texi
makeinfo --force logic.texi
logic-index.lisp: logic.info
perl ../../doc/info/build_index.pl $< > $#
Somehow I got the idea that the target all-local could cause the info and index to be rebuilt. That works OK for make install -- I guess all-local is a target for that. But all-local is not, it appears, a target for make dist. What other target could I use to ensure that the logic.info and logic-index.lisp are rebuilt for make dist as well as make install?
I have searched the web, and SO, and tried some random things, but so far I've come up empty-handed. Thanks in advance for your help.
I'm working with GNU make 3.81, GNU automake 1.14.1, and GNU autoconf 2.69, on Ubuntu 14.04.
You can force something to be built and included in the package by using EXTRA_DIST, so in your case
EXTRA_DIST = logic-index.lisp
This will cause the file to be always included in the distribution tarball.
I'm trying to build a project that supports easily building 'stripped-down' distributions with undesired features removed. The project uses automake and is structured with potentially removable features in their own feature.am files that are included in the top-level Makefile.am file as
include feature.am
The problem is, if you remove a feature (and its feature.am file), autoreconf fails with
automake: error: cannot open < feature.am: No such file or directory
Is there a way to simply ignore this error and continue? I tried using
-include feature.am
like GNU make does, but this ends up simply copying that line into the Makefile.in file (and thus the Makefile), rather than having automake read it.
This is not possible because of the way automake works (which has next to nothing to do with how make includes files by itself.)
You can use AM_CONDITIONAL and autoconf's AC_ARG_ENABLE to build or not build the components that you don't want built. If you would like to have separate tarballs, that's more complicated and I would suggest you just ship separate packages for those features.
I have a configure script that writes a Makefile (from Makefile.in). The clean target currently removes everything created from within the makefile, but it doesn't delete the makefile itself. (I'm not using Autotools as you can probably tell)
My question therefore: Should the makefile also remove itself, requiring the developer to run ./configure again?
On the one hand, I want the clean target to properly clean up the source tree. But, on the other hand, I'd like to be able to type make clean test to check that everything's working as it should before committing; Running the configure script again seems weird somehow.
This is a stylistic question, rather than a technical question. The best place to go for answers is the automake manual, which will tell you:
`make clean'
Erase from the build tree the files built by `make all'.
`make distclean'
Additionally erase anything `./configure' created.
So, no, make clean should not delete Makefile. make distclean should delete Makefile, since it's created by configure not make all.
One of the best things about autotools is that they are consistent and standard. It's best to not irritate your users by flouting those standards.
I'd probably have a separate target for that. So clean would leave them able to build again but distclean or realclean or allclean or something would force a reconfigure. You could see which autotools clean target (if any) has similar behaviour.
The purpose of the clean target is usually to remove interim files, so you can start your compile from scratch. See more here For instance, a common makefile target is "clean," which generally performs actions that clean up after the compiler--removing object files and the resulting executable.
In my Makefile.am, I have
SUBDIRS = libltdl .
This is because I want to be able to use the version of libltdl included with my package (i.e. ./configure --with-included-ltdl). However, I occasionally run into the problem where make invokes itself recursively forever. Unfortunately I'm not sure exactly what conditions cause this to occur.
This is usually solved by rerunning autoconf and configure. I'd like to know the "proper" way of doing this, because it seems this isn't it. (I also find after I update configure.ac that I have to run autoreconf && autoreconf libltdl instead of just autoreconf)
Thanks for the help!
Once again, I spoke too soon. This seems to be solved by moving the source into a separate directory (i.e. src) and then updating SUBDIRS to libltdl src.