bug#54063: automake cannot run without generated Texinfo manual

[Gavin Smith]

On Thu, Jul 13, 2023 at 04:34:39PM -0600, Karl Berry wrote:
> Bogdan, Pat, Gavin, all - back on this bug:
> 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54063
> Subject: bug#54063: - special case] Try .texi.in when .texi missing
> 


> As previously discussed in this bug, I added a warning to automake.texi
> about @setfilename having to match the basename if it's present. I think
> a check+warning for that could usefully be added to the code in this
> function (scan_texinfo_file), but I just can't cope with spending more
> time on this issue. I also don't want to think about adding "full"
> support for @setfilename to Automake, given that @setfilename is no
> longer required or especially recommended for Texinfo.
> 
> Wow, this is all confusing. I sure hope it works out (closing the bug,
> probably prematurely). --thanks, karl.

I didn't follow the details of the discussion closely, but it appears
to relate to a theoretical problem that didn't actually affect anybody,
only relevant if @setfilename was used.  I agree that it appears to
be an issue not worth spending much time on, and that adding full support
for @setfilename to Automake would be a waste of time and effort.

Looking at the thread of the original bug report above, the original
problem appears to have been fixed by Mike Frysinger's change:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54063#17
  Date: Thu, 24 Feb 2022 22:32:24 -0500
  > Fixes automake bug https://bugs.gnu.org/54063.
  > 
  > The function scanning for @setfilename will fall back to a default
  > value if the input doesn't have one defined.  But we need to handle
  > the case where the file doesn't even exist before falling back.

Thus, closing the bug makes sense.

We can see if we can remove the workaround for the original problem
in Texinfo if/when a new version of Automake is released.

bug#29188: [PATCH] texi2dvi usage doesn't work with

[Gavin Smith]

On Sun, Mar 19, 2023 at 05:57:19PM +0100, Bogdan wrote:
>  Anyway, I just provide code the way I'd do it. It's up to "someone higher
> up", like you, to make the decision if the patch is to be merged, modified
> first, or to be simply left out for some reason. There surely are things I
> don't know about so my patches can be wrong or unacceptable for variety of
> reasons.

Note that it's not up to me at all; I'm just an interested bystander when
it comes to Automake development.

If there is still a bug in texi2dvi could you please write to
bug-texi...@gnu.org with the details?  Many thanks for your time spent
on this issue.

bug#29188: [PATCH] texi2dvi usage doesn't work with

[Gavin Smith]

On Sat, Mar 18, 2023 at 10:10:05PM +0100, Bogdan wrote:
>  The problem was with "--build-dir=": the old texi2dvi (which is a shell
> script) splits "--build-dir=xxx" into "--build-dir" and "xxx", interprets
> the "--build-dir" switch as "--batch" (checks just the first letter, great)
> and the "xxx" stays on the command line and is being treated as another
> input file, causing the error.
> 
>  Fortunately, since texinfo-4.9, one can set the build directory with an
> environment variable "TEXI2DVI_BUILD_DIRECTORY". Unfortunately, texinfo has
> a bug there, too. When setting "--build-dir=" on the command line, the build
> mode is set to "tidy" (which cleans some log files, etc.). Fine. The problem
> is that if you set the build directory using an environment variable, the
> mode is NOT set to "tidy", leaving the logs files and failing tests.
> Luckily, you can also set the build mode from an environment variable,
> "TEXI2DVI_BUILD_MODE".

It may fix the bug for <= texinfo 4.8 but can I suggest that having
lengthy comments in code explaining why it is done one way and not
another is pretty distracting for anybody trying to understand or
modify the code in the future.  Also note that texinfo 4.8 was released
in 2004, nearly 20 years ago, so I question whether it is worth fixing
this in a complicated way for the benefit of the proprietary macOS
operating system (I believe they use old versions of GNU programs to
avoid using GPLv3-licensed code).


> From 05cb873bec12638b0218afcb0a42076f571c7836 Mon Sep 17 00:00:00 2001
> From: Bogdan Drozdowski <>
> Date: Sat, 18 Mar 2023 21:46:36 +0100
> Subject: [PATCH] Support for texinfo<4.9
> 
> ---
>  lib/am/texibuild.am | 24 ++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/am/texibuild.am b/lib/am/texibuild.am
> index 6f6099c8d..b83dbfa44 100644
> --- a/lib/am/texibuild.am
> +++ b/lib/am/texibuild.am
> @@ -76,7 +76,17 @@ INFO_DEPS += %DEST_INFO_PREFIX%%DEST_SUFFIX%
>  ## avoid hitting a Texinfo bug that could cause low-probability racy
>  ## failure when doing parallel builds; see:
>  ## https://lists.gnu.org/archive/html/automake-patches/2012-06/msg00073.html
> - $(TEXI2DVI) $(AM_TEXI2FLAGS) %MAKEINFOFLAGS% %TEXIQUIET% 
> --build-dir=$(@:.dvi=.t2d) -o $@ %TEXIDEVNULL% \
> +## See bug#29188 for why we are not using "--build-dir=": the old texi2dvi
> +## splits "--build-dir=xxx" into "--build-dir" and "xxx", interprets the
> +## "--build-dir" as "--batch" (checks just 1 letter, great!) and the "xxx"
> +## stays on the command line as another input file, causing the error.
> + TEXI2DVI_BUILD_DIRECTORY=$(@:.dvi=.t2d) \
> +## We need TEXI2DVI_BUILD_MODE=tidy due to another bug in texi2dvi:
> +## when "--build-dir" is passed on the command line, the build mode is
> +## automatically set to 'tidy' by default, but when the build directory
> +## is set using an environment variable, the build mode stays default.
> + TEXI2DVI_BUILD_MODE=tidy \
> + $(TEXI2DVI) $(AM_TEXI2FLAGS) %MAKEINFOFLAGS% %TEXIQUIET% -o $@ 
> %TEXIDEVNULL% \
>  ?GENERIC?%SOURCE%
>  ?!GENERIC?   `test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE%
>  
> @@ -97,7 +107,17 @@ INFO_DEPS += %DEST_INFO_PREFIX%%DEST_SUFFIX%
>  ## avoid hitting a Texinfo bug that could cause low-probability racy
>  ## failure when doing parallel builds; see:
>  ## https://lists.gnu.org/archive/html/automake-patches/2012-06/msg00073.html
> - $(TEXI2PDF) $(AM_TEXI2FLAGS) %MAKEINFOFLAGS% %TEXIQUIET% 
> --build-dir=$(@:.pdf=.t2p) -o $@ %TEXIDEVNULL% \
> +## See bug#29188 for why we are not using "--build-dir=": the old texi2dvi
> +## splits "--build-dir=xxx" into "--build-dir" and "xxx", interprets the
> +## "--build-dir" as "--batch" (checks just 1 letter, great!) and the "xxx"
> +## stays on the command line as another input file, causing the error.
> + TEXI2DVI_BUILD_DIRECTORY=$(@:.pdf=.t2p) \
> +## We need TEXI2DVI_BUILD_MODE=tidy due to another bug in texi2dvi:
> +## when "--build-dir" is passed on the command line, the build mode is
> +## automatically set to 'tidy' by default, but when the build directory
> +## is set using an environment variable, the build mode stays default.
> + TEXI2DVI_BUILD_MODE=tidy \
> + $(TEXI2PDF) $(AM_TEXI2FLAGS) %MAKEINFOFLAGS% %TEXIQUIET% -o $@ 
> %TEXIDEVNULL% \
>  ?GENERIC?%SOURCE%
>  ?!GENERIC?   `test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE%
>  
> -- 
> 2.35.1
> 

[bug#59989] [PATCH] tests: Fix txinfo-include test for texinfo 7.x

[Gavin Smith]

On Mon, Dec 12, 2022 at 07:28:38AM +0100, Frederic Berat wrote:
> From: Frédéric Bérat 
> 
> Texinfo modified its behavior regarding apostrophes, which are now
> replaced by UTF-8 right single quotes by default.
> It looks like this was supposed to be the default for few years already,
> but this behavior was broken so far.
> 
> Use the @verb construct in order to ensure that the quotes are kept
> has-is, so that we can easily grep for "GNU's Not Unix".

The change affected the output when a @documentencoding directive was
not present in the Texinfo file.  The curly quotes were used from
Texinfo 5.0 onwards I believe (the big Perl rewrite from 2013) if
"@documentencoding UTF-8" was specified.  Later (2019) UTF-8 was made the
default encoding for input files but the curly quotes were not used
in the output unless there was an explicit @documentencoding directive.
This was not documented well and users found it confusing, and in the latest
release, it makes no difference whether the directive is present.
These non-ASCII characters are on by default and turned off by passing
"-c ASCII_PUNCTUATION=0" on the texi2any command line.

I think using curly quotes by default was a mistake in the first place
for UTF-8 input; however, any changes to the defaults should be discussed
on bug-texi...@gnu.org.  The main issue that I would foresee is that
in Emacs Info mode, there can be highlighting of text surrounded by
curly quotes, so we would have to check that this highlighting also
worked if ASCII apostrophes were used instead.

One option would be to carry on using ‘ and ’ for the output of @code etc.,
but not for where literal ` and ' appeared in the Texinfo source.  Likewise
for “ and ” and `` and ''.  This would mean you could easily search for
words like "Don't" in the Info browser.

Re: How to prevent distribution of `texinfo.tex`

[Gavin Smith]

On Wed, Jun 23, 2021 at 12:27:15PM -0400, Nick Bowler wrote:
> On 2021-06-23, Werner LEMBERG  wrote:
> > The file `texinfo.tex` is in the list of files (given by `automake
> > --help`) that gets always distributed.  How can I disable this?  I
> > don't have texinfo documentation.
> 
> The texinfo.tex file (and others listed along with it) is included in
> the distribution only if the file is present in your project workspace
> when you run "automake" to (re)generate Makefile.in.
> 
> As far as I know there is no way to disable this behaviour, although I
> agree the automagic file inclusion can be a bit funky.

Would it make sense only to include this file if a _TEXINFOS variable
e.g. info_TEXINFOS is set in Makefile.am?

Re: Future plans for Autotools

[Gavin Smith]

On Thu, Jan 21, 2021 at 11:01:34AM -0500, Zack Weinberg wrote:
> Having said that, switching to *anything else* would be a gigantic
> task -- multiple full-time person-years of effort just for the core --
> and would mean either porting or losing all of the third-party macro
> libraries.  I don't think it makes sense to explore this possibility
> any further unless both a lot of funding and a lot of developers
> materialize.

It could be possible for autoconf to become one option of several for
use with automake.  Then it would not be necessary to replicate the
entire functionality of autoconf in a new system.  People could have
(part of) the configuration written in Perl or other languages.

For this to work, automake would need to change quite a lot, for
example not always using configure.ac as an input file.  There would
be the question of information sharing between automake's own checks and
checks done in user configuration code.  It would never be trivial
to add a new configuration language, but they could all have similar
characteristics, for example communicating their results as a list
of names and values (i.e. the "name=@name@" of autoconf), some of which
would be required for Automake rules (e.g. whatever configuration method
was used, it would have to yield a value for CC if C files were being
compiled).

Perhaps there could be an Automake variable CONFIGURATION_METHOD
that could select which system was to used ("autoconf" being the
current system).  Other options could be to generate the configure
script completely automatically, or to access other programs that
allow some user code in the script.

This all depends on somebody creating a replacement for autoconf, though,
and integrating it with automake.

> A lesser possibility we could think about, would be dusting off GNU M4
> 2.0 and thinking about what we could change about the M4 language to
> make it friendlier for Autoconf's purposes.  Again I would want
> funding and developers lined up, but we'd not need quite so much of
> either.

If you ask if the current design of the autotools is something that
should be preserved forever, when you look at what its use is (creating
build systems for software), you would answer that it shouldn't be.  M4
is part of this.

> [Bob Friesenhahn]
> > There is a fork of Automake which was re-done to be based on GNU
> > Make. This assumes that makefiles written in GNU make can noticeably
> > improve things.  I like your idea of supporting other underlying
> > build tools besides 'make'.  Make's dependence on matching rules and
> > file time stamps is problematic and it does not scale.
> 
> I haven't ever followed automake development closely.  I know that
> at least one person has tried to write a set of GNU Make library files
> intended to replace it altogether, but I've never seen anyone *finish*
> that project.  I'd very much like to see someone give that another go.
> 
> The alternative to the Make family of tools, that I'm most familiar
> with, is Ninja, and it also depends on matching rules and file time
> stamps.  What do you have in mind as a replacement for these things?
> Is there already an alternative tool that you like?

One issue here is that Makefile.am can contain Makefile rules, which
transfer cleanly to use by "make", but possibly not for other programs
like ninja.  (I don't know anything about ninja, though.)

> I have a lot more sympathy with people who are annoyed with the GNU
> *project* and/or the FSF.  I have any number of my own grievances with
> them.  However, I would prefer not to get into that in this
> conversation, because it's liable to drag it off-topic and/or turn
> into a flame war.  Let's declare the known obstacles imposed on
> Autotools by the FSF -- concretely, the requirement for copyright
> assignment paperwork and the requirement not to use proprietary CI and
> forge services -- immobile and out-of-scope for this discussion.

There could be a discussion to be had about project governance and how
to stimulate development in GNU packages: advertising for contributors,
promoting use of the package, encouraging exploratory development.  I
don't have any concrete suggestions, though, and many changes are also
possible for the worse.

Re: Future plans for Autotools

[Gavin Smith]

Thanks for writing all of this.

I'm writing from the perspective of a long-term user of the autotools.
A discussion like the one you have started will likely attract many
opinions. Some will be contradictory. However, somebody in the end
will have to decide.

The challenge seems to be to evolve the system with regard to backward
compatibility. You mention the use of many languages, like m4. This
brings me to my first suggestion: make automake work without autoconf.
This would potentially allow configuration scripts (if there is to be
such a thing) to be written in a language that doesn't use m4.

The purpose of autoconf, and of configure scripts, could be clarified.
The manual says, "Autoconf is a tool for producing shell scripts that
automatically configure software source code packages to adapt to many
kinds of Posix-like systems." Posix-like systems, and thus
portability, is implied to be a major issue. Many would not care about
portability, especially when starting a small personal project. (This
was my reaction when I first started using the autotools.) I see the
purpose of a configure script to be two-fold:
* Allowing a user to make choices about what features are built, and
how the package is built (e.g. installation paths)
* Adapting to operating system variants
The first will always be relevant, even if you don't care about the
second. I think configuration scripts on GNU-like systems would always
have a heavy element of shell script in them, even if m4 or autoconf
macros were abandoned. There would be no need to move so far away from
this.

If automake could generate its own configure script without autoconf,
then the interface of the GNU Build System could continue unchanged
for people building software. It would also simplify matters for
people learning to use the autotools, that they could just create a
single Makefile.am to describe their project (like a CMakefile for
cmake or .pro file for qmake), rather than having to create
Makefile.am and configure.ac.

It could be made easier to get started with automake. For example,
"AUTOMAKE_OPTIONS=foreign" should be the default; otherwise automake
refuses to finish if required files aren't found in the project.
There's a political problem here to persuade people of this. The
documentation could also be improved. I remember somebody was
complaining about this page:
https://www.gnu.org/software/automake/manual/html_node/Program-and-Library-Variables.html
and asking what "maude" meant - it turned out it was the name of the
dog or something of the person who first wrote the program, who didn't
want it to change. So think getting consensus is impossible for
changes that are needed to make the program simpler, easier and
better. There's a vacuum of responsibility where nobody wants to step
on others' feet. Forking the project would go nowhere as nobody would
use the fork.

Your idea about adding support for new programming languages is good
and if someone did this along with other changes, it could stimulate
adoption of the other changes. It would be nice if all the code
required to support a new language could occur as a self-contained
"module" within automake.

On Wed, Jan 20, 2021 at 10:15 PM Zack Weinberg  wrote:
>
> Now we've all had a while to recover from the long-awaited Autoconf
> 2.70 release, I'd like to start a conversation about where the
> Autotools in general might be going in the future.  Clearly any future
> development depends on finding people who will do the work, but before
> we worry about that I think we might want to figure out what work we
> _want_ to do.
>
> As a starting point, I wrote up a "strengths, weaknesses,
> opportunities, and threats" analysis for Autotools -- this is a
> standard project management technique, if you're not familiar with it,
> there's a nice writeup in the draft of the book my friend and
> colleague Sumana Harihareswara is writing [
> https://changeset.nyc/resources/getting-unstuck-sampler-offer.html ].
> I'm going to paste the full text of this analysis below, please reply
> inline.  You can also read it on my blog at
> https://www.owlfolio.org/development/autoconf-swot/ .
>
> zw
> 
>
> I’ve been a contributor to GNU projects for many years, notably both
> GCC and GNU libc, and recently I led the effort to make the first
> release of Autoconf since 2012 (release announcement for Autoconf
> 2.70). For background and context, see the LWN article my colleague
> Sumana Harihareswara of Changeset Consulting wrote.
>
> Autoconf not having made a release in eight years is a symptom of a
> deeper problem. Many GNU projects, including all of the other
> components of the Autotools (Automake, Libtool, Gnulib, etc.) and the
> software they depend upon (GNU M4, GNU Make, etc.) have seen a steady
> decline in both contributor enthusiasm and user base over the past
> decade. I include myself in the group of declining enthusiasts; I
> would not have done the work leading up to the Autoconf 2.70 release
> if I 

Re: preparing for a new release

[Gavin Smith]

On Sun, Nov 15, 2020 at 09:45:44AM -0800, Jim Meyering wrote:
> I've fixed a few of these failures, but here is still at least one
> that I have not fixed: t/txinfo-no-clutter. In this case, running it
> with no parallelism and by itself passes:
>   make -k check TESTS='t/txinfo-no-clutter'
> Yet running it with parallel make fails (I'm using make-4.3.90 built
> from git, in case it matters):
>   make -k check TESTS='t/txinfo-no-clutter' AM_TESTSUITE_MAKE="make
> -j$(( 2*$(nproc) + 1 ))"
> 
> Not sure I'll work more on this today, so sharing: The attached log
> shows that this fails when building that test's final "all" rule,
> often because a .dvi file could not be found:
> 
> ) localization,mv: cannot stat 'bar.dvi': No such file or directory

My suspicion is that it is interference between the dvi and ps targets.
When I remove the ps targets with the change at the bottom of this email,
the test passes every time.  The ps file is made from the dvi file so
perhaps the ps rules are deleting the dvi file while the dvi rules are
still using it, or vice versa.

diff --git a/t/txinfo-no-clutter.sh b/t/txinfo-no-clutter.sh
index b311f0348..4701462d2 100644
--- a/t/txinfo-no-clutter.sh
+++ b/t/txinfo-no-clutter.sh
@@ -26,7 +26,7 @@ AC_OUTPUT
 END
 
 cat > Makefile.am << 'END'
-all-local: ps pdf dvi html # For "make distcheck".
+all-local: pdf dvi html # For "make distcheck".
 info_TEXINFOS = foo.texi doc/bar.texi baz.texi
 SUBDIRS = sub
 END
@@ -34,7 +34,7 @@ END
 mkdir sub doc
 
 cat > sub/Makefile.am << 'END'
-all-local: ps pdf dvi html # For "make distcheck".
+all-local: pdf dvi html # For "make distcheck".
 info_TEXINFOS = baz.texi
 END
 
@@ -90,7 +90,7 @@ $AUTOCONF
 
 # Try one by one, to ensure later targets don't involuntarily
 # clean up potential cruft left by earlier ones.
-for fmt in info pdf ps dvi html all; do
+for fmt in info pdf dvi html all; do
   $MAKE $fmt
   # For debugging.
   ls -l . doc sub
@@ -103,7 +103,7 @@ for fmt in info pdf ps dvi html all; do
   test -e sub/baz.html
   ;;
 all)
-  for x in info pdf ps dvi; do
+  for x in info pdf dvi; do
 test -f foo.$x
 test -f doc/bar.$x
 test -f baz.$x
@@ -127,10 +127,9 @@ for fmt in info pdf ps dvi html all; do
   case $fmt in
 pdf) extension_rx="(texi|pdf|t2p)";;
 dvi) extension_rx="(texi|dvi|t2d)";;
- ps) extension_rx="(texi|ps|dvi|t2d)";;
info) extension_rx="(texi|info)";;
html) extension_rx="(texi|html)";;
-all) extension_rx="(texi|html|info|pdf|ps|dvi|t2[pd])";;
+all) extension_rx="(texi|html|info|pdf|dvi|t2[pd])";;
   *) fatal_ "unreachable code reached";;
   esac
   $EGREP -v "^$basename_rx\.$extension_rx$" lst && exit 1

Re: preparing for a new release

[Gavin Smith]

On Sun, Nov 15, 2020 at 09:45:44AM -0800, Jim Meyering wrote:
> Karl has made quite a few improvements, so I'm preparing to make a new
> release. But first, I wanted to make the tests pass reliably also when
> running them in parallel (the only way I run them, because otherwise,
> they take way too long). I run a command like this:
> 
> make check AM_TESTSUITE_MAKE="make -j$(( 2*$(nproc) + 1 ))"
> 
> That evoked a surprising number of test failures. Note that these are
> nondeterministic and depend on the amount of parallelism. All tests
> may pass consistently on a system with 2 cores, yet some will fail
> every time when nproc prints at least 6.
> 
> I've fixed a few of these failures, but here is still at least one
> that I have not fixed: t/txinfo-no-clutter. In this case, running it
> with no parallelism and by itself passes:
>   make -k check TESTS='t/txinfo-no-clutter'
> Yet running it with parallel make fails (I'm using make-4.3.90 built
> from git, in case it matters):
>   make -k check TESTS='t/txinfo-no-clutter' AM_TESTSUITE_MAKE="make
> -j$(( 2*$(nproc) + 1 ))"
> 
> Not sure I'll work more on this today, so sharing: The attached log
> shows that this fails when building that test's final "all" rule,
> often because a .dvi file could not be found:
> 
> ) localization,mv: cannot stat 'bar.dvi': No such file or directory
> 
> I've attached the four commits I'm about to push as well as that
> individual testsuite.log, in case someone wants to help accelerate the
> process.

I got the same with the recent version in git: ran OK with

make -k check TESTS='t/txinfo-no-clutter'

but broke with


make -k check TESTS='t/txinfo-no-clutter' AM_TESTSUITE_MAKE="make -j$(( 
2*$(nproc) + 1 ))"

My make version is GNU Make 4.1.  I'm attaching testsuite.log.





==
   GNU Automake 1.16b: ./test-suite.log
==

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: t/txinfo-no-clutter
=

txinfo-no-clutter: running makeinfo --version
texi2any (GNU texinfo) 6.7dev

Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
txinfo-no-clutter: running texi2dvi --version
texi2dvi (GNU Texinfo 6.7dev)

Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
txinfo-no-clutter: running dvips --version
This is dvips(k) 5.997 Copyright 2017 Radical Eye Software
kpathsea version 6.2.3
Copyright 2017 Radical Eye Software.
There is NO warranty.  You may redistribute this software
under the terms of the GNU General Public License
and the Dvips copyright.
For more information about these matters, see the files
named COPYING and dvips.h.
Primary author of Dvips: T. Rokicki.
Running from installcheck: no
Test Protocol: none
PATH = 
/home/g/src/automake-GIT/automake/bin:/home/g/src/automake-GIT/automake/t/ax:/home/g/go/bin:/home/g/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/local/go/bin:/home/g/.emacs.d/bin/doom
++ pwd
/home/g/src/automake-GIT/automake/t/txinfo-no-clutter.dir
+ cat
+ cat
+ mkdir sub doc
+ cat
+ cat
+ cat
+ cat
+ cp baz.texi sub
+ aclocal-1.16 -Werror
+ automake-1.16 --foreign -Werror -Wall --add-missing
Makefile.am:2: installing './mdate-sh'
Makefile.am:2: installing './texinfo.tex'
sub/Makefile.am:2: installing 'sub/texinfo.tex'
+ autoconf
+ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating sub/Makefile
+ for fmt in info pdf ps dvi html all
+ make -j5 info
Making info in sub
make[1]: Entering directory 
'/home/g/src/automake-GIT/automake/t/txinfo-no-clutter.dir/sub'
restore=: && backupdir=".am$$" && \
am__cwd=`pwd` && CDPATH="${ZSH_VERSION+.}:" && cd . && \
rm -rf $backupdir && mkdir $backupdir && \
if (/bin/bash 
'/home/g/src/automake-GIT/automake/t/txinfo-no-clutter.dir/missing' makeinfo 
--version) >/dev/null 2>&1; then \
  for f in baz.info baz.info-[0-9] baz.info-[0-9][0-9] baz.i[0-9] 
baz.i[0-9][0-9]; do \
if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
  done; \
else :; fi && \
cd "$am__cwd"; \
if /bin/bash 
'/home/g/src/automake-GIT/automake/t/txinfo-no-clutter.dir/missing' makeinfo   
-I . \
 -o 

bug#34201: [PATCH] automake: do not require @setfilename in Texinfo files

[Gavin Smith]

On Mon, Sep 2, 2019 at 6:28 PM Jim Meyering  wrote:
>
> Gavin Smith proposed a patch for this back in http://bugs.gnu.org/34201
> Another reference to the problem: http://bugs.gnu.org/36921
>
> In the attached (in Gavin's name), I've added a NEWS entry and
> adjusted the ChangeLog entry. Will push in a day or so if no comment.

Thanks for taking the time to look at this.

Re: bug#34201: [PATCH] automake: do not require @setfilename in Texinfo files

[Gavin Smith]

On Mon, Sep 2, 2019 at 6:28 PM Jim Meyering  wrote:
>
> Gavin Smith proposed a patch for this back in http://bugs.gnu.org/34201
> Another reference to the problem: http://bugs.gnu.org/36921
>
> In the attached (in Gavin's name), I've added a NEWS entry and
> adjusted the ChangeLog entry. Will push in a day or so if no comment.

Thanks for taking the time to look at this.

bug#36921: texinfo: @setfilename is not mandatory

[Gavin Smith]

On Sun, Aug 04, 2019 at 01:22:34PM +, Дилян Палаузов wrote:
> Hello,
> 
> I have a .texi file and in Makefile.am:
> 
> info_TEXINFOS = doc/z.texi
> 
> Running autoreconf -visf emits:
> 
> configure.ac:13: installing './compile'
> configure.ac:7: installing './missing'
> Makefile.am: installing './depcomp'
> Makefile.am: error: './doc/z.texi' missing @setfilename
> autoreconf: automake failed with exit status: 1
> 
> I have texinfo (or rather makeinfo) 6.6 and automake 1.16.1 (most likely 
> installed from most recent git).
> 
> The texinfo manual says in node @setfilename:
> 
> “   When a '@setfilename' line is present, the Texinfo processors ignore
> everything written before the '@setfilename' line.  This is why the very
> first line of the file (the '\input' line) does not show up in the
> output.
> 
> . . .
>'@setfilename' used to be required by the Texinfo processors, and
> some other programs may still expect it to be present; for example,
> Automake (*note (automake)Texinfo::).”
> 
> Please adjust automake to come forward, when @setfilename is missing, 
> implying the default value.
> 

I posted a patch to fix this issue: 
https://lists.gnu.org/archive/html/bug-automake/2019-01/msg2.html

Hopefully somebody will have time to apply it.  I am not sure how 
actively Automake is being developed at the moment.

bug#34201: Make @setfilename optional in Texinfo files

[Gavin Smith]

Is there anybody who has time to look at this issue? The requirement
for a @setfilename line is an unnecessary hurdle to getting Texinfo
and Automake working together. It has been unnecessary for several
years now.

I have a copyright assignment in place for Automake with the FSF, so
all that would be needed would be for someone to have a look at this
patch and apply it for the next Automake release.

On 1/25/19, Gavin Smith  wrote:
> @setfilename should not be required to occur inside Texinfo files, as it
> makes it harder to get them working.
>
> Earlier on this:
> https://lists.gnu.org/archive/html/automake/2015-09/msg0.html
>
> Here is a patch.  I added a test which is passing now, but it wasn't
> passing when I first added the test, so am not sure if it is written
> correctly.  I based it on the existing test
> t/txinfo-setfilename-repeated.sh.
>
> It says GPL version 2 in the licence because that's what was in the
> existing tests, although they should probably all be version 3.
>
> ChangeLog entry:
>
> Do not require @setfilename in Texinfo files.
>
> * bin/automake.in (scan_texinfo_file): Derive name of info file from
> name of input file if no @setfilename line occurs in the file.
> * t/texinfo-no-setfilename.sh: New test.
>
> diff --git a/bin/automake.in b/bin/automake.in
> index b4ae8f4..01e6a58 100644
> --- a/bin/automake.in
> +++ b/bin/automake.in
> @@ -3083,8 +3083,10 @@ sub scan_texinfo_file
>
>if (! $outfile)
>  {
> -  err_am "'$filename' missing \@setfilename";
> -  return;
> +  # Replace a .texi extension with .info
> +  $outfile = basename($filename);
> +  $outfile =~ s/\.[^.]+$//;
> +  $outfile .= '.info';
>  }
>
>return ($outfile, $vfile);
> diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
> index 84dd29a..32fca84 100644
> --- a/t/list-of-tests.mk
> +++ b/t/list-of-tests.mk
> @@ -1214,6 +1214,7 @@ t/txinfo-no-clutter.sh \
>  t/txinfo-no-extra-dist.sh \
>  t/txinfo-no-installinfo.sh \
>  t/txinfo-no-repeated-targets.sh \
> +t/txinfo-no-setfilename.sh \
>  t/txinfo-other-suffixes.sh \
>  t/txinfo-override-infodeps.sh \
>  t/txinfo-override-texinfo-tex.sh \
> diff --git a/t/txinfo-no-setfilename.sh b/t/txinfo-no-setfilename.sh
> new file mode 100644
> index 000..3ef1730
> --- /dev/null
> +++ b/t/txinfo-no-setfilename.sh
> @@ -0,0 +1,35 @@
> +#! /bin/sh
> +# Copyright (C) 2019 Free Software Foundation, Inc.
> +#
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 2, or (at your option)
> +# any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program.  If not, see <https://www.gnu.org/licenses/>.
> +
> +# Check Texinfo files work without a @setfilename line
> +
> +. test-init.sh
> +
> +cat > Makefile.am << 'END'
> +info_TEXINFOS = file.texi
> +END
> +
> +cat > file.texi << 'END'
> +contents
> +END
> +
> +$ACLOCAL
> +$AUTOMAKE --add-missing
> +
> +
> +grep 'file.info:' Makefile.in
> +
> +:
>
>
>
>

Re: bug#34201: Make @setfilename optional in Texinfo files

[Gavin Smith]

Is there anybody who has time to look at this issue? The requirement
for a @setfilename line is an unnecessary hurdle to getting Texinfo
and Automake working together. It has been unnecessary for several
years now.

I have a copyright assignment in place for Automake with the FSF, so
all that would be needed would be for someone to have a look at this
patch and apply it for the next Automake release.

On 1/25/19, Gavin Smith  wrote:
> @setfilename should not be required to occur inside Texinfo files, as it
> makes it harder to get them working.
>
> Earlier on this:
> https://lists.gnu.org/archive/html/automake/2015-09/msg0.html
>
> Here is a patch.  I added a test which is passing now, but it wasn't
> passing when I first added the test, so am not sure if it is written
> correctly.  I based it on the existing test
> t/txinfo-setfilename-repeated.sh.
>
> It says GPL version 2 in the licence because that's what was in the
> existing tests, although they should probably all be version 3.
>
> ChangeLog entry:
>
> Do not require @setfilename in Texinfo files.
>
> * bin/automake.in (scan_texinfo_file): Derive name of info file from
> name of input file if no @setfilename line occurs in the file.
> * t/texinfo-no-setfilename.sh: New test.
>
> diff --git a/bin/automake.in b/bin/automake.in
> index b4ae8f4..01e6a58 100644
> --- a/bin/automake.in
> +++ b/bin/automake.in
> @@ -3083,8 +3083,10 @@ sub scan_texinfo_file
>
>if (! $outfile)
>  {
> -  err_am "'$filename' missing \@setfilename";
> -  return;
> +  # Replace a .texi extension with .info
> +  $outfile = basename($filename);
> +  $outfile =~ s/\.[^.]+$//;
> +  $outfile .= '.info';
>  }
>
>return ($outfile, $vfile);
> diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
> index 84dd29a..32fca84 100644
> --- a/t/list-of-tests.mk
> +++ b/t/list-of-tests.mk
> @@ -1214,6 +1214,7 @@ t/txinfo-no-clutter.sh \
>  t/txinfo-no-extra-dist.sh \
>  t/txinfo-no-installinfo.sh \
>  t/txinfo-no-repeated-targets.sh \
> +t/txinfo-no-setfilename.sh \
>  t/txinfo-other-suffixes.sh \
>  t/txinfo-override-infodeps.sh \
>  t/txinfo-override-texinfo-tex.sh \
> diff --git a/t/txinfo-no-setfilename.sh b/t/txinfo-no-setfilename.sh
> new file mode 100644
> index 000..3ef1730
> --- /dev/null
> +++ b/t/txinfo-no-setfilename.sh
> @@ -0,0 +1,35 @@
> +#! /bin/sh
> +# Copyright (C) 2019 Free Software Foundation, Inc.
> +#
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 2, or (at your option)
> +# any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program.  If not, see <https://www.gnu.org/licenses/>.
> +
> +# Check Texinfo files work without a @setfilename line
> +
> +. test-init.sh
> +
> +cat > Makefile.am << 'END'
> +info_TEXINFOS = file.texi
> +END
> +
> +cat > file.texi << 'END'
> +contents
> +END
> +
> +$ACLOCAL
> +$AUTOMAKE --add-missing
> +
> +
> +grep 'file.info:' Makefile.in
> +
> +:
>
>
>
>

Re: A new, novel, and faster Binary Search algorithm

[Gavin Smith]

On Wed, Mar 13, 2019 at 12:39:24PM +0100, Gregorius van den Hoven wrote:
> I am hoping you find this an interesting development and are willing to
> double check my work and/or forward it to interested parties. If my
> algorithm gains traction it should have a positive impact on mankind's
> carbon footprint. :)

This is all very well, but the fact that you sent mail to a list that has 
not much to do with sorting algorithms does not do much for your 
credibility.  If your algorithm was really so great wouldn't it get 
popular without the need for you to send this kind of advertisment to 
irrelevant lists?

bug#34201: Make @setfilename optional in Texinfo files

[Gavin Smith]

@setfilename should not be required to occur inside Texinfo files, as it 
makes it harder to get them working.

Earlier on this:
https://lists.gnu.org/archive/html/automake/2015-09/msg0.html

Here is a patch.  I added a test which is passing now, but it wasn't 
passing when I first added the test, so am not sure if it is written 
correctly.  I based it on the existing test 
t/txinfo-setfilename-repeated.sh.

It says GPL version 2 in the licence because that's what was in the 
existing tests, although they should probably all be version 3.

ChangeLog entry:

Do not require @setfilename in Texinfo files.

* bin/automake.in (scan_texinfo_file): Derive name of info file from 
name of input file if no @setfilename line occurs in the file.
* t/texinfo-no-setfilename.sh: New test.

diff --git a/bin/automake.in b/bin/automake.in
index b4ae8f4..01e6a58 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -3083,8 +3083,10 @@ sub scan_texinfo_file
 
   if (! $outfile)
 {
-  err_am "'$filename' missing \@setfilename";
-  return;
+  # Replace a .texi extension with .info
+  $outfile = basename($filename);
+  $outfile =~ s/\.[^.]+$//;
+  $outfile .= '.info';
 }
 
   return ($outfile, $vfile);
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index 84dd29a..32fca84 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -1214,6 +1214,7 @@ t/txinfo-no-clutter.sh \
 t/txinfo-no-extra-dist.sh \
 t/txinfo-no-installinfo.sh \
 t/txinfo-no-repeated-targets.sh \
+t/txinfo-no-setfilename.sh \
 t/txinfo-other-suffixes.sh \
 t/txinfo-override-infodeps.sh \
 t/txinfo-override-texinfo-tex.sh \
diff --git a/t/txinfo-no-setfilename.sh b/t/txinfo-no-setfilename.sh
new file mode 100644
index 000..3ef1730
--- /dev/null
+++ b/t/txinfo-no-setfilename.sh
@@ -0,0 +1,35 @@
+#! /bin/sh
+# Copyright (C) 2019 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+# Check Texinfo files work without a @setfilename line
+
+. test-init.sh
+
+cat > Makefile.am << 'END'
+info_TEXINFOS = file.texi
+END
+
+cat > file.texi << 'END'
+contents
+END
+
+$ACLOCAL
+$AUTOMAKE --add-missing
+
+
+grep 'file.info:' Makefile.in
+
+:

Re: manual: Why use 'maude' as the example program name?

[Gavin Smith]

On 25 February 2018 at 19:13, Jonas Thiem  wrote:
> Disclaimer: I haven't read this part of the docs myself. But for what
> it's worth, I think Maude looks a bit like a misspelling of Make and
> doesn't stick out that well, compared to "exampleprog" or something.
> Also, I personally would suggest it's good if it's obvious from the name
> what it is, and what it's not. (e.g. Maude could be mistaken as a
> reference to an actual tool or some technical term the reader might
> think they have missed) Not saying it needs to be changed, just throwing
> in another impression.

I changed it from "maude" to "program" in my (unofficial) attempt at
editing the automake manual:
http://buildsystem-manual.sourceforge.net/Program-and-Library-Variables.html#Program-and-Library-Variables
I've no current plans to push this rewrite further but maybe someone
will want to use some parts of it. One of my goals was to remove any
sense of personality from the documentation so that it was as boring
as possible, in order to focus on the subject without any
distractions.

Re: Distcheck: wrong TeX

[Gavin Smith]

On Tue, Jun 27, 2017 at 11:14:37AM +0200, Hans Åberg wrote:
> [Please cc me, as I am not on this list.]
> 
> When I put 'export PDFTEX = luatex', then it works correctly with ./configure 
> && make, but 'make distcheck' still uses pdftex. Why is that?
> 

Why shouldn't it?

Re: Words in configure.ac that look like macros forbidden or merely discouraged?

[Gavin Smith]

On 22 December 2016 at 19:00, Eric Blake <ebl...@redhat.com> wrote:
> On 06/12/2016 05:25 AM, Gavin Smith wrote:
>> Hello,
>
> Apologies for just now noticing this thread.
>
>>
>> In the Autoconf manual we read:
>
> Any reason you mailed this to the automake list, and not autoconf, then?

Indeed, it doesn't need automake to fail. I used automake when I
tested this before. The following configure.ac makes autoconf give an
error message:

AC_INIT([test],[0])
AC_MSG_WARN([[AC_DC] stinks  --Iron Maiden])
AC_MSG_WARN([[AC_DC stinks  --Iron Maiden]])
AC_OUTPUT

The error is

configure.ac:2: error: possibly undefined macro: AC_DC
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.

>> Any ideas which it is: is it actually forbidden, or should it be just a 
>> warning?
>
> So I guess you are pointing out a documentation error in the autoconf
> manual, and that the manual should call it an error, not a warning?
> Sure, I can do that.

Either that, or autoconf could be changed to make it a warning. I
don't see any need for that, though: I think it is okay to be an
error.

Words in configure.ac that look like macros forbidden or merely discouraged?

[Gavin Smith]

Hello,

In the Autoconf manual we read:



When you use the same text in a macro argument, you must therefore
have an extra quotation level (since one is stripped away by the macro
substitution). In general, then, it is a good idea to use double
quoting for all literal string arguments, either around just the
problematic portions, or over the entire argument:

 AC_MSG_WARN([[AC_DC] stinks  --Iron Maiden])
 AC_MSG_WARN([[AC_DC stinks  --Iron Maiden]])

However, the above example triggers a warning about a possibly
unexpanded macro when running autoconf, because it collides with the
namespace of macros reserved for the Autoconf language. To be really
safe, you can use additional escaping (either a quadrigraph, or
creative shell constructs) to silence that particular warning:

 echo "Hard rock was here!  --AC""_DC"
 AC_MSG_WARN([[AC@@_DC stinks  --Iron Maiden]])


https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Autoconf-Language.html#Autoconf-Language

Note what it says: "triggers a warning". However, it seems in some
cases, using a word that looks like it could be a macro triggers a
hard error, not just a warning:

$ autoreconf -iv
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal
configure.ac:4: warning: macro 'AM_DC' not found in library
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf
configure.ac:4: error: possibly undefined macro: AM_DC
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1

Any ideas which it is: is it actually forbidden, or should it be just a warning?

I intend to put information about this here:
http://buildsystem-manual.sourceforge.net/Macro-name-quoting.html#Macro-name-quoting
, which I've adapted from the test in the automake manual.

Contents of files:

$ cat configure.ac
AC_INIT([helloprog], [1.0])
AM_INIT_AUTOMAKE

echo AM_DC rocks

AC_CONFIG_FILES([Makefile])
AC_OUTPUT
$ cat Makefile.am
AUTOMAKE_OPTIONS=foreign dist-xz
$

Re: variables in _SOURCES

[Gavin Smith]

> configure:
>
> ./configure ... \
>--with-python \
>PYCXX_SRCDIR=/usr/share/python2.7/CXX/Python2
>
>
> Makefile.am:
>
> nodist_libpyroute_la_SOURCES = $(PYCXX_SRCDIR)/cxxextensions.c
> nodist_libpyroute_la_SOURCES += $(PYCXX_SRCDIR)/cxx_extensions.cxx
> nodist_libpyroute_la_SOURCES += $(PYCXX_SRCDIR)/cxxsupport.cxx
> nodist_libpyroute_la_SOURCES +=
> $(PYCXX_SRCDIR)/../IndirectPythonInterface.cxx

It's possible that this would work if PYCXX_SRCDIR was a variable in
Makefile.am (I haven't checked). The page you linked to said that this
wouldn't work, though.

What you've done here is different: supplying the value of
PYCXX_SRCDIR with configure. This won't work because all the files
need to be given explicitly in Makefile.am.
(https://www.gnu.org/software/automake/manual/html_node/Program-and-Library-Variables.html#FOOT3)

bug#23521: XFAIL

[Gavin Smith]

On 19 May 2016 at 00:04, Mathieu Lirzin  wrote:
>> It is often easier to write expected-to-fail tests this way (so that
>> they can all look the same), rather than have to have, for example, an
>> extra driver that converts expected errors into success codes for the
>> automake test harness.
>
> What do you mean precisely by “an extra driver”?

This would be a reference to a "custom test driver".
https://www.gnu.org/software/automake/manual/html_node/Overview-of-Custom-Test-Drivers-Support.html#Overview-of-Custom-Test-Drivers-Support

Re: [RFC v2] new option: object-shortname

[Gavin Smith]

On 6 January 2016 at 09:23, Thomas Martitz  wrote:
> This option is intended to be used in conjunction with subdir-objects and
> Automake-time substitutions for included makefile fragments (%C%, %D%). It
> suppresses the generation path components in object filenames.
>
> It should equivalent to setting %C%_foo_SHORTNAME=foo, except it can work if
> the makefile fragment is conditionally included, which improves the modularity
> of Automake-using projects.
>
> Example:
> without object-shortname
>   root/path/to/Makefile.am:
>   bin_PROGRAMS += foo
>   %C%_foo_CFLAGS = $(CFLAGS)
>
> results in objects:
>   root/path/to/root_path_to_foo-foo.o
>
> with object-shortname the object filename is:
>   root/path/to/foo-foo.o
>
> And it allows the following in root/Makefile.am (not possible with 
> foo_SHORTNAME=foo)
>   if ENABLE_FOO
>   include path/too/Makefile.am
>   endif

The conditional could be moved into the Makefile fragment and the
SHORTNAME left outside of it. I don't know if that's desirable for
you.

Failing that, it would be better for conditional SHORTNAME to work,
instead of adding a new option.

Re: [RFC] new option: object-shortname

[Gavin Smith]

On 6 January 2016 at 09:17, Thomas Martitz  wrote:
> It should equivalent to setting %C%_foo_SHORTNAME=foo, except it can work if
> the makefile fragment is conditionally included, which improves the modularity
> of Automake-using projects.
>
> Example:
> without object-shortname
>   root/path/to/Makefile.am:
>   bin_PROGRAMS += foo
>   %C%_foo_CFLAGS = $(CFLAGS)
>
> results in objects:
>   root/path/to/root_path_to_foo-foo.o
>
> with object-shortname the object filename is:
>   root/path/to/foo-foo.o

If you can get this to work, I can't think of a reason why it
shouldn't be done all the time, unconditionally, without an option.

> +   # If object-shortname is enabled the object's 
> filename shall not contain the parts
> +   # derived from its path (e.g. if %C% is used), but 
> just the name of the object's target
> +   # e.g. instead of path_to_binary-object.o just 
> binary-object
> +   $dname = split ('_', $derived)[-1];
> +   }

This isn't completely correct. From the Automake manual:

   For example, if a program is named 'sniff-glue', this would be
canonicalized as 'sniff_glue'.  An example of a derived variable name is
'sniff_glue_SOURCES' (not 'sniff-glue_SOURCES'.)  Similarly, the sources
for a library named 'libmumble++.a' would be listed in the
'libmumble___a_SOURCES' variable.

The code you've given here would set the "short name" as "glue", not
"sniff_glue".

Re: _SHORTNAME in conditional

[Gavin Smith]

On 6 January 2016 at 06:01, Thomas Martitz <ku...@rockbox.org> wrote:
> Am 05.01.2016 um 23:41 schrieb Gavin Smith:
>> On 5 January 2016 at 21:05, Thomas Martitz <ku...@rockbox.org> wrote:
>>> Automake source code is a myth to me, I wasn't able to find the code that
>>> implements this limitation (only the place where the warning is printed
>>> (variable_value() => $self->check_defined_unconditionally in Variable.pm)
>>
>> There's the following code in the top-level 'automake' script -
>>
>>  if ($var)
>>  {
>>  # FIXME: should use the same Condition as
>>  # the _SOURCES variable.  But this is really
>>  # silly overkill -- nobody should have
>>  # conditional shortnames.
>>  $dname = $var->variable_value;
>>  }
>>
>> does that help?
>>
>
> I saw that, but I couldn't make sense of it. What does that mean? I get
> that the developer deemed it overkill but I can't follow that reason.

Whoever wrote that, if they are still around, can speak for
themselves, but I'll try to explain what I remember from my foray into
the Automake source code a couple of years ago.

The Automake conditional construct means that variables don't have to
have a single value:

if COND
VAR=val1
else
VAR=val2
endif

Here VAR has two values.

Each Automake conditional tests only a single condition. They can also
be nested:

if COND1
if COND2
VAR=val
endif
endif

Adding more conditions reduces the number of occasions that the
contained definition is applicable. The definition here is valid if
"COND1" AND "COND2".

A sequence of nested conditionals can be represented by a list of
conditionals: COND1 AND !COND2 AND COND3.

What about no conditionals at all? This is represented by TRUE. TRUE
is appropriate because when you add more conditions to it, it
disappears: TRUE AND CONDITION is equivalent to CONDITION.

This should answer the question of why when you ask for a definition
under the TRUE condition of a conditionally defined variable, it gives
an error: a definition for the TRUE condition would be an
unconditional definition. (I found this point confusing, myself.)

Note also that the word "Condition" as used in the Automake source
code has a narrower meaning than its common sense: it refers to a
conjunction of conditions only (AND), and not OR for the union of two
conditions.

When asking for a variables value, you have to specify the condition.
>From Variable.pm:

Therefore obtaining the value of a variable under a given
condition involves two lookups.  One to look up the variable,
and one to look up the conditional definition:

  my $var = var $name;
  if ($var)
{
  my $def = $var->def ($cond);
  if ($def)
{
  return $def->value;
}
  ...
}
  ...

What remains, I believe, is how to get the right condition to look up
the value of the *_SHORTNAME value. I assume that mustn't be easy,
otherwise they would have done it.

(In my humble opinion, Automake conditionals muddle the Automake
source code terribly. DisjConjunctions.pm and Conjunctions.pm together
constitute a weird reimplementation of the Boolean algebra that is
present in every programming language. I thought when I was looking at
the code before that it would at least twice as easy to understand the
code if this feature wasn't present.)

Re: [libtool] make install fails after an incremental build after a prefix change?

[Gavin Smith]

On 29 December 2015 at 19:52, Kees-Jan Dijkzeul  wrote:
> Either would obviously work, but kind of defeat the purpose of having
> incremental builds, and unnecessarily  load the buildserver. A
> solution where I could do an incremental build after a configure
> incantation would be much preferred.
>
> Note that this already seems to work well for configure incantations
> that modify config.h :-)

You want not to rebuild files that don't need to be rebuilt. Depending
on config.h doesn't achieve this: any source files including it will
have to be compiled again. If most of the source files do include
config.h, they'll all be rebuilt and it won't be much quicker to avoid
running "make clean" first.

Running configure changes the Makefile, and I believe that this is a
difficult problem to solve to know what has to be rebuilt in this
case. A similar problem is directly editing a Makefile to change the
flags being passed to the compiler: when you re-run "make", it doesn't
know that the flags have changed and the compiler won't be run again,
even though it should be. As long as "make" is being used to know what
depends on what, what would be needed in such a case would be for the
facts that change to be in a separate file that the Makefile refers to
and that "make" could see has changed. I expect that's difficult to
achieve with changing the installation directories.

Re: Automake puts unwanted flags in compilation command

[Gavin Smith]

On 29 December 2015 at 21:42, Daniel Campoverde Carrión [Alx741]
 wrote:
> Hello everyone,
>
> I'm trying to use autotools for the first time for a simple microntroller
> project, one of my Makefile.am files contains this:
>
>
>>PIC_DEVICE=18f4550
>>CC=sdcc
>>LD=sdcc
>>FLAGS= --use-non-free -mpic16 -p$(PIC_DEVICE)
>>AM_CFLAGS = $(FLAGS)
>>AM_LDFLAGS=
>>override CFLAGS=
>>
>>COMPILE=$(CC) $(FLAGS) -c -o
>>LINK=$(LD) $(FLAGS) -o $@
>>
>>noinst_PROGRAMS = firmware.hex
>>firmware_hex_SOURCES = firmware.c
>
> * Notice i've tried (with no success) AM_CFLAGS, AM_LDFLAGS, override CFLAGS

I don't think override CFLAGS means anything.

Maybe try taking all of this out of Makefile.am and giving this
information on the configure command-line:

./configure CC=sdcc LD=sdcc CFLAGS='--use-non-free -mpic16 -p18f4550'

and so on.

> I need to compile the code using SDCC compiler with the flags i specified 
> there,
> but when i try `make` i got error because of additional flags being added that
> SDCC doesn't recognize:

Right, I reckon the configure script isn't seeing what you put in
Makefile.am, finds another C compiler and is using flags appropriate
for that compiler. Putting CC=sdcc on the command line will let it
know. (I believe the error message you're getting is to do with the
"dependency style" of the C compiler that was found.)

Re: Draft of new combined manual for Autoconf and Automake

[Gavin Smith]

On 26 September 2015 at 15:36, Gavin Smith <gavinsmith0...@gmail.com> wrote:
> I've uploaded my work on editing the Automake manual at
> https://bitbucket.org/gavin_smith_/buildsystem-manual.

For reading on the WWW, I've put it on SourceForge, at
http://buildsystem-manual.sourceforge.net/index.html.

Draft of new combined manual for Autoconf and Automake

[Gavin Smith]

I've uploaded my work on editing the Automake manual at
https://bitbucket.org/gavin_smith_/buildsystem-manual. It combines
material from both the Autoconf and Automake manuals. I was hoping to
present this material in a logical way that would make sense to a
beginner. As you'll see from the many TODO notes in the text, it's a
work in progress. The manual there is in PDF and Info format, as well
as the Texinfo source. I haven't done much work on this for several
months, so I thought it would be better to polish off what I've done
in case it is interesting to anyone, and in case it motivates me to
carry on work on it.

Much of this combined manual is copied verbatim from the Autoconf and
Automake manuals. Some sections, like those on shell script or
Makefile portability, I haven't touched, and have no desire to touch.
I made more changes in the introductory sections as well as organizing
the material as a whole into a scheme that I felt was understandable.
Some left-over material got dumped at the end in sections called
"FAQ's" and "Rationales".

I'd like to acknowledge some of the comments made by Arthur Schwarz on
some of the drafts. He rewrote a chapter of the Automake manual, here:
http://lists.gnu.org/archive/html/bug-automake/2015-07/msg2.html,
which may or may not end up incorporated into this document.

Re: extra files for distribution

[Gavin Smith]

On 22 September 2015 at 18:12, Andy Falanga (afalanga)
 wrote:
> Hi,
>
> My project has some doc files which are currently generated by the
> parsing engine of Visual Studio.  Our plan is to simply generate them,
> periodically, and include them with our Linux build via autotools.  I'm
> not sure of how to include them though.  EXTRA_DIST isn't the answer
> because they are things which are *not* to be installed.  These files
> aren't necessary for the build which means I don't need them in the
> directives/primaries.  What is the Makefile.am magic I'm looking for
> which will include these extras in the installation but not include them
> in the build?

I don't understand what you mean: you say they are things that "are
*not* to be installed", but then you say you want to include them "in
the installation".

As far as I can tell EXTRA_DIST doesn't cause installation anywhere.

Re: extra files for distribution

[Gavin Smith]

On 23 September 2015 at 00:14, Andy Falanga (afalanga)
 wrote:
>> I previously wrote out a reply and then deleted it when I read your
>> email again. But maybe it was what you wanted. I was going to suggest
>> using a variable based on the DATA "primary", in Automake's
>> terminology. E.g. dist_foo_DATA = file.doc to install foo.doc in
>> ${foodir}.
>
> This does look promising but from this link,
> http://www.gnu.org/software/automake/manual/html_node/Uniform.html, it
> would seem that I've got to name a directory off of
> $(datadir)/[something] in order to make this work.  Unless I can force
> this datadir to be the same as $(libdir) then this will not work.  These
> xml files are parsed (I'm not sure how) by the python runtime.

It would naturally be dist_lib_DATA but if that doesn't work there is
a workaround in the Automake manual somewhere.

Please make @setfilename optional in Texinfo files

[Gavin Smith]

The next release of Texinfo will make a @setfilename line optional in
Texinfo files. Unfortunately Automake depends on its presence (as of
Automake 1.15). Please consider removing this requirement.

Re: Libtool, SWIG and testing

[Gavin Smith]

On 28 July 2015 at 16:58, Guillaume Marcais guilla...@marcais.net wrote:
 On Sat, Jul 25, 2015 at 9:41 AM, Gavin Smith gavinsmith0...@gmail.com
 wrote:


 I'd suggest not hard-coding the name of the shared library in the Perl
 code. It could be extracted from the *.la file. That would likely
 improve portability. I don't see any way to avoid looking in .libs.


 Thank you for your answer.

 In this case, the Perl code that loads the shared library is generated by
 SWIG (mummer.pm). It does use DynaLoader and calls bootstrap mummer;. The
 Makefile.am part that builds this library reads:

 perlextdir = $(PERL_EXT_LIB)
 perlext_SCRIPTS = perl5/mummer.pm
 perlext_LTLIBRARIES = perl5/mummer.la
 perl5_mummer_la_SOURCES = perl5/swig_wrap.cpp $(SWIG_SRC)

 plus some other flags set in _CPPFLAGS, _LDFLAGS etc. Could really LIBTOOL
 build a shared object in the .libs directory that could not be loaded by
 bootstrap mummer;?

From DynaLoader manpage:

 dl_findfile()
   Syntax:

   @filepaths = dl_findfile(@names)

   Determine the full paths (including file suffix) of one or more
   loadable files given their generic names and optionally one or more
   directories.  Searches directories in @dl_library_path by default
   and returns an empty list if no files were found.

   Names can be specified in a variety of platform independent forms.
   Any names in the form -lname are converted into libname.*, where .*
   is an appropriate suffix for the platform.

   bootstrap()
   Syntax:

   bootstrap($module [...])

   This is the normal entry point for automatic dynamic loading in
   Perl.

   It performs the following actions:

   ·   locates an auto/$module directory by searching @INC

   ·   uses dl_findfile() to determine the filename to load


so this relies on libtool creating the file and calling it
mummer.so.0 or similar. That's reasonably likely; I was being safe
because I figured that libtool added the dlname line to the *.la
file for a reason, for example:

# The name that we can dlopen(3).
dlname='mummer.so.0'


 In other words, for testing, I would rather use the Perl code that is
 generated by SWIG and that will ultimately will be installed, rather than
 having to write my own loader. So far it seems to work by only tweaking the
 environment with only the name .libs being really hard coded here. The
 name of the library is coming from the Makefile.am (perl5/mummer.la).

There are two library files, the *.la file and the actual file that is
dlopen'd, which could be a *.so file.

Does SWIG know anything about libtool?

Maybe you could ask on the libtool mailing list whether you can rely
on the library file being placed in .libs.

Re: Libtool, SWIG and testing

[Gavin Smith]

On 24 July 2015 at 20:13, Guillaume Marcais guilla...@marcais.net wrote:
 I am improving/writing a C++ project (called MUMmer) which creates a shared
 library with libtool. In the same project, I also create a SWIG binding to
 access in Perl some of the functionality of this shared library.

 Libtool creates the shared library in a hidden directory:

 .libs/libumdmummer.so

 The SWIG compilation creates a couple a files, a perl module file and a
 shared library:

 swig/perl5/mummer.pm
 swig/perl5/.libs/mummer.so

 The problem comes in when when I write tests in Perl. I need to add
 directories to the Perl lib path so that it finds the module and shared
 library, like this:

 perl -I ./swig/perl5 -I ./swig/perl5/.libs test.pl

 Passing the path './swig/perl5/.libs' seems very hackish and not portable.
 This path was not specified anywhere, libtools decided to hide files there
 on its own, and it feels like I should not use these files directly.

I'd suggest not hard-coding the name of the shared library in the Perl
code. It could be extracted from the *.la file. That would likely
improve portability. I don't see any way to avoid looking in .libs.

There are other ways to affect Perl's module search path: by setting
the PERL5LIB environmental variable, or by adding directories to @INC
when the Perl program is run.

I have a similar problem at the moment on a project. It doesn't use
SWIG, but XS. (I know nothing about SWIG.) You can see the code at
http://svn.savannah.gnu.org/viewvc/trunk/tp/Texinfo/Convert/XSParagraph/XSParagraph.pm?revision=6463root=texinfoview=markup
. It uses the DynaLoader module to load a dynamic library file.

See this recent discussion:
https://lists.gnu.org/archive/html/automake/2015-06/msg00018.html and
https://lists.gnu.org/archive/html/automake/2015-07/msg2.html.
Apparently this is a road not very well travelled, so there is no
proper way to do it.

Re: pre-dist hook?

[Gavin Smith]

On 11 July 2015 at 06:38, Harlan Stenn st...@ntp.org wrote:
 I'm thinking I want to run a hook before the distdir target is run.

 What's a good way to do that?

 The reason for this is that I'm packaging at least 2 nested packages in
 my distribution.  We only want to configure these if we need them.  The
 problem is that folks who don't need either/both of these packages
 don't want to spend the time configuring them, but in that case they
 cannot run make dist either.  To produce a distribution, one must
 generally configure these sub-packages so the dist target(s) can see
 these packages.

 So I figure a good answer is to have a pre-dist hook of some sort, so if
 somebody wants to run 'dist' I can make sure that the needed
 sub-packages have been built.

Could you do some trick with EXTRA_DIST? You could have a file that
only exists when the nested packages are configured that has to be
distributed.

Re: Integration of a Perl XS module with an Automake build system

[Gavin Smith]

On 3 July 2015 at 20:31, Russ Allbery ea...@eyrie.org wrote:
 You can see the approach that I took in various of my packages, such as:

 http://git.eyrie.org/?p=kerberos/webauth.git;a=blob;f=Makefile.am;h=2cc0aba845f450afcd60a6c01e02a33cb9bdc803;hb=9d3555c7f9047f5ac1c67237379072df5b864b82

 Search for BINDINGS to see the key components of this approach.  Also of
 interest are the Perl-related stuff in configure.ac:

 http://git.eyrie.org/?p=kerberos/webauth.git;a=blob;f=configure.ac;h=0dab897ff18323271e7e0455eca881bccbf314c2;hb=9d3555c7f9047f5ac1c67237379072df5b864b82

 and the Build.PL file:

 http://git.eyrie.org/?p=kerberos/webauth.git;a=blob;f=perl/Build.PL;h=f5bdb86d34c2a35a344404d6b00f431dd2cf27c6;hb=9d3555c7f9047f5ac1c67237379072df5b864b82

 which is extremely simple.  Note that this project (like all of my
 projects) uses a non-recursive make configuration.

Thanks for replying.

I've been trying to use Libtool as Bob hoped would be possible. I
haven't studied the build system in WebAuth that you linked to in
detail (or that in GraphicsMagick), but may do so if our current
approach doesn't work out.

 The key parts of this approach are:

 - Use Module::Build, not ExtUtils::MakeMaker.  It's significantly easier
   to deal with and supports a lot of options that make this much easier.

 - Perl's module build system does not handle VPATH properly, so if you
   want to support out-of-tree builds, the simplest approach is to just
   copy the Perl module source into the build directory before doing the
   build.

In the current Texinfo make distcheck does a VPATH build, and works
for me, at least (until we get a test failure due to different
behaviour from the XS module).

 - Let Perl handle its own compiler options and flags and only pass in
   things discovered by Autoconf that you know you need.  You'll have the
   least problems if you keep the Perl build as close to native as
   possible.  If you try to reinvent the Perl build system, you'll be in
   for a lot more work over time, since the build system changes a lot.

Alas, I fear I may have been doing exactly this. It didn't seem that
difficult really to replicate what ExtUtils::MakeMaker's Makefile did.
One rule to generate a .c file from a .xs file, plus some CFLAGS and
LDFLAGS obtained from the Perl Config module.

http://svn.savannah.gnu.org/viewvc/trunk/tp/Texinfo/Convert/XSParagraph/Makefile.am?revision=6386root=texinfoview=markup

Hopefully it doesn't rely on anything undocumented or unstable.

Re: Integration of a Perl XS module with an Automake build system

[Gavin Smith]

On 30 June 2015 at 23:06, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote:

 If you use a system which supports several completely different compilers
 targeting the same ABI, you immediately find dismay unless you compile
 Perl using the same compiler you plan to use.

 This is quite evident on Solaris systems which use the Sun/Oracle compiler
 to build the bundled Perl so it produces Sun compiler options which don't
 work with GCC.

I attempted to strip out all compiler flags but -I and -D, but that is
not good enough. The problem is not just with compiler flags, it's
also with the Perl config.h header, which is created when Perl is
compiled. For example, I was investigating this error:

libtool: compile:  /opt/solarisstudio12.3/bin/c99 -Xc -D_XPG6
-DPACKAGE_NAME=\texinfo\ -DPACKAGE_TARNAME=\texinfo\
-DPACKAGE_VERSION=\6.0\ -DPACKAGE_STRING=\texinfo 6.0\
-DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\texinfo\
-DVERSION=\6.0\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
-DLT_OBJDIR=\.libs/\ -I. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TS_ERRNO -DVERSION=\6.0\ -DXS_VERSION=\6.0\
-I/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE -I/opt/csw/include -c
XSParagraph.c  -KPIC -DPIC -o .libs/XSParagraph_la-XSParagraph.o
/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE/scope.h, line 221:
syntax error before or at: sigjmp_buf
/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE/proto.h, line 199:
syntax error before or at: off64_t

scope.h uses a preprocessor symbol  Sigjmp_buf which is defined as
sigjmp_buf or jmp_buf depending on config.h. In this case as
sigjmp_buf, which the compiler doesn't recognize. So you really do
have to use the same compiler, unless you want to find some way to
compensate somehow for everything decided in Perl's config.h.

I managed to compile and use the module fine when using gcc (which is
the opposite of what you might expect).

You see the configure script has selected the compiler
/opt/solarisstudio12.3/bin/c99, but the value of cc in the Perl
configuration is actually just cc on the system I tried it on. When
I forced it to use cc as the compiler, that worked as well.

Re: When is a compller needed in testing

[Gavin Smith]

On 2 July 2015 at 18:02, Arthur Schwarz aschwarz1...@att.net wrote:
 Shows specific identification of compilers, sic. PL_LOG_COMPILER and
 PY_LOG_COMPILER. Automake seems to have knowledge of particular language
 compilers and the user can specify their use as in:

 check_JAVA
 check_LISP
 check_PYTHON

 For _JAVA, _LISP, _PYTHON can I use check_ or must I separately specify a
 compiler as in ext_LOG_COMPILER and not use check_?

It seems like you're mixing up two different things. The JAVA, LISP
and PYTHON primaries are all used for processing interpreted languages
into a byte-code form. _LOG_COMPILER is for running tests. So if you
need to use bytecode-compiled Python as a test case, and if you need
to put something before the filename of the test case in the command
to run it, you need both.

 And just as a nit-noy, the document is clear to say that an AM_ prefix means
 that the variable is available to the developer and if AM_ is missing then
 the variable is available to the user. Why aren't ext_LOG_COMPILER prefixed
 with AM_ext_LOG_COMPILER as is done with AM_ext_LOG_FLAGS?

The AM_ prefix is only for user variables. ext_LOG_COMPILER are not
user variables. There are a handful of other Automake variables like
this: COMPILE, LINK, LDADD.

Integration of a Perl XS module with an Automake build system

[Gavin Smith]

Hello all,

I wonder if anyone could give pointers to advice on how to integrate a
Perl XS module with an Automake build system? Over at the Texinfo
project we're starting to replace parts of makeinfo with loadable
native-code modules, for speed.

The problem is that the Makefiles produced by ExtUtils::MakeMaker (the
module used by the XS tutorial, man perlxstut) doesn't follow the
standards required by Automake. (Info node (automake)Third-Party
Makefiles, and the GNU Coding Standards). For example, make clean
actually removes the Makefile.

I found a couple of web pages that mentioned this, so basically I was
looking for any updates since then, or other information.

http://www.eyrie.org/~eagle/journal/2013-01/025.html suggested not to
use ExtUtils::MakeMaker at all.

http://lists.gnu.org/archive/html/automake/2009-10/msg00034.html gave
a link to how t was done in GraphicsMagick. Today's version of that
appears to be at
http://hg.code.sf.net/p/graphicsmagick/code/file/f11c2c4e798c/PerlMagick/Makefile.am.

Many thanks,
Gavin

Re: Integration of a Perl XS module with an Automake build system

[Gavin Smith]

On 30 June 2015 at 14:25, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote:
 In addition to behavior issues, a major problem is that the re-link
 capabilities offered by libtool are not available.  If one links from the
 Perl module to a shared library in the build tree, then there is the risk of
 continued reference to the build tree after installation (a
 security/reliability issue) and the module might not even run. The Perl test
 suite is likely to use the wrong shared libraries while testing due to
 GNU/Linux's strong preference to using already-installed libraries cached by
 'ldconfig'.  Due to this, I changed GraphicsMagick so that it only links its
 Perl module at 'make install' and time it uses the already-installed shared
 library.  This still does not help with DESTDIR installs.

 After I made this change, some GNU/Linux distributions stopped building the
 GraphicsMagick Perl module at all due to claiming that the build is
 broken.  They expect that everything builds in tree in one step and that
 'make check' works as one would expect.  I don't think that this is possible
 to accomplish in a portable way using ExtUtils::MakeMaker.

 If there is a viable solution which avoids ExtUtils::MakeMaker and allows
 Automake to drive behavior, with linkage managed by libtool, then I am all
 ears.

I'm not linking to another dynamic library from the XS module, just a
static library, but I've been trying to build the library with libtool
using a Makefile.am of my own writing, using the Makefile output by
ExtUtils::MakeMaker as a reference. I've had a little bit success so
far, so hopefully I'm not on a wild-goose chase. I load the *.so file
libtool produces with the Perl DynaLoader module. The main problem
seems to be getting the right compiler flags. The first time I tried I
got a bizarre error message like Not a CODE reference when I tried
to run the bootstrap function in the module. (Although the object
wasn't null, I couldn't find out what it was.) I got it to work when I
copied a bunch of compiler flags over from the MakeMaker Makefile. My
Makefile.am currently has the lines:

-
pkglib_LTLIBRARIES = XSParagraph.la
XSParagraph_la_SOURCES = XSParagraph.c mylib/xspara.c mylib/xspara.h
BUILT_SOURCES = XSParagraph.c
XSParagraph_la_CPPFLAGS = -I. -I$(PERL_INC) -D_REENTRANT -D_GNU_SOURCE
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64

XSParagraph_la_CFLAGS = -fno-strict-aliasing -pipe -fstack-protector
-O2 -march=i486 -mtune=i686   -DVERSION=\6.0\ -DXS_VERSION=\6.0\
$(CCCDLFLAGS) -I/usr/lib/perl5/CORE

XSParagraph_la_LDFLAGS=-module


as well as a heap of other variable definitions copied from the
MakeMaker Makefile. Now I have to see how ExtUtils:MakeMaker knew what
flags to use to see if I can replicate it.

Using the DynaLoader module instead of XSLoader gives us the
flexibility to go looking for a dynamically-loaded library file
ourselves. The code to load the module looked like this:

---
our $VERSION = '6.0';
#bootstrap XSParagraph $VERSION;

# TODO: Get this from XSParagraph.la, the dlname field
my $dlname = Texinfo/Convert/XSParagraph/.libs/XSParagraph.so.0;

my $module = XSParagraph;

# Following steps under bootstrap in man DynaLoader.

# Doesn't work
#push @dl_require_symbols, boot_$module;

# TODO: Execute blib/arch/auto/XSParagraph/XSParagraph.bs ?
# That file is empty.

#my $flags = dl_load_flags $module; # This is 0 in DynaLoader
my $flags = 0;
my $libref = DynaLoader::dl_load_file($dlname, $flags);
if (!$libref) {
  die Couldn't find *.so file\n.;
}
my @undefined_symbols = DynaLoader::dl_undef_symbols();
if ($#undefined_symbols+1 != 0) {
  warn XSParagraph: still have undefined symbols after dl_load_file\n;
}
my $symref = DynaLoader::dl_find_symbol($libref, boot_$module);
if (!$symref) {
  die XSParagraph: Couldn't find boot_$module symbol\n;
}
my $xs = DynaLoader::dl_install_xsub(${module}::bootstrap,
$symref, $dlname);

if (!$xs) {
  die XSParagraph: Couldn't bootstrap\n;
}

# Doesn't work
#push DynaLoader::@dl_shared_objects, $file; # record files loaded

$xs($module, $VERSION);

Re: Integration of a Perl XS module with an Automake build system

[Gavin Smith]

On 30 June 2015 at 22:41, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote:
 as well as a heap of other variable definitions copied from the
 MakeMaker Makefile. Now I have to see how ExtUtils:MakeMaker knew what
 flags to use to see if I can replicate it.


 These definitely come from how Perl was originally compiled and built. If a
 different compiler sas used, the provided options may be completely
 different and not work with the compiler you are currently using (even if
 the generated code would interoperate).

 It would be good to find a way to tease these parameters out of the Perl
 installation.

I discovered the parameters were from a file
/usr/lib/perl5/Config_heavy.pl on my system, and they should be
retrievable using the Config perl module. I have the idea to retrieve
this information in configure.ac and substitute it into the Makefile.

What you say about using a different compiler is worrying, though, and
I hadn't thought about it before. So basically when compiling an XS
module, you need to use whatever compiler was used to compile perl in
the first place? I think we could retrieve this information and use it
only when compiling the XS module, allowing the rest of the program to
be compiled with the compiler that the configure script or user
chooses.

 Something else which changes is the identity of the target, which determines
 where build products go in the build tree and when installed.

What, you mean if cross-compiling? It seems impossible: how are we
supposed to know what compiler flags to use? Some information might
have to be provided manually. The same problem must have occurred with
libtool as well, for cross-compiling shared libraries.

Re: Integration of a Perl XS module with an Automake build system

[Gavin Smith]

On 30 June 2015 at 23:06, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote:
 On Tue, 30 Jun 2015, Gavin Smith wrote:


 What you say about using a different compiler is worrying, though, and
 I hadn't thought about it before. So basically when compiling an XS
 module, you need to use whatever compiler was used to compile perl in
 the first place? I think we could retrieve this information and use it
 only when compiling the XS module, allowing the rest of the program to
 be compiled with the compiler that the configure script or user
 chooses.


 If you use a system which supports several completely different compilers
 targeting the same ABI, you immediately find dismay unless you compile
 Python using the same compiler you plan to use.

 This is quite evident on Solaris systems which use the Sun/Oracle compiler
 to build the bundled Python so it produces Sun compiler options which don't
 work with GCC.

Assuming the same problem exists with Perl, then the only solution to
this I can think of is to generate the compiler options we need
automatically. Hopefully libtool can do this, and the diversity among
the ways that Perl can be compiled isn't so great that we are left in
the position of trying to convert from the compiler flags that Perl
was compiled with to the compiler flags of another compiler. If the
ABI is the same, it should be possible for Perl to load in a properly
compiled shared library object.

Through a process of elimination, I've found that the flag that made
the difference in my case was -D_FILE_OFFSET_BITS=64. Without this I
get:

Not a CODE reference at Texinfo/Convert/XSParagraph/lib/XSParagraph.pm line 83.
END failed--call queue aborted at
Texinfo/Convert/XSParagraph/lib/XSParagraph.pm line 83.
Compilation failed in require at Texinfo/Convert/Plaintext.pm line 34.
BEGIN failed--compilation aborted at Texinfo/Convert/Plaintext.pm line 34.
Compilation failed in require at Texinfo/Convert/Info.pm line 25.
BEGIN failed--compilation aborted at Texinfo/Convert/Info.pm line 25.
Compilation failed in require at ./texi2any.pl line 115.
BEGIN failed--compilation aborted at ./texi2any.pl line 115.

It still worked when I removed other flags like -fstack-protector,
so hopefully as long as _FILE_OFFSET_BITS and maybe a few other
symbols are defined to the same values as when Perl was compiled,
everything will work.

 Not specifically when cross-compiling. Perl has a particular way to name the
 directories in which it puts the module in the build tree and installation
 tree.  Part of this includes the basic architecture of the machine (as known
 to Perl).

As long as we use the directory layout Perl is expecting, everything
should be fine, right?

Re: How are data files input for to custom drivers?

[Gavin Smith]

On 27 May 2015 at 22:27, Arthur Schwarz aschwarz1...@att.net wrote:
 Then is seems that the test harness would have to do:
 cat data | tap-driver.sh
 ./script.sh | tap-driver.sh

 Because the awk loop in tap-driver.sh does a getline which reads from an
 input pipe (stdin). Have I read the code and the document correctly? This is
 really confusing to me. In 15.3.3.1 Command-line arguments for test drivers
 the manual says The first non-option argument passed to the test driver is
 the program to be run, and all the following ones are command-line options
 and arguments for this program. Which seems to mean that for custom drivers
 we get for:

In Makefile we have something like:

.t.log:
@p='$'; \
$(am__set_b); \
$(am__check_pre) $(T_LOG_DRIVER) --test-name $$f \
--log-file $$b.log --trs-file $$b.trs \
$(am__common_driver_flags) $(AM_T_LOG_DRIVER_FLAGS)
$(T_LOG_DRIVER_FLAGS) -- $(T_LOG_COMPILE) \
$$tst $(AM_TESTS_FD_REDIRECT)


The 'tst' shell variable is set inside 'am__check_pre' and is the name
of the test case.

In tap-driver.sh there is:

$@
echo $?
  ) | LC_ALL=C ${AM_TAP_AWK-awk} \
-v me=$me \
-v test_script_name=$test_name \
-v log_file=$log_file \
-v trs_file=$trs_file \
-v expect_failure=$expect_failure \
-v merge=$merge \
-v ignore_exit=$ignore_exit \
-v comments=$comments \
-v diag_string=$diag_string \
'
That final apostrophe is very important to notice: it is the start of
the awk script.

The $@ line executes the test case. This was all the arguments given
to the tap-driver.sh in the Makefile, but now all the options have
been shift'd. So the output of the test case is the input of awk, via
the pipe (|).

Re: What check_ programs can be used?

[Gavin Smith]

On 25 May 2015 at 16:28, Arthur Schwarz aschwarz1...@att.net wrote:

 What programs can be used for custom test drivers and test classes?

 check_JAVA
 check_LISP
 check_PYTHON
 check_FORTRAN
 check_?

There's no such variable as check_FORTRAN. Each language doesn't have
it's own primary.

I believe that check_ could be used for any primary - there's
nothing in the manual to suggest otherwise:

Info node (automake)Uniform:

   The special prefix 'check_' indicates that the objects in question
should not be built until the 'make check' command is run.  Those
objects are not installed either.

   The current primary names are 'PROGRAMS', 'LIBRARIES', 'LTLIBRARIES',
'LISP', 'PYTHON', 'JAVA', 'SCRIPTS', 'DATA', 'HEADERS', 'MANS', and
'TEXINFOS'.

Re: What does setting TEST_LOGS mean?

[Gavin Smith]

On 21 May 2015 at 09:12, Roman Neuhauser neuhau...@sigpipe.cz wrote:
 # aschwarz1...@att.net / 2015-05-20 17:00:57 -0700:
 15.2.3 Parallel Test Harness

 Suppose Makefile looks something like:

TESTS = foo.exe

 Then
TEST_LOGS = foo.log

 And the user sets this to
env TEST_LOGS = bar.log make -e check

 What on earth does this mean?

 first, it would have to be

   env TEST_LOGS=bar.log make -e check

 (no ws around the equals sign).

 second, it looks like a pilot error, and i would expect make to produce
 an error.

It seems pointless to set it in the Makefile.am, except maybe to
reduce the tests that are executed to a subset of those listed in
TESTS?

I would guess that overriding it from the command-line would need to
set it to a subset of the test logs. This seems pointless as you could
override TESTS instead.

 And what does 'set x subset*.log; shift' have to do with anything. It looks
 like something erroneously removed from an existing script and put in the
 document.

 that's just defensive shell script programming.  if no files match the
 pattern, it will expand to nothing, and set with no options or arguments
 produces a list of all parameters (variables) defined in the current
 shell environment (instead of setting argc = 0, argv = {}.  to prevent
 this mishap you need to ensure that set sees at least one argument,
 and then shift it off the beginning of argv.

It's like the test x$a = x$b trick in case either a or b is empty.

It would appear in the example that the subset*.log and foo.log are
logs for existing tests.

I can't see any purpose in this variable being documented.

Re: What cures a failure to make distdir?

[Gavin Smith]

On 18 May 2015 at 15:39, Arthur Schwarz aschwarz1...@att.net wrote:
 I've just tried to create and test my test case and received the message
 below. The script which is used to create the distribution is included along
 with the configure.ac, Makefile.am, and src/Makkefile.am files. The setup is
 for testing and not too large (130 lines - see below).

 What awful thing have I done to not be able to build distdir? Shouldn't this
 be part of the magic glue that holds the autotools together, which the
 autotools create all by themselves?

 == buildscript output ==

 if test -d test-0.5; then find test-0.5 -type d ! -perm -200 -exec chmod
 u+w {} ';'  rm -rf test-0.5 || { sleep 5  rm -rf test-0.5; }; else
 :; fi
 test -d test-0.5 || mkdir test-0.5
  (cd src  make  top_distdir=../test-0.5 distdir=../test-0.5/src \
  am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=:
 distdir)
 make[1]: Entering directory
 '/cygdrive/e/home/skidmarks/Projects/Test/automake/dist/src'
 make[1]: *** No rule to make target 'distdir'.  Stop.
 make[1]: Leaving directory
 '/cygdrive/e/home/skidmarks/Projects/Test/automake/dist/src'
 Makefile:515: recipe for target 'distdir' failed
 make: *** [distdir] Error 1
 tar: test-0.5.tar.xz: Cannot open: No such file or directory
 tar: Error is not recoverable: exiting now

 = Chaos comes from maintenance =

Hi Arthur,

I had to fiddle about a bit with ./buildscript.sh for it to build on
my system, here's what I ended up with:

#!/bin/bash
# cd ~/Projects/Test/automake/dist/ 
 autoreconf --install \
 ./configure 
 make dist-xz  \
 cp test-0.5.tar.xz ../installDir/  \
 cd ../installDir  \
 rm -rf test-0.5/;
 tar xfa test-0.5.tar.xz  \
 cd test-0.5/  \
 ./configure --prefix=`pwd`/..  make  make install  make check

I also had to touch README.

It seemed to run the test suite fine. I don't know what was going on
on your system.

Full output of ./buildscript.sh attached.


output
Description: Binary data

Re: Setting environment variable for make dist

[Gavin Smith]

On 10 May 2015 at 13:57, Bas Vodde b...@odd-e.com wrote:
 I'm trying to change my projects configure.ac so that it sets the
 COPYFILE_DISABLE=1 environment variable to influence the make dist target.

What running program needs to have this environment variable set in
its environment? Is it the shells that are created by Makefile rules
when make dist is run?

 Background: The COPYFILE_DISABLE=1 avoids having a second top-level
 directory in your package when packaging on MacOSX.

What programs pay attention to this variable?

 So far, my attempt was to set the variable in the configure.ac file and use
 AC_SUBST on it, but that didn't seem to work.

This will create a Makefile variable, which is different to an
environmental variable. That is, a line like COPYFILE_DISABLE=1 will
appear in the generated Makefile, and this will be substituted
elsewhere in the Makefile if the COPYFILE_DISABLE variable is referred
to. However there is nothing there to change environmental variables.

Re: Question of the use of TESTS

[Gavin Smith]

On 30 April 2015 at 23:01, Arthur Schwarz aschwarz1...@att.net wrote:

 I'm trying figure out how the serial testing environment works and:

 If TESTS is defined in Makefile.am as
 TESTS = a.sh

 And the user changes it to:

env TESTS=b.sh c.exe d.py e.pl make -e check

 What happens?

Why not try it and see?

Re: Question on --test-name=NAME

[Gavin Smith]

On 26 April 2015 at 16:30, Arthur Schwarz aschwarz1...@att.net wrote:


 15.3.3.1 Command-line arguments for test drivers

--test-name=NAME

The name of the test, with VPATH prefix (if any) removed. This can
 have a suffix and a directory component (as in e.g., sub/foo.test), and is
 mostly meant to be used in console reports about testsuite advancements and
 results (see Testsuite progress output).


 If test-name is _mostly meant to be used in console reports_ why is there
 any concern for a path? One can use any string in a report, paths are
 unnecessary, and you haven't specified any other use.

 So let me guess what you might be trying to say. From 15.3.1 Overview of
 Custom Test Drivers Support it appears that the test handler (responsible
 for test suite summaries and I suspect for executing test drivers) executes
 the _custom test driver_ which executes a test program, which must be a
 _test script_. The test script usage is directly contradicted in 15.3.2
 Declaring Custom Test Drivers where _ext_ may or may not be a script suffix,
 but whose counting.

 The _custom test driver_ is responsible for interpreting command line
 arguments. One assumption is that when this argument is received the _custom
 test driver_ executes the NAME given in the command line argument. Of
 course, if this were true then it is possible to input a NAME which is not
 one of the known tests given by the developer. I don't know that this makes
 much sense, to execute a random script not defined by the developer.

After the list of options it says:

The first non-option argument passed to the test driver is the program
to be run, and all the following ones are command-line options and
arguments for this program.

By program it means test script.

Maybe this could be clearer with a synopsis, like DRIVER
DRIVER-OPTIONS -- TEST [TEST-OPTIONS]. It could be more explicit that
the test driver has to run the program it is given: maybe

The first non-option argument passed to the test driver is the test
script for it to run.

Re: Automake Manuals (RANT)

[Gavin Smith]

On 26 April 2015 at 01:25, Arthur Schwarz aschwarz1...@att.net wrote:

 Well, putting it gently you have a good product and one of (maybe, the)
 worst manual on earth describing it.

I'd like to see improvements as well, but calling other people's work
the worst manual on earth is not conducive to soliciting their
cooperation.

 You can’t argue that as a volunteer
 effort you depend on volunteers, because you have volunteers willing and
 wanting to put their backs to the wheel to improve your manual, e.g.,
 http://lists.gnu.org/archive/html/autoconf/2014-09/msg0.html. My
 question is why don’t you use these ready hands or why don’t we see their
 result?

One of the maintainers has to take the time to review the suggestions.
In general, from what I can see, work on automake has been limited in
the last year or so. I am not an automake developer myself but I can
say that I didn't work through your initial email about the Test
Suites section in detail because I didn't have time.
(http://lists.gnu.org/archive/html/automake/2015-03/msg00077.html).


 Lest you think that I wail at others without efforts of myself, let me say
 “nay”. I am trying to help as best I can by rewriting all of Section 15
 Support for test suites. But I don't know Tex/LaTex/Texinfo and my efforts
 are restricted to Open Office/Adobe PDF and Open Office generated LaTex
 files - and others have commented on their inadequacy,
 http://lists.gnu.org/archive/html/automake/2015-04/msg00026.html.

One suggestion I have is that when you completely rewrite a section,
it takes effort to see what you have added, removed, and reordered,
and you have to guess at your reasons for doing so.

I expect it will be easier to get smaller changes accepted
incrementally. Are there any automake developers who would like to
work with Arthur, me and others on reviewing changes to the manual,
like the following suggestion:

  pg. 103 When no test protocol is in use ...
  Do you mean to say that script based testing does not use a test
protocol or that script based testing may or may not use a protocol but this
discussion centers on using script based testing without using a protocol?
Since no protocol is used, doesn't the exit status and its use constitute a
protocol? And what are we going to do about FAIL, PASS, SKIP ... previously
described. Are they protocols whereas exits statuses (stati sounds so
pretentious) of 0, 77 and 99 are not protocols?

I think that is a valid point: In the previous paragraph, we read: By
default, only the exit statuses of the test scripts are considered
when determining the testsuite outcome.  But Automake allows also the
use of more complex test protocols,... - which implies that the exit
status _is_ a protocol. Yes, the reader can work out what is meant;
but it does make it more difficult to read.

 My fondest hope is that the comments of others, as well as myself, are taken
 to heart and that you begin to solicit or perform needed document changes.

Re: Question on --test-name=NAME

[Gavin Smith]

 As a point, 15.3.3.1 Command-line arguments for test drivers shows all
 options as having the syntax --option=value. Your example does not have
 this syntax. Will your example work? Should this be in the manual, as in
 --option[=| ]value?

I am sure that both should be supported although I haven't found a
reference for this.

 By the way, you have @p='t/file.sh' and --test-name $$f. Do you mean
 --test-name $$p?

I just copied from a Makefile.in file, which does work. You wouldn't
be writing something like that by hand. I expect the f variable is
hidden in $(am__check_pre) somewhere.

Re: Question on --test-name=NAME

[Gavin Smith]

On 26 April 2015 at 18:39, Arthur Schwarz aschwarz1...@att.net wrote:
 Now for the case you mentioned in identifying a program, which is really a
 test case renamed in the manual for mystifying and unknowable reasons. Well,
 there is no mechanism for The first non-option argument passed to the test
 driver is the program to be run, and all the following ones are command-line
 options and arguments for this program. Let's go through some of options.

 Suppose command line arguments are input on the command line (seems
 reasonable huh).

I think you are wrong there. When it says command-line, it means a
command line in a Makefile recipe. You will see it by looking at any
Makefile.in generated from a Makefile.am with tests. It will look
like:

t/file.sh.log: t/file.sh
@p='t/file.sh'; \
b='t/file.sh'; \
$(am__check_pre) $(LOG_DRIVER) --test-name $$f \
--log-file $$b.log --trs-file $$b.trs \
$(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS)
$(LOG_DRIVER_FLAGS) -- $(LOG_COMPILE) \
$$tst $(AM_TESTS_FD_REDIRECT)

You can see the command-line options like --test-name etc.

 Note that none of the command line inputs are identified or
 described in the make help file (make --help) or the make man pages (man
 make). I haven't looked at info make but, things being what they are, their
 probably not there either. So, since the manual doesn't describe how or what
 to do I guess we get to make it all up.

As I said before, they are not options typed in by a user invoking make.


 In http://lists.gnu.org/archive/html/automake/2015-04/msg00022.html the
 question was asked as to how a program (test script) is to be entered. Let's
 see.

 Option 1: make program check
 Option 2: make program
 Option 3: make --test-name=NAME program check
 Option 4: make --test-name=NAME check
 Option 5: make program --test-name=NAME check
 Option 6: you can't do it

 Pick one or invent your own! That's how the command line options must be
 input. I can't think of another way.

They are input by automatically generated makefile rules - see above.


 Oh, about the example. The automake variable can't be used for anything but
 scripts, see 15 Support for test suites The other (and most used) form is
 based on the use of generic test scripts, and its activation is triggered by
 the definition of the special TESTS variable. This quite clearly says that
 anytime that a TESTS variable is seen then generic scripts are used. But the
 example has TESTS = foo.pl bar.py baz which are not generic scripts. It
 must mean that the test driver is a generic script, but oh wait. The test
 drivers are for PERL and PYTHON and scripts. And (last time I looked) PERL
 and PYTHON were not generic scripts.

They could be run the same way as shell scripts, as long as they have
the right #! header.

Re: Test Harness Command Line question

[Gavin Smith]

On 25 April 2015 at 00:13, Arthur Schwarz aschwarz1...@att.net wrote:

 15.3.3.1 Command-line arguments for test drivers

 --color-tests={yes|no}

 Is 'always' an option?  See 15.2.1 Scripts-based Testsuites
 AM_COLOR_TESTS=always

From my reading, if AM_COLOR_TESTS=always, then --color-tests=yes will
be passed as an argument, and always is not an option.

Re: automake document section 15 change

[Gavin Smith]

On 13 April 2015 at 20:34, Arthur Schwarz aschwarz1...@att.net wrote:
 I am very much a novice at this so if I have made (some) mistake(s) please
 tell me how to correct them.

 I have a suggested change to the general introduction given in Section 15
 support for test suites section of the manual. Before I proceed with any
 additional input/changes/opinions/or anything I would like to submit my
 suggestions. If they are favorably received then I will continue as best I
 can. My viewpoint is to contribute and not criticize.

 The .tex file generated was generated using Open Office vrs. 4.1.1 with
 extension writer2latex. This is my first use and I have not the slightest
 idea whether it works or how well it works (if you have suggestions of using
 a .tex reader then I'd be grateful).

I would like to comment on your text but can't because the generated
content like the following is unreadable:

 \newcommand\labellistLileveli{\textstyleBulletSymbols{{\textbullet}}}
 \newcommand\labellistLilevelii{\textstyleBulletSymbols{{\textbullet}}}
 \newcommand\labellistLileveliii{\textstyleBulletSymbols{{\textbullet}}}
 \newcommand\labellistLileveliv{\textstyleBulletSymbols{{\textbullet}}}
 \newenvironment{listLileveli}{\def\writerlistleftskip{\setlength\leftskip{0.
 5in}}\def\writerlistparindent{}\def\writerlistlabel{}\def\item{\def\writerli
 stparindent{\setlength\parindent{-0.25in}}\def\writerlistlabel{\makebox[0cm]
 [l]{\labellistLileveli}\hspace{0.25in}\writerlistremovelabel}}}{}
 \newenvironment{listLilevelii}{\def\writerlistleftskip{\setlength\leftskip{0
 .75in}}\def\writerlistparindent{}\def\writerlistlabel{}\def\item{\def\writer
 listparindent{\setlength\parindent{-0.25in}}\def\writerlistlabel{\makebox[0c
 m][l]{\labellistLilevelii}\hspace{0.25in}\writerlistremovelabel}}}{}
 \newenvironment{listLileveliii}{\def\writerlistleftskip{\setlength\leftskip{
 1in}}\def\writerlistparindent{}\def\writerlistlabel{}\def\item{\def\writerli
 stparindent{\setlength\parindent{-0.25in}}\def\writerlistlabel{\makebox[0cm]
 [l]{\labellistLileveliii}\hspace{0.25in}\writerlistremovelabel}}}{}
 \newenvironment{listLileveliv}{\def\writerlistleftskip{\setlength\leftskip{1
 .25in}}\def\writerlistparindent{}\def\writerlistlabel{}\def\item{\def\writer
 listparindent{\setlength\parindent{-0.25in}}\def\writerlistlabel{\makebox[0c

You would get more comments if you used the format of the existing
Texinfo sources for the manuals. If you don't want to learn how to
write Texinfo plain text would be preferable to automatically
generated LaTeX.

 I have looked at the generated .tex file and I don't see any of my created
 figures. If figures are not supported I suppose that text and effort are
 wasted.

Images are supported with the @image Texinfo command.

Re: Questions on Test Command Line inputs

[Gavin Smith]

On 25 April 2015 at 00:04, Arthur Schwarz aschwarz1...@att.net wrote:

 In 15.3.3.1 Command-line arguments for test drivers

 --log-file=PATH.log

 The .log file the test driver must create (see Basics of test metadata).
 If it has a directory component (as in e.g., sub/foo.log), the test harness
 will ensure that such directory exists before the test driver is called.

 Q: Does this mean that custom, dejagnu, and TAP test drivers must generate a
 log file? When I run a test it seems that the output of scripts or programs
 (TEST = some_script_or_program) is captured in a log file by the test
 harness, as in some_script_or_program.log.

From my reading, it means that a custom driver must recognize this
option, but it could do what it likes with it. See 15.3.1. Overview of
Custom Test Drivers Support.


 --trs-file=PATH.trs

 The .trs file the test driver must create (see Basics of test metadata).
 If it has a directory component (as in e.g., sub/foo.trs), the test harness
 will ensure that such directory exists before the test driver is called.

 Q: The command line input is given without qualification. Does this mean
 that it applies to all of the serial and parallel test harness, the custom,
 dejagnu and TAP test drivers, and test scripts?  Or should there be some
 qualification

This is in a section of the manual that is specifically about custom
test drivers.

Re: API for Custom Drivers

[Gavin Smith]

On 25 April 2015 at 00:27, Arthur Schwarz aschwarz1...@att.net wrote:

 In 15.3.3.1 Command-line arguments for test drivers there is the
 statement:

 The first non-option argument passed to the test driver is the program to
 be run, and all the following ones are command-line options and arguments
 for this program.

 In 15.3.2 Declaring Custom Test Drivers we have the automake variables
 LOG_DRIVER and ext_LOG_DRIVER. Assuming LOG_DRIVER = driver, does the
 statement mean that to execute driver I type:

make driver

 Instead of
make check ?


I don't how the statement could mean that. When it mentions an
arguments passed to the test driver, this is not referring the
arguments passed to make.

Re: API for Custom Drivers

[Gavin Smith]

On 25 April 2015 at 13:11, Arthur Schwarz aschwarz1...@att.net wrote:
 In 15.3.2 Declaring Custom Test Drivers we have the automake variables
 LOG_DRIVER and ext_LOG_DRIVER. Assuming LOG_DRIVER = driver, does the
 statement mean that to execute driver I type:

make driver

 Instead of
make check ?


 I don't how the statement could mean that. When it mentions an
 arguments passed to the test driver, this is not referring the
 arguments passed to make.

 Q: From the reading it looks like there are options followed by non-options
 on the command line. I guess my confusion is that the options (--options)
 seem to be command line options.

They are command-line options, just not the options passed to the
make command line.

 Q: Are there other ways to pass options to a test driver?

I've never used the custom driver feature of Automake and all I know
comes from reading the manual. Section 15.3.2 Declaring Custom Test
Drivers appears to explain how to specify a custom test driver to
use.

 Q: How can you select one of perhaps many, test drivers?
 Q: If there are many test drivers how can you select many, but not all, of
 them, make [options] driver1 driver2 check?


From what I can see it would be something like LOG_DRIVER=driver1
make check to override the test driver to use. I don't think there's
any way of using more than one at once.

Re: Is TEST_EXTENSIONS a user or developer variable?

[Gavin Smith]

On 28 March 2015 at 23:54, Arthur Schwarz aschwarz1...@att.net wrote:
 Win7-64 bits
 Cygwin
 Automake 1.14,  Nov 2013

 15.2.3 Parallel Test Harness
 Pg. 113

 TEST_EXTENSIONS defaults to .test; it can be overridden by the user ...

 All examples indicate that this is a developer variable, and the body of
 thext seems to focuse on the develop and not the user. Is there a role for
 this on the user side? How can it be used?

It could be overridden by the developer writing the Makefile.am, but I
can't see any point in it being overridden by the user who is running
make.

Re: Autmoake (test) editing

[Gavin Smith]

On 1 April 2015 at 00:35, Arthur Schwarz aschwarz1...@att.net wrote:
 Well, I've never done a patch. More appropriately, the Automake document
 needs a thorough review and rewriting. I don't have the knowledge to do
 that, I don't know automake. More appropriately, the patches would be more
 extensive then just casual corrections, and I don't have the authority to do
 them.

 My argument is that the document unsuccessfully presents a quality product.
 I can participate in a dialog of how to change the product documentation so
 that it provides the Autoake developers intent in a manner suitable for a
 new user, and suitable as a reference for an experienced user. But, sign, I
 haven't been asked.

I made some comments about the introductory sections of the Automake
manual here:
http://lists.gnu.org/archive/html/autoconf/2014-09/msg00061.html. But
nobody has had time to look at it yet. I expect that factual
inaccuracies are easier to get fixed than style and organization,
which are more subjective.

Re: Automake Manual pg. 113 qutestion

[Gavin Smith]

On 2 April 2015 at 17:41, Arthur Schwarz aschwarz1...@att.net wrote:
 Win7-64-bit
 Cygwin
 Automake 1.14.1

 The example given on the page has:

 % cat configure.ac
  o o o
 AC_REQUIRE_AUX_FILE([tap-driver.sh])

  o o o

 % cat Makefile.am
 TEST_LOG_DRIVER = env AM_TAP_AWK='$(AWK)' $(SHELL) \
  $(top_srcdir)/build-aux/tap-driver.sh

  o o o

 % cp PREFIX/share/automake-APIVERSION/tap-driver.pl .

 Do you mean

 % cp /PREFIX/share/automake-APIVERSION/tap-driver.sh .


 That's what it says on
https://www.gnu.org/software/automake/manual/html_node/Use-TAP-with-the-Automake-test-harness.html#Use-TAP-with-the-Automake-test-harness
so it must have been fixed.

 On my cygwin system there are several automakes (automake-1.5 automake-1.7
 automake-1.9 automake-1.4 automake-1.6 automake-1.8 automake-1.10
 automake-1.11 automake-1.12 automake-1.13 automake-1.14) which allows (I
 suspect) inconsistencies between versions to be best accommodated by
 selecting a version of choice (?). In consequence the tap-driver.sh
 reference is version specific (automake-*/). Again on my system, there is no
 automake-APIVERSION. So, is this access path specific to Unix* or is it no
 longer relevant?

It depends on how the cygwin package was installed. You should be able
to find the tap-driver.sh file somewhere.

Re: How are env variables passed to the compilation process

[Gavin Smith]

On 10 March 2015 at 22:04, Andy Falanga (afalanga) afala...@micron.com wrote:
 I'm trying to figure out how things like CXXFLAGS and CFLAGS get passed to 
 ultimate point of compilation.  I thought I had it down but something that 
 just happened recently has me wondering.  I've gotten my project building now 
 using automake/autoconf/etc. (what I understand to be the autotools).  Now, 
 the first target system I'm building on builds the code just fine but the 
 library caused a segmentation violation.  I'd like to debug.

 I go through the list of output made by the build process and discover that 
 the build process didn't do what seems to be the standard options, -O2 
 -g.   Neither of these were used.  So, I thought I'd add them.  I did this:

 make clean
 ./configure CFLAGS=-ggdb -O0 CXXFLAGS=-ggdb -O2
 make

 Much to my surprise, the -ggdb -O0 didn't appear then either.  Did I miss 
 something?  Isn't this how they are set?

To get a hint of where it has gone wrong, have a look in the
Makefile file that is produced by the configure script. It should
have a lines like

CFLAGS = -ggdb -O0

in it. If it does, there is something wrong in the rest of the
Makefile, so the problem is with the Makefile.am file. If it says
something else, the value of CFLAGS is not being set properly by the
configure script, so the problem is with the configure.ac file.

Re: How to add new Makefile-Rules through Configure?

[Gavin Smith]

On 8 March 2015 at 22:29, Marc Wäckerlin m...@waeckerlin.org wrote:
 I didn't find any proper solution with google for the following problem:

 How do the makefile rules come into the makefile?

 E.g. when I use AC_PROG_CXX, in the makefile rules should be added, such as
 compiling .o from .cxx and to cleanup .o files, and so on -  or ar these
 rules always there?

The rules are always there. To be more precise, automake will generate
rules to build .o files from .cxx files if you give .cxx files as
source files in Makefile.am. However, these rules will use a variable
to give the name of the compiler. Hence, automale checks that the
necessary macros are used in configure.ac to appropriately set the
variables these rules need.


 I would like to add something to configure.ac, that creates new rules, new
 cleanup files, etc.

 e.g. for adding Qt support (or support for any other code generating tool):

 uic creates uic_%.h files from %.ui and the derieved uic_%.h files should
 then be cleaned up with make clean

 I found the following hack as solution:

 In ax_check_qt.m4 that I include in configure.ac, I add:
 ---
   AX_ADDITIONAL_QT_RULES_HACK='
 %_ui.hxx: %.ui
 ${UIC} -o [$][@] $

 moc_%.cxx: %.hxx
 ${MOC} -o [$][@] $'
   AC_SUBST(AX_ADDITIONAL_QT_RULES_HACK)
 ])
 ---

 In the makefile, automake copies the variable, but is unable to handle the
 multi-line content, so the rules go straight into the makefile:
 ---
 AX_ADDITIONAL_QT_RULES_HACK =
 %_ui.hxx: %.ui
 ${UIC} -o $@ $

 moc_%.cxx: %.hxx
 ${MOC} -o $@ $
 ---

 So, it works, but it is a dirty hack, and it doesnot resolve the problem of
 adding the derieved objects to CLEANFILES.

In case you didn't know, you can add your own rules directly in
Makefile.am. You may have trouble if you use GNU make extensions,
though.


 All ui-files in xxx_SOURCES should automatically add ui_xxx.hxx to the
 CLEANFILES, so:
 ---
 bin_PROGRAMS = cardgui
 cardgui_SOURCES = cardgui.cxx cardgui.hxx \
   password.hxx cardgui-model.hxx \
   cardgui.ui password.ui
 ---
 Should generate CLEANFILES += ui_cardgui.hxx ui_password.hxx. How can I
 achieve this?


 Any ideas? What would be the intended solution?

If you are generating files to be used as sources, you might want to
use the BUILT_SOURCES automake variable in Makefile.am. This should
cause these built sources to be included in cleaning.

Re: AM_CONDITIONAL + AM_COND_IF does not work

[Gavin Smith]

On 9 March 2015 at 15:06, Marc Wäckerlin m...@waeckerlin.org wrote:
 According to the official documentation(*):
 --
 Here is an example of how to define a conditional config file:
 AM_CONDITIONAL([SHELL_WRAPPER], [test x$with_wrapper = xtrue])
 AM_COND_IF([SHELL_WRAPPER],
[AC_CONFIG_FILES([wrapper:wrapper.in])])
 --

 I try to generically find out, whether examples/makefile.am exists in a
 project and to automatically use it, if it exists:
 --
 AM_CONDITIONAL([HAVE_EXAMPLES_DIR], [test -f examples/makefile.am])
 AM_COND_IF([HAVE_EXAMPLES_DIR], [AC_CONFIG_FILES([examples/makefile])])
 --

 But automake fails:
 --
 configure.ac:27: error: required file 'examples/makefile.in' not found
 --

 So, what's the problem?

 It's nearly the same code as in the example ...


As you found automake gets information from configure.ac. It does this
using a macro tracing feature of autoconf. If you run automake
--verbose you will see the macros it is tracing, including
AC_CONFIG_FILES. With a setup like yours,

$autoconf --trace=AC_CONFIG_FILES:\$f:\$l::\$d::\$n::\${::}%

gives the output

configure.ac:6::1::AC_CONFIG_FILES::examples/makefile:examples/makefile.in
configure.ac:12::1::AC_CONFIG_FILES::Makefile

automake doesn't know or care that one of these uses of
AC_CONFIG_FILES was conditional. It is looking for the input files to
automake (like Makefile.am), which it will derive from the arguments
to AC_CONFIG_FILES. It wouldn't be possible for these input files to
be defined conditionally in the configure script, because logically
automake runs before the configure script.

The automake manual says that automake won't recognize an argument to
AC_CONFIG_FILES if its value is given indirectly through a shell
variable (see Requirements node), so maybe you could try that.

Re: converting to subdir-objects

[Gavin Smith]

On 8 March 2015 at 11:50, Diego Elio Pettenò flamee...@flameeyes.eu wrote:
 On 8 March 2015 at 09:46, Harlan Stenn st...@ntp.org wrote:

  foo_SRCS = ... $(srcdir)/../foo/bar.c


 Have you tried omitting $(srcdir) altogether? It should work just fine
 then. So just foo_SOURCES = ../foo/bar.c

This does work, once you manage to get back to a clean state avoiding
the brokenness of the current build system, which is tricky. make
distclean is broken as well. I got my test case to work by doing
something like autoreconf -i, rerunning configure and removing the
incorrectly created directories A/foo and A/$(srcdir)  manually.

Re: How to use ld options correctly for --whole-archive in automake and libtool

[Gavin Smith]

On 4 March 2015 at 19:05, Andy Falanga (afalanga) afala...@micron.com wrote:
 I'm trying to reproduce this using the automake tools.  I have this in the 
 Makefile.am located in sata:

 lib_LTLIBRARIES = satacpp.la
 satacpp_la_SOURCES = ...

 pyexec_LTLIBRAIRES = sata.la
 sata_la_LDFLAGS = -module
 sata_la_LIBADD = -Wl,--whole-archive ../Shared/HwMgmt/.libs/libhwmgmt.a 
 ../Shared/Misc/.libs/libmisc.a .libs/libsata.a -Wl,--no-whole-archive -lz -lrt

 As I'm sure no one here will be surprised, this causes automake to fail 
 because, linker flags such as '-Wl,--whole-archive' belong in 
 sata_la_LDFLAGS.  However, when I place this there, I find that Makefile.in 
 and the final Makefile have things where I expect them, but when make runs, 
 the libraries I've specified to be included as whole-archive are not listed 
 between this option.  Instead, they are listed earlier and *nothing is 
 listed* between -Wl,--whole-archive -Wl,--no-whole-archive.  I assume that 
 libtool is doing this for me.


I don't know if will work in your case, but I managed to work around
automake's policing of one of its variables in a similar situation by
hiding the value in a variable set by the configure script, e.g. do

my_libadd=-Wl,--whole-archive ../Shared/HwMgmt/.libs/libhwmgmt.a
../Shared/Misc/.libs/libmisc.a .libs/libsata.a -Wl,--no-whole-archive
-lz -lrt
AC_SUBST([my_libadd])

in configure.ac, and

sata_la_LIBADD=$(my_libadd)

in Makefile.am.

Re: Auto-Generating ChangeLog and AUTHORS for projects in a version tracking system?

[Gavin Smith]

On Wed, Oct 29, 2014 at 10:39 PM, Eric Blake ebl...@redhat.com wrote:
 On 10/29/2014 04:29 PM, Diego Elio Pettenò wrote:

 Can't we just say that gnu-flavour automake is pointless and foreign should
 be the default? Or am I too opinionated on that?

 For GNU projects, the 'gnu' flavor still makes sense, even if it could
 use a little modernization such as easier automation of generating
 ChangeLog from version control.  And while these days, automake is
 probably used by more non-gnu projects (where 'foreign' may make more
 sense) than GNU projects, that's still not a good reason to toggle the
 default.  I like what the GNU Coding Standards represent, and deviating
 from them deserves a mention in configure.ac to make it apparent that
 you thought about it.


Having to either specify 'foreign' or creating files like ChangeLog
or AUTHORS is an extra step in initializing an automake project,
which would be a slightly tricky and involved process even without
this step. It's annoying that automake /could/ run, but refuses to
because you forgot to put AUTOMAKE_OPTIONS=foreign in Makefile.am.
Extra steps like this limit the usefulness and applicability of a
program Even if you intend to follow the GNU Coding Standards you will
not necessarily want to write all these files at the beginning. Or the
project may never be intended for release.

What about checking for these files in make distcheck instead? That
way you could initialize and use an automake build system without
worrying about it, but you would still get a warning when you were
thinking of making a release, when the project is in a more complete
state.

Re: Building Automake 1.14.1 on mac os x 10.6.8

[Gavin Smith]

On Sun, Nov 2, 2014 at 6:27 PM, Arno Bootsmann boom...@icloud.com wrote:
 I am trying to compile Automake on mac os x 10.6.8, but get the following 
 error
 message:

 forge:automake-1.14.1 boomaxx$ make
 cd .  /opt/src/automake-1.14.1/t/wrap/automake-1.14 --gnu --ignore-deps 
 Makefile
 Can't locate /opt/src/automake-1.14.1/bin/automake in @INC (@INC contains: 
 /Library/Perl/Updates/5.10.0 
 /System/Library/Perl/5.10.0/darwin-thread-multi-2level 
 /System/Library/Perl/5.10.0 /Library/Perl/5.10.0/darwin-thread-multi-2level 
 /Library/Perl/5.10.0 /Network/Library/Perl/5.10.0/darwin-thread-multi-2level 
 /Network/Library/Perl/5.10.0 /Network/Library/Perl 
 /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level 
 /System/Library/Perl/Extras/5.10.0 .) at 
 /opt/src/automake-1.14.1/t/wrap/automake-1.14 line 27.
 make: *** [Makefile.in] Error 2


I've managed to get a similar error message to appear under GNU/Linux,
although not compiling from the released file directly with
./configure and make. It appears when the rule runs to regenerate the
Makefile and the generated automake file (bin/automake) is missing:

$ tar xf automake-1.14.1.tar.xz
$ cd automake-1.14.1
$ ./configure
[...]
$ make
[...]

This works successfully. Then:

$ rm bin/automake
rm: remove write-protected regular file 'bin/automake'? y
$ touch Makefile.am
$ make V=1
rm -f t/testsuite-part.tmp t/testsuite-part.am
/usr/bin/perl ./gen-testsuite-part \
  --srcdir .  t/testsuite-part.tmp
chmod a-w t/testsuite-part.tmp
mv -f t/testsuite-part.tmp t/testsuite-part.am
 cd .  /home/g/extsrc/automake-1.14.1/t/wrap/automake-1.14 --gnu
--ignore-deps Makefile
Can't locate /home/g/extsrc/automake-1.14.1/bin/automake in @INC (@INC
contains: /usr/local/lib/perl5 /usr/local/share/perl5
/usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5
/usr/share/perl5 .) at
/home/g/extsrc/automake-1.14.1/t/wrap/automake-1.14 line 27.
make: *** [Makefile.in] Error 2

I would guess there is something wrong with the timestamps causing the
Makefile rebuilding rules to be run.

Re: Static Library Linking Problem using Autotool

[Gavin Smith]

On Tue, Oct 28, 2014 at 3:34 AM, Wy kevinthesun kevinthesu...@gmail.com wrote:
 Finally I tried to test Encoder library as before. I create Test6 Project
 which only included Encoder.h and wrote Makefile.am similarly as Test3:

 bin_PROGRAMS = Test6
 Test6_SOURCES = Test6.cpp

 Test6_LDFLAGS = -L/home/kevinthefire/workspace/Encoder/src
 Test6_LDADD =  /home/kevinthefire/workspace/Encoder/src/libEncoder.a

 AM_CXXFLAGS = -I/home/kevinthefire/workspace/Encoder/src
 AM_LDFLAGS = @Test6_LIBS@ @Test6_LDFLAGS@
 AM_LDADD = @Test6_LDADD@
 CLEANFILES = *~

 It gave errors:

[...]
)
 It seems that the compiler couldn't link to GPIOPIn library through Encoder
 library? So I modified Makefile.am of Test6 as:

 bin_PROGRAMS = Test6
 Test6_SOURCES = Test6.cpp

 Test6_LDFLAGS = -L/home/kevinthefire/workspace/Encoder/src
 -L/home/kevinthefire/workspace/GPIOPin/src
 Test6_LDADD =  /home/kevinthefire/workspace/Encoder/src/libEncoder.a
 /home/kevinthefire/workspace/GPIOPin/src/libGPIOPin.a

 AM_CXXFLAGS = -I/home/kevinthefire/workspace/Encoder/src
 -I/home/kevinthefire/workspace/GPIOPin/src
 AM_LDFLAGS = @Test6_LIBS@ @Test6_LDFLAGS@
 AM_LDADD = @Test6_LDADD@
 CLEANFILES = *~

 I just added information of GPIOPin library and it compiled well!

 Now I am wondering why I can't write Makefile.am of Test6 as simple as
 Test3, but have to list all the library information(GPIOPin and Encoder).
 If my Encoder library includes several libraries I created, writing
 Makefile.am would be trouble.


As you have found, the linker needs to be told about all libraries
that are going to contribute to the produced executable. If you find
it time-consuming to keep track of what other libraries a library
requires, you might consider using a program called pkg-config
(http://www.freedesktop.org/wiki/Software/pkg-config/), which can
retrieve these dependencies so they can be included in the link
command.

Re: Makefile error in simple library

[Gavin Smith]

You are getting an error message that says that AM_PROG_AR is required
in configure.ac. You have AM_PROG_AR in configure.ac, but it has a #'
in front of it, which could be why you are still getting this error
message. It's likely that that it is being interpreted as a comment
and not recognized as occurring in the file as it is expected to. Try
removing the # character in front of AM_PROG_AR to see if you
still get this error message.

On Wed, Aug 20, 2014 at 1:36 AM, Arthur Schwarz aschwarz1...@att.net wrote:
 Isn't '#' just a comment?

 -Original Message-
 From: Gavin Smith [mailto:gavinsmith0...@gmail.com]
 Sent: Tuesday, August 19, 2014 5:30 PM
 To: Arthur Schwarz
 Cc: Automake Mailing List
 Subject: Re: Makefile error in simple library

 On Wed, Aug 20, 2014 at 12:47 AM, Arthur Schwarz aschwarz1...@att.net
 wrote:
 I'm trying to build and distribute a static library and keep getting a 
 warning: 'libslip.a': linking libraries using a non-POSIX  archiver
 requires
 AM_PROG_AR' in 'configure.ac' message. I don't know why.

 The configure.ac lines in question are: (I think)

 AC_CONFIG_FILES([
   Makefile
   src/Makefile
 ])

 # automake macro's - REQUIRED
 AM_INIT_AUTOMAKE([-Wall -Werror])

 # linking libraries using a POSIX archiver
 #AM_PROG_AR


 I don't think that # should be there.


 From Section Automake Manual Section 8.2 Building a Library it should
 work.
 I've been hitting a wall on this, any ideas would be appreciated.

Re: Guide on updating autofoo

[Gavin Smith]

On Tue, Aug 12, 2014 at 4:10 PM, Wookey woo...@wookware.org wrote:
 As porting work (for arm64) recently I have done a lot of fixing up
 packages to run autoreconf on build as this is the only way to ensure
 that their config.sub/guess and libtool files are up to date for
 architectures released since the software last had it's auto* files
 updated.

 In general this works well, but we sometimes get breakage if the
 autoconf macros in the package are particularly old and unloved. i.e
 are still using a lot of now-deprecated stuff.

 I have not found a good guide on best practice in updating such
 files. Is there one? The lack of such is one reason people don't
 update their configure.in/ac until they are forced to, I suspect.


The NEWS file in the automake distribution has some information about
the changes between versions.

Re: How to run TESTS automatically on each source code change?

[Gavin Smith]

On Thu, Jul 24, 2014 at 4:48 PM, Steffen Dettmer
steffen.dett...@gmail.com wrote:
 Hi,

 I have a test that generates a log file, which I can manually run via
 make check. Is there a simple way to automate that? For the moment I
 just created a pragmatic target autotest, but I think it is ugly
 (and too specific).

What do you want to happen? The test to be automatically run whenever
make is run?

 Any pointers appreciated!

 Regards,
 Steffen


 autotest:
 @echo Will run \`make check' after each change, stop with INT. ; \
 while true ; do \
   if ! make --question -s -j4 testrunner ; then \
 echo Rechecking... ; \
   make -s check || { \
 echo failed to run `date`  testrunner.log ; \
   } ; \
   fi ; \
   sleep 1 ; \
 done

Re: Automake 1.14 and subdir-objects

[Gavin Smith]

On Thu, Jul 31, 2014 at 9:32 PM, David Beer db...@adaptivecomputing.com wrote:
 Gavin,

 Thanks for your reply. Here's a more specific breakdown of what the project
 does:

 src/a/Makefile.am:

 a_SOURCES = bob.c tom.c

 src/b/Makefile.am:

 b_SOURCES = mary.c ../a/tom.c

 The purpose was so that tom.c would be recompiled with a different
 preprocessor switch. There were only a few files that failed for this case,
 so I was able to work around this. The other case:

It is clearer now what you are trying to do. It might be worth noting
that you can specify target-specific compliation flags with variables
like a_CPPFLAGS and b_CPPFLAGS: however, this would normally be done
when a and b were targets defined in the same Makefile.am. This would
lead the created object files to have different names, so might work
in your case, but I believe that this kind of sharing of source files
between Makefile.am's is not really supported. I imagine there could
be problems with e.g. dependency tracking. Maybe consider using a
non-recursive build system with a single Makefile.am if it is
appropriate for your project.

Another idea is to specify the files like tom.c in src/b/Makefile.am as

BUILT_SOURCES=tom.c

and then have a hand-written rule to copy the tom.c file into the
build directory for b, e.g.

tom.c:
cp $(top_builddir)/a/tom.c .

(I haven't tested this.)

Re: building executables with pattern rules

[Gavin Smith]

On Mon, Jul 14, 2014 at 6:49 PM, Will Estes westes...@gmail.com wrote:
 I have the following in my Makefile.am, and automake is not using the rule to 
 build the executable.

 tableopts_nr%.c: tableopts.l4
 $(FLEX) -P $(subst -,_,$(*F)) $* -o $@ $

 tableopts_nr%.$(OBJEXT): tableopts_nr%.c
 $(COMPILE) -c -o $@ $

 tableopts_nr%.tableopts$(EXEEXT): tableopts_nr.$(OBJEXT)
 $(LINK) $^

 The % is matching various things like -Ca and so on that are options to flex 
 for different kinds of tables that flex can produce. This is in the test 
 suite and I've generated the long list of _SOURCES variables and the programs 
 are listed in CHECK_PROGRAMS and TESTS.

 The .tableopts  suffix is present because I'm using the parallel test harness 
 to distinguish between various kinds of tests in the flex test suite that 
 need different kinds of arguments when they're run.

 THe output from trying to build the program with the Makefile.am as above 
 looks like this:

 /bin/bash ../libtool  --tag=CC   --mode=link gcc  -g -O2   -o 
 tableopts_nr-Ca.tableopts   -lm
 libtool: link: gcc -g -O2 -o tableopts_nr-Ca.tableopts  -lm
 /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crt1.o: In 
 function `_start':
 (.text+0x20): undefined reference to `main'
 collect2: error: ld returned 1 exit status

 As a test, I did try explicitly listing tableopts_nr-Ca.tableopts$(EXEEXT) as 
 a target and make did build the program correctly.

 How do I get automake to recognize my pattern rule? Or, if there's another 
 way to do this that's easier / better, what is that?

Try checking your generated Makefile.in and Makefile files to see
if automake has copied these rules through. If not, it could be
because automake doesn't recognize GNU make extensions (pattern rules
with % don't exist in some other make programs). However, if it did
succeed in passing them through, it could be a problem with your
rules. I thought it was strange that in the rule

 tableopts_nr%.tableopts$(EXEEXT): tableopts_nr.$(OBJEXT)
 $(LINK) $^

the object file doesn't have a % in it (so the same file will be used
for all matches of this pattern), but in


 tableopts_nr%.$(OBJEXT): tableopts_nr%.c
 $(COMPILE) -c -o $@ $

there is a % there. Try making a simple Makefile to check the logic of
your rules first and then try to incorporate it in your Makefile.am.

Re: What would the correct way be to handle a program with a PID file being built to a prefix directory?

[Gavin Smith]

On Wed, Jun 18, 2014 at 3:47 AM, Michael Lueck
mlu...@lueckdatasystems.com wrote:
 Prefix, building the program with non root permissions to be run in the
 context of a user's home directory.

 PID file, generally defaults to /var/run, however in this case permissions
 are not granted to /var/run. One could assume ~/var/run would be the proper
 place for the PID file.

 Building a certain OSS/FS app fails when being built with a prefix
 specified, as /var/run is still assumed for the PID file. I hacked the
 source code to obtain ability to target ~/var/run for the PID file, and the
 program works as expected.

It depends on the build system of the program in question, but it
looks like localstatedir is the preferred makefile variable for this
directory, and is as an autoconf output variable. It should be set
automatically from whatever prefix directory was specified.

Re: Issues with subdir-objects enabled

[Gavin Smith]

On Tue, Apr 22, 2014 at 5:06 PM, Nick Bowler nbow...@elliptictech.com wrote:
 On 2014-04-22 16:15 +0100, Gavin Smith wrote:
 Is support for setting variables with names of source directories
 after automake is run (with configure scripts, or on the command line
 when make is run) is needed? If not, could variables in the paths of
 source files ($(testd)) above could be expanded when automake is
 run?

 So Makefile currently has lines like

 include $(testd)/test-imgloader.Po

 and this would become

 include ctests/test-imgloader.Po

 with no opportunity to change the value of testd. Then config.status
 could read the name of the file from Makefile and create it properly.

 Even if the value depended on configure-time substitutions (@VAR@-
 style) I think there would be no problem here (maybe other problems
 though) because the depfiles creation step happens afterwards.

 Make-time substitutions for this sort of thing would be exceptionally
 weird and I can't imagine it actually working properly in current
 versions of Automake.

 If config.status knew how to perform the variable substitutions
 I think there would be no problem.  This may be too tricky to
 implement in portable shell.  However, the same substitutions
 could be done by postprocessing Makefile.in so I don't see why
 it could not be done at Automake-time.

Here's my attempt at a fix. I couldn't find anything to expand
variables defined in the Automake::Variable module so I've written
code to expand these, with a maximum level of expansion in case of
cyclic definitions. One complication is that variables can be defined
conditionally, so I tried to check that they weren't. The error
messages here leave something to be desired - there may be some way of
continuing instead of having a fatal error, and the messages don't say
what source files are affected - it is not obvious how to get this
information.
diff --git a/bin/automake.in b/bin/automake.in
index f19cac7..9198724 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -1208,10 +1208,48 @@ sub handle_languages ()
 		$output_rules .= (subst ('AMDEP_TRUE')
   . subst ('am__include')
   . ' '
-  . subst ('am__quote')
-  . $iter
-  . subst ('am__quote')
-  . \n);
+  . subst ('am__quote'));
+
+		# Expand any variables used to specify the source file.
+		my $i = 0;
+		while (my @vars = scan_variable_expansions ($iter)) {
+		  # The code in m4/depout.m4 depends on DEPDIR
+		  # being unexpanded.
+		  if (@vars == 1) {
+		last if (DEPDIR eq $vars[0]);
+		  }
+
+		  # Don't repeat indefinitely if a variable is defined
+		  # in terms of itself.
+		  $i++;
+		  if ($i == 10) {
+		   fatal Source file specified with too deep
+		   	. a level of of variable expansion;
+		  }
+		  foreach my $varname (@vars) {
+		  # The code in m4/depout.m4 depends on DEPDIR
+		  # being unexpanded.
+		  next if $varname eq DEPDIR;
+		  my $var = var $varname;
+		  my ($vardef, $varval);
+
+		  if ($var) {
+			$vardef = $var-def (new Automake::Condition);
+			# Check that the variable is defined unconditionally.
+			if (! $vardef) {
+			fatal Variable '$varname' defined conditionally
+			.  in specification of source file.\n;
+			}
+		  }
+
+		  $varval = $vardef-value;
+		  $iter =~ s/\$\($varname\)/$varval/g;
+		  $iter =~ s/\${$varname}/$varval/g;
+		  }
+		}
+			
+		$output_rules .= $iter;
+		$output_rules .= (subst ('am__quote') . \n);
 	}
 
 	# Compute the set of directories to remove in distclean-depend.

Re: Issues with subdir-objects enabled

[Gavin Smith]

On Sun, Apr 13, 2014 at 2:47 AM, Jonas Thiem jonasth...@googlemail.com wrote:
 # -
 # Unit test section
 # -
 TESTS=
 testd = ctests
 TEST_CFLAGS= $(AM_CFLAGS) -DUNITTEST

 # -
 # C tests
 # -
 check_PROGRAMS = $(testd)/test-imgloader $(testd)/test-texman-1
 $(testd)/test-imgloader-colors
 __testd__test_imgloader_SOURCES = $(testd)/test-imgloader.c
 $(source_code_files)
 __testd__test_imgloader_LDFLAGS = $(FINAL_LD_FLAGS)
 __testd__test_imgloader_CFLAGS = $(TEST_CFLAGS)
 __testd__test_imgloader_colors_SOURCES =
 $(testd)/test-imgloader-colors.c $(source_code_files)
 __testd__test_imgloader_colors_LDFLAGS = $(FINAL_LD_FLAGS)
 __testd__test_imgloader_colors_CFLAGS = $(TEST_CFLAGS)
 __testd__test_texman_1_SOURCES = $(testd)/test-texman-1.c
 $(source_code_files)
 __testd__test_texman_1_LDFLAGS = $(FINAL_LD_FLAGS)
 __testd__test_texman_1_CFLAGS = $(TEST_CFLAGS)
 TESTS += $(testd)/test-imgloader $(testd)/test-texman-1
 $(testd)/test-imgloader-colors


 Basically, I want to link the tests in the ctests/ subdirectory
 (referenced with $(testd)/ in most places) together with the main
 object files of the main program (as listed in $source_code_files).


Is support for setting variables with names of source directories
after automake is run (with configure scripts, or on the command line
when make is run) is needed? If not, could variables in the paths of
source files ($(testd)) above could be expanded when automake is
run?

So Makefile currently has lines like

include $(testd)/test-imgloader.Po

and this would become

include ctests/test-imgloader.Po

with no opportunity to change the value of testd. Then config.status
could read the name of the file from Makefile and create it properly.

Re: [RFC] improving support for building native tools in cross setups

[Gavin Smith]

On Wed, Jan 29, 2014 at 10:40 PM, Yann Dirson ydir...@free.fr wrote:
 Hello,

 It is not uncommon for software packages to build tools to be executed
 at build time, to generate data files or more input files to compile.

 Unless I miss something, the current autotools does not help much
 dealing with this for cross-compilation:


(Link to discussion on other mailing list for reference:
http://lists.gnu.org/archive/html/automake/2014-01/msg6.html.)
Using hand-written rules for these data files and tools with
AX_CC_FOR_BUILD is a solution if the tools are written in C. If that
works, even though it needs hand-written rules, unless this is a
common problem it's probably better to do that then complicate the
autotools (unless the extra features definitely won't get in the way
when they're not being used), given that at present it's assumed that
all files are being built for the same architecture. It would have to
be thoroughly thought out and tested.


 For the first point I was able to derive an AC_PROG_BUILD_CC from
 AC_PROG_CC, to probe for a compiler using AC_CHECK_PROG instead of
 AC_CHECK_TOOL, and set BUILD_CC.  That's just a PoC, not sufficient in
 itself, since other tools from the toolchain will be required (and it
 partly duplicates code, which is not nice eiher).  At least it does
 not *require* modificaiton to autoconf in itself, as the macro can be
 embedded into source packages if needed.

 For the second point, it would seem a good idea at some point to
 support a native_ prefix, so setting eg. native_PROGRAMS will
 trigger the use of BUILD_* tools.


The noinst_ prefix could be closely related. It would seem that most
of the time you wouldn't want to install these files.

(PS What's PoC? Piece of cake?)

 But as a first step I experimented with setting $program_CC, like can
 be done for flags.  The PoC patch below attempts to do that, and in
 fact setting gnushogi_CC=$(BUILD_CC) does produce the expected
 result in Makefile.in (separate rules for gnushogi-*.o are produced,
 with the correct CC being called).

File-specific variables could work. I imagine you are using generic
rules for cross-compilation, and explicit rules for when you are
building your auxiliary tools?

My general advice is to keep rules, flags, variables, etc. used for
building files for one architecture completely separate from those
used for another architecture. Also you have to make sure that you
find all the tools you need.


 Where I'm running into problems is that setting CCLD in the same way
 requires further changes (eg. expanding LINK for all targets instead
 of using this as a variable, or overriding LINK instead which looks
 not as clean).


I don't know if you saw in the manual that you can set a
target-specific linker? See maude_LINK at

http://www.gnu.org/software/automake/manual/html_node/Program-and-Library-Variables.html#Program-and-Library-Variables

 And without even trying to touch this, I also have
 another problem to deal with, where requesting my native binary
 triggers some sort of default rule attempting to build the binary in
 one step directly from the C source, with the cross-cc and wrong flags.


If it is running the wrong rule make sure there is an explicit rule
for the target in the makefile.

Re: Updating the shared library cache automatically using ldconfig

[Gavin Smith]

On Fri, Dec 6, 2013 at 8:56 AM, Richard Crozier r.croz...@ed.ac.uk wrote:
 I am seeing the same issue as described in this previous post to the
 automake mailing list:

 http://gnu-automake.7480.n7.nabble.com/quot-error-while-loading-shared-libraries-foo-so-0-cannot-open-shared-object-file-No-such-file-or-di-td3970.html

 The issue is that my program uses a shared library installed by 'make
 install' at the same time as my program, but the shared library cache is not
 updated, resulting in the error

 error while loading shared libraries: foo.so.0: cannot open shared object
 file: No such file or directory

 when you try to run the program. This can be solved by manually running
 ldconfig or rebooting. Mostly my users do not know to do this, so we get bug
 reports. How can I have ldconfig run if necessary after make install? What
 exactly should I put in my Makefile.am or elsewhere to do this?

Not completely sure but I'll explain my understanding of the situation.

There are two possible places where this could be fixed:
* When the library is installed
* When the program linking against the library is installed

When the library is installed: This is done using libtool in the
makefile. Installing a libtool library under /usr/local/lib (with an
automake-generated Makefile) I get the following message:
---
Libraries have been installed in:
   /usr/local/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
 during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
 during linking
   - use the `-Wl,--rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
---
(This is under Slackware 14.0.) This message is printed by libtool,
but the makefile calling libtool might also do something to facilitate
linking against the library. In either case you can imagine installing
libraries in locations that you *don't* want to find automatically, so
this is probably fine.

When the program is installed: I get the same results at Ralf
Wildenhues in his post
http://gnu-automake.7480.n7.nabble.com/quot-error-while-loading-shared-libraries-foo-so-0-cannot-open-shared-object-file-No-such-file-or-di-td3970.html#a3973.
When /usr/local/lib is not listed in ld.so.conf, libtool adds an rpath
linker flag and the library search path appears in the produced
binary:
$ readelf -d .libs/foo | grep rpath
 0x000f (RPATH)  Library rpath: [/usr/local/lib]
But if /usr/local/lib *is* in ld.so.conf, it doesn't. However, that is
not enough to find the library - ldconfig has to be run. From the
ld-linux.so man page:

 The shared libraries needed by the program are searched for in the fol-
   lowing order:

   o  (ELF only) Using the directories specified in the  DT_RPATH  dynamic
  section  attribute of the binary if present and DT_RUNPATH attribute
  does not exist.  Use of DT_RPATH is deprecated.

   o  Using the environment variable LD_LIBRARY_PATH.  Except if the  exe-
  cutable  is  a  set-user-ID/set-group-ID binary, in which case it is
  ignored.

   o  (ELF only) Using the directories specified in the DT_RUNPATH dynamic
  section attribute of the binary if present.

   o  From  the cache file /etc/ld.so.cache which contains a compiled list
  of candidate libraries previously found  in  the  augmented  library
  path.   If,  however,  the  binary  was  linked with the -z nodeflib
  linker option, libraries in the default library paths  are  skipped.
  Libraries  installed  in hardware capability directories (see below)
  are preferred to other libraries.

   o  In the default path /lib, and then  /usr/lib.   If  the  binary  was
  linked with the -z nodeflib linker option, this step is skipped.

ld-linux.so does not look at /etc/ld.so.conf. This would seem to be a
problem - maybe libtool should use the -Wl,-rpath -Wl,/usr/local/lib
option in both circumstances?

In the meantime, I think you could use the install-exec-hook target to
run ldconfig to update the cache.

Re: Long file lists and deep directioriies with Automake

[Gavin Smith]

On Mon, Dec 2, 2013 at 8:21 PM, PenguinDude24 beowul...@yandex.com wrote:

 Automake generates the Makefile.in files, and configure makes the 'Makefile'
 for the directory. But the generated makefiles give errors. GNU Make gives
 the ominous 'missing separator error'. That errors can be triggered for a
 variety of reasons. Long file list for targets and deep nested dirs are at
 least two of the reasons.

Are you sure those are the reasons, and there aren't extra newlines
being inserted in these long lines? Can you post the relevant lines of
the Makefiles?

Re: automake breaks my file by putting includes after rules; how do I fix this?

[Gavin Smith]

On Mon, Dec 16, 2013 at 3:49 PM, Jason Gross jasongro...@gmail.com wrote:
 These compiled files get distributed/installed, so I think they belong in
 DATA.

 The solution I ended up using was manually including an all-am target
 below the definition, which overrides the one that automake generates.

 I think the other contributors to the project would complain only slightly
 less about depending on automake than they did about depending on autoreconf
 (I ended up setting up an extra branch of the source repo which the
 autogenerated files get automatically pushed to); the intended
 contributors/users of the source repo are mathematicians who may have little
 to no programming experience.

 -Jason


Your problem is like the question in the automake manual about how to
use wildcards in automake variables (e.g. DATA, SOURCES) that list
files (the answer being it is not possible). In both cases the list of
files is not in Makefile.am, but to be determined later (either by
wildcard expansion or editing the included file).

In the case of wildcard expansion, the manual notes that the expansion
would have to be done by the automake process, requiring automake to
be re-run each time make was (or each time new files were added).
(This was due to the lack of portable make wildcard facilities.) This
would not necessarily be the case for your problem, though. But in
general this approach does not seem to be supported: even if it could
be made to work for DATA (having an include in the generated makefile
setting variables that the makefile uses), it probably wouldn't work
for SOURCES.

All this is assuming that automake does not get re-run when make does.
Diego mentioned maintainer mode: if you include a file in Makefile.am,
the generated makefile should see that as a dependency of Makefile.in.
Hence whenever you run make, if the included file has changed,
Makefile.in and Makefile should be rebuilt automatically - no need for
the user to run automake (like they were running autoconf). There is
still a dependency on automake, but only that it has to be installed -
the user shouldn't have to run it themselves.

Re: automake breaks my file by putting includes after rules; how do I fix this?

[Gavin Smith]

On Wed, Nov 20, 2013 at 9:33 PM, Jason Gross jasongro...@gmail.com wrote:
 I have a Makefile.am which includes another file in order to get a list of
 files it should compile (I don't want to require running autoreconf and
 configure whenever you add a file that the makefile already knows how to
 compile).  But this does not work with automake's generated all and all-am
 targets, which compute their dependencies on the basis of the DATA
 variable, which is auto-defined to be nobase_hott_DATA, which depends on
 variables set in the included file.  How do I fix this?  (Should I submit a
 bug report that includes should come before the autogenerated targets?)

Is it possible to use the all-local target to compile these files,
and use another variable to list the files instead of DATA?

Re: cannot build library on HP-UX

[Gavin Smith]

On Sat, Nov 2, 2013 at 5:43 PM, Denis Laroche dlaroc...@gmail.com wrote:
 I used version 2.69 of autoconf and version 1.13.4 of automake to
 generate the configure script. I use a recent version of GNU make,
 3.82, on the HP-UX system. I also use option subdir-objects in
 AM_INIT_AUTOMAKE to minimize the number of recursions, although the
 gnulib library is still built in its own directory.

 I reproduced below the ouput of make --debug=v; the gnulib source
 files are in directory lib. If someone is willing to help, I'll be
 glad to provide any file that you might require.

 (cut)

 Updating goal targets
 Considering target file `all-am'.
  File `all-am' does not exist.
   Pruning file `Makefile'.
   Considering target file `libgnu.la'.
File `libgnu.la' does not exist.
 Considering target file `exitfail.lo'.
  File `exitfail.lo' does not exist.
  Finished prerequisites of target file `exitfail.lo'.
 Must remake target `exitfail.lo'.
make[4]: Entering directory
`/tmp_mnt/home/limpet/ex36672/tools/dist/glog-hppa64/lib'
make[4]: *** No rule to make target `exitfail.lo', needed by `libgnu.la'.  
Stop.
make[4]: Leaving directory

This is a libtool file. I don't know what the problem is but I suggest
making a minimal automake project that uses libtool to see if you can
get it to run on HP-UX. That might be easier to debug than compiling
gnulib.

Re: Managing Emacs org-mode projects with automake - how to make this easier?

[Gavin Smith]

 The not so nice part is, though, that the Makefile.am looks quite messy.
 Very messy in fact:


 $ cat Makefile.am

 vortrag = vortrag.pdf
 vortrag_DATA = vortrag.org data.txt dist-tarball.png
 vortragdir = .

 EXTRA_DIST = ${vortrag_DATA} ${vortrag}
 MOSTLYCLEANFILES = \\\#* *~ *.bak *.vrb *.bbl *.blg *_flymake.* #
 kill editor backups and latex stuff
 CLEANFILES = ${vortrag}
 DISTCLEANFILES = ${CLEANFILES} \\\#* *~ *.bak *.vrb *.bbl *.blg
 *_flymake.* auto/*el

 all : ${vortrag}

 ${vortrag} : ${vortrag_DATA}
 if test $ != $(notdir $); then cp -u $ $(notdir $); fi
 echo yes | @emacs@ --batch --load ~/.emacs --visit $(notdir $)
 --funcall org-beamer-export-to-pdf
 if test $ != $(notdir $); then rm -f $(notdir $); rm -f
 $(basename $(notdir $)).tex $(basename $(notdir $)).tex~
 auto/$(basename $(notdir $)).el; else rm -f $(basename $).tex
 $(basename $).tex~ auto/$(basename $).el; fi



 Most of this is required to make distcheck happy.

 Is there a way to make this cleaner?

 Best wishes,
 Arne

 PS: I documented my usage of autotools on
 http://draketo.de/light/english/free-software/makefile-to-autotools
 --
From your link:
I use pyxplot for generating some plots. Pyxplot does not have a way (I know 
of) to search for datafiles in a different folder. I have to copy the files to 
the build dir and kill them after the build. But only if I use a separate 
build dir.

If I understand rightly, you are having a problem with VPATH builds?
Is there no way to get your tools (emacs and pyxplot) to read from
files in the source directory but output in the current directory?

Re: version dependencies

[Gavin Smith]

openvswitch should tell you what its dependencies are.

On Sat, Sep 28, 2013 at 7:37 PM, Ferenc Cserepkei csf...@gmail.com wrote:
 Welcome,
 I'm doing jenkins build of openvswitch-1.11 on a centos 6.4 amd64 host.
 Openvswitch coming from git repo has a boot.sh scrit contains command
 autoreconf --install --force

 since OVS requires autoconf 2.64+ i have compiled latest autmake, autoconf
 and libtool, but still have problems with the autotest part of OVS.

 Probably there are more dpendencies. So i have
 - automake 1.14
 -autoconf 2.69
 -libtool 2.4

 other stuff, such as bash, sed, grep, awk are the centos 6-4 default. What
 is Your recommendation, what else should be upadted? Note that an official
 open virtual switch 1.11.0 tarball compiles without any problem, but due to
 the currents production envroment we should use the git snapshot, so the
 autoreconf way
 Thank You:
 Ferenc

Re: Enhancing automake support for silent-rules

[Gavin Smith]

On Fri, Jun 7, 2013 at 2:55 PM, Darren Garvey darren.gar...@gmail.com wrote:
 Hi all,

 I've been trying to make a large automake-generated project I work on build
 quieter. While there is some support for silent-rules, there are several
 places where automake templates* don't silence themselves, which I'd like
 to rectify.

 I have made several changes locally which helps a lot and I'd like to
 prepare a patch. Since I've not hacked on automake before I may need some
 guidance on conventions as not all of them are obvious to me.

 To make a rule conditionally silent, I use $(AM_V_at) in _my_ projects, but
 automake sources itself have %SILENT% which seems to be equivalent, IIUC.
 Is %SILENT% preferred?

My understanding is as follows. Strings like %SILENT% are substituted
in the templates by the file_contents function, and probably end up
as $(AM_V_at). See the silent_flag function. I think it would be
better to use %SILENT% for consistency. There is also the %VERBOSE%
automake-time substitution, but this expands to something different
for every language (e.g. $(AM_V_CC)).

 The HACKING file says:

 * For install and uninstall rules, if a loop is required, it should be
   silent.  Then the body of the loop itself should print each important
   command it runs.  The printed commands should be preceded by a single
   space.

 This means there are several places in the templates that have a long
 multi-line rule that is itself silent, but includes one or more echos.
 One idea was to define a local function such as:

 am_echo() { echo $@ /dev/null; }

 and then define $(AM_V_echo) that conditionally used either echo or
 am_echo. This feels a bit ugly but it should be minimally intrusive.
 Perhaps there's a more canonical way to do this using some existing
 automake feature. I imagine anyone working on the silent-rules support may
 have already thought about this and may have a superior alternative
 suggestion
How about setting AM_V_echo to either echo or something like true,
and writing $(AM_V_echo) whatever instead of echo whatever, if
this is desired?

Re: Enhancing automake support for silent-rules

[Gavin Smith]

 %SILENT% doesn't work in any of the places I tried. I'm speculating that
 this is because it's substituted too early. I see it being used in a few
 places (eg. lib/am/library.am), but those rules are full of other %NAME%
 strings.
Different files will use different substitutions. For SILENT to work
it needs to have been included in the arguments to file_contents.
Search automake.in for SILENT to see how and where it is set.

Re: Broken install-data-yes target

[Gavin Smith]

On Wed, Jun 5, 2013 at 10:37 PM, Kip Warner k...@thevertigo.com wrote:
 My make install target for my autotool'd project's translations
 directory has a number of prerequisites. The one which seems to be
 causing trouble is the install-data-yes target. Yes, I am aware the path
 I am using contains spaces and yes I am aware that makefiles can choke
 on it if not properly dealt with (e.g. escaped).
AFAIK file names with spaces and funny characters in them are not
supported by automake.

Re: Where Do All These Macros Come From?

[Gavin Smith]

 Alright, cool. I can get used to this syntax. How does autoconf know
 what SOME_MACRO is and how to use it in generating a `configure`
 script? I found a list of configure.ac macros in the automake manual
 (the auto*conf* section) but I see a lot of macros that people use that
 are not on the list or nowhere previously defined. How is this
 possible? I'm sorry...I'm really confused here.

autoconf reads a file called aclocal.m4 for extra macro definitions.
This is generated by the aclocal program which is part of automake.

Re: Specifying Flag Order?

[Gavin Smith]

On Thu, May 23, 2013 at 12:46 AM, Jordan H. jorda...@fastmail.fm wrote:
 I'm using mysql in a program. Here is a snipped of my Makefile.am:

 project_LDADD += -lboost_thread
 project_LDADD += -lboost_regex
 project_LDADD += -lboost_system

 AM_LDFLAGS = -L/usr/local/lib
 AM_LDFLAGS += `mysql_config --libs_r`
 AM_LDFLAGS += `mysql_config --include`
 AM_LDFLAGS += -std=c++0x
 AM_LDFLAGS += `mysql_config --cflags`

 When I compile the program, automake generated:

 g++  -g -O2 -L/usr/local/lib `mysql_config --libs_r` `mysql_config
 --include` -std=c++0x
 `mysql_config --cflags`  -o /[ ... a bunch of .o files ... ]/
 -lboost_thread -lboost_regex
 -lboost_system

 As expected, since g++ needs linker flags at the end I get a bunch of
 compile errors saying the `mysql_*` functions don't exist. How do I
 specify for the linker flags to go at the end? I tried to put them in
 the project_LDADD macro but automake complained:

 Makefile.am:13: linker flags such as `--libs_r`' belong in
 `project_LDFLAGS

 Which got me back to square one. I must be doing something wrong. Any
 ideas? This has been bugging me for days. Thanks in advance.

You haven't said whether you've tried using project_LDFLAGS (you've
used AM_LDFLAGS and project_LDADD).

It might be easier if you wrote out the command you would like to be generated

Re: Put GNU build system files in a subdirectory?

[Gavin Smith]

On Mon, Apr 29, 2013 at 8:16 PM, Bob Rossi b...@brasko.net wrote:

 Autotools is a great build system. However, after configuring it to
 place as many files as possible in a subdirectory, it still takes up
 87.5% of my projects root directory.

 aclocal.m4
 autom4te.cache
 build
 configure
 configure.ac
 Makefile.am
 Makefile.in
 src - This is my project


I too dislike all the files in the top-level directory created or used
by the build system. It seems that changing this would require changes
to automake, autoconf, or both. If it is possible at present (it
probably isn't), it would require messy workarounds.

Suppose you place all files in a subdirectory (Automake), except
Makefile and configure, which are all that a package user will use.
Then you also have to pull Makefile.in out to the top-level, or
specify AC_CONFIG_FILES([Makefile:Automake/Makefile.in]) in
configure.ac.

Creating Makefile in the Automake subdirectory wouldn't work, because
it would be looking for all the source files in there, i.e. configure
will set srcdir=Automake instead of srcdir=.. in the generated
Makefile.

With the second option, cd Automake  autoconf works (as autoconf
does not seem to check for the existence of any files mentioned in
configure.ac in the source tree), but you also have to cp
Automake/configure ., as the autoconf-generated configure script
relies on being located in the top-level source directory. (Moving
configure and running it with the --srcdir option does not work: it
contains references to itself as $(srcdir)/configure.)

This breaks running automake though. It checks for the existence of
some files mentioned in configure.ac, and their paths are relative to
the top-level directory, not the Automake subdirectory. So the ugly
workaround is, from the top-level directory, cp
Automake/{aclocal.m4,configure.ac} .  automake  rm
{aclocal.m4,configure.ac}. (You'd also have to clean up the
autom4te.cache directory that automake creates.) automake will see the
input file for configure is called Automake/Makefile.in and derive
the name of its own input file as Automake/Makefile.am. You see it
is natural for configure.ac and aclocal.m4 to be in the top-level
directory, as automake needs to read them both.

make dist is broken after this, because it still looks for aclocal.m4
in the top-level (and probably for other reasons as well).

So it is not straightforward to move files to a subdirectory. You find
that you have to have one of them in the top-level directory, and that
in turn leads to others having to be in the top-level directory too.

It might be possible to add an option to automake so you could do
something like automake --auxdir Automake (run from the top level)
to tell it where to look for its input files. This still wouldn't fix
the verbose lines needed in configure.ac (e.g.
AC_CONFIG_FILES([Makefile:Automake/Makefile.in])).

Re: [FYI] {branch-1.13.2} HACKING: miscellaneous fixes, updates and enhancements

[Gavin Smith]

 -  We used to use '_am_' as the prefix for an internal AC_SUBST.
 +  We used to use '_am_' as the prefix for an internal AC_SUBSTs.

This looks like a typo - should the s be there?

On Wed, May 15, 2013 at 8:20 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
 Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
 ---
  HACKING | 102 
 
  1 file changed, 51 insertions(+), 51 deletions(-)

 diff --git a/HACKING b/HACKING
 index 604bf67..606702f 100644
 --- a/HACKING
 +++ b/HACKING
 @@ -12,16 +12,16 @@
and check everything in.

  * If you incorporate a change from somebody on the net:
 -  First, if it is a large change, you must make sure they have signed the
 -  appropriate paperwork.
 -  Second, be sure to add their name and email address to THANKS
 +  - First, if it is a large change, you must make sure they have
 +signed the appropriate paperwork.
 +  - Second, be sure to add their name and email address to THANKS.

  * If a change fixes a test, mention the test in the commit message.
If a change fixes a bug registered in the Automake debbugs tracker,
mention the bug number in the commit message.

  * If somebody reports a new bug, mention his name in the commit message
 -  and in the test case you write.  Put him into THANKS.
 +  that fixes or exposes the bug, an put him into THANKS.

  * When documenting a non-trivial idiom or example in the manual, be
sure to add a test case for it, and to reference such test case from
 @@ -35,19 +35,18 @@
which should be updated by hand whenever the GPL gets updated (which
shouldn't happen that often anyway :-)

 -* Changes other than bug fixes must be mentioned in NEWS.  Important
 -  bug fixes should be mentioned in NEWS, too.
 +* Changes other than *trivial* bug fixes must be mentioned in NEWS.

  
  = Naming

 -* We've adopted the convention that internal AC_SUBSTs should be
 -  named with a leading 'am__', and internally generated targets
 -  should be named with a leading 'am--'.  This convention, although
 -  in place from at least February 2001, isn't yet universally used.
 +* We've adopted the convention that internal AC_SUBSTs and make variables
 +  should be named with a leading 'am__', and internally generated targets
 +  should be named with a leading 'am--'.  This convention, although in
 +  place from at least February 2001, isn't yet universally used.
But all new code should use it.

 -  We used to use '_am_' as the prefix for an internal AC_SUBST.
 +  We used to use '_am_' as the prefix for an internal AC_SUBSTs.
However, it turns out that NEWS-OS 4.2R complains if a Makefile
variable begins with the underscore character.  Yay for them.
I changed the target naming convention just to be safe.
 @@ -57,12 +56,11 @@

  * Always use $(...) and not ${...}

 -* Use ':', not 'true'.  Use 'exit 1', not 'false'.
 +* Prefer ':' over 'true', mostly for consistency with existing code.

 -* Use '##' comments liberally.  Comment anything even remotely
 -  unusual.
 +* Use '##' comments liberally.  Comment anything even remotely unusual.

 -* Never use basename or dirname.  Instead use sed.
 +* Never use basename or dirname.  Instead, use sed.

  * Do not use 'cd' within back-quotes, use '$(am__cd)' instead.
Otherwise the directory name may be printed, depending on CDPATH.
 @@ -71,9 +69,9 @@
computed with CDPATH.

  * For install and uninstall rules, if a loop is required, it should be
 -  silent.  Then the body of the loop itself should print each
 -  important command it runs.  The printed commands should be preceded
 -  by a single space.
 +  silent.  Then the body of the loop itself should print each important
 +  command it runs.  The printed commands should be preceded by a single
 +  space.

  * Ensure install rules do not create any installation directory where
nothing is to be actually installed.  See automake bug#11030.
 @@ -88,9 +86,6 @@

  * Don't use  for function calls, unless required.
The use of  prevents prototypes from being checked.
 -  Just as above, don't change massively all the code to strip the
 -  , just convert the old code as you work on it, and write new
 -  code without.

  
  = Automake versioning and compatibility scheme
 @@ -118,18 +113,21 @@
should be added, and ideally, only trivial bugs, recent regressions,
or documentation issues should be addressed by them.

 -* Minor releases can introduce new safe features, do non-trivial
 -  but mostly safe code clean-ups, and even add new runtime warnings
 -  (rigorously non-fatal); but they shouldn't include any backward
 -  incompatible change, nor contain any potentially destabilizing
 -  refactoring or sweeping change, nor introduce new features whose
 -  implementation might be liable to 

Re: install-strip variant that strips then installs?

[Gavin Smith]

On Tue, May 7, 2013 at 5:12 PM, Rhys Ulerich rhys.uler...@gmail.com wrote:
 I gather that 'make install-strip' installs and then strips binaries.
 Is there some variant that reverses the order?  If not, any
 recommendations for how to write one in an Automake-compliant manner?

 My unstripped binaries are absurdly large and my installation
 directory is NFS-mounted.  So I get to pay lots of network overhead to
 install what eventually becomes O(100MB) of binaries because the
 unstripped copy is O(1.5GB).

 Thanks,
 Rhys


This seems like a good idea to me. Is there any reason why the order
couldn't be reversed?

The only problem I can think of is that make install-strip isn't
expected to modify the binaries in the build directory, and the user
might conceivably be relying on them being unstripped (for some
obscure reason). If that could be a problem, perhaps a solution is to
have a separate strip rule which could be run.

You could try writing a rule yourself in your Makefile.am to strip the
binaries. You could use the bin_PROGRAMS make variable that is set in
the output Makefile.

Re: Creating plain Makefiles with automake

[Gavin Smith]

On Wed, Apr 24, 2013 at 12:10 AM, Gavin Smith gavinsmith0...@gmail.com wrote:
 I've been working recently on making automake create plain Makefiles
 when it is run, rather than Makefile.in's, and thought I would share
 my progress and thoughts on this.

...

 I haven't included the patches I've made so far as the changes are
 incomplete and there are a few problems which I need to sort out which
 would be distracting, but I can certainly share more information if
 desired. When I get it in a more polished state, I'll post the patches
 for playing around with.

The modifications have support now for functionality such as VPATH and
non-VPATH builds, verbosity settings, toggling dependency tracking,
make distclean and make distcheck. It is obviously incomplete but I
think it's clear now how the system would work.

Top-level Makefile.am from a test project:
AUTOMAKE_OPTIONS=foreign
noinst_PROGRAMS = hello
hello_SOURCES = hello.c beetroot.h rhubarb.h second.c
EXTRA_DIST = config.mk.in
DISTCLEANFILES = config.mk
SUBDIRS = subdir

The lines distributing and cleaning config.mk and config.mk.in will
stop being necessary in future.

(subdir/Makefile.am is an empty file).

configure.ac:
AC_INIT([hello], [0])
AC_CONFIG_AUX_DIR([build-aux])
AM_INIT_AUTOMAKE
AC_PROG_CC
AC_CONFIG_LINKS([Makefile:Makefile subdir/Makefile:subdir/Makefile])
AX_CONFIG_INCLUDE([config.mk])
AC_OUTPUT

Notice that AC_CONFIG_LINKS is being used instead of AC_CONFIG_FILES
for the makefiles. In future, there will be a nicer syntax for this.

The makefiles are generated by running amplain --plain.

There is one top-level config.mk which is included by all the
generated makefiles. Directory-specific variables such as top_builddir
are set in the individual makefiles. The way this is done, variables
like srcdir get values like .././subdir where previously they would
be . - this could be a problem, although it doesn't break documented
behaviour as far as I can see. I used to have an extra file dir.mk
where these variables were set, and this could be done again if it's a
problem (at the expense of having more files in directories).

List of some changes to be done:
* libtool support
* Distribute and clean config.mk automatically
* Guards to check if config.mk was not generated on every target for
users - this would improve portability to non-GNU make's.
* Use option module in autoconf instead of global variable '$plain'.
* Checks for use of automake conditionals (not supported in plain mode)

There are quite a few commits in my git branch for this feature, so I
will include them in aggregate below. I've put my branch up at
https://github.com/GavinSmith0123/automake-amplain/tree/amplain, which
is what you should download if you want to test this.

I've based my modifications on a git branch renaming the installed
automake executable to amplain, so I can use my modified version as
well as the unmodified version. Below are the changes I've made since
the rename, which will give some idea of how the system works but
cannot actually be applied as a patch. The rename branch itself was
based on v1.13.

diff --git a/Makefile.am b/Makefile.am
index 4a1837c..0fb0c96 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -222,13 +222,16 @@ dist_am_DATA = \
   lib/am/clean.am \
   lib/am/compile.am \
   lib/am/configure.am \
+  lib/am/configure.amp \
   lib/am/data.am \
   lib/am/dejagnu.am \
   lib/am/depend.am \
   lib/am/depend2.am \
+  lib/am/depend2.amp \
   lib/am/distdir.am \
   lib/am/footer.am \
   lib/am/header-vars.am \
+  lib/am/header-vars.amp \
   lib/am/header.am \
   lib/am/install.am \
   lib/am/inst-vars.am \
@@ -262,6 +265,7 @@ dist_am_DATA = \
 ## -- ##

 dist_automake_ac_DATA = \
+  m4/ax_config_include.m4 \
   m4/amversion.m4 \
   m4/ar-lib.m4 \
   m4/as.m4 \
diff --git a/amplain.in b/amplain.in
index 3194c99..e465af5 100644
--- a/amplain.in
+++ b/amplain.in
@@ -307,6 +307,9 @@ my $copy_missing = 0;
 # TRUE if we should always update files that we know about.
 my $force_missing = 0;

+# Generate plain Makefiles
+my $plain = 0;
+

 ##  ##
 ## Variables filled during files scanning.  ##
@@ -485,6 +488,13 @@ my $am_file = 'BUG';
 # Relative dir of the output makefile.
 my $relative_dir;

+# Path from build/source directory to top build/source directory
+my $top_builddir;
+
+# Path from build/source directory to top build/source directory with
+# trailing slash
+my $top_build_prefix;
+
 # Greatest timestamp of the output's dependencies (excluding
 # configure's dependencies).
 my $output_deps_greatest_timestamp;
@@ -1142,13 +1152,20 @@ sub define_verbose_var ($$;$)
 my $pvar = verbose_private_var ($name);
 my $silent_var = $pvar . '_0';
 my $verbose_var = $pvar . '_1';
+
+if (! $plain) {
 # For typical 'make's, 'configure' replaces AM_V (inside @@) with $(V)
 # and AM_DEFAULT_V (inside @@) with $(AM_DEFAULT_VERBOSITY).
 # For strict POSIX 2008 'make's

Creating plain Makefiles with automake

[Gavin Smith]

I've been working recently on making automake create plain Makefiles
when it is run, rather than Makefile.in's, and thought I would share
my progress and thoughts on this.

The Makefile would trigger configure to be run when it is run for the
first time, eliminating the need for both ./configure and make to
be run manually. Why? Basically, for simplicity. I don't feel that
there's a strong philosophical distinction between the configure and
make stages: some of what is done at the make stage could be viewed as
portability checks as well; for example, a compiler deciding what type
of object code to output. It would remove a layer of indirection from
the build system and possibly make it is easier to reason about. In
the long run I'd like to see creating and running a build system to be
as simple as doing something like

$ echo Makefile.am END
bin_PROGRAMS = hello
hello_SOURCES = hello.c beetroot.h rhubarb.h second.c
END
$ automake
$ make

(This would also require generating a configure script, which is an
orthogonal design decision.)

The challenge has been to remove autoconf substitutions from generated
Makefile.in's. Most them are simple assignments like CC = @CC@, and
I have placed these in a separate file which is included in the
generated Makefile. There are various other uses:

* To toggle particular lines in the makefile at configure time using
automake conditionals. This is possible in a restricted way: we can
toggle commands in makefile rules, but nothing else. I'll give an
example. Currently, automake outputs a rule template like the
following:

.c.o:
@am__fastdepCC_TRUE@$(AM_V_CC)$(COMPILE) -MT $@ -MD -MP -MF
$(DEPDIR)/$*.Tpo -c -o $@ $
@am__fastdepCC_TRUE@$(AM_V_at)$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
@AMDEP_TRUE@@am__fastdepCC_FALSE@   $(AM_V_CC)source='$'
object='$@' libtool=no @AMDEPBACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@   DEPDIR=$(DEPDIR) $(CCDEPMODE)
$(depcomp) @AMDEPBACKSLASH@
@am__fastdepCC_FALSE@   $(AM_V_CC@am__nodep@)$(COMPILE) -c $

Strings like @am__fastdepCC_TRUE@ and @am__fastdepCC_FALSE@ are
replaced with # or  to optionally comment out lines. My modified
version optionally outputs the following instead:

.c.o:
$(AM_V_CC)
$(am__fastdepCC_enabled)$(AM_V_at)$(COMPILE) -MT $@ -MD -MP
-MF $(DEPDIR)/$*.Tpo -c -o $@ $
$(am__fastdepCC_enabled)$(AM_V_at)$(am__mv) $(DEPDIR)/$*.Tpo
$(DEPDIR)/$*.Po
$(am__fastdepCC_disabled)$(am__AMDEP_enabled)$(AM_V_at)source='$'
object='$@' libtool=no \
DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \
$(COMPILE) -c  $
$(am__AMDEP_disabled)$(AM_V_at)$(COMPILE) -c  $

Variables like $(am_fastdepCC_enabled) evaluate to either  or @: ,
a shell no-op which has the effect of disabling the line. $(AM_V_CC)
has been placed on its own line as : doesn't have any effect past a
semi-colon (i.e. : echo foo; echo bar will echo bar).

All automake conditionals would need to be TRUE or FALSE at automake
time, which would dramatically reduce their availability. Apart from
the conditionals to pick the dependency tracking method, automake uses
a couple of other configure-time automake conditionals (declared with
AM_CONDITIONAL): am__EXEEXT, and a check whether maintainer mode is
enabled. I've only glanced at how these are used, but they don't
appear to be essential.

* @AM_BACKSLASH@ and @AMDEPBACKSLASH@ in conjunction with @am__nodep@
to optionally join lines, as seen above. (Actually, @AM_BACKSLASH@
doesn't appear to be used at all.) These would not be available, but
you can work round it by doubling up the lines you want to create.

* Variables to avoid nested make variable expansion - @AM_V@ used in
the likes of AM_V_at = $(am__v_at_@AM_V@) where we would otherwise
$(V). This would be incompatible with some versions of make.

* @am__include@ and @am__quote@ for variance in the syntax of include
directives.

* Miscellaneous substitutions like @SET_MAKE@ (whose functionality can
be replicated using a hack), @ac_configure_input@ (replaced with
created by automake), and @PACKAGE@ (we can use $(PACKAGE) instead).

The good news for this approach is it is possible to get rid of all of
the autoconf substitutions. The bad news is that you can't do this
portably; but the lack of portability is limited to make syntax
(syntax of include directives and nested variables), not any other
behaviour or property that autoconf scans for.

One possible problem which was pointed out to me on the autoconf
mailing list with having an included file with all the autoconf
substitutions in it is that the user may want to override these
variables in their Makefile.am. (Nick Bowler on April 1st 2013.) I'm
not sure how much of a problem this is: firstly, I don't know if
overriding these variables is ever necessary; and secondly, in GNU
make at least, multiple variable definitions can be read in a makefile
and the later ones do override the earlier ones.

I'm still working on the details of exactly what goes in a

Add missing '$' for variable expansion in depout.m4

[Gavin Smith]

(I hope I have prepared this patch properly.)

Add missing '$' for variable expansion in depout.m4

* m4/depout.m4: am__include appeared where $am__include was meant.

diff --git a/m4/depout.m4 b/m4/depout.m4
index 880a597..c79d04b 100644
--- a/m4/depout.m4
+++ b/m4/depout.m4
@@ -40,7 +40,7 @@ AC_DEFUN([_AM_OUTPUT_DEPENDENCY_COMMANDS],
 DEPDIR=`sed -n 's/^DEPDIR = //p'  $mf`
 test -z $DEPDIR  continue
 am__include=`sed -n 's/^am__include = //p'  $mf`
-test -z am__include  continue
+test -z $am__include  continue
 am__quote=`sed -n 's/^am__quote = //p'  $mf`
 # Find all dependency output files, they are included files with
 # $(DEPDIR) in their names.  We invoke sed twice because it is the

Re: Add missing '$' for variable expansion in depout.m4

[Gavin Smith]

The code here is looking for lines including *.Po dependency files in
output Makefiles. It never caused a problem because if am__include
wasn't set in the output file, then there would be unlikely to be any
lines picked up by the sed expression looking for the include lines.

I found this really by accident. I've been patching automake to see if
I can make it output plain Makefiles. I've arranged for many autoconf
output variables to be in a Makefile include file, so a line like
am__include = include was not in the Makefile, but in the include
file. However, I found that it would get past this check anyway.

am__include seems only to be set as a make variable so that
config.status can read it. Otherwise you would expect it to be
declared with _AM_SUBST_NOTMAKE. automake is passing config.status a
note via Makefile.in; there aren't any other ways for them to
communicate (although an unusual way of doing it would be for automake
to generate files which are source'd or m4_include'd from
configure.ac).

On Thu, Apr 11, 2013 at 7:45 PM, Nick Bowler nbow...@elliptictech.com wrote:
 On 2013-04-11 19:12 +0100, Gavin Smith wrote:
 (I hope I have prepared this patch properly.)

 Add missing '$' for variable expansion in depout.m4

 * m4/depout.m4: am__include appeared where $am__include was meant.

 diff --git a/m4/depout.m4 b/m4/depout.m4
 index 880a597..c79d04b 100644
 --- a/m4/depout.m4
 +++ b/m4/depout.m4
 @@ -40,7 +40,7 @@ AC_DEFUN([_AM_OUTPUT_DEPENDENCY_COMMANDS],
  DEPDIR=`sed -n 's/^DEPDIR = //p'  $mf`
  test -z $DEPDIR  continue
  am__include=`sed -n 's/^am__include = //p'  $mf`
 -test -z am__include  continue
 +test -z $am__include  continue

 Well-spotted!  This definitely looks like a mistake.  How did you
 find this?

 The test appears to have been defective ever since it was introduced
 almost 10 years ago.  At this point, it may be better to simply remove
 the dead code entirely unless this is known to fix a real problem.

 Cheers,
 --
 Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)