Re: sections without nodes in automake manual?

[Ralf Wildenhues]

Hi Karl,

thanks for the quick review!

* Karl Berry wrote on Fri, Mar 27, 2009 at 11:26:24PM CET:
 
 +* SUBDIRS vs DIST_SUBDIRS:: Two sets of directories
 
 Probably a period after vs, to match the @subsection name (and because
 this manual is (primarily?) in American English rather than British
 English).

What about this node in (texinfo)Node Line Requirements:

   * Unfortunately, you cannot use periods, commas, colons or
 parentheses within a node name; these confuse the Texinfo
 processors.  Perhaps this limitation will be removed some day, too.

In light of that, I haven't added a period here yet.
It seems to work with makeinfo 4.11.90 though.
Has this recently been fixed, and if yes, in which texinfo version?
Thanks.  I don't want to have to require a very recent one.

 +* Non-configured Subdirectories::  Not even creating a @samp{Makefile}
 
 I think Unconfigured would be somewhat more idiomatic English, unless
 I'm missing some subtle distinction you're making.

Nope, fixed throughout the manual.

 +* The two Parts of Install::Installing data and programs separately
 
 two should be capitalized.

Fixed.

 +...@node Subdirectories with AM_CONDITIONAL
 +...@subsection Conditional Subdirectories with @code{AM_CONDITIONAL}
 
 I am a fan of making the node name and sectioning name the same,
 wherever possible.  Overall, this makes it easier for the reader.  I
 think length of the node name is far less important.

But it will make the menus all ugly, no?  Anyway, I like this too.

 So in this case (and the following similar cases) I would either have
 the Conditional in both names, or neither.

I've removed it from both now, as well as the next node.

 +...@node Required file ltmain.sh not found
  @subsubsection @samp{required file `./ltmain.sh' not found}
 
 Perhaps prepend the word Error: to both, and downcase required in
 the @node.

Again, what about colons which are disallowed in @node names, and
actually cause errors with this makeinfo version?

 @subsubsection Objects @samp{created with both libtool and without}
 
 Why @samp?  Is this more error message text?

Yes.

 -...@subsection Third-party files
 +...@subheading Third-party files
 
 Files should be capitalized for consistency.  Probably something to
 check throughout ...

Done in all headings and node names.

 +...@node Recommendations for Tools
  @subsection Recommendations for Tool Writers
 
 Again I'd make the two names the same.  In this case, the two versions
 even mean different things :).

Indeed.  Adjusted.

 +* Future Directions for Dependencies::  Languages Automake does not know
 ...
 +...@node Future Directions for Dependencies
  @subsection Future Directions for Automake's Dependency Tracking
 
 I think the @subsection should be made the same as @node here.
 Automake's doesn't buy anything.

Agreed.

 That's an unusual description in the menu, but interesting :).

| * Future Directions for Dependencies::  Languages Automake does not know

What is unusual about it?

 For example, one thing I don't like much with the result yet is that the
 introductory chapter has a section about two-part install, and its name
 is very similar to the section about two-part install later.
 
 Can you send me the whole master menu after applying changes above as
 you see fit, and I'll look again?

Thanks, here you go.

Cheers,
Ralf

@menu
* Introduction::Automake's purpose
* Autotools Introduction::  An Introduction to the Autotools
* Generalities::General ideas
* Examples::Some example packages
* Invoking Automake::   Creating a Makefile.in
* configure::   Scanning configure.ac or configure.in
* Directories:: Declaring subdirectories
* Programs::Building programs and libraries
* Other objects::   Other derived objects
* Other GNU Tools:: Other GNU Tools
* Documentation::   Building documentation
* Install:: What gets installed
* Clean::   What gets cleaned
* Dist::What goes in a distribution
* Tests::   Support for test suites
* Rebuilding::  Automatic rebuilding of Makefile
* Options:: Changing Automake's behavior
* Miscellaneous::   Miscellaneous rules
* Include:: Including extra files in an Automake template
* Conditionals::Conditionals
* Gnits::   The effect of @option{--gnu} and 
@option{--gnits}
* Cygnus::  The effect of @option{--cygnus}
* Not Enough::  When Automake is not Enough
* Distributing::Distributing the Makefile.in
* API versioning::  About compatibility between Automake versions
* Upgrading::   Upgrading to a Newer Automake 

Re: sections without nodes in automake manual?

[Karl Berry]

   * Unfortunately, you cannot use periods, commas, colons or
 parentheses within a node name; these confuse the Texinfo
 processors.  Perhaps this limitation will be removed some day, too.

Oh yeah :).

Well, the situation is that in practice, periods only cause trouble in
unusual circumstances.  Like a cross-manual reference to the node from
another manual?  And even then it often works.  To be honest, I don't
remember the exact problematic case(s).

Colons, on the other hand, are definitely troublesome, even in regular
menus they can break.

So, you're right, probably best to leave the punctuation out of the node
names.  None of this behavior has changed since the inception of
Texinfo, by the way.

| * Future Directions for Dependencies::  Languages Automake does not know
What is unusual about it?

Just that languages and dependencies sound like quite different
things, even though they're not in this case, exactly.  I think it's ok.

Thanks, here you go.

Nothing jumped out at me.  What were the close introductory names you
were concerned about?


All I noticed were several that need capitalization fixes:

* Length limitations::  Staying below the command line length limit
* Macro search path::   How aclocal finds .m4 files
* Public macros::   Macros that you can use.
* Obsolete macros:: Macros that you should stop using.
* Private macros::  Macros that you should not use.
* Program variables::   Variables used when building a program
* Built sources example::   Several ways to handle built sources.

Maybe something like grep '^...@node .* [a-z]' would help for a quick
check.  (It'll get false matches too, but anyway.)

Thanks,
Karl

Re: sections without nodes in automake manual?

[Ralf Wildenhues]

Hi Karl,

* Karl Berry wrote on Sat, Mar 28, 2009 at 11:25:26PM CET:
* Unfortunately, you cannot use periods, commas, colons or
  parentheses within a node name; these confuse the Texinfo
  processors.  Perhaps this limitation will be removed some day, too.
 
 Oh yeah :).
 
 Well, the situation is that in practice, periods only cause trouble in
 unusual circumstances.  Like a cross-manual reference to the node from
 another manual?  And even then it often works.  To be honest, I don't
 remember the exact problematic case(s).

Ah, ok.  Thanks.

 Colons, on the other hand, are definitely troublesome, even in regular
 menus they can break.

OK.  I will leave both out, also for consistency: the Autoconf manual
also has a FOO vs BAR node without a period in the node name.

 | * Future Directions for Dependencies::  Languages Automake does not know
 What is unusual about it?
 
 Just that languages and dependencies sound like quite different
 things, even though they're not in this case, exactly.  I think it's ok.

Good.

 Thanks, here you go.
 
 Nothing jumped out at me.  What were the close introductory names you
 were concerned about?

`The Two Parts of Install' and `Two-Part Install'.  Oh well, they do
have the same topic, and the latter even links to the former.

 All I noticed were several that need capitalization fixes:
 
 * Length limitations::  Staying below the command line length limit
 * Macro search path::   How aclocal finds .m4 files
 * Public macros::   Macros that you can use.
 * Obsolete macros:: Macros that you should stop using.
 * Private macros::  Macros that you should not use.
 * Program variables::   Variables used when building a program
 * Built sources example::   Several ways to handle built sources.
 
 Maybe something like grep '^...@node .* [a-z]' would help for a quick
 check.  (It'll get false matches too, but anyway.)

OK thanks, I will fix them before I push.

Thanks again!
Ralf

manual: minor cleanups.

[Ralf Wildenhues]

This trivial patch fixes a couple of minor glitches in the manual.
Committed to master and branch-1-10.

Cheers,
Ralf

manual: minor cleanups.

* doc/automake.texi (Yacc and Lex): Adjust spacing in example.
(Mixing Fortran 77 With C and C++): Drop unneeded @page breaks.

diff --git a/doc/automake.texi b/doc/automake.texi
index 2d1e6f8..2f756b6 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -6032,7 +6032,7 @@ We recommend using the following renaming hack used in 
@command{gdb}:
 #define yylhs   c_yylhs
 #define yylen   c_yylen
 #define yydefred c_yydefred
-#define yydgoto c_yydgoto
+#define yydgoto  c_yydgoto
 #define yysindex c_yysindex
 #define yyrindex c_yyrindex
 #define yygindex c_yygindex
@@ -6312,7 +6312,6 @@ Fortran 77, C and C++ compilers on nearly all platforms.  
However,
 @command{cfortran} is not yet Free Software, but it will be in the next
 major release.}.
 
-...@page
 Automake can help in two ways:
 
 @enumerate
@@ -6365,8 +6364,6 @@ is mentioned in @file{configure.ac}.  Also, if 
@samp{$(FLIBS)} hadn't
 been mentioned in @code{foo_LDADD} and @code{libfoo_la_LIBADD}, then
 Automake would have issued a warning.
 
-
-...@page
 @menu
 * How the Linker is Chosen::Automatic linker selection
 @end menu

Re: proposed patch: parallel-tests: per-extension test driver: ext_COMPILE.

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Tue, Mar 24, 2009 at 10:57:16PM CET:
 How about this?  I really appreciate a look over this.
 
 Note that for extension .foo, the variable names will be FOO_LOG_*,
 i.e., remove the dot, then uppercase the rest.
 
 I chose to go all the way and add AM_*FLAGS too.
 
 One could, as a generalization, even add, for the non-extension rules,
 add
   LOG_COMPILER = $(LOG_COMPILE) $(AM_LOG_FLAGS) $(LOG_FLAGS)
 
 but I haven't done that yet.  WDYT?

For now, I have pushed the patch as-is to the ad-parallel-tests branch.

Cheers,
Ralf

 parallel-tests: per-extension test driver: EXT_LOG_COMPILER.
 
 For test files with extension ext, introduce the internal
 variable EXT_LOG_COMPILE, which expands to
 $(EXT_LOG_COMPILER) $(AM_EXT_LOG_FLAGS) $(EXT_LOG_FLAGS).
 Turn also the lib/Automake/tests testsuite over to the new
 test driver.
 * doc/automake.texi (Tests): Document `EXT_LOG_COMPILER' and
 `EXT_LOG_FLAGS'.
 * lib/am/check2.am: Insert `%COMPILE%' right before test.
 * automake.in (handle_tests): Substitute `COMPILE' for check2,
 empty for tests without extension, and `$(ext_LOG_COMPILE)' for
 extension `ext'.  In the latter case, define it from the public
 components.
 * configure.ac (AM_INIT_AUTOMAKE): Use `parallel-test' globally.
 * tests/Makefile.am (AUTOMAKE_OPTIONS): Remove, not needed here
 any more.
 * lib/Automake/tests/Makefile.am (TESTS_ENVIRONMENT): Split ...
 (PL_LOG_COMPILER, PL_LOG_FLAGS): ... into these new variables.
 (TESTS_EXTENSIONS): New variable, initialize to `.pl'.
 * tests/parallel-tests7.test: New test.
 * tests/Makefile.am: Update.
 Suggestion by Akim Demaille.

check-html: Always create HTML output, note conversion failure.

[Ralf Wildenhues]

* Akim Demaille wrote on Sat, Mar 14, 2009 at 01:39:07PM CET:
 # Be sure to run check-TESTS first, and then to convert the result.
 # Beware of concurrent executions.  Run check, not check-TESTS,
 # since the dependencies (check_PROGRAMS and others) are attached to
 # the former, not the latter.  And expect check to fail.
 check-html:
 @if $(MAKE) $(AM_MAKEFLAGS) check; then :; else \
   rv=$$?;   \
   $(MAKE) $(AM_MAKEFLAGS) $(TEST_SUITE_HTML);   \
   exit $$rv;\
 fi

I noted that this is not in line with with how check-TESTS works,
always creating $(TEST_SUITE_LOG).

This patch fixes it.  Applied to ad-parallel-tests.

Cheers,
Ralf

check-html: Always create HTML output, note conversion failure.

* lib/am/check.am (check-html): Create `$(TEST_SUITE_HTML)' in
any case.  Exit unsuccessfully if HTML creation failed.
* tests/parallel-tests2.test: Amend test to expose this.

diff --git a/lib/am/check.am b/lib/am/check.am
index 28af2ee..b8b512e 100644
--- a/lib/am/check.am
+++ b/lib/am/check.am
@@ -266,11 +266,11 @@ check-TESTS:
 # Be sure to run check-TESTS first, and then to convert the result.
 # Beware of concurrent executions.  And expect check-TESTS to fail.
 check-html:
-   @if $(MAKE) $(AM_MAKEFLAGS) check-TESTS; then :; else   \
- rv=$$?;   \
- $(MAKE) $(AM_MAKEFLAGS) $(TEST_SUITE_HTML);   \
- exit $$rv;\
-   fi
+   @if $(MAKE) $(AM_MAKEFLAGS) check-TESTS; then   \
+ rv=0; else rv=$$?;\
+   fi; \
+   $(MAKE) $(AM_MAKEFLAGS) $(TEST_SUITE_HTML) || exit 4;   \
+   exit $$rv
 .PHONY: check-html
 .MAKE: check-html
 
diff --git a/tests/parallel-tests2.test b/tests/parallel-tests2.test
index 17a5108..61b05e8 100755
--- a/tests/parallel-tests2.test
+++ b/tests/parallel-tests2.test
@@ -56,4 +56,11 @@ $AUTOMAKE -a
 $MAKE check-html stdout  { cat stdout; Exit 1; }
 cat stdout
 test -f mylog.html
+
+# Always create the HTML output, even if there were no failures.
+rm -f mylog.html
+env TESTS=foo.test $MAKE -e check-html stdout || { cat stdout; Exit 1; }
+cat stdout
+test -f mylog.html
+
 :

parallel-tests: do not mark check-TESTS as `.MAKE'.

[Ralf Wildenhues]

This patch fixes a small glitch I overlooked earlier.
Pushed to ad-parallel-tests.

Cheers,
Ralf

parallel-tests: do not mark check-TESTS as `.MAKE'.

* lib/am/check.am [PARALLEL_TESTS] (.MAKE): Remove check-TESTS.
This rule removes files, which should not be executed with BSD
`make -n'.

diff --git a/lib/am/check.am b/lib/am/check.am
index b8b512e..1880de5 100644
--- a/lib/am/check.am
+++ b/lib/am/check.am
@@ -242,7 +242,6 @@ check-TESTS:
  set_logs=TEST_LOGS=;  \
fi; \
$(MAKE) $(AM_MAKEFLAGS) $(TEST_SUITE_LOG) $$set_logs
-.MAKE: check-TESTS
 
 
 ## -- ##

parallel-tests: redo lazy checking: recheck and RECHECK_LOGS.

[Ralf Wildenhues]

Hi Akim,

* Akim Demaille wrote on Sat, Mar 14, 2009 at 01:39:07PM CET:

 For the records, here is the version I use currently, some of bugs you  
 mentioned being fixed.  I don't know which was the last I sent, so I  
 can't send a patch.  Among changes that I believe, are worth mentioning 
 are:

 - make recheck
   runs only the test that failed last time.

This is a nice idea.  Thanks!

 Contrary to your implementation, I still accept TESTS=foo.log whereas  
 the genuine test is foo.test.  This makes many things easier, and it is 
 also very convenient for the user.  I have a test suite which uses many 
 different extensions, in which case it is simpler for me brains to simply 
 enter the (base)name of the test(s).

Agreed.  While I won't change the TESTS=foo.test semantics, we can
publish that the user can use TEST_LOGS=foo.log to limit the tests to be
run.

 - LAZY_TEST_SUITE is not flexible enough
   It is global, it should be per test-case.

Indeed.  I like your idea, but I don't like the naming scheme too much,
nor do I think we need to be backwards compatible with an unpublished
interface.  I'm removing the LAZY_TEST_SUITE API and replacing it with a
RECHECK_LOGS API (instead of your STRICT_TESTS).

Sorry if this causes trouble for you.

 I often use

   STRICT_TEST_LOGS = $(shell $(LIST_FAILED_TEST_LOGS))

 which makes all failing test strict.  In other words, successful tests  
 are not rerun by make check, but failing tests are.  This is because  
 our test suite sometimes hits the limit of the machine, and tests  
 timeout for no sound reason.  So there is no reason to rerun successful 
 tests, but failing test might pass if the machine has a lesser load.

This is what the 'recheck' target does, right?

Here's what I've been able to come up with, and I think it is portable,
but I still need to test it on various systems.

One thing that one needs to look out for is, when overriding variables
in recursive `make' instances is that non-GNU make don't override by
default unless you use `make -e' and pass via the environment.
Requiring our users to do so if they want to override variables is ok
IMVHO, because then they are warned that their environment needs to be
clean.  OTOH using -e internally is not ok at all, as the users may not
be aware, and their environment could cause subtle breakage.  So
consequently we can only transport overrides one recursion deep and not
any further, unless each lower re-sets the variables on the make command
line.

This detail was BTW the reason that I have backed off of allowing shell
globbing for TESTS or TEST_LOGS.  It is just too complicated to get
right portably, causes other problems (e.g., I do not want to have a
rule that has both TESTS and TEST_LOGS expanded in one shell command:
it might overrun command line length limits), and can be emulated by the
user on the command line or with a script (or, for GNU make, a simple
wrapper target).  Thus this patch documents such an example.

Anyway, so much for details.  Here's what I'm pushing to
ad-parallel-tests.

Cheers,
Ralf

2009-03-28  Ralf Wildenhues  ralf.wildenh...@gmx.de
Akim Demaille  a...@lrde.epita.fr

parallel-tests: redo lazy checking: recheck and RECHECK_LOGS.
Replace the LAZY_TEST_SUITE API with a simpler yet more powerful
one: RECHECK_LOGS specifies those tests which are to be removed
in any case before testing.  Provide a `recheck' convenience
target to set RECHECK_LOGS to all failed and unexpectedly passed
tests.  Document several ways to limit the set of tests run.
* lib/am/check.am [PARALLEL_TESTS] (RECHECK_LOGS): New variable,
default to $(TESTS_LOGS).
(check-TESTS): Remove $(RECHECK_LOGS) not $(TEST_LOGS).  Drop use
of LAZY_TEST_SUITE.
($(TEST_SUITE_LOG)): Do not output note about lazy rerun, as
LAZY_TEST_SUITE is gone.
(recheck): New target.
(recheck-am, recheck-TESTS): New internal targets.
* doc/automake.texi (Tests): Update @vindex for TESTS and
TEST_LOGS.  Replace description of LAZY_TEST_SUITE with a list
of ways the set of tests to be run can be modified.  Document
RECHECK_LOGS and the recheck target.
* tests/defs.in: Unset RECHECK_LOGS not LAZY_TEST_SUITE.
* tests/parallel-tests.test: Adjust, replacing LAZY_TEST_SUITE
with corresponding RECHECK_LOGS settings.
* tests/parallel-tests9.test: New tests.
* tests/Makefile.am: Update.
Suggestion and different implementation by Akim Demaille.

diff --git a/doc/automake.texi b/doc/automake.texi
index bf41acb..84a8a21 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -8388,7 +8388,7 @@ This test driver is still experimental and may undergo 
changes in order
 to satisfy additional portability requirements.
 
 @vindex TEST_SUITE_LOG
-...@vindex TEST_LOGS
+...@vindex TESTS
 The driver operates by defining a set of @command{make} rules 

[PATCH] build: use automake's --silent-rules option when possible

[Jim Meyering]

I like automake's upcoming --silent-rules option enough
that I'm making it the default (when possible) for coreutils.
Since I bootstrap using automake from its next branch, it's
enabled for me.  And that translates to enhanced Makefile.in
files in the tarballs I generate.  The net result is that when
you run make (using distributed Makefile.in files), you'll
see something like this:

 ...
 CC  id.o
 CC  kill.o
 CC  operand2sig.o
 CC  logname.o
 CC  pathchk.o
 CC  printenv.o
 CC  printf.o
 CC  pwd.o
 CC  runcon.o
 CC  seq.o
 CC  sleep.o
 CC  tee.o
 CC  test.o
 CC  timeout.o
 CC  true.o
 CC  truncate.o
 CC  tty.o
 CC  whoami.o
 CC  yes.o
 CC  base64.o
 CC  setuidgid.o
 CC  getlimits.o
 CC  su.o
 AR  libver.a
 CCLD  uname
 CCLD  chroot
 CCLD  hostid
 CCLD  nice
 CCLD  df
 CCLD  pinky
 CCLD  users
 CCLD  uptime
 CCLD  stty
 CCLD  [
 CCLD  chcon
 CCLD  who
 CCLD  chgrp
 CCLD  chown
 CCLD  chmod
 ...

rather than less-readable lines full of gcc command-line options.


From 9f39fa8559a8f87e1199f11f6cee295ac8cf6781 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sat, 28 Mar 2009 12:48:24 +0100
Subject: [PATCH] build: use automake's --silent-rules option when possible

* bootstrap: Use automake's --silent-rules option.
---
 bootstrap |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/bootstrap b/bootstrap
index 27e4ec2..e834a2b 100755
--- a/bootstrap
+++ b/bootstrap
@@ -686,6 +686,12 @@ find $m4_base $source_base \
   -depth \( -name '*.m4' -o -name '*.[ch]' \) \
   -type l -xtype l -delete  /dev/null 21

+# Use automake's --silent-rules option, if possible.
+automake=${AUTOMAKE-automake} --add-missing --copy --force-missing
+(${AUTOMAKE-automake} --help) 21 \
+| grep -e '^  *--silent-rules'  /dev/null \
+   automake=$automake --silent-rules
+
 # Reconfigure, getting other files.

 for command in \
@@ -693,7 +699,7 @@ for command in \
   ${ACLOCAL-aclocal} --force -I m4 \
   ${AUTOCONF-autoconf} --force \
   ${AUTOHEADER-autoheader} --force \
-  ${AUTOMAKE-automake} --add-missing --copy --force-missing
+  $automake
 do
   if test $command = libtool; then
 use_libtool=0
--
1.6.2.rc1.285.gc5f54

Re: [PATCH] build: use automake's --silent-rules option when possible

[Bob Friesenhahn]

On Sat, 28 Mar 2009, Jim Meyering wrote:


I like automake's upcoming --silent-rules option enough
that I'm making it the default (when possible) for coreutils.
Since I bootstrap using automake from its next branch, it's
enabled for me.  And that translates to enhanced Makefile.in
files in the tarballs I generate.  The net result is that when
you run make (using distributed Makefile.in files), you'll
see something like this:
...
CC  id.o


What happens when things go wrong with the compilation command line? 
How will the user diagnose build problems in this Linux-kernel like 
mode?


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: [PATCH] build: use automake's --silent-rules option when possible

[Russ Allbery]

Ralf Corsepius rc040...@freenet.de writes:
 Jim Meyering wrote:

 Since I bootstrap using automake from its next branch, it's
 enabled for me.  And that translates to enhanced Makefile.in
 files in the tarballs I generate.  The net result is that when
 you run make (using distributed Makefile.in files), you'll
 see something like this:

  ...
  CC  id.o

 Now your users won't see the silent bugs your package comes with.

I'm planning on doing the same thing with my packages because I think my
users will see the bugs *better*.  One of the problems with the default
Automake output is that it's very difficult, without redirecting output or
the assistance of a separate parsing program, to extract the warnings from
the long compiler strings.  This format makes the warnings *far* more
obvious, which is very useful.

The only thing that I'm worried about is not seeing the list of libraries
with which executables are linked.  That's the single piece of debugging
information about builds that I use the most often.

But the long, repetitive compiler lines, which are mechanically generated
and rarely contain useful information, get in the way of seeing bits of
output that are actually important.

-- 
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/