[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Automake AM_COND_IF problem: libopts/Makefile.in split personality
From: |
Dave Hart |
Subject: |
Automake AM_COND_IF problem: libopts/Makefile.in split personality |
Date: |
Sun, 21 Nov 2010 13:10:05 +0000 |
I've put together a stripped-down example of a problem currently
beguiling Harlan Stenn and myself with Automake used in the NTP
reference implementation:
http://support.ntp.org/people/hart/am-libopts-subpkg.tar.gz
The layout is:
am-libopts-subpkg/
configure.ac
Makefile.am
top.c
subproj/
configure.ac
Makefile.am
sub.c
libopts/
m4/
...
Both top.c and sub.c are libopts clients, sharing the single
subproj/libopts bundled copy. The problem is that sometimes
subproj/libopts/Makefile.in is generated correctly by the subproj
machinery, and other times it is generated incorrectly as if it were
produced by the top-level configure. The incorrect resulting
subproj/libopts/Makefile breaks "make distcheck" using GNU Make,
though curiously FreeBSD's make is able to complete distcheck
successfully. The incorrect subproj/libopts/Makefile contains "subdir
= subproj/libopts" while the working one has "subdir = libopts". The
distcheck break happens when subproj/libopts/Makefile attempts to
regenerate itself using a missing automake invocation that contains an
extra "subproj/" that makes the filename non-existent.
In trying to straighten this out, I modified our copy of
libopts/m4/libopts.m4, originally from Autogen 5.11.2, to add an
optional second argument to LIBOPTS_CHECK which can be used to
conditionalize the AC_CONFIG_FILES(libopts-dir/Makefile) under
AM_COND_IF. The top-level configure.ac uses this facility, so that
the top-level config.status does not generate subproj/libopts/Makefile
as it would otherwise. Instead, subproj/config.status generates (from
its perspective) libopts/Makefile.
The current snag I'm having is with autoreconf -i from the top level.
After autoreconf completes, subproj/libopts/Makefile.in is
consistently incorrect. This can be worked around with, for example:
autoreconf -i -v --no-recursive ; cd subproj ; autoreconf -i -v ; cd
.. # in the srcdir
After which subproj/libopts/Makefile.in is consistently correct.
The workaround is only temporary, as invariably something triggers
automake self-rebuilding magic and the miscreant libopts/Makefile.in
stops progress again. It appears autoreconf (or automake invoked from
autoreconf) is not respecting the conditionalization of
AC_CONFIG_FILES(libopts-dir/Makefile) using AM_COND_IF in
LIBOPTS_CHECK, so that a recursive autoreconf gives the wrong
top_builddir and subdir in subproj/libopts/Makefile.in, while
autoreconf from the subproj dir does the right thing.
Your thoughts and wisdom are solicited. Can we avoid going back to a
separate top-level copy of libopts required by the subpackage? How
might I convince in-the-field Autoconf and Automake to stop fighting
amongst the packages over which owns subproj/libopts/Makefile? Can
you help me in my quest to stop grepping Makefiles before kicking off
a "make distcheck"? :)
Thanks for your time,
Dave Hart
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Automake AM_COND_IF problem: libopts/Makefile.in split personality,
Dave Hart <=