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
aclocal.m4 is up to date but older than prerequisites (was: automake/535: Extract correct man section from files in MAN_MANS)
Let's drop the GNATS PR for this topic. * Peter Breitenlohner wrote on Mon, Mar 09, 2009 at 10:04:28AM CET: 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? I don't think current autotools have this behavior. Can you please post a small test case? Quoting a comment from aclocal.in: # We try not to update $output_file unless necessary, because # doing so invalidate Autom4te's cache and therefore slows down # tools called after aclocal. # # We need to overwrite $output_file in the following situations. # * The --force option is in use. # * One of the dependencies is younger. # (Not updating $output_file in this situation would cause # make to call aclocal in loop.) # * The contents of the current file are different from what # we have computed. Also, which system are you on, which make version do you use, and is it perhaps the case that some files have the same timestamps? make should notice that aclocal.m4 has not been updated, and consequently not run the other rules at all. At least, GNU and BSD make behave this way. IIRC make and aclocal have interesting semantic differences when files have the same timestamp, maybe that's the reason for your issues? (I don't remember the exact reason right now, but it was done deliberately.) Thanks, Ralf
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: automake/535: Extract correct man section from files in MAN_MANS
Hello Peter, * Peter Breitenlohner wrote on Sat, Mar 07, 2009 at 04:56:10PM CET: On Sat, 7 Mar 2009, Ralf Wildenhues wrote: 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. 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. Let's not go this way. The current git master version works well in this regard, with less than a dozen forks per 40 manpages that go in the same directory, of those typically only one or two `install' commands (which are by far the most expensive of them). 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? Well, your scheme still forks once per file, when computing $ext. Don't worry about it, I'm not interested in making branch-1-10 faster, all that work has gone into git master already and will be in 1.11. +# 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)? 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. :-) Cheers, Ralf
