bug#12198: automake 1.12.3 self-tests failure: t/distcheck-override-infodir
Stefano Lattarini stefano.lattar...@gmail.com writes: On 08/14/2012 03:38 PM, Peter Rosin wrote: On 2012-08-14 15:14, Simon Josefsson wrote: Hi. It builds and passes self-checks except for the t/distcheck-override-infodir test. Output below. /Simon FAIL: t/distcheck-override-infodir A post is (soon) available in automake-patches, I posted it 10 minutes before seeing your report but it hasn't gone full circle yet. Thanks! Stefano: How did this one slip through your pre-release checks? Now, that is a good question... Ah, the test was skipped because 'install-info' wasn't installed on the system where I did the last test before pushing :-/ Maybe, in the future, it would be a good idea to refrain from last-minute changes just to pacify some overly eager maintainer check ... Maybe you could include a test for whether 'install-info' is available in your release scripts? That would help to avoid this ever happening again. I find such tests useful, because I usually forget about checking such things manually sooner or later. /Simon
Re: Dynamic package version numbers with Autoconf and Automake (was: Re: Automake 1.12.0b test release)
On Tue, Aug 14, 2012 at 06:57:02PM -0500, Bob Friesenhahn wrote:
AC_INIT(m4_esyscmd([scripts/pkginfo.sh package_name]),
m4_esyscmd([scripts/pkginfo.sh package_version]),
m4_esyscmd([scripts/pkginfo.sh package_bugreport]))
Unfortunately, the values passed to AC_INIT are cached so even if
the configure script is run again, it uses the cached values rather
than the new values.
I've been doing a similar thing, though I do it directly in configure.ac
rather than using an external script:
AC_INIT(sbuild_m4_esyscmd_s([sed -ne
'/^Package:/{s/Package:[[:space:]][[:space:]]*//p;q}' VERSION]),
[sbuild_m4_esyscmd_s([sed -ne
'/^Version:/{s/Version:[[:space:]][[:space:]]*//p;q}' VERSION])],
[buildd-tools-de...@lists.alioth.debian.org])
In this case, the information is taken from a static file with the format:
Package: schroot
Version: 1.6.3
Release-Date: 23 Jul 2012
Released-By: Roger Leigh rle...@debian.org
Git-Tag: release/schroot-1.6.3
This is generated by the bootstrap script.
Package and Version are derived from NEWS (since this must be updated
for a release, we require the version here to be the definitive source
of the version.
The other date is taken from the release tag in git; if it's not a
release, i.e. isn't tagged, it's just left as Unreleased.
Your version is better, because it permits vanilla autoreconf to be
used. Providing that we have a stable interface for autoconf to
call an external script, packages could do whatever they wish to
provide the information. Maybe a single-argument AC_INIT which
just has a script file as its argument? However it's done, having
this standardised would be beneficial to all.
In addition to it invoking the script with arguments for
package, version and bugreport address, it might also be nice to
provide the ability to supply information for arbitrary other
stuff such as
- public git URI
- public website
- public bug tracker
- git release and distribution tags
- git branch
And perhaps also allow this to be extended by the builder/distributor,
for example with
- build date
- builder
- distribution
- distribution bug tracker etc.
These are all examples of things which are currently done by some
packages on an ad-hoc basis, but which would benefit from more
generalised support in autoconf. Maybe add a command-line option
to run additional script(s) to source supplementary/overriding
information?
On the automake side, I'm still using custom targets for git integration
with make dist which inject $(distdir) into a separate git branch and
tag that as a distribution; a separate step tags the release, which
is then distributed. If it's not possible to support directly in
automake, being able to disable tarball generation in the dist target
and do completely custom stuff there would be useful. In particular,
having a logical separation of releasing and distributing would be
good.
One thing which is currently done wrong is that some stuf, e.g.
gettext, tries to regenerate stuff at make dist time. This is
rather annoying, as it's creating updated versions of files /after/
you've tagged the release. This means you need to run make dist, then
tag, then run make dist again. While workable, it's easy to forget and
mess up the release process. When you're using a DVCS, this is the wrong
point. We only want to tag the release /after/ all sources changes have
been made and *committed*. Thus there are three steps:
1) release preparation
- updates any files e.g. gettext po files etc.
- commit any changes resulting from this step
2) release
- tags the repo with a signed release tag
3) distribution
- makes the distdir and injects it onto a distribution branch
- branch is tagged
- release tarball is obtained (if required) using git archive
to export the tagged distribution. Not needed for an all-git
workflow (e.g. future Debian git source package format).
The existing make dist does of course do everything in a single
step; but it would be nice if these were split into separate,
overridable/hookable targets, and tools like gettext updated to
run in the release prep stage.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Re: Dynamic package version numbers with Autoconf and Automake
On Wed, 15 Aug 2012, Miles Bader wrote: (3) The final version info is updated (using VCS info and/or autoconf version info) at make time using a script, and when it changes, only causes a source file (e.g., version.c) to change. This means that although some things are rebuilt after a commit (version.o, and relinking of any binaries that use it), the amount of rebuilding is relatively minor while still yielding accurate info. Likewise, GraphicsMagick configures a version.h as well as a version file used for non-autotools builds under Windows. With the currently used mechanism, only the few files depending on version.h need to be rebuilt but the whole project relinks. If the project config.h was to be re-generated (seems to be necessary with new AC_INIT), then all of the source modules would need to be recompiled and relinked since everything depends on the configuration header. Bpb -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Dynamic package version numbers with Autoconf and Automake
On 08/15/12 08:45, Bob Friesenhahn wrote: On Wed, 15 Aug 2012, Miles Bader wrote: (3) The final version info is updated (using VCS info and/or autoconf version info) at make time using a script, and when it changes, only causes a source file (e.g., version.c) to change. This means that although some things are rebuilt after a commit (version.o, and relinking of any binaries that use it), the amount of rebuilding is relatively minor while still yielding accurate info. Likewise, GraphicsMagick configures a version.h as well as a version file used for non-autotools builds under Windows. With the currently used mechanism, only the few files depending on version.h need to be rebuilt but the whole project relinks. If the project config.h was to be re-generated (seems to be necessary with new AC_INIT), then all of the source modules would need to be recompiled and relinked since everything depends on the configuration header. Bpb I've had a similar complaint when using Autotest. In my project, the test suite depends on an M4 input file that has the project version encoded in it. cat test_suite/package.m4 # Signature of the current package. m4_define([AT_PACKAGE_NAME], [my_server]) m4_define([AT_PACKAGE_TARNAME], [my_server]) m4_define([AT_PACKAGE_MINOR_VERSION], 4.18) m4_define([AT_PACKAGE_VERSION], [4.18.5]) m4_define([AT_PACKAGE_STRING], [my_server 4.18.5]) Which is created by a makefile rule as suggested in the autoconf documentation: http://www.gnu.org/software/autoconf/manual/autoconf.html#Making-testsuite-Scripts So when I change the version of the package, I autoreconf, then make then autoreconf again. Scenario #2 - I have inherited a library versioning scheme that doesn't play nice with Libtool (an absolute requirement) when the Automake name is not encoded with the version - lib_LTLIBRARIES = libmy_server-4.18.la So every time I change the version argument to AC_INIT, I have to search around my makefiles for anything that references each library and make the same changes there. So I would be very interested in a solution to these issues. Cheers, Robert
Using convenience libraries with non-recursive make
I'm using automake 1.11.1 and autoconf 2.68. I am switching from a set
of hand-written Makefiles to autoconf/automake. I'm switching to
autotools since the support for cross-compilation is already there; my
hand-written Makefiles are getting hard to manage, and they don't
support VPATH builds cleanly.
I have a lot of source files (4K+) and a lot of libraries (40+). My
goal is to generate a single (typically/initially static) library and an
executable that demos/drives it. I am hoping to avoid a recursive make
(SUBDIRS=...), since I am holding to the Recursive makefiles considered
harmful mantra.
A representative Makefile.am for my project is:
# Automake rules to build application.
AM_CXXFLAGS = -I${includedir}
ACLOCAL_AMFLAGS = -I m4
bin_PROGRAMS = myprog
myprog_SOURCES = b/c/d/myprog__main.cpp
myprog_LDADD = libmyprog.la
lib_LTLIBRARIES = libmyprog.la
nodist_EXTRA_libmyprog_la_SOURCES = dummy.cxx
lib_LTLIBRARIES += liba_s1.la libb_s2.la libb_c_s3.la libb_c_d_myprog.la
libmyprog_la_LIBADD = liba_s1.la libb_s2.la libb_c_s3.la
libb_c_d_myprog.la
liba_s1_la_SOURCES = a/s1.cpp
libb_s2_la_SOURCES = b/s2.cpp
libb_c_s3_la_SOURCES = b/c/s3.cpp
libb_c_d_myprog_la_SOURCES = b/c/d/myprog.cpp
And it's similarly-simple configure.ac:
AC_PREREQ([2.59])
AC_INIT([libmyprog], [1.0], [d...@alum.mit.edu])
AM_INIT_AUTOMAKE([foreign subdir-objects])
AC_CONFIG_SRCDIR([a/s1.cpp])
AC_CONFIG_HEADERS([libmyprogconfig.h])
AC_CONFIG_MACRO_DIR([m4])
AC_PROG_MKDIR_P
AC_PROG_CXX
AM_PROG_LIBTOOL
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
The directory structure is similar to:
./a/s1.cpp
./b/s2.cpp
./b/c/d/myprog.cpp
./b/c/d/myprog__main.cpp
./b/c/s3.cpp
and in my real project there's lots more source in each subdirectory,
and lots more nested subdirectories. Yes, the source containing main()
is down deep in the structure; myprog.cpp instances some top-level
classes, and myprog_main.cpp is just the main() that gets things rolling.
When ./configure and make, I get:
del@oyster ~/am $ make
make all-am
make[1]: Entering directory `/home/del/am'
make[1]: *** No rule to make target `libmyprog.lo', needed by
`libmyprog.la'. Stop.
make[1]: Leaving directory `/home/del/am'
make: *** [all] Error 2
With the legacy hand-written makefile my project builds just fine. I'm
looking for suggestions as to what I'm missing in my Makefile.am. Note
that I can explicitly say:
$ make libb_c_s3.la
and I lo, that library's source(s) compile and link. So part of the
generated Makefile is cool.
Thanks,
-Del
Re: Using convenience libraries with non-recursive make
On 15/08/2012 08:26, Del Merritt wrote: nodist_EXTRA_libmyprog_la_SOURCES = dummy.cxx I would bet that this one is giving you trouble, but... why are you using multiple convenience libraries? If you're not going to install any of them, and the result is one final binary, you should just list all the sources to that one target. This also helps if you change some of the source files as it only needs to re-perform the final link step instead of having to do one or more ar calls. And I somehow doubt you want to use lib_LTLIBRARIES given the name (which will install the libraries as well). -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
RE: Using convenience libraries with non-recursive make
Hi Del,
First, if you're building a pure convenience library (you don't want shared
objects), then save yourself a layer of complexity by removing libtool from
the equation - just use LIBRARIES instead of LTLIBRARIES in your Makefile.am
file. Second, make sure all your relative paths are correct - that's often
the problem with errors like this.
Regards,
John
-Original Message-
From: automake-bounces+john.calcote=gmail@gnu.org
[mailto:automake-bounces+john.calcote=gmail@gnu.org] On Behalf Of
Del Merritt
Sent: Wednesday, August 15, 2012 9:27 AM
To: automake@gnu.org
Subject: Using convenience libraries with non-recursive make
I'm using automake 1.11.1 and autoconf 2.68. I am switching from a set of
hand-written Makefiles to autoconf/automake. I'm switching to autotools
since the support for cross-compilation is already there; my hand-written
Makefiles are getting hard to manage, and they don't support VPATH builds
cleanly.
I have a lot of source files (4K+) and a lot of libraries (40+). My goal
is to
generate a single (typically/initially static) library and an executable
that
demos/drives it. I am hoping to avoid a recursive make (SUBDIRS=...),
since I
am holding to the Recursive makefiles considered harmful mantra.
A representative Makefile.am for my project is:
# Automake rules to build application.
AM_CXXFLAGS = -I${includedir}
ACLOCAL_AMFLAGS = -I m4
bin_PROGRAMS = myprog
myprog_SOURCES = b/c/d/myprog__main.cpp
myprog_LDADD = libmyprog.la
lib_LTLIBRARIES = libmyprog.la
nodist_EXTRA_libmyprog_la_SOURCES = dummy.cxx
lib_LTLIBRARIES += liba_s1.la libb_s2.la libb_c_s3.la
libb_c_d_myprog.la
libmyprog_la_LIBADD = liba_s1.la libb_s2.la libb_c_s3.la
libb_c_d_myprog.la
liba_s1_la_SOURCES = a/s1.cpp
libb_s2_la_SOURCES = b/s2.cpp
libb_c_s3_la_SOURCES = b/c/s3.cpp
libb_c_d_myprog_la_SOURCES = b/c/d/myprog.cpp
And it's similarly-simple configure.ac:
AC_PREREQ([2.59])
AC_INIT([libmyprog], [1.0], [d...@alum.mit.edu])
AM_INIT_AUTOMAKE([foreign subdir-objects])
AC_CONFIG_SRCDIR([a/s1.cpp])
AC_CONFIG_HEADERS([libmyprogconfig.h])
AC_CONFIG_MACRO_DIR([m4])
AC_PROG_MKDIR_P
AC_PROG_CXX
AM_PROG_LIBTOOL
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
The directory structure is similar to:
./a/s1.cpp
./b/s2.cpp
./b/c/d/myprog.cpp
./b/c/d/myprog__main.cpp
./b/c/s3.cpp
and in my real project there's lots more source in each subdirectory, and
lots
more nested subdirectories. Yes, the source containing main() is down
deep
in the structure; myprog.cpp instances some top-level classes, and
myprog_main.cpp is just the main() that gets things rolling.
When ./configure and make, I get:
del@oyster ~/am $ make
make all-am
make[1]: Entering directory `/home/del/am'
make[1]: *** No rule to make target `libmyprog.lo', needed by
`libmyprog.la'. Stop.
make[1]: Leaving directory `/home/del/am'
make: *** [all] Error 2
With the legacy hand-written makefile my project builds just fine. I'm
looking for suggestions as to what I'm missing in my Makefile.am. Note
that I
can explicitly say:
$ make libb_c_s3.la
and I lo, that library's source(s) compile and link. So part of the
generated
Makefile is cool.
Thanks,
-Del
Re: Using convenience libraries with non-recursive make
On Wed, 15 Aug 2012, Diego Elio Pettenò wrote: why are you using multiple convenience libraries? If you're not going to install any of them, and the result is one final binary, you should just list all the sources to that one target. This also helps if you change some of the source files as it only needs to re-perform the final link step instead of having to do one or more ar calls. +1 on this opinion. The software I maintain does not use convenience libraries. They are only needed for recursive (i.e. evil) builds. Convenience libraries are slow and they block parallel builds. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Using convenience libraries with non-recursive make
On 08/15/2012 03:16 PM, Diego Elio Pettenò wrote: On 15/08/2012 08:26, Del Merritt wrote: nodist_EXTRA_libmyprog_la_SOURCES = dummy.cxx I would bet that this one is giving you trouble, but... I was using that on a hint from the automake manual: http://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html#Libtool-Convenience-Libraries Is that a known problem? why are you using multiple convenience libraries? If you're not going to install any of them, and the result is one final binary, you should just list all the sources to that one target. All good questions; mostly because I am not completely sure yet that a) I won't want to be able to install the sub-libraries later, b) my hand-built makefiles do it this way already, so I was minimizing change, and c) this is my first run creating an autoconfiscated project. Oh, and d) when I try to do a make dist with my thousands of source files, I was met with a command line too long error. So I was trying to keep things in smaller chunks to see if that would help all of the make targets work better. Thanks, -Del This also helps if you change some of the source files as it only needs to re-perform the final link step instead of having to do one or more ar calls. And I somehow doubt you want to use lib_LTLIBRARIES given the name (which will install the libraries as well).
Using convenience libraries with non-recursive make
I'm using automake 1.11.1 and autoconf 2.68. I am switching from a set
of hand-written Makefiles to autoconf/automake. I'm switching to
autotools since the support for cross-compilation is already there; my
hand-written Makefiles are getting hard to manage, and they don't
support VPATH builds cleanly.
I have a lot of source files (4K+) and a lot of libraries (40+). My
goal is to generate a single (typically/initially static) library and an
executable that demos/drives it. I am hoping to avoid a recursive make
(SUBDIRS=...), since I am holding to the Recursive makefiles considered
harmful mantra.
A representative Makefile.am for my project is:
# Automake rules to build application.
AM_CXXFLAGS = -I${includedir}
ACLOCAL_AMFLAGS = -I m4
bin_PROGRAMS = myprog
myprog_SOURCES = b/c/d/myprog__main.cpp
myprog_LDADD = libmyprog.la
lib_LTLIBRARIES = libmyprog.la
nodist_EXTRA_libmyprog_la_SOURCES = dummy.cxx
lib_LTLIBRARIES += liba_s1.la libb_s2.la libb_c_s3.la libb_c_d_myprog.la
libmyprog_la_LIBADD = liba_s1.la libb_s2.la libb_c_s3.la
libb_c_d_myprog.la
liba_s1_la_SOURCES = a/s1.cpp
libb_s2_la_SOURCES = b/s2.cpp
libb_c_s3_la_SOURCES = b/c/s3.cpp
libb_c_d_myprog_la_SOURCES = b/c/d/myprog.cpp
And it's similarly-simple configure.ac:
AC_PREREQ([2.59])
AC_INIT([libmyprog], [1.0], [d...@alum.mit.edu])
AM_INIT_AUTOMAKE([foreign subdir-objects])
AC_CONFIG_SRCDIR([a/s1.cpp])
AC_CONFIG_HEADERS([libmyprogconfig.h])
AC_CONFIG_MACRO_DIR([m4])
AC_PROG_MKDIR_P
AC_PROG_CXX
AM_PROG_LIBTOOL
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
The directory structure is similar to:
./a/s1.cpp
./b/s2.cpp
./b/c/d/myprog.cpp
./b/c/d/myprog__main.cpp
./b/c/s3.cpp
and in my real project there's lots more source in each subdirectory,
and lots more nested subdirectories. Yes, the source containing main()
is down deep in the structure; myprog.cpp instances some top-level
classes, and myprog_main.cpp is just the main() that gets things rolling.
When ./configure and make, I get:
del@oyster ~/am $ make
make all-am
make[1]: Entering directory `/home/del/am'
make[1]: *** No rule to make target `libmyprog.lo', needed by
`libmyprog.la'. Stop.
make[1]: Leaving directory `/home/del/am'
make: *** [all] Error 2
With the legacy hand-written makefile my project builds just fine. I'm
looking for suggestions as to what I'm missing in my Makefile.am. Note
that I can explicitly say:
$ make libb_c_s3.la
and I lo, that library's source(s) compile and link. So part of the
generated Makefile is cool.
Thanks,
-Del
Re: Using convenience libraries with non-recursive make
Bob Friesenhahn bfrie...@simple.dallas.tx.us writes: On Wed, 15 Aug 2012, Diego Elio Pettenò wrote: why are you using multiple convenience libraries? If you're not going to install any of them, and the result is one final binary, you should just list all the sources to that one target. This also helps if you change some of the source files as it only needs to re-perform the final link step instead of having to do one or more ar calls. +1 on this opinion. The software I maintain does not use convenience libraries. They are only needed for recursive (i.e. evil) builds. Convenience libraries are slow and they block parallel builds. I use convenience libraries with non-recursive make in Automake projects, usually because the convenience library is imported from another project and therefore represents an isolated set of code with a well-defined API. (I use it for my equivalent of gnulib, for example.) Often, the convenience library requires CPPFLAGS or the like that the rest of the project doesn't, and I like to keep those things granular so that I catch the unintentional introduction of unwanted dependencies in the rest of the code. So there are some reasons to do this. However, I agree that when you have dozens of them, there may be something amiss. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
Re: GNU Automake 1.12.3 released
Congratulations on the new release. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call
