bug#20186: Failure to create directory during info-building phase of make distcheck
On Tue, 24 Mar 2015, James Youngman wrote: The timestamps look OK to me: ... Perhaps the cause is this rule, though: dblocation.texi: ../locate/dblocation.texi cp ../locate/dblocation.texi $@ This will clearly update the mtime of dblocation.texi. Hi James, indeed. You could use the modified rule dblocation.texi: ../locate/dblocation.texi $(LN_S) ../locate/dblocation.texi $@ where $(LN_S) is 'ln -s' on systems with working symlinks or otherwise one of 'ln' or 'cp'. I assume your Makefile.in already contains LN_S = @LN_S@ otherwise you should add AC_PROG_LN_S to your configure.ac. I assume 'make distcheck' will never run on systems without working symlinks so this should be OK. Regards Peter
bug#20186: Failure to create directory during info-building phase of make distcheck
On Tue, 24 Mar 2015, James Youngman wrote: I'm seeing a failure of make distcheck which I think is caused by the fact that Automake 1.14.1's rule for .texi.info is trying to create a backup directory in a read-only directory: Hi James, the .info file in the read-only directory should not be older than the .texi file (and other dependencies), thus the rule for .texi.info should never be used during make distcheck. Something wrong with your timestamps and or filesystem? Regards Peter Breitenlohner p...@mppmu.mpg.de
bug#11346: automake-1.12 - one test fails (due to truncated timestamp)
On Thu, 26 Apr 2012, Stefano Lattarini wrote: Good idea. Can you confirm that the attached patch solves your problem? Hi Stefano, it does indeed. BTW: The Copyright-paperwork-exempt: yes should be unnecessary because you should still have the paperwork from the ObjC++ integration. Regards Peter
bug#11346: automake-1.12 - one test fails (due to truncated timestamp)
On Thu, 26 Apr 2012, Stefano Lattarini wrote: because you should still have the paperwork from the ObjC++ integration. I wasn't involved in the project yet back then, so I wasn't aware you had the paperwork in place already. Now I am :-) Hi Stefano, and the whole ObjC++ integration (one of two reasons I was waiting for 1.12) somehow got lost. I still have the old patches 0001-2009-07-22-Support-for-Objective-C.patch from 2009-07-22 etc, but could also apply them to the current git version and send you these. I may, however, have problem to modernize the test cases. Regards Peter
bug#10997: pkglibexecdir is unconditionally created when make install
On Mon, 12 Mar 2012, Stefano Lattarini wrote: On 03/12/2012 05:55 AM, Daiki Ueno wrote: I got a bug report for my package, which conditionally installs some scripts into pkglibexecdir like this: if ENABLE_FOO pkglibexec_SCRIPTS = bar endif where pkglibexec* is not referred outside of if...endif. When make install, automake creates pkglibexecdir even when ENABLE_FOO is false. I'm attaching a prove which demonstrates the behavior. I agree it would be nice to avoid creating directories that are not actually needed; still, this is a low-priority bug, and I'm not yet sure how difficult it would be to fix. For the moment, I've committed (in your name) the test case you've sent us (with minor tweakings), so that the bug will at least remain exposed in the testsuite. Attached is the patch I've pushed (to maint). Fixing this particular case might be fine, but please watch out. In the quite similar (unconditional) case pkglibexec_SCRIPTS = one might actually expect that that $(pkglibexecdir) is created unconditionally. (Perhaps because 'install-exec-local' or 'install-data-local' wants to install some files into that directory.) In the TeX Live build system we actually use something quite analogous: nodist_bin_SCRIPTS = texmfdir = $(datarootdir)/texmf/scripts/xindy nodist_texmf_SCRIPTS = texindy.pl xindy.pl install-data-hook: install-perl-links where 'install-perl-links' installs in $(bindir) the symbolic links 'texindy' and 'xindy' pointing to the respective perl scripts in $(texmfdir). To summarize: 'nodist_bin_SCRIPTS =' is an extremely convenient way to ensure that $(bindir) -- or rather $(DESTDIR)$(bindir) -- exists. Regards Peter Breitenlohner p...@mppmu.mpg.de
bug#8969: improve synchronization between examples in the manual and test cases
On Fri, 1 Jul 2011, Stefano Lattarini wrote: Oops, one of the amhello tests has an unecessary requirement (copy paste blunder). Consider the following squashed in: diff --git a/tests/amhello-binpkg.test b/tests/amhello-binpkg.test index 8da3495..47add73 100755 --- a/tests/amhello-binpkg.test +++ b/tests/amhello-binpkg.test @@ -17,7 +17,6 @@ # Document an example from the manual about the `amhello' package: # using DESDIR to build simple, no-frills binary packages. Hi Stefano, could this be a typo (DESDIR vs DESTDIR)? Regards Peter Breitenlohner p...@mppmu.mpg.de
bug#8718: error when using nested conditionals
On Fri, 10 Jun 2011, Stefano Lattarini wrote:
Nope, it gets the information from the fact each AM_CONDITIONAL invocation
does this:
AC_CONFIG_COMMANDS_PRE(
[if test -z ${$1_TRUE} test -z ${$1_FALSE}; then
AC_MSG_ERROR([[conditional $1 was never defined.
Usually this means the macro was only invoked conditionally.]])
fi])])
Hi Stefano, Bruno,
how about the following alternative (for all conditionals, or just for some
of them, e.g., those under the regime of AM_IGNORE_UNDEFINED_CONDITIONALS):
Replace the AC_MSG_ERROR() above by a warning and set both $1_TRUE and
$1_FALSE to something that, when not hidden in a false branch of the
Makefile, (1) triggers a make syntax error, and (2) contains sufficient info
to deduce the cause for that error.
That way there is a warning from configure (often overlooked and/or
ignored), but an error from make only if that conditional is actually
needed.
Regards
Peter
bug#7833: automake uses two different values for DejaGNU srcdir
On Fri, 14 Jan 2011, Ralf Wildenhues wrote: Through testing I found out again that DejaGNU does not cope with white space in absolute directory names anyway, regardless of srcdir being relative or absolute. That obviates my first point. Remains only the fairly minor src+build-tree relocatability point. Hi Ralf, I remember a problem with gcc's 'make check' that could be related. Some tests failed when `pwd -L` was different from `pwd -P`, presumably due to the two different srcdir's. I could avoid this problem by first doing 'cd `pwd -P`'. Regards Peter Breitenlohner p...@mppmu.mpg.de
Re: automake/535: Extract correct man section from files in MAN_MANS
On Sat, 7 Mar 2009, Ralf Wildenhues wrote: Erm, I've already done all that in the patch that I posted; and I have applied to master. So there is nothing left to do on this topic, except to argue (if you want) that this should be fixed in branch-1-10. :-) Hello Ralf, not really, since there is a reasonable workaround. BTW: any idea about the schedule for for 1-11? == There is, however, a completely different problem. I am using Automake together with an m4/ directory, and my top-level Makefile.am starts with 'ACLOCAL_AMFLAGS = -I m4'. Consequently the generated aclocal.m4 ends with several 'm4_include([m4/xxx.m4])'s. The problem is, that when any of these m4/*.m4 files is changed (and maintainermode is enabled explicitly or by default), then 'make' runs aclocal but doesn't update aclocal.m4 because that remains the same. Thus aclocal is run again and again, quite inconvenient. IMHO a better alternative would be to touch aclocal.m4 and consequently run configure and automake once, but never again until some other files are changed. I found the present behaviour fairly annoying and would prefer if it could be changed as indicated above. However, I am not quite sure how that would be done best: in aclocal or in the rule generated by autmoake? Regards, Peter Breitenlohner p...@mppmu.mpg.de
Re: automake/535: Extract correct man section from files in MAN_MANS
On Sat, 7 Mar 2009, Ralf Wildenhues wrote: Attached is a small patch (current git) correcting this problem. @@ -39,8 +39,8 @@ if %?NOTRANS_MANS% ## Extract all items from notrans_man_MANS that should go in this section. ## This must be done dynamically to support conditionals. ?HAVE_NOTRANS? l2='%NOTRANS_LIST%'; for i in $$l2; do \ -## Accept files like `foo.1c'. -?HAVE_NOTRANS? case $$i in *.%SECTION%*) echo $$i;; esac; \ +## Accept for `man1' files like `foo.1c' but not `sub.1/foo.2' or `foo-2.1.4'. +?HAVE_NOTRANS? case `echo $$i | sed -e 's,.*\.,,'` in %SECTION%*) echo $$i;; esac; \ ?HAVE_NOTRANS? done; \ ## Extract basename of manpage, change the extension if needed. } | while read p; do \ This has the disadvantage that we're now again forking at least twice per installed file. The point of the install rule changes in master was to make them faster! :-) I don't know a good way to fix this without adding any forks at all, but the patch below fixes the issue for master with adding two forks per set of man pages installed. It uses the same regex for matching the section as is used in automake.in. Hallo Ralf, actually, I never thought about that aspect. I think there is a way to reduce the number of forks, replacing the two loops by one such that one could extract ext rather early and reuse it later on. However, this would be major surgery and require extensive testing. The idea is roughly this, e.g., for the install-man1 target: dot_seen=no for i in $(man1_MANS) . $(man_MANS); do if test x$i = x.; then dot_seen=yes continue fi ext=`echo $i | sed -e 's/^.*\\.//'` case $ext in 1*) ;; *) if test $dot_seen = yes; then continue else ext=1 fi ;; esac [proceed as now, reusing the ext extracted above] done Could also be 'dot_seen=false', 'dot_seen=:', and 'if $dot_seen; then'. This is for branch-1-10. Perhaps something analogous can be done for the new scheme in git master (just updated my local copy, still have to study it). Comments? +# Let's play with $DESTDIR too, it shouldn't hurt. +./configure --prefix='' --mandir=/man Let's just omit --prefix here, rather than passing an empty one. Also, let's add a 'make uninstall' as well as the notrans man pages, so all changed code paths are exercised; and rename a bit, so we can better test that no wrong directories are created. Shall I try to do that, or will you (knowing better exactly what you have in mind)? Regards, Peter Breitenlohner p...@mppmu.mpg.de
Re: MAINTAINERCLEANFILES in srcdir
On Thu, 15 Mar 2007, Stepan Kasal wrote: Hello Ralf, On Thu, Mar 15, 2007 at 09:11:37AM +0100, Ralf Wildenhues wrote: * Stepan Kasal wrote on Wed, Mar 14, 2007 at 01:34:06PM CET: -test -n $(MAINTAINERCLEANFILES) \ rm -f $(MAINTAINERCLEANFILES) \ cd $(srcdir) rm -f $(MAINTAINERCLEANFILES) . Hello Ralf, Stepan, quite some time ago I sent an email about a different but somewhat related problem (together with a very small and simple patch): When some manpages are present in both the source and build tree, the automake generated rules install those from the source tree and not those from the build tree as it should be. Unfortunately I never got an answer and last time I looked in CVS this bug was still there. Couldn't you take care of that problem? regards Peter Breitenlohner [EMAIL PROTECTED]
A problem (bug) in automake (1.10 and earlier version)
I have noticed the following problem (bug) in automake-1.10:
(1) A package (ImageMagick-6.3.0) uses configure to generate manpages with
substitutions (e.g., .1 from .1.in) but also distributes the
generated manpages from an older version (i.e., with wrong substitutions).
(2) The automake-generated rule to install manpages looks for the files to
install FIRST under ${srcdir} and THEN under the current directory.
===
The effect of (1)+(2) is, that the manpages with the wrong substitutions are
installed.
===
(1) is certainly not the right way to do things.
On the other hand I would think that (2) is equally wrong. Whenever a file
is to be installed, then the automake-generated rules should FIRST look for
that file in the current directory and THEN under ${srcdir}!
===
Peter Breitenlohner [EMAIL PROTECTED]
