[FYI] Merge branch 'maint' into master
commit 18143e7cfe66eaddffa481211ad4e340a11a22f4 Merge: 1efb88c 2f584fa Author: Stefano Lattarini stefano.lattar...@gmail.com Date: Sat Nov 17 20:30:11 2012 +0100 Merge branch 'maint' * maint: build: fix rebuild rules for Makefile.in and aclocal.m4 hacking: release procedure: fix order of some steps maint: post-release minor version bump release: stable release 1.12.5 Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
Re: TAP support documentation
On 11/16/2012 04:32 PM, Alexis Praga wrote: No, it won't work properly, because the old (pre-1.12) Automake testsuite harness won't be able to see and report the results saved in the *.trs files. Ok. You might correctly see some FAIL displayed by the tap-driver.sh script, but the final exit status of make check will still be zero, regardless of such errors. Otherwise, what do you recommand (upgrading is not an option) ? If you really want to use TAP in you tests, you should use some other TAP harness, like the 'prove' utility (warning: will require perl); Thanks for the suggestion. Does it always come with perl ? Yes (OTOH, the Automake harness requires just awk, but we've seen that such harness is available only since Automake 1.12). For now, I would like to avoid too much dependencies. Maybe as a last resort measure. Regards, Stefano
looking for a good example of non-recursive Make using project
Hi. I am looking for a good example of a project with non-recursive Make that is using Automake, that is not trivial. I would like to convert my project, log4cplus, to non-recursive Make style, if it is possible. Any recommendations? -- VZ signature.asc Description: OpenPGP digital signature
Re: Several pass for a simple test in make check
A band-aid solution is to have a test script automatically generated for each configuration you have to support. This might also offer better performances with concurrent make (and if your per-configuration tests are not fast, this might indeed become the preferred solution). I have thought about that, but the TESTS variable should contains around 400 files then. Is there a way to list such a large set of file automatically ? AS wildcards are not supported by Automake, the only solution I see is to create a custom macro to set TESTS by doing a 'ls' in the adequate directory. -- Alexis Praga
Re: looking for a good example of non-recursive Make using project
On Sat, Nov 17, 2012 at 11:13 AM, Václav Zeman vhais...@gmail.com wrote: Hi. I am looking for a good example of a project with non-recursive Make that is using Automake, that is not trivial. I would like to convert my project, log4cplus, to non-recursive Make style, if it is possible. Any recommendations? -- VZ I don't know if it's a good example or not, but it's non trivial and is using non-recusrvice build. As it builds several libraries and binaries, I have separated them in several files that I have called Makefile_Foo.am (they are just included and not managed by automake directly) Hth Vincent Torri
Re: looking for a good example of non-recursive Make using project
On 11/17/2012 11:13 AM, Václav Zeman wrote: Hi. I am looking for a good example of a project with non-recursive Make that is using Automake, that is not trivial. I would like to convert my project, log4cplus, to non-recursive Make style, if it is possible. Any recommendations? GNU Coreutils has been recently converted to a non-recursive make setup. You might take a look there for initial inspiration, and get back here once you have pinpointed more precise problems and/or doubts. In your case (looking at the current SVN trunk of your project), a good first step might be de-recursivize the 'tests/' and 'include/' directories. HTH, Stefano
Re: Splitting make check into separate build and run targets
On 11/16/2012 08:38 AM, Björn Stenberg wrote: Stefano Lattarini wrote: Couldn't you simply add a 'buil-tests' target that creates all the programs in $(TESTS)? Something as simple as: build-tests: $(TESTS) Then run it on the build system, before running make check on the embedded target. Or am I missing something? The check target depends on the test programs, which in turn depend on their source code files. I want to install only the test programs and test data on target, leaving out the the source and object files. That's why I created a run target that does not depend on those files being present. You could add a dummy dependency for these missing sources, so that make won't try to rebuild them (and fail, because there are no rules to do so): $ cat Makefile all: a.c b.c @echo $^ $ make # Oops, missing deps! make: *** No rule to make target `a.c', needed by `all'. Stop. $ echo status = $? status = 2 $ echo 'a.c b.c:' | make -f Makefile -f - # Lie to make a.c b.c $ echo status = $? status = 0 HTH, Stefano
Re: Several pass for a simple test in make check
On 11/17/2012 11:26 AM, Alexis Praga wrote: A band-aid solution is to have a test script automatically generated for each configuration you have to support. This might also offer better performances with concurrent make (and if your per-configuration tests are not fast, this might indeed become the preferred solution). I have thought about that, but the TESTS variable should contains around 400 files then. Is there a way to list such a large set of file automatically ? You might write a script that generates both the tests and their list, and have this list included in the Makefile.am. Automake's own build system do something similar in its bootstrap.sh script: # Create required makefile snippets. $PERL ./gen-testsuite-part t/testsuite-part.tmp chmod a-w t/testsuite-part.tmp mv -f t/testsuite-part.tmp t/testsuite-part.am You might want to peek at the Automake tarball for more details. AS wildcards are not supported by Automake, the only solution I see is to create a custom macro to set TESTS by doing a 'ls' in the adequate directory. You mean at configure runtime? Like in: # in configure.ac all_tests=`cd $srcdir echo *.test` AC_SUBST([all_tests) # in Makefile.am TESTS = @all_tests@ That would be feasible as well, but only if you use tests with the '.test' suffix, or some other suffixes declared in TEST_EXTENSIONS (this will allow Automake to produce correct rules even without knowing the list of tests at automake runtime). HTH, Stefano
Re: looking for a good example of non-recursive Make using project
On 11/17/2012 11:36 AM, Vincent Torri wrote: On Sat, Nov 17, 2012 at 11:13 AM, Václav Zeman vhais...@gmail.com wrote: Hi. I am looking for a good example of a project with non-recursive Make that is using Automake, that is not trivial. I would like to convert my project, log4cplus, to non-recursive Make style, if it is possible. Any recommendations? -- VZ I don't know if it's a good example or not, but it's non trivial and is using non-recusrvice build. As it builds several libraries and binaries, I have separated them in several files that I have called Makefile_Foo.am (they are just included and not managed by automake directly) Maybe I am getting blind or you have forgotten to actually mention what is the example. :) -- VZ signature.asc Description: OpenPGP digital signature
Re: looking for a good example of non-recursive Make using project
On Sat, 17 Nov 2012, Václav Zeman wrote: Hi. I am looking for a good example of a project with non-recursive Make that is using Automake, that is not trivial. I would like to convert my project, log4cplus, to non-recursive Make style, if it is possible. Any recommendations? I am not sure if it is a good example (might not use official recommended practices) but GraphicsMagick (~300K lines of code) has been using non-recursive make since not long after Automake supported it. Parallel build is shown to scale very well on multi-core systems (tested on up to 64 cores). I am observing 86% per-core scalability for fully optimized (-O2) debuggable (-g -g3 -ggdb) builds, with the linker being the main limiter of scalability. Make sure to avoid any directory recursion and avoid use of things like libtool convenience libraries. Try to simplify the dependency chain so as many files may be compiled at once as possible. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
How Do Parallel Builds Scale?
I suspect that this anaysis has been mentioned on the Automake list before but (if so) it is worth looking at again. It seems that few packages benefit significantly from parallel builds. Many packages use Automake, but they use it in a very inefficient way. Here is a web page which shows the current pitiful state of parallel builds: http://hubble.gforge.inria.fr/parallel-builds.html Given that even desktop and laptop computers support 4 CPU cores and that affordable server type hardware is available with as many as 64 CPU cores, it is useful if the build process of packages is redone so that it benefits from compilation on modern hardware. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
GNU Automake 1.12.5 released
We are pleased to announce the Automake 1.12.5 maintenance release. This release fixes a couple of minor bugs: one related to the use of Microsoft tools for compiling and linking, the other related to spurious remake rules being generated in some cases by the AC_CONFIG_HEADERS macro. Support for the Vala programming language is also enhanced. See below for the detailed list of changes since Automake 1.12.4, as summarized by the NEWS file. Download here: ftp://ftp.gnu.org/gnu/automake/automake-1.12.5.tar.gz ftp://ftp.gnu.org/gnu/automake/automake-1.12.5.tar.xz Please report bugs and problems to bug-autom...@gnu.org, and send general comments and feedback to automake@gnu.org. Thanks to everyone who has reported problems, contributed patches, and helped testing Automake! -*-*-*- New in 1.12.5: * WARNING: Future backward-incompatibilities! - Future versions of Automake will likely drop support for the long-deprecated 'configure.in' name for the Autoconf input file. You are advised to use the recommended name 'configure.ac' instead. - Support for the Cygnus-style trees (as enabled by the 'cygnus' option) will be removed in the next major Automake release (1.13). - The long-obsolete (since automake 1.10) AM_PROG_MKDIR m4 macro will be removed in Automake 1.13. The $(mkdir_p) make variable and the @mkdir_p@ substitution will still remain available (as aliases of $(MKDIR_P)) for the moment, for better backward compatibility. - Autoconf 2.65 or later will be required by the next major Automake version (1.13). Until now, Automake has required Autoconf version 2.62 or later. - Starting from the next major Automake version (1.13), the rules to build pdf, ps and dvi output from Texinfo input will use the '--build-dir' option by default. Since such an option was only introduced in Texinfo 4.9, this means that Makefiles generated by future Automake versions will require at least that version of Texinfo. - Starting from the next major Automake version (1.13), the parallel testsuite harness (previously only enabled by the 'parallel-tests' option) will become the default one; the older serial testsuite harness will still be available through the use of the 'serial-tests' option. - The following long-obsolete m4 macros will be removed in the next major Automake version (1.13): AM_PROG_CC_STDC:superseded by AC_PROG_CC since October 2002 fp_PROG_CC_STDC:broken alias for AM_PROG_CC_STDC fp_WITH_DMALLOC:old alias for AM_WITH_DMALLOC AM_CONFIG_HEADER: superseded by AC_CONFIG_HEADERS since July 2002 ud_PATH_LISPDIR:old alias for AM_PATH_LISPDIR jm_MAINTAINER_MODE: old alias for AM_MAINTAINER_MODE ud_GNU_GETTEXT: old alias for AM_GNU_GETTEXT gm_PROG_LIBTOOL:old alias for AC_PROG_LIBTOOL fp_C_PROTOTYPES:old alias for AM_C_PROTOTYPES (which was part of the now-removed automatic de-ANSI-fication support of Automake) - All the old alias macros in 'm4/obsolete.m4' will be removed in the next major Automake version (1.13). - The '--acdir' option of aclocal is deprecated, and will probably be removed in the next major Automake release (1.13). You should use the options '--automake-acdir' and '--system-acdir' instead (which have been introduced in Automake 1.11.2). - The 'missing' script will no longer try to update the timestamp of out-of-date files that require a maintainer-specific tool to be remade, in case the user lacks such a tool (or has a too-old version of it). In fact, starting from Automake 1.13, all it'll do will be giving more useful warnings than a bare command not found from a make recipe would. * Vala support: - The AM_PROG_VALAC macro has been enhanced to takes two further optional arguments; it's signature now being AM_PROG_VALAC([MINIMUM-VERSION], [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND]) - By default, AM_PROG_VALAC no longer aborts the configure invocation if the Vala compiler found is too old, but simply prints a warning messages (as it did when the Vala compiler was not found). This should avoid unnecessary difficulties for end users that just want to compile the unmodified, distributed Vala-generated C sources, but happens to have an old Vala compiler in their PATH. This fixes automake bug#12688. - If no proper Vala compiler is found at configure runtime, AM_PROG_VALAC will set the AC_SUBST'd variable 'VALAC' to 'valac' rather than to ':'. This is a better default, because with it a triggered makefile rule invoking a Vala compilation will clearly fail with an informative error message like valac: command not found, rather than silently, with the error possibly going unnoticed or triggering harder-to-diagnose fallout failures in later
Re: NASM/YASM support
Hi Luca. On 11/17/2012 08:28 PM, Luca Barbato wrote: Hi, VLC is considering adding some nasm/yasm assembly in its codebase and that would require adding support to it in their autotools build system. How likely would be to add support for such assembler directly in automake? I know basically nothing about assembly, and this is just a quick reply before bedtime, but... would this help? http://www.gnu.org/software/automake/manual/automake.html#Assembly-Support If not, what's missing? HTH, Stefano
Re: NASM/YASM support
On 17/11/2012 16:08, Stefano Lattarini wrote: I know basically nothing about assembly, and this is just a quick reply before bedtime, but... would this help? Not really. The problem with that, is that it's designed to support gas-style assembly (i.e. using the GCC frontend to compile the assembly). NASM at least does not conform to this that much, and it does not support the -c option. Basically what Luca is looking for is adding specific rules for using nasm-style command lines for building (yasm would follow from that). Not sure how easy it is tbh. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: GNU Automake 1.12.5 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
