Re: Portability warnings: split into non-GNU and non-portable?

[Ralf Wildenhues]

* Reuben Thomas wrote on Sat, Jan 27, 2007 at 08:25:41PM CET:
> On Sat, 27 Jan 2007, Ralf Wildenhues wrote:
> 
> >Why not, I guess.  Except that automake isn't really able to distinguish
> >between GNU extensions and a large class of typos or otherwise malformed
> >makefiles.  Bothered enough to write a patch?  ;-)
> 
> To clarify what I meant, I meant splitting the non-portable constructs it 
> currently detects into a) GNU extensions and b) other non-portable 
> constructs.

That's how I understood it.  My point is that the current Automake code
doesn't "detect" GNU extensions.  It cannot distinguish between correct
GNU make extensions and plain bugs.  Merely not warning about any of
those would be a regression for some cases: for example, they may not be
noticed by 'make' on your system, say, because on your system some
Automake conditional branch won't be expanded.

> Does that sound sane?

Not so sure.

> Shouldn't therefore be a large patch.

Yes, what you propose shouldn't be hard.  Can't tell you whether it
would be acceptable, but you can give it a try.

Cheers,
Ralf

Re: Can't use automake-1.10 in Mingw and Cygwin in Windows XP

[Ralf Wildenhues]

Hello Haibin, 

Please do not cross-post to more than one group.  There is no need. 


* haibin zhang wrote on Fri, Feb 09, 2007 at 04:43:17PM CET:


I found that automake-1.10 can't be used in Mingw and Cygwin in
Windows XP.


No, that's not right in general. 

if I use automake-1.9.6, it 's ok. 


I have diffed the line, that I found automake-1.10 have cut some words


Quoting from
: 


|   - Per-target flags are now correctly handled in link rules.
|
| For instance maude_CFLAGS correctly overrides AM_CFLAGS; likewise
| for maude_LDFLAGS and AM_LDFLAGS.  Previous versions bogusly
| preferred AM_CFLAGS over maude_CFLAGS while linking, and they
| used both AM_LDFLAGS and maude_LDFLAGS on the same link command.
|
| The fix for compiler flags (i.e., using maude_CFLAGS instead of
| AM_CFLAGS) should not hurt any package since that is how _CFLAGS
| is expected to work (and actually works during compilation).
|
| However using maude_LDFLAGS "instead of" AM_LDFLAGS rather than
| "in addition to" breaks backward compatibility with older versions.
| If your package used both variables, as in
|
|   AM_LDFLAGS = common flags
|   bin_PROGRAMS = a b c
|   a_LDFLAGS = more flags
|   ...
|
| and assumed *_LDFLAGS would sum up, you should rewrite it as
|
|   AM_LDFLAGS = common flags
|   bin_PROGRAMS = a b c
|   a_LDFLAGS = $(AM_LDFLAGS) more flags
|   ...
|
| This new behavior of *_LDFLAGS is more coherent with other
| per-target variables, and the way *_LDFLAGS variables were
| considered internally. 

Hope that helps. 


Cheers,
Ralf 

Re: automake1.10 ignoring _LDFLAGS

[Ralf Wildenhues]

Hello Tom, Gary, all,

* Tom Epperly wrote on Tue, Feb 13, 2007 at 07:34:38PM CET:
> I am in the process of upgrading Babel, 
> http://www.llnl.gov/CASC/components/, from automake 1.9.6 to
> automake (GNU automake) 1.10
[...]

> Automake 1.10 seems to be ignoring my _LDFLAGS settings for library and 
> program targets.

Does this help (quoting automake/NEWS for 1.10):
|  - Per-target flags are now correctly handled in link rules.
|
|For instance maude_CFLAGS correctly overrides AM_CFLAGS; likewise
|for maude_LDFLAGS and AM_LDFLAGS.  Previous versions bogusly
|preferred AM_CFLAGS over maude_CFLAGS while linking, and they
|used both AM_LDFLAGS and maude_LDFLAGS on the same link command.
|
|The fix for compiler flags (i.e., using maude_CFLAGS instead of
|AM_CFLAGS) should not hurt any package since that is how _CFLAGS
|is expected to work (and actually works during compilation).
|
|However using maude_LDFLAGS "instead of" AM_LDFLAGS rather than
|"in addition to" breaks backward compatibility with older versions.
|If your package used both variables, as in
|
|  AM_LDFLAGS = common flags
|  bin_PROGRAMS = a b c
|  a_LDFLAGS = more flags
|  ...
|
|and assumed *_LDFLAGS would sum up, you should rewrite it as
|
|  AM_LDFLAGS = common flags
|  bin_PROGRAMS = a b c
|  a_LDFLAGS = $(AM_LDFLAGS) more flags
|  ...
|
|This new behavior of *_LDFLAGS is more coherent with other
|per-target variables, and the way *_LDFLAGS variables were
|considered internally.

Cheers,
Ralf

Re: unsubscribe me plz

[Ralf Wildenhues]

Hello Fred,

* FRED QUIMPY wrote on Sun, Feb 25, 2007 at 07:38:38AM CET:
>  
> unsubscribe me plz

You can (and have to) do that yourself at


Hope that helps.

Cheers,
Ralf

Re: MAINTAINERCLEANFILES in srcdir

[Ralf Wildenhues]

Hi Stepan,

* Stepan Kasal wrote on Wed, Mar 14, 2007 at 01:34:06PM CET:
>   the target maintainer-clean contains
>   -test -z "$(MAINTAINERCLEANFILES)" || rm -f $(MAINTAINERCLEANFILES)
[...]
> Could we perhaps change the above command to:
> 
>   -test -n "$(MAINTAINERCLEANFILES)" && \
>   rm -f $(MAINTAINERCLEANFILES) && \
>   cd $(srcdir) && rm -f $(MAINTAINERCLEANFILES)
> 
> (I'm willing to implemement this eventually.)

Then make it something like this, please:

-test -z "$(MAINTAINERCLEANFILES)" || \
  { rm -f $(MAINTAINERCLEANFILES) && \
cd $(srcdir) && rm -f $(MAINTAINERCLEANFILES); }

Cheers,
Ralf

Re: How do I avoid a specific variable in the Makefile?

[Ralf Wildenhues]

[ Cc:ing bug-automake for an documentation request ]

Hello Jules,

* Jules Colding wrote on Thu, Mar 15, 2007 at 12:10:54PM CET:
> 
> I've got a multiline configure.in variable like this:
> 
>   RPM_BUILDREQUIRES='BuildRequires:  package_1
>   BuildRequires:  package_2'
>   AC_SUBST(RPM_BUILDREQUIRES)
[...]
> This unfortunately has a side effect as it creates a target in my
> Makefile named "BuildRequires:" requiring the target "package_2".

I assume you use Automake 1.10 (and Autoconf >= 2.60 earlier versions
did not cope with multiline variables)?  Because if you don't use
Automake, but write Makefile.in yourself, just not mentioning
@RPM_BUILDREQUIRES@ in Makefile.in would be sufficient.

> Is there a way for me to get the required substitution in the spec file
> without AC_SUBST()'ing so that I avoid getting the value substituted
> into the Makefile as well?

Yes, but I'm afraid it's currently not documented by Automake.
Add
  _AM_SUBST_NOTMAKE([RPM_BUILDREQUIRES])

I think Automake should publicize this interface; more precisely, I
think Automake should implement an alias AM_SUBST_NOTMAKE which does the
same thing, document it, and keep the underscored name as undocumented
alias.

Cheers,
Ralf

Re: How do I avoid a specific variable in the Makefile?

[Ralf Wildenhues]

[ let's drop the autoconf list ]

Hi Stepan,

* Stepan Kasal wrote on Thu, Mar 15, 2007 at 06:21:23PM CET:
> On Thu, Mar 15, 2007 at 01:29:30PM +0100, Ralf Wildenhues wrote:
> > [ Cc:ing bug-automake for an documentation request ]
> > 
> > * Jules Colding wrote on Thu, Mar 15, 2007 at 12:10:54PM CET:
> > [...]
> > > This unfortunately has a side effect as it creates a target in my
> > > Makefile named "BuildRequires:" requiring the target "package_2".
> 
> this is a bug in Automake.

That may well be, but...

> >   _AM_SUBST_NOTMAKE([RPM_BUILDREQUIRES])
> > 
> > I think Automake should publicize this interface; more precisely, I
> > think Automake should implement an alias AM_SUBST_NOTMAKE which does the
> > same thing, document it, and keep the underscored name as undocumented
> > alias.
> 
> I do not think it is justified to publish this macro.
> 
> I do not see any use for the macro, besides working around this
> Automake bug.

... I beg to disagree here.  I may simply not want to have some macro
to be defined in Makefiles, but have its variable substituted elsewhere
(in other config files).  The awkward semantics of macro propagation
alone:
<http://www.gnu.org/software/autoconf/manual/html_node/Macros-and-Submakes.html>
justify this additional liberty for the developer IMO.

What would be your argument for limiting developer's possibilities?
Allowing the package developer to override Automake's "magic" has
always been a valuable goal.

Cheers,
Ralf

Re: subdir-objects fails with non-literal _SOURCES

[Ralf Wildenhues]

Hi Jim,

Thanks for the bug report.

* Jim Meyering wrote on Tue, Apr 17, 2007 at 06:18:44PM CEST:
> Some automake-generated code malfunctions when using the combination of
> the subdir-objects option and non-literal _SOURCES.

I actually have a patch (about half a year old, see followup to [1])
lying around that invokes `make' to build the depdirs, quite similar to
how you propose; the issue turned out to be much more hackish and
fragile than what you indicate, and IMHO not really applicable.

The strongest argument against invoking `make' at the end of configure
is one of debugging: if your makefile contains a syntax error -- and for
newbies it frequently will -- then configure won't finish successfully.

Note that I had in mind other cleanups of depout.m4, but any changes of
that code are very very fragile.  So, I guess a patch to document the
existing limitation better would be happily accepted.

Cheers,
Ralf

[1] 

Re: subdir-objects fails with non-literal _SOURCES

[Ralf Wildenhues]

Hi Jim,

* Jim Meyering wrote on Tue, Apr 17, 2007 at 09:16:59PM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> ...
> > The strongest argument against invoking `make' at the end of configure
> > is one of debugging: if your makefile contains a syntax error -- and for
> > newbies it frequently will -- then configure won't finish successfully.
> 
> If you're tempted, maybe a two-pronged approach.  First use the naive
> sed-based approach, but if there are any '$' in the result, try using
> "make".

Not such a bad idea, but...

> If make-based process fails for any reason, simply continue
> with the results (guaranteed to fail upon build attempt) of the
> sed-based approach.

... what if make decides to rerun `config.status --recheck &&
config.status', say, because the user has his CONFIG_STATUS_DEPENDENCIES
wrong?  I don't see an easy, non-error-prone way to guard against the
ensuing endless loop.  Of course the same failure would happen at the
time the user typed `make' later, but:
- maybe he knows what he's doing and knows not to type `make' right now,
- maybe he knows to run gmake later (which won't rerun config.status)
  but has not issued `configure MAKE=gmake' (in which case we don't know
  to use gmake over ${MAKE-make}).

I've encountered both failure scenarios before, with me being the user,
or the developer in the process of fixing the build system.  These
things are tricky enough when you see what's going on, but supposedly
the new depout.m4 would hide $MAKE's output, no?  Thus making debugging
neigh impossible.

> Then, it should work no worse than the existing code, and
> you can hide any make diagnostics so as not to confuse newbies.
> The only cost is the added complexity.

Complexity is another counter argument, yes.  There is already a lot
complexity in Automake, in that it is quite difficult to expose all
cases well.

FWIW, I overlooked your (nice!) idea to avoid a temp makefile.

> I can see how you'd prefer to document the current limitation,
> but I hate to force people to un-factor their Makefiles.
> On the other hand, I get the impression that this is a pretty
> obscure corner, probably because few people use subdir-objects,
> and even fewer also use make variables in _SOURCE values.

I think this bug has been reported a few times already.

Cheers,
Ralf

Re: Typo in section 10.5 of automake 1.10 info manual

[Ralf Wildenhues]

Hello Reuben,

* Reuben Thomas wrote on Fri, Apr 20, 2007 at 12:37:17AM CEST:
> "Search a Python interpreter on the system" should be "Search for a Python 
> interpreter on the system".

Thanks.  Applied to HEAD and branch-1-10.

Cheers,
Ralf

2007-04-23  Reuben Thomas  <[EMAIL PROTECTED]>  (tiny change)

* doc/automake.texi (Python): Fix typo.

Index: doc/automake.texi
===
RCS file: /cvs/automake/automake/doc/automake.texi,v
retrieving revision 1.165
diff -u -r1.165 automake.texi
--- doc/automake.texi   29 Mar 2007 23:02:02 -  1.165
+++ doc/automake.texi   23 Apr 2007 16:31:56 -
@@ -7269,7 +7269,7 @@
 
 @defmac AM_PATH_PYTHON ([EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL 
PROTECTED])
 
-Search a Python interpreter on the system.  This macro takes three
+Search for a Python interpreter on the system.  This macro takes three
 optional arguments.  The first argument, if present, is the minimum
 version of Python required for this package: @code{AM_PATH_PYTHON}
 will skip any Python interpreter that is older than @var{VERSION}.

Re: subdir-objects fails with non-literal _SOURCES

[Ralf Wildenhues]

Hi Jim,

* Jim Meyering wrote on Sat, Apr 21, 2007 at 09:10:22PM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> >
> > ... what if make decides to rerun `config.status --recheck &&
> > config.status', say, because the user has his CONFIG_STATUS_DEPENDENCIES
> > wrong?  I don't see an easy, non-error-prone way to guard against the
> > ensuing endless loop.  Of course the same failure would happen at the
[...]
> No problem :-)  Just disable the potentially-offending rule in
> the temporary makefile that is probably already required -- see below.

That seems possible.  I'm a bit worried at all of this getting more and
more complicated.

FWIW, another approach to deal with non-literal *_SOURCES is to get it
right in `automake'.  That way, it won't work for @substituted@ values,
but that's not such an issue for the application you propose, I guess.

> > FWIW, I overlooked your (nice!) idea to avoid a temp makefile.
> 
> Thanks.  Unfortunately, I doubt usage like this
> is portable enough to use there:
> 
>   echo 'target:; rule...' | make -f Makefile -f - target"
> 
> So we'd need a temporary, makefile, as well as code to
> clean up afterwards (and upon interruption).

I'm pretty sure all modifications required so far can be put into the
form
  sed < $orig_makefile "$convoluted_sed_script" | $MAKE -f - target

(using the i, a, and d sed commands), but it certainly won't be fun to
debug for the casual bug observer.

I'll try to come up with a patch.

Cheers,
Ralf

Re: help me please

[Ralf Wildenhues]

Hello Андрей,

* Андрей Аваков wrote on Fri, Apr 27, 2007 at 12:28:07PM CEST:
> I build LFS system (Linux From Scratch) - www.linuxfromscratch.org.
> On point 6.26.1. Installation of Automake, after compile
> i take some tests and get next mistake:
> .
> .
> PASS: yaccvpath.test
> =
> 1 of 531 tests failed
> (36 tests were not run)
> Please report to bug-automake@gnu.org
> =

Thanks for the report.  Please rerun the testsuite and capture the
output, so you can find out which test failed (it will be preceded
by "FAIL:").  Then please rerun that one test verbosely, like this:
  cd tests
  env VERBOSE=yes make -e check TESTS=$test_that_failed.test

Post all output of this last command.

Thanks,
Ralf

Re: Incorrect rule generated for assembly source with subdir-objects

[Ralf Wildenhues]

Hello Bas,

* Bas Wijnen wrote on Fri, Apr 27, 2007 at 01:51:37PM CEST:
> When using subdir-objects and assembly source (with CCAS), the generated
> rule does
> 
> gcc -g -O2 -c 
> 
> For a filename path/to/file.S, this creates file.o, not path/to/file.o.

Please try Automake-1.10 rather than 1.9.x.  This bug should have been
fixed there.

Cheers,
Ralf

Re: help me please

[Ralf Wildenhues]

Hello Андрей,

* Андрей Аваков wrote on Tue, May 01, 2007 at 10:35:16PM CEST:
> В сообщении от 28 апреля 2007 03:52 вы написали:
> >
> > Thanks for the report.  Please rerun the testsuite and capture the
> > output, so you can find out which test failed (it will be preceded
> > by "FAIL:").  Then please rerun that one test verbosely, like this:
> >   cd tests
> >   env VERBOSE=yes make -e check TESTS=$test_that_failed.test
> >
> > Post all output of this last command.

> Hello Ralf,
> I made all what you say, and get:
> 
> root:/LFS# cd automake-1.9.6
> root:/LFS/automake-1.9.6# make check | grep FAIL
> XFAIL: auxdir2.test
> XFAIL: cond17.test
> XFAIL: txinfo5.test

Those are all ok: they are eXpected FAILures.  But your original report
said there was one unexpected failure.  I don't understand why it should
not show up now.

> root:/LFS/automake-1.9.6/tests# env VERBOSE=yes make -e check 
> TESTS=$auxdir2.test

Ah, this is a misunderstanding, sorry.  Please leave out the $ sign,
and you can type just like this for multiple tests:

  cd tests
  env VERBOSE=yes make -e check TESTS="auxdir2.test cond17.test txinfo5.test"

But if there are no tests that failed unexpectedly, there is no problem.

Cheers, and thanks,
Ralf

Re: info_TEXINFOS should not assume source file exists

[Ralf Wildenhues]

Hello Noah,

* Noah Slater wrote on Mon, May 07, 2007 at 07:36:26PM CEST:
>
> I generate my "foo.texi" Texinfo documentation from DocBook
> ("foo.dbk") and using the info_TEXINFOS rule in my Makefile.am causes
> automake to check for "foo.texi" before completing.

Well, yes, automake needs to know about @setfilename to infer the info
file name, whether you include a `version.texi' file, and similar
things.

I think you may be able to get around this using nodist_info_TEXINFOS
instead.  If you still want foo.texi (and maybe also the info file)
distributed (and thus generated in the source tree), then I suggest that
you add it/them (and all its prerequisites) to EXTRA_DIST, but it sounds
like you don't (and thus require the users of your package to have
texinfo installed).

> As "foo.texi" is generated by a rule in my Makefile I have to have my
> bootstrap script touch the "foo.texi" file and then cat some content
> in to it to fool automake.

That does not sound like a good idea.

Hope that helps.

Cheers,
Ralf

Re: info_TEXINFOS should not assume source file exists

[Ralf Wildenhues]

* Noah Slater wrote on Thu, May 10, 2007 at 10:09:51AM CEST:
>
> Do you have a public bug tracker?

Yes: 

>>  - it is a bug that this limitation is not documented in the manual;
>>patches welcome.
>
> Happy to help out... point me in the right direction.

There was a stab at a related issue by Paolo recently:


where it turned out that more work is needed.  You may want to
coordinate with Paolo (Cc:ed).

Note that nontrivial patches to GNU software require copyright
assignment (more information off-list in case you're still interested).

Hope that helps.

Cheers,
Ralf

Re: info_TEXINFOS should not assume source file exists

[Ralf Wildenhues]

Hi Noah,

* Noah Slater wrote on Thu, May 10, 2007 at 10:20:56AM CEST:
> I would be hopelessly useless at patching the source but I was
> offering to patch the docs to reflect the advice you gave me as
> you suggested.

Oh, that's fine, I just misunderstood.  Please send patches to the
automake-patches list.

Cheers,
Ralf

Re: automake-1.8.5-r3 - test fails - Gentoo 2007.0

[Ralf Wildenhues]

Hello Steffen,

Thanks for the reports.

* [EMAIL PROTECTED] wrote on Tue, May 15, 2007 at 04:46:00PM
CEST:
[...]
> FAIL: exdir2.test
[...]
> FAIL: man2.test
[...]
> FAIL: transform.test
[...]
> =
> 3 of 505 tests failed
> (25 tests were not run)
> Please report to bug-automake@gnu.org
> =
> make[2]: *** [check-TESTS] Error 1
> make[2]: Leaving directory
`/var/tmp/portage/sys-devel/automake-1.8.5-r3/work/automake-1.8.5/tests'

Please note that Automake-1.10 is the current release.  Unless your
reports concerning older releases have any relevance to the current
version, or to other, current packages (like Autoconf or m4), there is
little chance that anybody will spend a lot of time on them.

Anyway it would be helpful to see verbose test output for failures. In the
above case, that would be the output of
  cd /var/tmp/portage/sys-devel/automake-1.8.5-r3/work/automake-1.8.5/tests
  env VERBOSE=yes make -e check TESTS='exdir2.test man2.test transform.test'

for the other releases adjust TESTS to contain the FAILed tests.

The gentoo maintainer(s) of the Automake packages may be interested in the
failures.

Cheers,
Ralf

Re: test-closein.sh

[Ralf Wildenhues]

Hello Eric,

* Eric Blake wrote on Thu, May 17, 2007 at 02:39:04PM CEST:
>
> Shouldn't automake automatically distribute files listed in TESTS, without
> requiring the use of EXTRA_DIST?

TESTS are often generated (for example check_PROGRAMS), so that would
unnecessarily limit its usefulness.

Cheers,
Ralf

Re: Acvhieving the equivalent of check-hook?

[Ralf Wildenhues]

Hello James,

* James Youngman wrote on Sat, May 19, 2007 at 02:52:26PM CEST:
> 
> However, it seems to me that while this check is currently performed
> at "make dist" time, the _right_ plase for it is "make check".
> However, per Tom Tromey's email in January, there is no "check-hook".

Would the `check-local' target be ok for you?

Cheers,
Ralf

Re: Acvhieving the equivalent of check-hook?

[Ralf Wildenhues]

* James Youngman wrote on Sun, May 20, 2007 at 10:17:18PM CEST:
> On 5/20/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>> * James Youngman wrote on Sat, May 19, 2007 at 02:52:26PM CEST:
>> >
>> > However, it seems to me that while this check is currently performed
>> > at "make dist" time, the _right_ plase for it is "make check".
>> > However, per Tom Tromey's email in January, there is no "check-hook".
>>
>> Would the `check-local' target be ok for you?
>
> Won't that inhibit the running of the DejaGnu test suite?

Have you tried it and it did not work as expected?

> (BTW, the reply-to header of your email pointed at me; was that 
> deliberate?)

There was no Reply-To: header in the mail I sent, nor in the one I
received from lists.gnu.org.  My mailer does set Mail-Followup-To:,
in this case to bug-automake and to you.  But that should not be a
problem AFAIK.  Could you (privately) send me the header of the mail
you received?

Thanks,
Ralf

Re: Need more EXTRA_PROGRAMS variables

[Ralf Wildenhues]

Hello Behdad,

* Behdad Esfahbod wrote on Sun, Jun 17, 2007 at 01:02:27AM CEST:
> 
> For the first time I'm stuck with an automake problem and think it's an
> unfair limitation of automake rather than my skills being short.
> 
> The problem is, the make check target that automake generates builds and
> runs $(TESTS), but on systems with non-empty EXEEXT this doesn't work.
> 
> The only way I see to fixing this is to add $(EXEEXT) at the end of all
> 300 test names in my $(TESTS), which is far from elegant.

Are you using Automake 1.10?  Quoting from its NEWS file:
|  - $(EXEEXT) is automatically appended to filenames of TESTS
|  that have been declared as programs in the same Makefile.
|  This is mostly useful when some check_PROGRAMS are listed in TESTS.

Note that CVS (both HEAD and branch-1-10) has a bugfix to do the same
with XFAIL_TESTS, so that XFAILing is detected reliably.

Other than that, you may not have known about check_PROGRAMS?

If there are still issues, please show an example where things go wrong,
including on which system you are experiencing this (esp. if you are
using a cross setup with a simulator, say).

Thanks,
Ralf

Re: Need more EXTRA_PROGRAMS variables

[Ralf Wildenhues]

Never mind, I think I misunderstood you first.
Still I think the mechanism is general enough to support what you need:

ALL_TESTS = a b c
MORE_PROGS = d e f
EXTRA_PROGRAMS = $(ALL_TESTS) $(MORE_PROGS)
TESTS = $(ALL_TESTS)

This causes the entries of TESTS to all have EXEEXT added, which I think
is what you want, no?  If you can live with $(EXTRA_PROGRAMS) also
containing the tests, that is.  If not, then I'd like to know why not.

Cheers,
Ralf

Re: automake-1.9: ## Internal Error ##

[Ralf Wildenhues]

Hello Tomaž,

Thanks for the bug report.  Unfortunately, it is not enough information
for me to go by yet.

* Tomaž Žveglič wrote on Tue, Jun 19, 2007 at 07:36:35PM CEST:
> automake-1.9: 
> automake-1.9: ## Internal Error ##
> automake-1.9: 
> automake-1.9: unrequested trace `'
> automake-1.9: Please contact .
> at /usr/local/share/automake-1.9/Automake/Channels.pm line 562
>Automake::Channels::msg('automake', '', 'unrequested trace `\'')
> called at /usr/local/share/automake-1.9/Automake/ChannelDefs.pm line 191
>Automake::ChannelDefs::prog_error('unrequested trace `\'') called at
> /usr/local/bin/automake-1.9 line 4675
>Automake::scan_autoconf_traces('configure.in') called at
> /usr/local/bin/automake-1.9 line 4877
>Automake::scan_autoconf_files() called at /usr/local/bin/automake-
> 1.9 line 7493
> *** Error code 1
>
> Stop in /home/ezi1httpd (line 171 of Makefile).

Which package are you building when you get this?  Is there any output
before this error?  Which system are you on?  Perchance OpenBSD and you
are using its m4 instead of GNU m4?  Which m4 version, which autoconf
version?  Can you post configure.in and Makefile.am of the package where
this fails?

If m4 is older than 1.4.9, autoconf is older than 2.61, then please
update each (in that order), rebuild automake to use the newer
respective tool (with m4 you also should be able instead to override the
choice by exporting $M4, but for a newer Autoconf you have to rebuild
Automake) and try again to see whether the bug is fixed.

Thanks,
Ralf

Re: Need more EXTRA_PROGRAMS variables

[Ralf Wildenhues]

* Behdad Esfahbod wrote on Thu, Jun 21, 2007 at 01:42:18AM CEST:
> On Tue, 2007-06-19 at 09:18 +0200, Ralf Wildenhues wrote:
> > 
> > All fair.  Except I simply don't see a use case for this yet, nor do I
> > see what `something' should mean in this case.  If you can create a
> > sensible use case, let's see how to implement it.  IOW: where do you
> > need EXEEXT rewriting for something that is not an optionally built
> > program?
> 
> Ok, maybe I have a wrong idea of what the committed fix was.  I want
> to be able to have something like this work:
> 
> 
> EXTRA_PROGRAMS = 
> 
> DANCE_PROGS = dance1 dance2 dance3
> EXTRA_PROGRAMS += $(DANCE_PROGS)
> dance: $(DANCE_PROGS)
>   ./perform-dance # uses progs dance1, dance2, and dance3
> 
> 
> Now does automake rewrite DANCE_PROGS to include EXEEXT?

No, it doesn't.  Thanks for the example, I think I understand now
and I see that this requires another variable, e.g., in order to also
have

SWIM_PROGS = swim1
EXTRA_PROGRAMS += $(SWIM_PROGS)
swim: $(SWIM_PROGS)
./perform_swim # ...

in which case you could not just use $(EXTRA_PROGRAMS) as prerequisite
of dance any more (as that would be suboptimal).

> 
> EXTRA_DANCE_PROGRAMS = dance1 dance2 dance3
> dance: $(EXTRA_DANCE_PROGRAMS)
>   ./perform-dance # uses progs dance1, dance2, and dance3
> 
> 
> It will do. (and since it's a "EXTRA_" var, there is no need for
> DANCEdir to be defined).

I'm not yet totally convinced that this is the best solution, but
currently I fail to see technical issues with it.  Are you motivated to
work on a patch?  If yes, then look at automake.in:handle_programs and
automake.in:am_install_var to get going.  If you'd rather not venture
into that, it'd help a lot already if you wrote a documentation patch
and (used above in) a test.

FWIW, here's a couple of random ideas about why this naming is maybe
not ideal: it deviates from there where_HOW principle used in Automake.
The EXTRA_ bit is all clear, but the DANCE_ bit suddenly carries no
obvious meaning, unlike other variables.  Such special cases IMHO make
Automake's semantics more difficult to grasp for newcomers (and they
also make the documentation more difficult to write in a concise
manner).  OTOH I don't see an obvious better choice either.

Since this would be a new feature, and pose a small incompatibility:
  EXTRA_FOO_PROGRAMS = p
  EXTRA_FOOdir = $(bindir)

will be treated differently with the patch than without the change
(wrt. what's build at 'all' time and what's installed),
this change is suitable for HEAD but not for branch-1-10.

Thanks for your patience with me.

Cheers,
Ralf

Re: automatic update Makefile.am -> Makefile.in -> Makefile no longer working

[Ralf Wildenhues]

Hello world,

* Eric Blake wrote on Thu, Jun 21, 2007 at 02:16:32PM CEST:
> According to Paul Eggert on 6/20/2007 11:36 PM:
> > 
> > +[m4_warning([this file was generated for autoconf $ac_version.
> > +You have another version of autoconf.  It may work, but it may not.
> > +If you have problems, you may need to regenerate the build system 
> > entirely.])])

Thanks for the bug report, discussion, and patch.

> ...except should we also mention 'autoreconf' as the way to regenerate
> the build system?

autoreconf may not always be appropriate.  Also, to my humble non-native
English ear, the sentence `It may work, but it may not.' sounds strange.
How about this?

[m4_warning([this file was generated for autoconf $ac_version.
You have another version of autoconf.  It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically 
`autoreconf'.])])

And tests/missing4.test needs to be fixed appropriately (see
  cd tests && make check VERBOSE=yes TESTS=missing4.test
).

And NEWS should have (since it mentioned the check introduction in 1.10)
something like:

  - The autoconf version check implemented by aclocal in aclocal.m4
is degraded to a warning.

I think this should be applied to HEAD and branch-1-10.
Would you like me to do it?

With this patch, of course maintenance of Automake gets yet another bit
harder: if the user had overlooked this warning at one point in time,
and it just so happened that the version difference was an incompatible
one, then it is even more difficult to reconstruct this after the fact.
Of course the problem existed rather similarly before this patch, only
that a Makefile.in that was not updated at all due to the version
difference is usually much easier to detect as inconsistent with
Makefile.am.

So this is yet another reason to keep Autoconf version incompatibilities
as few as possible.  Which is in turn a reason for Autoconf to have a
testsuite with as extensive coverage of functionality as possible.  ;-)

Cheers,
Ralf

Re: automatic update Makefile.am -> Makefile.in -> Makefile no longer working

[Ralf Wildenhues]

* Paul Eggert wrote on Thu, Jun 21, 2007 at 09:15:56PM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> 
> > I think this should be applied to HEAD and branch-1-10.
> > Would you like me to do it?
> 
> Yes, please.  And thanks for your review; your points all look right
> to me.

Thanks.  This is what I installed.

Cheers,
Ralf

2007-06-23  Paul Eggert  <[EMAIL PROTECTED]>
Ralf Wildenhues  <[EMAIL PROTECTED]>

* aclocal.in (write_aclocal): Warn about autoconf
incompatibilities instead of making them fatal.
* tests/missing4.test: Adjust.
* NEWS: Update.
Problem reported by Bruno Haible in
<http://lists.gnu.org/archive/html/bug-automake/2007-06/msg00010.html>.

Index: NEWS
===
RCS file: /cvs/automake/automake/NEWS,v
retrieving revision 1.326
diff -u -r1.326 NEWS
--- NEWS29 Mar 2007 23:01:59 -  1.326
+++ NEWS22 Jun 2007 08:32:17 -
@@ -1,5 +1,11 @@
 New in 1.10a:
  
+* Changes to aclocal:
+
+  - The autoconf version check implemented by aclocal in aclocal.m4
+(and new in Automake 1.10) is degraded to a warning.  This helps
+in the common case where the Autoconf versions used are compatible.
+
 * Languages changes:
 
   - subdir-object mode works now with Fortran (F77, FC, preprocessed
Index: aclocal.in
===
RCS file: /cvs/automake/automake/aclocal.in,v
retrieving revision 1.140
diff -u -r1.140 aclocal.in
--- aclocal.in  14 Oct 2006 17:40:25 -  1.140
+++ aclocal.in  22 Jun 2007 08:32:17 -
@@ -783,9 +783,10 @@
   # use it in the header below.  autom4te will output the name of
   # the file in the diagnostic anyway.
   $output = "m4_if(m4_PACKAGE_VERSION, [$ac_version],,
-[m4_fatal([this file was generated for autoconf $ac_version.
-You have another version of autoconf.  If you want to use that,
-you should regenerate the build system entirely.], [63])])
+[m4_warning([this file was generated for autoconf $ac_version.
+You have another version of autoconf.  It may work, but is not guaranteed to.
+If you have problems, you may need to regenerate the build system entirely.
+To do so, use the procedure documented by the package, typically 
`autoreconf'.])])
 
 $output";
 }
Index: tests/missing4.test
===
RCS file: /cvs/automake/automake/tests/missing4.test,v
retrieving revision 1.1
diff -u -r1.1 missing4.test
--- tests/missing4.test 21 Apr 2006 19:02:29 -  1.1
+++ tests/missing4.test 22 Jun 2007 08:32:18 -
@@ -1,5 +1,5 @@
 #! /bin/sh
-# Copyright (C) 2006  Free Software Foundation, Inc.
+# Copyright (C) 2006, 2007  Free Software Foundation, Inc.
 #
 # This file is part of GNU Automake.
 #
@@ -42,14 +42,12 @@
 
 $MAKE 2>stderr
 cat stderr
-grep 'WARNING:.*automake.*probably too old' stderr
-grep 'WARNING:.*autoconf.*probably too old' stderr
-test 2 = `grep -c 'aclocal.m4:.*this file was generated for' stderr`
+grep 'You have another version of autoconf' stderr
+grep -c 'aclocal.m4:.*this file was generated for' stderr
 
 $MAKE 2>stderr
 cat stderr
-grep 'WARNING:.*automake.*probably too old' stderr && exit 1
-grep 'WARNING:.*autoconf.*probably too old' stderr && exit 1
+grep 'You have another version of autoconf' stderr && exit 1
 grep 'aclocal.m4:.*this file was generated for' stderr && exit 1
 
 :

Re: ylwrap proposition

[Ralf Wildenhues]

Hello Sergey,

* Sergey Poznyakoff wrote on Fri, Jun 22, 2007 at 01:15:32PM CEST:
> 
> Some (rather long) time ago, I proposed an extension to ylwrap that
> would enable it to provide a functionality similar to that
> of `bison -p prefix', i.e. replacing `yy' prefix in idenifiers with
> the given string. (The original proposition is available here:
> http://lists.gnu.org/archive/html/bug-automake/2001-06/msg00021.html)
> 
> Tom seemed to agree with this. However, the patch never made it to the
> distribution. So, here is the similar patch, this time against the
> CVS automake.

Thanks for the patch.  I'm not very experienced with yacc, so some of
the following questions may seem stupid:

Can s/yy/.../ change anything unintended?  E.g., do we need to ensure it
only changes words beginning with yy?  Can it omit anything that needs
changed (what about `YY...')?  What about the header file, doesn't that
need to be changed as well?  Does the renaming work for extensions such
as bison's for C++ parsers?  ylwrap is used for both lex and yacc:
should we disable the functionality for lex (as it may produce garbage
there?), and should it be made clear in the help output that -p is only
for the yacc part?

This patch needs the following things to be complete.  If you are
willing to help with any of them, that'd be great.  Otherwise it may
be a little while until I get to it:

- update scriptversion and copyright year in the ylwrap script.
- add test(s) to ensure the new functionality works as expected.
  tests/yacc8.test can serve as a starting point for a new test.
- write ChangeLog entry, adjust NEWS, THANKS, doc/automake.texi:
  mention new option, change recommendation about multiple parsers
  (probably the list of #defines should not be removed just yet,
  it may be interesting if only for historical purposes).
- test with 2-3 yacc implementations (I have access to some systems).
  Ensure none of the other ylwrap-related tests fail.
- put the patch in HEAD: this is a new feature so not eligible for
  branch-1-10.

Some nits:

> Index: lib/ylwrap
> --- automake/lib/ylwrap   2007-06-22 11:57:46.0 +0300
> +++ automake.orig/lib/ylwrap  2007-06-22 13:05:20.0 +0300
> @@ -41,9 +41,13 @@ case "$1" in
>  basedir=$2
>  shift 2
>  ;;
> +  --p|--pr|--pre|--pref|--prefi|--prefix)

-p is not actually supported, but documented.

> +YYREPL="s/yy/$2/g"
> +shift 2
> +;;

> @@ -177,7 +186,8 @@ if test $ret -eq 0; then
>  -e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/'\
>  -e 's/[^ABCDEFGHIJKLMNOPQRSTUVWXYZ]/_/g'`
>  
> -  sed -e "/^#/!b" -e "s,$input_rx,," -e "s,$from,$2," \
> +  sed -e "$YYREPL"  \

The command
  sed -e ""

is actually not portable, it will fail with AIX 5.3 sed:
$ echo x | sed -e ""
| sed: 0602-429 No editing script was provided.
| Usage:  sed [-n] Script [File ...]
| sed [-n] [-e Script] ... [-f Script_file] ... [File ...]

Let's just rewrite the whole thing like:

  sed -e "
$YYREPL
/^#/!b
s,$input_rx,,
s,$from,$2,
s,$FROM,$TARGET," "$from" >"$target" || ret=$?

and really the variables used in the sed substitutions could use more
escaping (for example comma needs to be escaped).  This latter bug has
been present before your patch, of course.

> +  -e "/^#/!b" -e "s,$input_rx,," -e "s,$from,$2," \
>-e "s,$FROM,$TARGET," "$from" >"$target" || ret=$?
>  
># Check whether header files must be updated.

Cheers,
Ralf

Re: ylwrap proposition

[Ralf Wildenhues]

* Sergey Poznyakoff wrote on Sat, Jun 23, 2007 at 02:04:29PM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> ha escrit:
> 
> > Can s/yy/.../ change anything unintended?  E.g., do we need to ensure it
> > only changes words beginning with yy?
> 
> In theory it could, for example if the programmer used identifiers
> beginning with, or containing `yy'. However, I can hardly imagine
> someone who does that. At least, all yacc manuals declare that `yy'
> prefix is reserved for yacc/lex identifiers and explicitly discourage
> its use in application identifiers.
> 
> It would be preferable, of course, to change only those `yy' that occur
> at the beginning of words. But I cannot figure out a portable way of
> doing so in sed.

Something like 
  s/^yy/REPL/
  s/\([^a-zA-Z0-9]\)yy/\1REPL/

but then sed should be executed as 'LC_ALL=C sed' to avoid locale
issues.  Another possibility is to just list all letters, as is done
elsewhere in the script (and could be factored in shell variables, like
Autoconf does.

Cheers,
Ralf

Re: formatting in gnupload

[Ralf Wildenhues]

Hello Karl,

* Karl Berry wrote on Fri, Jun 29, 2007 at 11:59:44PM CEST:
> It's a trivial point, but in gnupload in CVS, I see:
> 
> for file;
> do
> 
> Why the newline?

Actually it's not a trivial point at all.  Quoting from the Autoconf
manual shell portability section (Limitations of Builtins):

| `for'
|  To loop over positional arguments, use:
| 
|   for arg
|   do
| echo "$arg"
|   done
| 
|  You may _not_ leave the `do' on the same line as `for', since some
|  shells improperly grok:
| 
|   for arg; do
| echo "$arg"
|   done

This holds especially for "for" loops over positional arguments.
And yes, the code in gnupload has a bug here in that the semicolon
should not be there.  Solaris 10 /bin/sh exposes this issue.

I'm applying the patch below to Automake and syncing to gnulib.
(Note the semicolon after "$to" isn't actually a problem, but it's not
necessary either, so I removed it.)  Thanks for the report.

Cheers,
Ralf

2007-06-30  Ralf Wildenhues  <[EMAIL PROTECTED]>

* lib/gnupload: Fix shell portability issues with for loops.
Report by Karl Berry.

Index: lib/gnupload
===
RCS file: /cvs/automake/automake/lib/gnupload,v
retrieving revision 1.10
diff -u -r1.10 gnupload
--- lib/gnupload12 Nov 2006 09:49:50 -  1.10
+++ lib/gnupload30 Jun 2007 09:17:41 -
@@ -1,9 +1,9 @@
 #!/bin/sh
 # Sign files and upload them.
 
-scriptversion=2006-11-12.11
+scriptversion=2007-06-30.12
 
-# Copyright (C) 2004, 2005, 2006  Free Software Foundation
+# Copyright (C) 2004, 2005, 2006, 2007  Free Software Foundation
 #
 # 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
@@ -102,7 +102,7 @@
 
 # Make sure all files exist.  We don't want to ask
 # for the passphrase if the script will fail.
-for file;
+for file
 do
   if test ! -f $file; then
 echo "$0: Cannot find \`$file'" 1>&2
@@ -127,16 +127,16 @@
 stty echo
 echo
 
-for file;
+for file
 do
   echo "Signing $file..."
   rm -f $file.sig
   echo $passphrase | $GPG --passphrase-fd 0 -ba -o $file.sig $file
 done
 
-for dest in $to;
+for dest in $to
 do
-  for file;
+  for file
   do
 echo "Uploading $file to $dest..."
 files="$file $file.sig"

Re: [Esound] Plz~Help compiling!

[Ralf Wildenhues]

Hello Sean,

* SEUNGHO SHIN wrote on Wed, Jun 27, 2007 at 04:43:13AM CEST:
> I'm having a trouble compiling esound.I downloaded Esound and trying
> to build it on Visual C++ 6.I installed Cygwin to get some of header
> files but, still missing multiple header files such as
> sys/audio.h, alsa/asoundlib.h, CoreAudio/CoreAudio.h, i386/gstabs.h,
> etc.It seems pretty difficult to find those on the web. Where can I
> find those header files or what can I do to successfuly compile Esound
> on Visual C++ 6.0 Thanks in adavance -Sean

This definitely is a question for Esound mailing lists rather than
Automake's.  It sounds like you need to first install some prerequisite
packages such as ALSA.  However, I have no idea whether they have been
ported to Cygwin or even native w32.  I suggest you take a look at their
installation documentation.

Hope that helps.

Cheers,
Ralf

Re: how to create dependencies for conditional sources

[Ralf Wildenhues]

Hello Roumen,

* Roumen Petrov wrote on Thu, Jun 28, 2007 at 10:26:31PM CEST:
> Please find attached test case "bootstrap.sh".
> 
> How to write Makefile.am so that created makefiles to contain 
> dependencies for conditional sources ?

For example, you coud use this Makefile.am instead:

--- snip ---
noinst_PROGRAMS = target
target_SOURCES = main.c

if WITH_CASE1
target_SOURCES += case1.c
endif

if WITH_CASE2
target_SOURCES += case2.c
endif
--- snip ---

With the above, there is no need to set target_LDADD or
target_DEPENDENCIES.

Does that work for you?  If no, there is also the possibility to do
something like this:

--- snip ---
if WITH_CASE1
DEPS1=case1.lo
else
DEPS1=
endif

if WITH_CASE2
DEPS2=
else
DEPS2=case2.lo
endif

noinst_PROGRAMS=target

target_SOURCES = main.c
EXTRA_target_SOURCES = case1.c case2.c
target_LDADD= $(DEPS1) $(DEPS2)
--- snip ---

But you would still not need to set target_DEPENDENCIES: automake is
smart enough to figure it out itself.

Cheers,
Ralf

Re: how to create dependencies for conditional sources

[Ralf Wildenhues]

Hello Roumen,

* Roumen Petrov wrote on Sun, Jul 01, 2007 at 09:30:51PM CEST:
> Ralf Wildenhues wrote:
> >
> >noinst_PROGRAMS = target
> >target_SOURCES = main.c
> >
> >if WITH_CASE1
> >target_SOURCES += case1.c
> >endif
> >
> >if WITH_CASE2
> >target_SOURCES += case2.c
> >endif
> >--- snip ---
> >
> >With the above, there is no need to set target_LDADD or
> >target_DEPENDENCIES.

> Its seems to me that automake 1.9.6 textinfo page "Conditional Sources" 
> is obsolete.  Since page in CVS is same, please update textinfo.

I assume you're speaking about this (for version 1.10):
<http://sources.redhat.com/automake/automake.html#Conditional-Sources>

Well, details matter here.  If you list sources explicitly but
conditionally in Makefile.am, then automake is smart enough to infer the
dependencies.  If OTOH you assign them to a variable in configure.ac,
there is no way for automake to find out.  In that latter case you do
need to set *_DEPENDENCIES.

Hope that helps.

Cheers,
Ralf

Re: ylwrap proposition

[Ralf Wildenhues]

Hello Sergey, Bob,

* Bob Proulx wrote on Sun, Jun 24, 2007 at 12:44:15AM CEST:
>
[ using a "simple" sed script to rename yacc/lex output ]
> 
> Lately instead of the sed renaming method I have been using the
> gdb-style cpp define renaming method.  It is six of one and a half
> dozen of the other one.  But to my eyes it seems the slightly nicer of
> the two methods.

It seems there are people stumbling over the "simple" renaming, see
bug 503 in Automake's GNATS:


Sorry for not looking there earlier.

Cheers,
Ralf

Re: manual/html_mono/.symlinks

[Ralf Wildenhues]

Hi Karl,

* Karl Berry wrote on Tue, Jul 10, 2007 at 07:56:13PM CEST:
> 
> As a workaround until that glorious day comes, I added a .symlinks file
> in automake/manual/html_mono to try to make them resolve.  Hope that
> doesn't disturb anything.

Thanks.  The Automake manuals on gnu.org are quite outdated -- the one
on sources.redhat.com isn't.  We should remember to update both for
1.10.1 (which, among other things, is still pending license review, my
already-applied patches to move CVS to GPLv3 notwithstanding).

Cheers,
Ralf

Re: mingw host and def-files

[Ralf Wildenhues]

Hello Roumen,

* Roumen Petrov wrote on Sat, Jul 14, 2007 at 10:58:07PM CEST:
> Env.: mingw host, linux buld, i.e. cross compilation.
> 
> In this environment some of libraries are not ported entirely.
> Possible work around is to def file with imports instead of library.
> If I add def file to the source list sources it is removed in link mode.
> 
> How to add *def file to the list of files in link command ?

You can pass
  -Wc,$DLLNAME.def

to libtool and it will pass $DLLNAME.def through.  See also -Xcompiler
for a similar method that also allows passing through arguments that
contain comma.

Strictly speaking, this is a libtool question (and as such addressed in
its manual).

Cheers,
Ralf

Re: Why aren't BUILT_SOURCES removed by "make distclean"?

[Ralf Wildenhues]

Hello Reuben,

* Reuben Thomas wrote on Fri, Jul 20, 2007 at 10:34:47PM CEST:
> I have to add $(BUILT_SOURCES) to CLEANFILES to avoid complaints about 
> files that still exist after make distclean. Since the point of 
> BUILT_SOURCES is to get sources built that aren't distributed, it would 
> seem reasonable that they be cleaned up by make distclean.

BUILT_SOURCES is a band-aid to help build some targets early.  It can be
useful for things that are distributed (in which case you have to add
them to EXTRA_DIST, or some other variable that causes distribution, and
in which case you would not want them in CLEANFILES), or that are not
distributed but cleaned upon 'make clean'.  To allow for the choice,
also necessarily means that you have to choose yourself, or neither will
happen.

Hope that helps.

Cheers,
Ralf

Re: Where's the sequel?!

[Ralf Wildenhues]

Hello Reuben,

* Reuben Thomas wrote on Fri, Jul 20, 2007 at 09:26:44PM CEST:
> 
> "For this reason we refer to such setups using the name _VPATH builds_ in 
> the sequel."
> 
> I am presuming you mean "we refer below to such setups as _VPATH builds_." 
> rather than what you wrote, exciting as it sounds.

Thanks for proof-reading the manual!  Having a native speaker aboard is
always good! ;-)

I've applied this to branch-1-10 and HEAD.

Cheers,
Ralf

* doc/automake.texi (VPATH Builds): Fix wording.
Report by Reuben Thomas.

Index: doc/automake.texi
===
RCS file: /cvs/automake/automake/doc/automake.texi,v
retrieving revision 1.169
diff -u -r1.169 automake.texi
--- doc/automake.texi   16 Jul 2007 21:55:43 -  1.169
+++ doc/automake.texi   22 Jul 2007 09:24:58 -
@@ -819,7 +819,7 @@
 reference to the way the build tree shadows the source tree, it is not
 about some concurrency in the way build commands are run.  For this
 reason we refer to such setups using the name @emph{VPATH builds} in
-the sequel.  @emph{VPATH} is the name of the @command{make} feature
+the following.  @emph{VPATH} is the name of the @command{make} feature
 used by the @file{Makefile}s to allow these builds (@pxref{General
 Search, , @code{VPATH}: Search Path for All Prerequisites, make, The
 GNU Make Manual}).

Re: Internal Error with 1.10, unterminated IF

[Ralf Wildenhues]

Hello Jason,

* Jason Curl wrote on Mon, Jul 30, 2007 at 04:06:44PM CEST:
> 
> Makefile.am
>   FILES = dir1 dir2
>   if BUILD_DIR3
>   FILES += dir3
>   fi
>   SUBDIRS = $(FILES)
> 
> Then you get an error output like:
> Makefile.am:19: unterminated conditionals: BUILD_DIR3_TRUE
> automake-1.10: 
> automake-1.10: ## Internal Error ##
> automake-1.10: 
[...]

Do you think it would be more helpful if the error were like this?
| Makefile.am:4: conditional terminated with `endif' instead of `fi'

OK to apply the patch below to this end (and add Jason to THANKS)?

Cheers, and thanks,
Ralf

2007-08-09  Ralf Wildenhues  <[EMAIL PROTECTED]>

* automake.in (FI_PATTERN): New pattern.
(read_am_file, file_contents_internal): Use it to produce a
helpful error with `fi' instead of `endif', consider the
conditional terminated.
* tests/cond39.test: New test.
* tests/Makefile.am: Update.
* THANKS: Update.
Report by Jason Curl.

Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.1647
diff -u -r1.1647 automake.in
--- automake.in 7 Jul 2007 12:16:27 -   1.1647
+++ automake.in 9 Aug 2007 18:54:26 -
@@ -189,6 +189,8 @@
   '^else(?:\s+(!?)\s*([A-Za-z][A-Za-z0-9_]*))?\s*(?:#.*)?' . "\$";
 my $ENDIF_PATTERN =
   '^endif(?:\s+(!?)\s*([A-Za-z][A-Za-z0-9_]*))?\s*(?:#.*)?' . "\$";
+my $FI_PATTERN =
+  '^fi(?:\s+(!?)\s*([A-Za-z][A-Za-z0-9_]*))?\s*(?:#.*)?' . "\$";
 my $PATH_PATTERN = '(\w|[+/.-])+';
 # This will pass through anything not of the prescribed form.
 my $INCLUDE_PATTERN = ('^include\s+'
@@ -6212,6 +6214,11 @@
  {
$cond = cond_stack_endif ($1, $2, $where);
  }
+   elsif (/$FI_PATTERN/o)
+ {
+   error $where, "conditional terminated with `endif' instead of `fi'";
+   $cond = cond_stack_endif ($1, $2, $where);
+ }
 
elsif (/$RULE_PATTERN/o)
{
@@ -6612,6 +6619,11 @@
  {
$cond = cond_stack_endif ($1, $2, $file);
  }
+   elsif (/$FI_PATTERN/o)
+ {
+   error $where, "conditional terminated with `endif' instead of `fi'";
+   $cond = cond_stack_endif ($1, $2, $file);
+ }
 
 # Handling rules.
elsif (/$RULE_PATTERN/mso)
Index: tests/Makefile.am
===
RCS file: /cvs/automake/automake/tests/Makefile.am,v
retrieving revision 1.622
diff -u -r1.622 Makefile.am
--- tests/Makefile.am   22 Jul 2007 08:48:18 -  1.622
+++ tests/Makefile.am   9 Aug 2007 18:54:34 -
@@ -151,6 +151,7 @@
 cond36.test \
 cond37.test \
 cond38.test \
+cond39.test \
 condd.test \
 condhook.test \
 condinc.test \
--- /dev/null   2007-08-04 15:05:22.228065249 +0200
+++ tests/cond39.test   2007-08-09 20:53:08.0 +0200
@@ -0,0 +1,46 @@
+#!/bin/sh
+# Copyright (C) 2007  Free Software Foundation, Inc.
+#
+# This file is part of GNU Automake.
+#
+# GNU Automake 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 3, or (at your option)
+# any later version.
+#
+# GNU Automake 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 Automake; see the file COPYING.  If not, write to
+# the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+# Boston, MA 02110-1301, USA.
+
+# Produce a decent error with `fi' instead of `endif'.
+# Report by Jason Curl.
+
+. ./defs
+
+set -e
+
+cat >>configure.in <<'EOF'
+AM_CONDITIONAL([COND], [:])
+AC_OUTPUT
+EOF
+
+cat >>Makefile.am <<'EOF'
+VAR = a
+if COND
+VAR += b
+fi
+SUBDIRS = $(VAR)
+EOF
+
+mkdir a b
+
+$ACLOCAL
+$AUTOCONF
+AUTOMAKE_fails
+grep 'conditional terminated .*endif' stderr

Re: Automake 1.10 "make check" created 519 errors

[Ralf Wildenhues]

Hello Robert,

* [EMAIL PROTECTED] wrote on Thu, Aug 09, 2007 at 08:53:35PM CEST:
> Hi Ralf.  You were right about the autoconf version.  I did mean 2.59,
> and today I did upgrade to 2.61, which solved the whole problem.  It
> passed every test.  I should have ensured my autoconf was current before
> I bothered you, sorry.

Nothing to be sorry about, au contraire.  We forgot to adjust the
configure check to check for >= 2.60.  I'm applying this patch to
HEAD and branch-1-10.

Thanks again,
Ralf

2007-08-09  Ralf Wildenhues  <[EMAIL PROTECTED]>

* configure.ac: Actually require version 2.60 in the test for
Autoconf, and recommend it in the error messages.
* THANKS: Update.
Report by Robert Swafford.

Index: configure.ac
===
RCS file: /cvs/automake/automake/configure.ac,v
retrieving revision 1.35
diff -u -r1.35 configure.ac
--- configure.ac7 Jul 2007 11:23:27 -   1.35
+++ configure.ac9 Aug 2007 19:04:09 -
@@ -1,7 +1,7 @@
 # Process this file with autoconf to produce a configure script.
 
 # Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2006,
-# 2004, 2006  Free Software Foundation, Inc.
+# 2004, 2006, 2007  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
@@ -81,7 +81,7 @@
   am_cv_autoconf_installed=no
 fi])
 if test "$am_cv_autoconf_installed" = no; then
-  AC_MSG_ERROR([Autoconf 2.58 or better is required.
+  AC_MSG_ERROR([Autoconf 2.60 or better is required.
 Please make sure it is installed and in your PATH.])
 fi
 
@@ -102,7 +102,7 @@
 
 AC_CACHE_CHECK([whether autoconf is recent enough], [am_cv_autoconf_version],
 [mkdir conftest
-echo 'AC''_PREREQ(2.58)' > conftest/conftest.ac
+echo 'AC''_PREREQ(2.60)' > conftest/conftest.ac
 if AM_RUN_LOG([cd conftest && eval $am_AUTOCONF -o /dev/null conftest.ac]);
 then
   am_cv_autoconf_version=yes
@@ -111,7 +111,7 @@
 fi
 rm -rf conftest])
 if test "$am_cv_autoconf_version" = no; then
-  AC_MSG_ERROR([Autoconf 2.58 or better is required.])
+  AC_MSG_ERROR([Autoconf 2.60 or better is required.])
 fi
 
 # Test for ln.  We need use it to install the versioned binaries.

Re: Automake mailing list link wrong

[Ralf Wildenhues]

Hello Karl,

* Karl Berry wrote on Thu, Aug 09, 2007 at 11:52:51PM CEST:
> Hello Automakers -- we received this report on webmasters,
> can you dtrt please?  Thanks.

Done already.  This issue was also reported on the Automake lists and in
Automake's GNATS.

> Which contains archives that haven't been updated in over 2 years.
> The real place it should point is somewhere on lists.gnu.org.

Yeah, now the site has pointers to both archives, because the
sourceware.org ones go back further, and it's sometimes helpful
for history digging.

Thanks,
Ralf

Re: Automake 1.10 fails to cleanup .libs directory for a program in a subdirectory

[Ralf Wildenhues]

Hello Karsten, Guillermo,

* Karsten Hopp wrote on Mon, Aug 13, 2007 at 02:43:58PM CEST:
> The problem described in 
> http://lists.gnu.org/archive/html/bug-automake/2007-06/msg0.html still 
> exists in automake -1.10.
> http://people.redhat.com/sgrubb/audit/audit-1.5.6.tar.gz is the package 
> where one .libs subdir doesn't get removed with 'make distclean'
> As there haven't been any answers to that mail, I'm not sure if this is a 
> user error or a bug in automake.

Apologies for not answering earlier.  It's an Automake bug.  For now
it's easiest to work around it with adding something like
  # Work around an Automake bug:
  clean-local:
rm -rf bar/.libs bar/_libs

in Makefile.am.  Automake should be fixed though.

Hope that helps.

Cheers,
Ralf

Re: Automake 1.10 fails to cleanup .libs directory for a program in a subdirectory

[Ralf Wildenhues]

> * Karsten Hopp wrote on Mon, Aug 13, 2007 at 02:43:58PM CEST:
[...]
> > http://lists.gnu.org/archive/html/bug-automake/2007-06/msg0.html

Proposed patch below.  OK to install to HEAD and branch-1-10, and put
Guillermo in THANKS?  I assume it doesn't matter much that ChangeLog is
encoded in ISO-8859 and THANKS is UTF-8 at the moment?

Cheers,
Ralf

* automake.in (handle_programs): Also clean .libs/_libs
directory for _PROGRAMS.
* tests/libtoo10.test: New test.
* tests/Makefile.am: Update.
* THANKS: Update.
Report by Guillermo Ontañón.

Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.1647
diff -u -r1.1647 automake.in
--- automake.in 7 Jul 2007 12:16:27 -   1.1647
+++ automake.in 15 Aug 2007 05:26:32 -
@@ -2485,6 +2485,8 @@
   # make sure this directory will exist.
   my $dirstamp = require_build_directory_maybe ($one_file);
 
+  $libtool_clean_directories{dirname ($one_file)} = 1;
+
   $output_rules .= &file_contents ('program',
   $where,
   PROGRAM  => $one_file,
Index: tests/Makefile.am
===
RCS file: /cvs/automake/automake/tests/Makefile.am,v
retrieving revision 1.622
diff -u -r1.622 Makefile.am
--- tests/Makefile.am   22 Jul 2007 08:48:18 -  1.622
+++ tests/Makefile.am   15 Aug 2007 05:26:32 -
@@ -332,6 +332,7 @@
 libtool7.test \
 libtool8.test \
 libtool9.test \
+libtoo10.test \
 license.test \
 link_c_cxx.test\
 link_dist.test \
--- /dev/null   2007-08-04 15:05:22.228065249 +0200
+++ tests/libtoo10.test 2007-08-15 07:26:01.0 +0200
@@ -0,0 +1,63 @@
+#! /bin/sh
+# Copyright (C) 2007  Free Software Foundation, Inc.
+#
+# This file is part of GNU Automake.
+#
+# GNU Automake 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 3, or (at your option)
+# any later version.
+#
+# GNU Automake 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 Automake; see the file COPYING.  If not, write to
+# the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+# Boston, MA 02110-1301, USA.
+
+# Make sure .libs directories are removed for _PROGRAMS.
+# Report from Guillermo Ontañón.
+
+required=libtoolize
+. ./defs || exit 1
+set -e
+
+cat >> configure.in << 'END'
+AC_PROG_LIBTOOL
+AC_OUTPUT
+END
+
+cat > Makefile.am << 'END'
+lib_LTLIBRARIES = lib/libfoo.la
+lib_libfoo_la_SOURCES = foo.c
+bin_PROGRAMS = src/main
+check_PROGRAMS = check/test
+src_main_SOURCES = main.c
+check_test_SOURCES = main.c
+LDADD = lib/libfoo.la
+END
+
+mkdir lib src check
+cat > foo.c << 'END'
+int foo () { return 0; }
+END
+
+cat > main.c << 'END'
+extern int foo ();
+int main () { return foo (); }
+END
+
+libtoolize
+$ACLOCAL
+$AUTOMAKE --add-missing
+$AUTOCONF
+./configure
+$MAKE all check clean
+test ! -d src/.libs
+test ! -d src/_libs
+test ! -d check/.libs
+test ! -d check/_libs
+$MAKE distcheck

Re: typo in automake.pdf

[Ralf Wildenhues]

Hello John,

Thanks for the report.

* John Simpson wrote on Tue, Aug 14, 2007 at 08:26:31PM CEST:
>
> i *think* i've found a typo in the "automake.pdf"
[...]
>
>   This file is ready by both autoconf (to create `configure.ac') and ...
>
> should the filename here not be `configure.in' ?

No, it should be

|   This file is ready by both autoconf (to create `configure') and ...

and yes, it has been fixed in CVS Automake on 2006-10-28.  A corrected
PDF will be uploaded with the next Automake release.

Cheers,
Ralf

Re: Automake 1.10 fails to cleanup .libs directory for a program in a subdirectory

[Ralf Wildenhues]

Hi Guillermo,

* Guillermo Ontañón wrote on Thu, Aug 16, 2007 at 08:58:16AM CEST:
> On Wed, 2007-08-15 at 07:26 +0200, Ralf Wildenhues wrote:
> > Proposed patch below.  OK to install to HEAD and branch-1-10, and put
> > Guillermo in THANKS?  I assume it doesn't matter much that ChangeLog
> > is encoded in ISO-8859 and THANKS is UTF-8 at the moment? 
> 
> Thanks for the fix Ralf, the patch works for me.

Cool, I've applied that.

Cheers,
Ralf

Re: ar(1) issue building coreutils on 64-bit AIX

[Ralf Wildenhues]

Hello Eric,

* Eric Blake wrote on Fri, Aug 17, 2007 at 05:33:31AM CEST:
> 
> We ought to be consistent across all of the autotools.  I personally
> prefer ARFLAGS over AR_FLAGS, since it is CFLAGS and not C_FLAGS.

Yes, if the variable in question fulfills the same semantics.
Here, it definitely does not: Automake uses already
  ARFLAGS = cru

albeit as Makefile macro; but distinguishing between that and
environment variables can only lead to trouble.  So we cannot really
change without breaking backward compatibility.  So AR_FLAGS would come
as a natural second choice for flags to ar that are independent of the
action to be taken.  But really autotools have always usesd the scheme
that program variables may contain options, so
  AR='ar -X32_64'

seems like the most natural choice to me.  (Of course, AR_FLAGS should
still be used consistently.)

Cheers,
Ralf

Re: LFS 6.2: step 6.26.1

[Ralf Wildenhues]

Hello Jesse,

* Jesse Chisholm wrote on Sun, Aug 19, 2007 at 09:05:22PM CEST:
> 
> This is my first install of LFS, so the error may be mine.
> At the end of "make check" it reported:
> 
> =
> 1 of 532 tests failed
> (35 tests were not run)
> Please report to [EMAIL PROTECTED]
> =
> 
> Unfortunately, I wasn't paying close enough attention as the numerous 
> passes scrolled by (on my system it takes about 50 minutes) so I don't know 
> WHICH test failed.  There doesn't seem to be a tests.log  for me to peruse 
> or attach.

Once you find out which test failed, please also run
  cd tests && make check VERBOSE=yes TESTS=FOO.test

with FOO replaced by the failed test, and post the output.

Thanks,
Ralf

Re: LFS 6.2: step 6.26.1

[Ralf Wildenhues]

* Jesse Chisholm wrote on Mon, Aug 20, 2007 at 02:02:09AM CEST:
> 
> OK.  Attached is the tee log of the specific test: gcj4.test

Thanks.  I need more information in order to find out where it fails.
After running the test verbosely,

> >>  cd tests && make check VERBOSE=yes TESTS=FOO.test

please enter the testSubDir directory, edit the depcomp and the
configure scripts, adding
  set -x

as second line.  Then in the configure script find the line matching
  SHELL.*depcomp

and in the following line, replace
 >/dev/null 2>conftest.err &&

with
 2>&1 | tee conftest.err &&

then please run
  ./configure GCJ=gcj >log 2>&1

and send the log file packed (either bzip2 or gzip).  Thanks.

> I am guessing that the "XFAILED" lines means "Expected and acceptable 
> Failure".

Yes, that's right.

Cheers,
Ralf

Re: ar(1) issue building coreutils on 64-bit AIX

[Ralf Wildenhues]

Hello all,

* Peter Rosin wrote on Fri, Aug 17, 2007 at 09:24:39PM CEST:
> 
> Just pointing out that for libtool the archiver is never invoked as
> either of:
>   $AR $AR_FLAGS cru ...
>   $AR $AR_FLAGS x ...
>   $AR $AR_FLAGS t ...
> it is always one of these instead:
>   $AR $AR_FLAGS ...
>   $AR x ...
>   $AR t ...
> 
> That usage of $AR_FLAGS seems consistent with your description
> of $ARFLAGS in automake.

Ah, so the chance of reconciliation with Automake's ARFLAGS just got a
wee bit better.  Except that Automake uses
  $(AR) $(ARFLAGS) LIBRARY OBJECTS...

and Libtool would like to not have a space after ${ARFLAGS}, if it wants
to support the w32 LIB program.  This, however, would not work with the
$(ARFLAGS) macro in a makefile: it is not portable to assume that 'make'
will honor trailing white space in a macro set in the makefile (besides
the fact that I think it is error-prone):  pmake for example does not,
contray to Posix.  However, it does honor it on the command line, like:
  pmake "ARFLAGS=cru "

So then I thought of ugly hacks like
  AC_SUBST([ARFLAGS], ["cru ''"])

but that will then fail when $ARFLAGS is used in scripts like libtool
(could maybe be hacked around?), or
  AC_SUBST([ARFLAGS], ["cru \\
 "])

but even that will not get pmake to behave.  I can get pmake to add a
space with this:
  ARFLAGS = cru
  ARFLAGS +=

but of course that is not portable either, and I haven't yet found a way
to add one for Solaris 2.6 make.

So pick and choose:
- drop $AR_FLAGS in libtool, instead use ${ARFLAGS} and keep in sync
  with Automake's idea of it
- keep $AR_FLAGS and allow for LIB to be used as archiver from within
  Libtool.

FWIW, I don't currently see how to easily get Automake to allow LIB as
archiver for *_LIBRARIES.

Cheers,
Ralf

Re: LFS 6.2: step 6.26.1

[Ralf Wildenhues]

Hello Jesse,

Thanks for the feedback.  Please let's keep the mailing lists in Cc:.

* Jesse Chisholm wrote on Thu, Aug 23, 2007 at 05:49:04AM CEST:
> 
> I found time to test you patch and search my system.
> 
> 1: Your patch does indeed allow the automake-1.9.6 to pass all tests.

Good.  I've applied the patch to both branches.

> 2: looking back through the LFS install so far, we never do install gcj. 
> In fact, the LFS live CD doesn't even have gcj.

Well, the 'gcj' program certainly is available on your system; maybe as
part of another package?

Cheers,
Ralf

> >>* tests/defs.in (required): For gcj, check whether `gcj -v'
> >>works, to avoid broken installations without libgcj.spec.
> >>Export $GCJ.
> >>* tests/gcj4.test: Setting GCJ not needed any more.
> >>* THANKS: Update.
> >>Report by Jesse Chisholm.

Re: GNITS being referenced, with no link...

[Ralf Wildenhues]

[ <http://lists.gnu.org/archive/html/bug-automake/2006-01/msg6.html> ]

Hello Alfred,

Sorry for the very long delay, I just stumbled over your mail again.

* Alfred M. Szmidt wrote on Tue, Jan 03, 2006 at 11:46:41PM CET:
> The GNITS is being referenced in the automake manual, but with no link
> to it!  GNITS was usually quite a internal thing, but I dug it up from
> the dead a while a go (got a copy from Franc,ois Pinard many years ago
> I think); and now a copy--which has only had some structural changes
> so that it is in sync with the layout for the GNU Coding Standards--is
> avaiable in the GNU womb project.
> 
> I just commited the generated HTML pages for GNITS, so they should be
> avaiable from http://www.gnu.org/software/womb/gnits shortly (the
> top-level directory has no content yet).

The GNITS manual does have several links to the GCS, but none of the
HTML references work.  ;-)

For example, in
<http://www.gnu.org/software/womb/gnits/Errors.html> there is a
reference to
<http://www.gnu.org/software/womb/standards/Errors.html>
You should be able to fix that with some addition to the womb/.symlinks
file.

How about the patch below (for HEAD and branch-1-5)?
Barring objections, I'll apply in a few days.

Cheers,
Ralf

2007-09-07  Ralf Wildenhues  <[EMAIL PROTECTED]>

* doc/automake.texi (Strictness, Gnits): Add URL to Gnits
document.
Report by Alfred M. Szmidt.

Index: doc/automake.texi
===
RCS file: /cvs/automake/automake/doc/automake.texi,v
retrieving revision 1.171
diff -u -r1.171 automake.texi
--- doc/automake.texi   19 Aug 2007 07:46:52 -  1.171
+++ doc/automake.texi   7 Sep 2007 02:50:29 -
@@ -1818,11 +1818,12 @@
 standards for packages.  This is the default.
 
 @item gnits
-Automake will check for compliance to the as-yet-unwritten @dfn{Gnits
+Automake will check for compliance to the as-yet-unfinished @dfn{Gnits
 standards}.  These are based on the GNU standards, but are even more
 detailed.  Unless you are a Gnits standards contributor, it is
 recommended that you avoid this option until such time as the Gnits
-standard is actually published (which may never happen).
+standard is actually finished (which may never happen).  See
[EMAIL PROTECTED]://www.gnu.org/software/womb/gnits/} for more information.
 @end table
 
 @xref{Gnits}, for more information on the precise implications of the
@@ -8959,8 +8960,7 @@
 
 @item
 @code{VERSION} is checked to make sure its format complies with Gnits
-standards.
[EMAIL PROTECTED] FIXME xref when standards are finished
+standards, see @uref{http://www.gnu.org/software/womb/gnits/}.
 
 @item
 @cindex @file{README-alpha}

Re: Automake's invokation of libtool doesnt handle $prefix with spaces in directory names

[Ralf Wildenhues]

Hello Noah,

* Noah Slater wrote on Sat, Oct 06, 2007 at 07:04:37PM CEST:
> If I run configure like so:
> 
> ./configure --prefix="/tmp/foo bar"
> 
> Everything runs fine, but when I "make install" I get the following
> error output:

If I may quote from automake/TODO:
| * quoting bugs
|   - how to install file with a space in its name?
|   [ don't bother with this -- make is just too losing ]

[...]
>  /bin/bash ../../libtool --mode=install /usr/bin/install -c
> 'couch_erl_driver.la' '/tmp/couchdb test/lib/couch_erl_driver.la'
> /usr/bin/install -c .libs/couch_erl_driver.so /tmp/couchdb
> test/lib/couch_erl_driver.so
> /usr/bin/install: target `test/lib/couch_erl_driver.so' is not a directory
> make[3]: *** [install-libLTLIBRARIES] Error 1
> 
> Notice how the "/bin/bash ../../libtool" command properly quotes the
> path but the resulting command does not have a quoted path.
> 
> Am I doing anything wrong or is this a bug with automake/libtool?

Oh well, in this case it's a Libtool bug rather than an Automake/make
one.  Still, the rule applies: don't use white space in file names.
It's too much work and very ugly to fix this throughout Libtool as well.
Even if this particular failure may be rather simple to fix, it will
lead to followup issues with packages that use the installed libraries.

Sorry,
Ralf

Re: Internal error (weird)

[Ralf Wildenhues]

* John-John Tedro wrote on Wed, Oct 10, 2007 at 09:38:00PM CEST:
> On 10/8/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > * John-John Tedro wrote on Mon, Oct 08, 2007 at 12:16:46PM CEST:
> > >
> > > Use of uninitialized value in exists at /usr/bin/automake-1.10 line
> > 4823,
> > >  line 1.
> > > Use of uninitialized value in concatenation (.) or string at
> > > /usr/bin/automake-1.10 line 4823,  line 1.
> > > automake-1.10: 
> > > automake-1.10: ## Internal Error ##
> > > automake-1.10: 
> > > automake-1.10: unrequested trace `'
> > > automake-1.10: Please contact .
> > >  at /usr/share/automake-1.10/Automake/Channels.pm line 570
> > > Automake::Channels::msg('automake', '', 'unrequested trace `\'')
[...]
> > You mean, running `./configure' outputs the following, no?
> >
> > > as_func_failure succeeded.
> > > as_func_failure succeeded.
> > >
> > > Not typo, it says it twice, no matter what you do.
> > > And it's _not_ shell dependant, tested it with bash and zsh.
> >
> > How exactly do you invoke configure?  Do you have $SHELL or
> > $CONFIG_SHELL set in the environment?  Where are bash and zsh installed,
> > and which exact versions are they?  If you've compiled them yourself, or
> > if you or Gentoo have applied any patches to these shells, could you
> > provide pointers to them?
[...]
> I had /bin/sh linked to zsh, this was the problem, must be some bug in the
> zsh parser (if it's 100% sh compatible).
> I think i should take this with the zsh devs instead : P.

Which zsh version was this?

> I linked /bin/sh to bash, so now it's working.

I assume this removed the `as_func_failure succeeded.' warnings?
Did this also eliminate the internal error output by automake
(that would be surprising to me)?

Thanks,
Ralf

Re: bug report

[Ralf Wildenhues]

Hello Kyoji,

Thanks for the report.

* Kyoji Kamei wrote on Sun, Oct 14, 2007 at 11:31:13PM CEST:
> XFAIL: cond17.test

This is not a problem: XFAILs are expected failures.  So everything is
going right here, only FAILs and XPASSes (unexpected passes) are
problematic.

Cheers,
Ralf

Re: Simple improvement of "make check" performance

[Ralf Wildenhues]

Hello Sven,

Thanks for the patch.

* Sven Herzberg wrote on Fri, Oct 12, 2007 at 06:29:57PM CEST:
> 
> this patch adds the check targets (eg. check_PROGRAMS) directly to the
> dependencies of check-am, resulting in make spawning one command less
> and better parallel build performance because make can decide whether
> check_PROGRAMS need to be rebuild.
> 
> In a simple example in one of my projects (with "TESTS=" - so that no
> tests are executed) it reduced the overall time for running make check
> in an updated source tree by ~32%.

If you use parallel make with this patch, then it is not guaranteed any
more that `all-am' is completed before any tests are invoked.  For that,
`all-am' would further need to be listed as prerequisite of all check
and check_tests targets.

Further, while the relative speedup of your proposed change sounds nice,
I assume that, in absolute time, it's very small.  Is that correct?  If
yes, then I would not worry so much about it.

> Please tell me if you are interested in this patch and want me to update
> it to cvs HEAD.

No need, it still applies fine.

> PS: Please CC me for replies, as I'm not subscribed to this list.

Sure.

> PPS: I consider this patch being so trivial that no copyright assignment
> should be necessary.

Certainly.

Cheers,
Ralf

>   * automake.in: add the check targets directly to the dependencies of
>   check-am
>   * tests/Makefile.in: changed the Makefile.in according to automake's
>   new output

Re: [PATCH] Should use backslashes in depend2.am

[Ralf Wildenhues]

Hello Jan,

* Jan Engelhardt wrote on Sun, Oct 21, 2007 at 08:53:40PM CEST:
> 
> ---
>  lib/am/depend2.am |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> Index: automake-1.10/lib/am/depend2.am
> ===
> --- automake-1.10.orig/lib/am/depend2.am
> +++ automake-1.10/lib/am/depend2.am
> @@ -66,7 +66,7 @@ if %FASTDEP%
>  ## In fast-dep mode, we can always use -o.
>  ## For non-suffix rules, we must emulate a VPATH search on %SOURCE%.
>  ?!GENERIC?   %COMPILE% -MT %OBJ% -MD -MP -MF %DEPBASE%.Tpo %-c% -o %OBJ% 
> `test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE%
> -?GENERIC??!SUBDIROBJ?%COMPILE% -MT %OBJ% -MD -MP -MF %DEPBASE%.Tpo 
> %-c% -o %OBJ% %SOURCE%
> +?GENERIC??!SUBDIROBJ?%COMPILE% -MT %OBJ% -MD -MP -MF %DEPBASE%.Tpo 
> %-c% -o %OBJ% %SOURCE% && \
>  ?GENERIC??SUBDIROBJ? depbase=`echo %OBJ% | sed 
> 's|[^/]*$$|$(DEPDIR)/&|;s|\.o$$||'`;\
>  ?GENERIC??SUBDIROBJ? %COMPILE% -MT %OBJ% -MD -MP -MF %DEPBASE%.Tpo %-c% -o 
> %OBJ% %SOURCE% &&\
>   mv -f %DEPBASE%.Tpo %DEPBASE%.Po
[...]

Thanks for the patch.  Could you please show what it is supposed to fix?

Cheers,
Ralf

Re: [PATCH] Should use backslashes in depend2.am

[Ralf Wildenhues]

* Jan Engelhardt wrote on Sun, Oct 21, 2007 at 09:13:43PM CEST:
> On Oct 21 2007 21:01, Ralf Wildenhues wrote:
> >* Jan Engelhardt wrote on Sun, Oct 21, 2007 at 08:53:40PM CEST:
> >> 
> >>  ?!GENERIC?%COMPILE% -MT %OBJ% -MD -MP -MF %DEPBASE%.Tpo %-c% -o 
> >> %OBJ% `test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE%
> >> -?GENERIC??!SUBDIROBJ? %COMPILE% -MT %OBJ% -MD -MP -MF %DEPBASE%.Tpo 
> >> %-c% -o %OBJ% %SOURCE%
> >> +?GENERIC??!SUBDIROBJ? %COMPILE% -MT %OBJ% -MD -MP -MF %DEPBASE%.Tpo 
> >> %-c% -o %OBJ% %SOURCE% && \
> >>  ?GENERIC??SUBDIROBJ?  depbase=`echo %OBJ% | sed 
> >> 's|[^/]*$$|$(DEPDIR)/&|;s|\.o$$||'`;\
> >>  ?GENERIC??SUBDIROBJ?  %COMPILE% -MT %OBJ% -MD -MP -MF %DEPBASE%.Tpo 
> >> %-c% -o %OBJ% %SOURCE% &&\
> >>mv -f %DEPBASE%.Tpo %DEPBASE%.Po
> >[...]
> >
> >Thanks for the patch.  Could you please show what it is supposed to fix?
> 
> My "don't be so verbose" patch (now posix compliant as it seems to
> have turned out) - where the full command needs to be (read: should
> be, preferably, but not striclty necessary) on one line, as @echo is
> used.

Hmm, can't you just push that onto your patch?  The way the code is
written now it saves one shell invocation per compilation, which is
a nice speedup for gcc users.  GNU make implements this optimization:
in case the rule command does not contain shell active characters,
it execs the compiler right away instead of `sh -c ...'.

> Since ?SUBDIROBJ? uses &&\ I thought it would not hurt too much to also
> use it in the ?!SUBDIROBJ? case.

Well, in the ?SUBDIROBJ? case there is a shell command substitution
`cmd`, so in that case the shell will be invoked anyway.

Cheers,
Ralf

Re: [BUG] automake 1.9 failure to build

[Ralf Wildenhues]

Hello, and thanks for the bug report.

* Technomage-hawke wrote on Fri, Nov 02, 2007 at 05:32:13AM CET:
[...]
> X-1:~/build/automake-1.9 root# export DYLD_LIBRARY_PATH=/opt/local/lib
> X-1:~/build/automake-1.9 root# export LIBDIR=/opt/local/lib
> X-1:~/build/automake-1.9 root# ./configure --prefix=/opt/local
> checking build system type... i686-apple-darwin8.4.1
[...]
> FAIL: exdir2.test
[...]
> FAIL: man2.test
[...]
> FAIL: transform.test
[...]
> =
> 3 of 526 tests failed
> (22 tests were not run)

You can look at the verbose output of these tests like this:
  cd ~/build/automake-1.9/tests
  make check VERBOSE=yes TESTS='exdir2.test man2.test transform.test'

But I bet that the issue is that you have a new Autoconf (2.60 or newer)
but this old Automake.  1.9 is more than three years old, the current
version is 1.10.  If my guess is true, no need to show any error output,
just update your Automake version occasionally.

Please also note that you are not required to build Automake as root,
and would suggest against doing so, in general.  It's sufficient to do
the `make install' step with privileges.

Cheers,
Ralf

Re: Workarounds for "automake does not support info_TEXINFOS being defined conditionally"

[Ralf Wildenhues]

Hello Brooks,

* Brooks Moses wrote on Tue, Nov 06, 2007 at 11:19:21PM CET:
>
> This resulted in the error quoted in the subject line, "automake does not 
> support info_TEXINFOS being defined conditionally", followed by an Internal 
> Error.

Hmm, something got stuck there:

Paolo, do you have time to look at this?

> (Incidentally, would it be possible to have automake just quit 
> after the first error?  I nearly missed it hiding before all the noise of 
> the Internal Error!)

AFAICS it quits after the first internal error.  Fixing
ICE-after-invalid issues in automake is low on my priority list, sorry.

> Is there a workaround or other solution to do what I want?  I tried 
> defining an INFOFILES variable in the conditional, and using an 
> unconditional info_TEXINFOS=$(INFOFILES), but that didn't do what I 
> expected either -- it sets PDFS to bdf.pdf unconditionally in Makefile.in.

Well, I'd prefer to just fix conditional texinfos in HEAD so you can use
that.

Cheers,
Rafl

Re: Workarounds for "automake does not support info_TEXINFOS being defined conditionally"

[Ralf Wildenhues]

* Paolo Bonzini wrote on Thu, Nov 08, 2007 at 09:52:30AM CET:
> Ralf Wildenhues wrote:
>> * Brooks Moses wrote on Tue, Nov 06, 2007 at 11:19:21PM CET:
>>> This resulted in the error quoted in the subject line, "automake does not 
>>> support info_TEXINFOS being defined conditionally", followed by an 
>>> Internal Error.
>>
>> Hmm, something got stuck there:
>> <http://thread.gmane.org/gmane.comp.sysutils.automake.patches/2731/focus=2757>
>> Paolo, do you have time to look at this?
>
> Not soonish, but I will.  On the other hand, did you look into improving 
> portability of my patch for faster autotest? :-)

Not yet, but I will.  It's not fixing a serious bug though, "only"
optimization, so it's less high priority.  ;-)

Cheers,
Ralf

Re: failure in "colorful tests"

[Ralf Wildenhues]

Hi Bob,

* Bob Proulx wrote on Mon, Nov 12, 2007 at 11:44:42PM CET:
> This following automake 'make check' finishes successfully.
> 
>   env TERM=ansi make -C tests check TESTS=color.test
> 
> However this next one has a failure.
> 
>   env TERM=dumb make -C tests check TESTS=color.test
> 
> And this one is quite colorful! :-)
> 
>   env TERM=dumb VERBOSE=yes make -C tests check TESTS=color.test

Thanks!  Do we need to guard against other TERM settings, too?

Cheers,
Ralf

   * tests/color.test: Skip if TERM is `dumb'.
   Report by Bob Proulx.

diff --git a/tests/color.test b/tests/color.test
index d30d1e0..b2deb23 100755
--- a/tests/color.test
+++ b/tests/color.test
@@ -22,6 +22,10 @@
 
 . ./defs || exit 1
 
+case $TERM in
+dumb) exit 77;;
+esac
+
 set -e
 
 red=''

Re: Missing *-local hooking

[Ralf Wildenhues]

Hi Akim,

* Akim Demaille wrote on Mon, Nov 19, 2007 at 03:25:51PM CET:
> Automake does not notice the use of *-local targets
> when defined together:

Go ahead if you'd like to commit this as a currently-XFAILing test,
but even better if you fix it.  :-)

See this comment in automake.in:file_contents_internal:

# FIXME: 1. We are not robust to people defining several targets
# at once, only some of them being in %dependencies.  The
# actions from the targets in %dependencies are usually generated
# from the content of %actions, but if some targets in $targets
# are not in %dependencies the ELSE branch will output
# a rule for all $targets (i.e. the targets which are both
# in %dependencies and $targets will have two rules).

# FIXME: 2. The logic here is not able to output a
# multi-paragraph rule several time (e.g. for each condition
# it is defined for) because it only knows the first paragraph.

# FIXME: 3. We are not robust to people defining a subset
# of a previously defined "multiple-target" rule.  E.g.
# `foo:' after `foo bar:'.

[...]
| +echo "$targets:" | sed -e 's/[ :]/-local\&/g' > Makefile.am

However, you need to lose the \ before the &.

Cheers,
Ralf

Re: compile failure (was: (no subject))

[Ralf Wildenhues]

Hello Novella,

* [EMAIL PROTECTED] wrote on Fri, Nov 23, 2007 at 05:48:13PM CET:
> I am trying to compile oSIP library on Debian system but I have 
> encountered any problems.
> 
> When I type make, the make fails with some 
> error message like these:
> 
> make[3]: Entering directory 
> `/home/debian/project_server/libosip/src/osipparser2 '

Is there really a space in the output after "osipparser2" and before the
single quote?

> Makefile:325: .deps/osip_accept.Plo: No such file or directory
[...]
> Makefile:362: .deps/sdp_message.Plo: No such file or directory
> make[3]: *** No rule to make target `.deps/sdp_message.Plo'.  Stop.
> make[3]: Leaving directory 
> `/home/debian/project_server/libosip/src/osipparser2'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/home/debian/project_server/libosip/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/debian/project_server/libosip'
> make: *** [all] Error 2

Hmm.  What does 
  ./config.status && make

output?  In case there is a separate config.status file in the
libosip/src/osipparser2 subdirectory, "cd" into that first and run
  ./config.status

there (and post that output, too).  There should be something about
depfiles in the output.  Please show how you invoked configure, too.

Cheers,
Ralf

Re: not hardwiring gpg

[Ralf Wildenhues]

* Jim Meyering wrote on Tue, Dec 18, 2007 at 04:51:33PM CET:
> Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> >
> > I don't object, but your change would do good with a small explanation
> > to refute Gary's argument for the commit in Automake that added the full
> > name in the first place, <5176801c82cc0ea98b344260b4accf4cab08a0e3>, see
> > <http://thread.gmane.org/gmane.comp.gnu.libtool.patches/1533/focus=1546>.
> 
> If the hypothetical cracker ever gets in to my (or any developer's) system
> with sufficient privilege to modify the contents of directories in my PATH
> (or change my PATH altogether), they can already compromise my development
> work in so many ways that using such absolute names in gnupload
> gives reduced functionality with no added security.
> 
> I thought this was common knowledge, along with the "don't hard-code
> file names" dictum, but if you still think it's worth a comment in
> the code, I'll add one.

I know the reasoning and approve of it; my point is that, whenever you
explicitly undo an earlier change, then you note that you do it *on
purpose*, either in the ChangeLog entry or the git commit entry, so that
the next person looking at the history will not have to do guesswork.
This applies pretty much regardless of the obviousness of the actual
change.

So, please commit, and e.g., put the first paragraph of your reply in
the log.

Thanks,
Ralf

Re: RFE: make automake's output deterministic

[Ralf Wildenhues]

Hello Bruno,

Thanks for the bug report, and a Happy New Year.

* Bruno Haible wrote on Wed, Dec 26, 2007 at 03:43:40PM CET:
> 
> When automake is installing files, it does so in a non-deterministic order.
> For example, in the same situation, sometimes "automake -a" outputs
> 
> configure.in:5: installing `./config.sub'
> configure.in:3: installing `./install-sh'
> configure.in:3: installing `./missing'
> configure.in:5: installing `./config.guess'
> 
> and sometimes it outputs
> 
> configure.in:5: installing `./config.guess'
> configure.in:3: installing `./install-sh'
> configure.in:3: installing `./missing'
> configure.in:5: installing `./config.sub'
[...]

> Can automake be made to use a deterministic hash table or sort the list of
> files before processing it?

The patch below should do the trick, I think.  It would be nice to have
a test to expose this to go along with this change if possible.  Can you
provide a recipe to reproduce the ordering change?

I guess it depends on the order the traces are read from the autom4te
cache, which in turn might depend on the order in which autotools have
been called and whether called by autoreconf.  However, in a couple of
casual tests I can't expose this here.  Which M4 and Autoconf versions
do you use?

FWIW, the patch should go into branch-1-10, too.

Thanks,
Ralf

2008-01-02  Ralf Wildenhues  <[EMAIL PROTECTED]>

* automake.in (scan_autoconf_files): Sort loop over
%required_aux_file, for stable verbose output.
Report by Bruno Haible.

diff --git a/automake.in b/automake.in
index 3720769..a3d56a0 100755
--- a/automake.in
+++ b/automake.in
@@ -5146,8 +5146,9 @@ sub scan_autoconf_files ()
   # check must be done for every run, even those where we are only
   # looking at a subdir Makefile.  We must set relative_dir for
   # maybe_push_required_file to work.
+  # Sort the files for stable verbose output.
   $relative_dir = '.';
-  foreach my $file (keys %required_aux_file)
+  foreach my $file (sort keys %required_aux_file)
 {
   require_conf_file ($required_aux_file{$file}->get, FOREIGN, $file)
 }

Re: My code got autolicensed...

[Ralf Wildenhues]

Hello Polarina,

* Polarina wrote on Wed, Jan 02, 2008 at 08:35:26PM CET:
> The automake and friends automatically licensed my code with GPLv2 (They
> added the COPYING file with that license) when I wanted GPLv3. What
> gives? I'm using version 1.10.
> $ automake --add-missing --copy

The next Automake release will, in the same situation, install GPLv3 by
default.  Until that is available, you can just grab the GPLv3 text
here:  and put that in COPYING.
Further reruns of the above command will not modify an existing COPYING
file.

If you would like automake to avoid messing with COPYING at all, use the
`foreign' option or the --foreign argument; for automake options see
.

Hope that helps.

Cheers,
Ralf

Re: [PATCH] * tests/defs.in (required=GNUmake): Do not call $MAKE with -v.

[Ralf Wildenhues]

Hi Stepan,

Thanks for the patch.

* Stepan Kasal wrote on Fri, Dec 14, 2007 at 08:51:45PM CET:
> ---
> Hi,
>   I noticed the following detail.  Since we have to grep the output of
> make --version for GNU, we catch SGI make, I suppose.
> 
> So I think the special trick for SGI, which was in use before the
> commit 693c934 is no longer needed.
> 
> If you agree, please commit and push the following patch.

I agree with your analysis, but I don't think making the code a couple
of bytes shorter at the expense of making it more subtle and less
obvious is helpful.  Thus I am not applying this.

Cheers,
Ralf

> +2007-12-14  Stepan Kasal  <[EMAIL PROTECTED]>
> +
> + * tests/defs.in (required=GNUmake): Do not call $MAKE with -v.
> +
>  2007-12-08  Ralf Wildenhues  <[EMAIL PROTECTED]>
>  
>   * lib/Automake/FileUtils.pm (open_quote): New function.
> diff --git a/tests/defs.in b/tests/defs.in
> index a797a82..e8ebd3a 100644
> --- a/tests/defs.in
> +++ b/tests/defs.in
> @@ -119,11 +119,10 @@ do
>( etags --version -o /dev/null ) || exit 77
>;;
>  GNUmake)
> -  # Use --version AND -v, because SGI Make doesn't fail on --version.
> -  # Also grep for GNU because newer versions of FreeBSD make do
> -  # not complain about `--version' (they seem to silently ignore it).
> -  echo "$me: running $MAKE --version -v | grep GNU"
> -  ( $MAKE --version -v | grep GNU ) || exit 77
> +  # grep for GNU because newer versions of FreeBSD make do not
> +  # complain about `--version' (they seem to silently ignore it).
> +  echo "$me: running $MAKE --version | grep GNU"
> +  ( $MAKE --version | grep GNU ) || exit 77
>;;
>  gcc)
># When gcc is required, export `CC=gcc' so that ./configure

Re: acloca20 test intermittent failure

[Ralf Wildenhues]

[ http://lists.gnu.org/archive/html/bug-automake/2006-10/msg00026.html ]
[ http://lists.gnu.org/archive/html/bug-automake/2006-10/msg00036.html ]

Yeah, it's ancient... :-/

* Greg Schafer wrote on Tue, Oct 24, 2006 at 11:51:35PM CEST:
> On Tue, Oct 24, 2006 at 06:04:30PM +0200, Stepan Kasal wrote:
> 
> > I think I have found the bug now.
> 
> ...
> 
> > The fix is obvious: `autom4te' should always create the output file,
> > if --force was given.  Patch attached.
> > I committed it to the Autoconf CVS.
> > 
> > Greg, if you are willing to test the fix, then please build and
> > install CVS Autoconf or apply the patch to autoconf-2.60 and build
> > and install it.  Then apply Ralf's patch to acloca20.test (--force).
> > Then the test should pass.
> 
> Indeed it does! No failures at all now :-)

I have applied the patch from
.

Cheers,
Ralf

Re: some automake-1.10 tests fail because of lacking go=x permissions

[Ralf Wildenhues]

Hello Arto,

* [EMAIL PROTECTED] wrote on Tue, May 08, 2007 at 05:46:27PM CEST:
> 
> When unpacking the automake-1.10 tarball by a different user
> (e.g. root, with 'tar xpf -' ) and then building and running
> 'make check' from a different object directory, some tests
> fail because of missing execute permissions:
> 
> /bin/ksh[9]: /build/automake-1.10/tests/cond33.test: cannot execute
> 
> This is because some *.test files have permission rwxr--r--
> instead of rwxr-xr-x.
[...]

Thanks for the bug report, and apologies for the long delay.
I am applying this to master and branch-1-10 (and putting you
in THANKS), so that we don't have to remember doing the change
by hand.

Cheers,
Ralf

2008-01-08  Ralf Wildenhues  <[EMAIL PROTECTED]>

* Makefile.am (dist-hook): New, ensure world-executable tests.
* THANKS: Update.
Report by Arto C. Nirkko.

diff --git a/Makefile.am b/Makefile.am
index bb069df..6a370cf 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,7 +3,7 @@
 ## Makefile for Automake.
 
 ## Copyright (C) 1995, 1996, 1997, 1998, 1999, 2001, 2002, 2003, 2004,
-## 2005, 2006, 2007  Free Software Foundation, Inc.
+## 2005, 2006, 2007, 2008  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
@@ -101,6 +101,10 @@ INSTALL: lib/INSTALL
 ## to anybody else
 ##
 
+# Ensure tests are world-executable
+dist-hook:
+   cd $(distdir)/tests && chmod a+rx *.test
+
 # Some simple checks, and then ordinary check.  These are only really
 # guaranteed to work on my machine.
 maintainer-check: automake aclocal

Re: `automake -a -c -f` wrongly updates the INSTALL file

[Ralf Wildenhues]

Hello Mike,

* Mike Frysinger wrote on Wed, Jan 02, 2008 at 10:44:12PM CET:
> On Thursday 28 September 2006, Mike Frysinger wrote:
> > i normally use automake-1.9.6 but i just tried out 1.9b and it appears to
> > have the same problem
> 
> automake-1.10 exhibits the problem as well ... finally spent some time 
> digging 
> at it for fun
> 
> > $ svn st INSTALL
> > $ automake-1.9b -a -c
> > $ svn st INSTALL
> > $ automake-1.9b -a -f
> > $ svn st INSTALL

That doesn't happen for me.  After `-a -f', the file is replaced with
the symlink pointing to the installed INSTALL file.

With --foreign, however, that doesn't happen.  Neither with -a -f, nor
with -a -c -f.

> > $ automake-1.9b -a -c -f
> > $ svn st INSTALL
> > M  INSTALL
> > $ svn diff INSTALL
> > ...
> > -HOMEPAGE:http://freestdf.sourceforge.net/liblzw.php
> > -AUTHOR:  Mike Frysinger <[EMAIL PROTECTED]>
> > +Installation Instructions
> > +*
> > ...

While I understand that you don't want this change to happen, I'm not
sure what would be the desirable or intended semantics.  After all, `-a
-f' replaces all files except COPYING.  If we change semantics, at least
the new ones should be documented, I think.

Cheers,
Ralf

Re: TEXINFO_TEX and not-recursive Makefiles.am

[Ralf Wildenhues]

* Roumen Petrov wrote on Fri, Jan 11, 2008 at 09:08:47PM CET:
> Fine with me.

Thanks, pushed.

Cheers,
Ralf

Re: Automake and libtool

[Ralf Wildenhues]

Hello Dilyan,

* Dilyan Palauzov wrote on Sat, Jan 12, 2008 at 08:00:55PM CET:
> 
>Libtool always creates .libs - directory, and uses it for temporary 
> files, but Automake generates makefiles, that on make clean, clean .libs 
> only if there were libraries compiled within that directory. So `make 
> clean` does not clean all directories created by libtool at compile-time.

Thank you for the bug report.  I believe I fixed that with the patches
applied to the branches master and branch-1-10 on 2007-08-16.  So in
1.10.1 that should be fixed:

| * automake.in (handle_programs): Also clean .libs/_libs
| directory for _PROGRAMS.
| * tests/libtoo10.test: New test.
| * tests/Makefile.am: Update.
| * THANKS: Update.
| Report by Guillermo Ontañón.

You can work-around it by something like this in your Makefile.am:

clean-local:
-rm -rf .libs _libs

Cheers,
Ralf

Re: 334-gary-remove-libtool-dvi.patch

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Fri, Jan 18, 2008 at 10:43:30AM CET:
> [[FYI: bug-automake]]

I consider this a texinfo bug, sorry for not pointing out earlier:

Please apply, but don't blame Automake in the patch.

Thanks,
Ralf

>   from  Gary V. Vaughan  <[EMAIL PROTECTED]>
>
>   * Makefile.am (DISTCLEANFILES): Remove libtool.dvi generated
>   by 'make dvi'.

Re: make dist fails for directories with spaces in their name

[Ralf Wildenhues]

Hello Paul,

* Paul Brannan wrote on Sun, Jan 20, 2008 at 03:24:20PM CET:
> I'm using automake 1.10 on cygwin where my home directory is "/home/Paul 
> Brannan".  I have a project located in my home directory which uses 
> automake.

Building in a directory with spaces is not supported.  That said, in the
current git master version (what will eventually be 1.11, not 1.10.1),
I fixed most but not all issued with spaces in the build directory name.

> Two changes are necessary to fix the problem:
> 
> - $distdir must be quoted whenever it is used
> - The $(MKDIR_P) line in the distdir rule that creates the dist 
> directory must be quoted as well.

These have been fixed.

Cheers,
Ralf

Re: automake results on OpenBSD 4.0

[Ralf Wildenhues]

Hi Eric,

* Eric Blake wrote on Wed, Jan 23, 2008 at 06:26:20AM CET:
> According to Eric Blake on 1/22/2008 10:22 PM:
> | FAIL: color.test
> | =
> | 1 of 526 tests failed
> | (95 tests were not run)
> | Please report to bug-automake@gnu.org
> | =
> |
> | I suspect this is because 'which expect' claims that expect is not
> | installed, in which case the test should be skipped rather than failed.
> 
> This was on the master branch, not 1.10.1 (which doesn't have color
> support), tested on OpenBSD 4.0.

Can you post output of the following please?
  cd tests && TESTS=color.test VERBOSE=yes make -e check

Thank you,
Ralf

Re: automake results on OpenBSD 4.0

[Ralf Wildenhues]

Hi Eric,

* Eric Blake wrote on Wed, Jan 23, 2008 at 06:34:10PM CET:
>
> I'm not sure if grep -a is portable (POSIX doesn't require it),

AIX grep has no -a.

> so is the following patch appropriate (and should we also mention
> this in the autoconf manual)?

FWIW, as a general (hand-waving) rule, I would rather use POSIX as base
from which to document deviations, than BSD or GNU features.  That way
the Autoconf manual doesn't end up documenting all extensions as such.

> and if I were to install expect, I assume the entire test would pass.

Yes, I expect that, too (sorry for the pun).

> Eric Blake  byu.net> writes:
> > 
> > +# Check that grep can parse nonprinting characters
> > +# BSD grep can do so from a pipe, but not a file.
> 
> Maybe we should also add a line:
> +# BSD 'grep -a' does just fine from files, but 'grep -a' is not portable.

Why not, and yes, please apply the patch with this.  Thanks for the
report and analysis; confirmed, BTW.

> > -  grep ": pass" stdout | $FGREP "$grn"
> > +  cat stdout | grep ": pass" | $FGREP "$grn"
> 
> Wow - I wrote something that superficially looks like a useless use of
> cat, but which actually changes the test outcome.

If you want to add a note about that, too, feel free to.

Cheers,
Ralf

Re: automake-1.10.1: instsh2.test fails when run as root

[Ralf Wildenhues]

Hello Theodoros,

* Theodoros V. Kalamatianos wrote on Thu, Jan 24, 2008 at 06:26:03PM CET:
> 
> as the subject suggests, the instsh2.test from automake-1.10.1 fails when 
> run as root. The culprit is circa line 96:

> test ! -w d1/file
> 
> which will fail when run as root (at least on Linux). Perhaps this should 
> be moved to an additional test to be executed with required='non-root' ?

Indeed.  Thanks for the bug report.  I've applied this patch to master
and branch-1-10, and put you in THANKS.

Cheers,
Ralf

Split instsh2.test, so that only the new part requires non-root.

* tests/instsh2.test: Split off testing of `install-sh -C' ...
* tests/instsh3.test: ... to this new test, requiring non-root.
* tests/Makefile.am: Adjust.
* THANKS: Update.
Report by Theodoros V. Kalamatianos.

diff --git a/tests/Makefile.am b/tests/Makefile.am
index ec10801..8405c7a 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -293,6 +293,7 @@ install2.test \
 installdir.test \
 instsh.test \
 instsh2.test \
+instsh3.test \
 instdat.test \
 instdat2.test \
 instexec.test \
diff --git a/tests/instsh2.test b/tests/instsh2.test
index 17b61ab..f0b729e 100755
--- a/tests/instsh2.test
+++ b/tests/instsh2.test
@@ -1,5 +1,5 @@
 #! /bin/sh
-# Copyright (C) 2002, 2004, 2006  Free Software Foundation, Inc.
+# Copyright (C) 2002, 2004, 2006, 2008  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
@@ -77,20 +77,6 @@ test -f d3/y
 ./install-sh -T x d3 && exit 1
 ./install-sh -T x d4// && exit 1
 
-# Do not change the timestamps when using -C.
-echo foo >file
-./install-sh -C file d1
-TZ=UTC0 touch -t $old_timestamp d1/file
-./install-sh -C file d1
-is_newest file d1/file
-echo foo1 >file
-./install-sh -C file d1
-diff file d1/file
-# Rights must be updated.
-./install-sh -C -m 444 file d1
-test -r d1/file
-test ! -w d1/file
-
 # Ensure that install-sh works with names that include spaces
 touch 'a  b'
 mkdir 'x  y'
diff --git a/tests/instsh3.test b/tests/instsh3.test
new file mode 100755
index 000..95b74c7
--- /dev/null
+++ b/tests/instsh3.test
@@ -0,0 +1,37 @@
+#! /bin/sh
+# Copyright (C) 2006, 2008  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 3, 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 .
+
+# More install-sh checks: check -C.
+
+required=non-root
+. ./defs || exit 1
+set -e
+
+./install-sh -d d1
+
+# Do not change the timestamps when using -C.
+echo foo >file
+./install-sh -C file d1
+TZ=UTC0 touch -t $old_timestamp d1/file
+./install-sh -C file d1
+is_newest file d1/file
+echo foo1 >file
+./install-sh -C file d1
+diff file d1/file
+# Rights must be updated.
+./install-sh -C -m 444 file d1
+test -r d1/file
+test ! -w d1/file

Re: Logic-o in automake manual

[Ralf Wildenhues]

Hello Reuben,

* Reuben Thomas wrote on Mon, Feb 04, 2008 at 12:50:45PM CET:
> You mean "appear newer", not "appear older", as "configure.ac" is 
> lexically after "configure". If configure.ac "appeared older" than 
> configure, then configure would not be rebuilt, spuriously or otherwise.
>
> By the way, "alphabetical order" should be "lexical order".

Thanks for the report.  Patched as follows, master and branch-1-10.

Cheers,
Ralf

2008-02-05  Reuben Thomas  <[EMAIL PROTECTED]>

* doc/automake.texi (CVS): configure.ac will appear newer, not
older, than configure.  Use `lexical' instead of `alphabetical'.

diff --git a/doc/automake.texi b/doc/automake.texi
index 9d311be..c0ace40 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -9636,8 +9636,8 @@ update, not the original timestamp of this revision.  
This is meant to
 make sure that @command{make} notices sources files have been updated.
 
 This timestamp shift is troublesome when both sources and generated
-files are kept under [EMAIL PROTECTED]  Because CVS processes files in 
alphabetical
-order, @file{configure.ac} will appear older than @file{configure}
+files are kept under [EMAIL PROTECTED]  Because CVS processes files in lexical
+order, @file{configure.ac} will appear newer than @file{configure}
 after a @command{cvs update} that updates both files, even if
 @file{configure} was newer than @file{configure.ac} when it was
 checked in.  Calling @command{make} will then trigger a spurious rebuild

Re: aclocal.m4 not regenerated when Makefile.am changes

[Ralf Wildenhues]

Hello Colin,

* Colin Watson wrote on Sun, Feb 17, 2008 at 04:23:32PM CET:
> In a fresh unpacked copy of
> http://download.savannah.nongnu.org/releases/man-db/man-db-2.5.1.tar.gz:
> 
>   $ touch Makefile.am
>   $ ./configure
>   $ make
>   configure.ac:7: version mismatch.  This is Automake 1.10.1,
>   configure.ac:7: but the definition used by this AM_INIT_AUTOMAKE
>   configure.ac:7: comes from Automake 1.10.  You should recreate
>   configure.ac:7: aclocal.m4 with aclocal and run automake again.
>   WARNING: `automake-1.10' is probably too old.  You should only need it if
>you modified `Makefile.am', `acinclude.m4' or `configure.ac'.
>You might want to install the `Automake' and `Perl' packages.
>Grab them from any GNU archive site.
> 
> Of course, I have upgraded automake on my system to 1.10.1 since
> producing that tarball. But why didn't the rebuild rules just run
> aclocal for me? This seems as simple as adding Makefile.am to the
> dependencies of $(ACLOCAL_M4).

But normally, aclocal.m4 does not need to be regenerated when
Makefile.am is updated.  What you would really need in your case is a
dependency of aclocal.m4 on /usr/bin/aclocal-1.10.

Since we don't have dependencies on installed packages, pragmatically
the best thing to do when you update system tools is to run autoreconf.

> If nothing else, Makefile.am may contain ACLOCAL_AMFLAGS (and in fact
> does in this case), so IMO correct rebuild rules should re-run aclocal
> in case those flags changed;

Good point.  I don't know how to formulate this without making a blanket
dependency on Makefile.am, though; and that would, for the vast majority
of use cases, be much more work than is normally needed.  Users would
complain about this.

> although in order to get that completely
> right it also ought to fish ACLOCAL_AMFLAGS out of Makefile.am à la
> autoreconf ...

This does happen though, when the aclocal rule is executes: it has
$(ACLOCAL) $(ACLOCAL_AMFLAGS)

Hope that helps.

Cheers,
Ralf

Re: 'nonemtpy' typo in lib/am/tags.am

[Ralf Wildenhues]

Hi Colin,

* Colin Watson wrote on Sun, Feb 17, 2008 at 05:58:58PM CET:
> The attached patch fixes a typo I happened to notice while upgrading
> man-db to Automake 1.10.1.

Thanks!  Applied like this, master and branch-1-10.

Cheers,
Ralf

2008-02-17  Colin Watson  <[EMAIL PROTECTED]>  (tiny change)

* lib/am/tags.am (ID): Fix typo in workaround for old awk.

diff --git a/lib/am/tags.am b/lib/am/tags.am
index 5383e0d..d279b19 100644
--- a/lib/am/tags.am
+++ b/lib/am/tags.am
@@ -26,7 +26,7 @@ ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
 ## Handle VPATH correctly.
if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
  done | \
- $(AWK) '{ files[$$0] = 1; nonemtpy = 1; } \
+ $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
  END { if (nonempty) { for (i in files) print i; }; }'`; \
mkid -fID $$unique
 

Re: Problems building coreutils HEAD against gnulib HEAD

[Ralf Wildenhues]

Hello,

* Eric Blake wrote on Tue, Feb 19, 2008 at 02:28:35PM CET:
> [adding bug-automake]
>
> According to Jim Meyering on 2/19/2008 4:33 AM:
> |> But I am, having seen it myself.  It happens when you have a stale symlink
> |> from an older copy of gnulib, but which now points nowhere because the
> |> file was renamed in gnulib.
> |
> | It's annoying.  Didn't someone (you, Eric?) post an automake
> | patch to generate Makefile rules that would avoid this?
>
> You are thinking about this patch of Ralf's:
> http://git.sv.gnu.org/gitweb/?p=automake.git;a=commitdiff;h=d0ebf71
>
> I'm not sure if that was ported back to the 1.10 branch.  But it looks
> like that patch only handles the make rules for rerunning aclocal, and
> will not impact the ./bootstrap rules for running aclocal afresh when
> there are broken symlinks matching *.m4 in the included directories.
> Maybe one more automake patch is needed, to avoid warning on broken
> symlink source files

I don't think aclocal should silenctly ignore stale symlinks.  I can't
imagine a situation in which I wouldn't call stale symlinks a bug in
another program, or a mistakenly broken tree.

> if the resulting aclocal still manages to provide
> every needed macro?

Well, aclocal cannot easily detect whether you intended for that local
pkg/gnulib/m4/foo.m4 macro to override that installed
/usr/share/aclocal/foo.m4 macro file or not.  I prefer if such issues do
not go silent in any cases we can avoid.

>  Meanwhile, I still think coreutils' bootstrap should
> delete these broken symlinks before trying to run aclocal.

I think that's just the proper solution to this issue.  And with
Automake master, it should also not cause hickups any more.

Cheers,
Ralf

Re: Tidy-up of node "Why doesn't automake support wildcards?"

[Ralf Wildenhues]

Hello Reuben,

* Reuben Thomas wrote on Mon, Feb 25, 2008 at 05:40:50PM CET:
> I attach a diff against current git. It fixes the following problems:

Thanks for the patch.

> 1. The English is a bit ropey in places.
>
> 2. @file was used once where @emph was needed.
>
> 3. The point in the itemized list starting "Listing files" is redudant, 
> it's just a restatement of the previous two points.

While I agree that there is partial redundancy here, IMVHO the other
items by themselves do not make it clear enough that 'make dist' will
complain about missing files.

> @@ -9860,24 +9860,18 @@ you remember to @samp{cvs add} it.
>  @item
>  Using wildcards makes easy to distribute files by mistake.  For

There is an 'it' missing before 'easy', no?

>  instance, some code a developer is experimenting with (a test case,
> -say) but that should not be part of the distribution.
> +say) that should not be part of the distribution.

> [EMAIL PROTECTED]
> -Finally it's really hard to @file{forget} adding a file to
> [EMAIL PROTECTED], because if you don't add it, it doesn't get
> +Finally, it's really hard to @emph{forget} to add a file to
> [EMAIL PROTECTED], because if you don't add it it is neither

I prefer if that comma remains in there, both because I think it is
justified by the grammar, and because otherwise the sentence is more
difficult to read.

>  compiled nor installed, so you can't even test it.
>  @end itemize

Can you be bothered to resubmit the patch with these items and the one
Tim found addressed, to the automake-patches list, including a ChangeLog
entry?

Thanks,
Ralf

Re: Tidy-up of node "Why doesn't automake support wildcards?"

[Ralf Wildenhues]

* Reuben Thomas wrote on Wed, Feb 27, 2008 at 12:22:30AM CET:
> On Tue, 26 Feb 2008, Ralf Wildenhues wrote:
>
>>> [EMAIL PROTECTED]
>>> -Finally it's really hard to @file{forget} adding a file to
>>> [EMAIL PROTECTED], because if you don't add it, it doesn't get
>>> +Finally, it's really hard to @emph{forget} to add a file to
>>> [EMAIL PROTECTED], because if you don't add it it is neither
>>
>> I prefer if that comma remains in there, both because I think it is
>> justified by the grammar,
>
> Only if you add another after "because".

Fine with me.

> (I'll work up a patch+ChangeLog once you're happy.)

Feel free to.  :-)

Cheers,
Ralf

Re: Please report to bug-automake@gnu.org

[Ralf Wildenhues]

Hi Younes,

* Younes Younes wrote on Fri, Feb 29, 2008 at 10:48:06AM CET:
> =
> 1 of 540 tests failed
> (74 tests were not run)
> Please report to bug-automake@gnu.org
> =

Thanks for the report.  Can you look at the output before that to find out
which test failed?  Say its name was foo.test, can you then post the
output of
  cd tests
  env TESTS=foo.test VERBOSE=yes make -e check

please?

Thanks,
Ralf

instsh2.test failure on Solaris (was: Please report to bug-automake@gnu.org)

[Ralf Wildenhues]

Hello Younes,

* Younes Younes wrote on Mon, Mar 03, 2008 at 11:21:29AM CET:
>
> the test file is instsh2.test
>
> hier is the report

Thanks.

[...]
> /home/younes/built/automake-1.10.1/tests:/usr/local/bin:/usr/ccs/bin:/usr/ucb:/usr/bin:/usr/sfw/bin:/opt/csw/bin:/usr/openwin/bin:/usr/lang/bin:/opt/csw/php5/bin:/home/ini/younes/bin
>  

Ah, ok.  I suppose this test was run on Solaris, and you have /usr/ucb
early in $PATH.  'touch -t' is POSIX, but not understood by
/usr/ucb/touch, so for that to work, /usr/bin should come before
/usr/ucb.

> === Running test ./instsh2.test
> + pwd /home/younes/built/automake-1.10.1/tests/testSubDir
[...]
> + echo foo + ./install-sh -C file d1 + touch -t 198309271735.59 d1/file  
> TZ=UTC0
> usage: touch [-amcf] file ...
> FAIL: instsh2.test

I'm applying this to master and branch-1-10 (the instsh2.test has since
been split up, and the parts your failure is dealing with are in
instsh3.test now), and putting you in THANKS.

Cheers,
Ralf

Skip instsh3.test if `touch -t' does not work.

* tests/instsh3.test: Test for `touch -t', fails with Solaris
/usr/ucb/touch.
* THANKS: Update.
Report by Younes Younes.

diff --git a/tests/instsh3.test b/tests/instsh3.test
index 95b74c7..4ed67b9 100755
--- a/tests/instsh3.test
+++ b/tests/instsh3.test
@@ -20,6 +20,9 @@ required=non-root
 . ./defs || exit 1
 set -e
 
+# Solaris /usr/ucb/touch does not accept -t.
+touch -t $old_timestamp foo || exit 77
+
 ./install-sh -d d1
 
 # Do not change the timestamps when using -C.

Re: automake-1.10.1 : 2 of 547 tests failed

[Ralf Wildenhues]

Hello Dennis,

* Dennis Clarke wrote on Mon, Mar 10, 2008 at 07:31:10PM CET:
> 
> $ uname -a
> Linux vesta 2.6.19-rc6 PREEMPT Mon Nov 27 20:48:16 CET 2006 ppc GNU/Linux

> FAIL: cond35.test
> FAIL: lex3.test

> =
> 2 of 547 tests failed
> (67 tests were not run)
> Please report to bug-automake@gnu.org
> =

Thanks for the report.  Please post the output of
  cd tests
  make check VERBOSE=yes TESTS="cond35.test lex3.test"

as well as the versions of flex, bison, gcc, and make you're using.

Thanks,
Ralf

Re: RFE: support per-program noinst_HEADERS

[Ralf Wildenhues]

Hi Chris,

* Chris Pickett wrote on Wed, Mar 12, 2008 at 07:50:46PM CET:
>
> I would like to be able to use noinst_prog_HEADERS, but with 1.10.1 I  
> get a complaint about noinst_progdir not being defined:

You can just put all your not-to-be installed headers into the *_SOURCES
alongside the .c/.cc/... files.  *_HEADERS really is necessary only for
headers that are to be installed.

Cheers,
Ralf

Re: RFE: support per-program noinst_HEADERS

[Ralf Wildenhues]

* Chris Pickett wrote on Wed, Mar 12, 2008 at 08:10:41PM CET:
> Ralf Wildenhues wrote:
>> * Chris Pickett wrote on Wed, Mar 12, 2008 at 07:50:46PM CET:
>>> I would like to be able to use noinst_prog_HEADERS, but with 1.10.1 I 
>>>  get a complaint about noinst_progdir not being defined:
>>
>> You can just put all your not-to-be installed headers into the *_SOURCES
>> alongside the .c/.cc/... files.  *_HEADERS really is necessary only for
>> headers that are to be installed.
>
> That doesn't work for me.  I am #include'ing .c files, and I do not want  
> objects built for them.  This works fine with noinst_HEADERS for a  
> single library or program:

So why not this?

noinst_HEADERS =
if PROG1
noinst_HEADERS += ...
else
noinst_HEADERS += ...
endif

if PROG2
noinst_HEADERS += ...
endif

Really adding files to noinst_HEADERS isn't much different from just
adding them to EXTRA_DIST.

I agree that the warning 

>>> `noinst_prog_HEADERS' is used but `noinst_progdir' is undefined

is weird.  I'm mostly arguing to avoid having to do the work of fixing
the warning.  ;-)

> I did play with other methods, like adding the objects to prog_LDADD,  
> but I couldn't get them to work.

prog_LDADD is for adding stuff to the link of the program.

> P.S.  I also did get this to work using prog_DEPENDENCIES, but the  
> manual warns that it is not for source code.

prog_DEPENDENCIES is for explicitly listing link dependencies which
automake can not infer from prog_LDADD.

Cheers,
Ralf

Re: RFE: support per-program noinst_HEADERS

[Ralf Wildenhues]

* Chris Pickett wrote on Wed, Mar 12, 2008 at 08:34:34PM CET:
> Ralf Wildenhues wrote:
>> So why not this?
>>
>> noinst_HEADERS =
>> if PROG1
>> noinst_HEADERS += ...
>> else
>> noinst_HEADERS += ...
>> endif
>>
>> if PROG2
>> noinst_HEADERS += ...
>> endif
>
> I'm sorry, I don't really understand... how do I set PROG1 and PROG2?  
> What I want is this: per-test program sets of dependencies so that if a  
> file in the library is touched, only those test programs that are  
> possibly dependent upon it need to be recompiled.  I don't want every  
> test program dependent upon the same noinst_HEADERS.  Can you elaborate?

Oh, ok.  Like this?

if PROG1
prog1_headers = ...
else
prog1_headers =

endif
...
noinst_HEADERS = $(prog1_headers) ...

IOW: just rename all *_HEADERS to *_headers, that way automake will
ignore them.  And list all *_headers in noinst_HEADERS.

>> I agree that the warning 
>>
>>>>> `noinst_prog_HEADERS' is used but `noinst_progdir' is undefined
>>
>> is weird.  I'm mostly arguing to avoid having to do the work of fixing
>> the warning.  ;-)
>
> Yeah, if it's a lot of work, forget it.

No, it's probably not.

Cheers,
Ralf

Re: RFE: support per-program noinst_HEADERS

[Ralf Wildenhues]

* Chris Pickett wrote on Wed, Mar 12, 2008 at 10:50:36PM CET:
> Ralf Wildenhues wrote:
>> IOW: just rename all *_HEADERS to *_headers, that way automake will
>> ignore them.  And list all *_headers in noinst_HEADERS.
>
> s/HEADERS/headers/ and adding them all to noinst_HEADERS works, thanks.  
> Apparently I have a limited understanding of dependencies.

_HEADERS cause no kind of dependencies to be implied by automake.

> I still  don't know what the "if PROG1" stuff is about (I don't want
> these test  programs to exist conditionally),

Well, if you don't want them only conditionally, then just don't use the
conditionals.  I added them only because you had them and I guessed that
you needed them for some reason.

Cheers,
Ralf

Re: new coreutils snapshot available

[Ralf Wildenhues]

Hi Jim,

* Jim Meyering wrote on Thu, Mar 20, 2008 at 06:49:35PM CET:
> -dist_man_MANS = $(MAN)
> +# We must include at least one literal name here, so that
> +# automake-1.10.1 emits the required install-man* rules.
> +dist_man_MANS = rm.1 $(MAN)

You can instead also just s/dist_man_MANS/dist_man1_MANS/
because all automake needs to know is the section.

Cheers,
Ralf

Re: some clean rules don't work when some file starts with '-'

[Ralf Wildenhues]

Hello Vincent,

* Vincent Lefevre wrote on Thu, Mar 20, 2008 at 01:26:21PM CET:
> mostlyclean-compile:
> -rm -f *.$(OBJEXT)
> 
> This results in:

> rm -f *.o
> rm: invalid option -- .
> Try `rm ./-.o' to remove the file `-.o'.

Why would you do that, using non-portable file names?
The linker will not even work with -.o.

Are you going to argue next that 'make' should be "fixed"
because it cannot handle file names with spaces?

There are lots of characters you cannot use portably,
some due to file system limitations, e.g., on w32,
some due to Autoconf, Automake, Make, M4, or the shell.
You can look at automake/tests/instspc.test for a
collection.

> mostlyclean-compile:
> -rm -f ./*.$(OBJEXT)

FWIW, this wouldn't work (touch ./-a.o ./-b.o).

Cheers,
Ralf

Re: ABOUT-NLS

[Ralf Wildenhues]

> All of what Micah Cowan wrote:
> >
> > I'm also mailing the automake list to allow them to discuss
> > whether the requirement on ABOUT-NLS should be altered (I'm
> > guessing it's probably better to alter ABOUT-NLS as mentioned
> > though).

FWIW, automake requires ABOUT-NLS only in 'gnu' strictness mode.
So you can use the 'foreign' option (on the command line, as
argument to AM_INIT_AUTOMAKE, or listed in AUTOMAKE_OPTIONS;
see the manual for details).

Hope that helps.

Cheers,
Ralf

Re: some clean rules don't work when some file starts with '-'

[Ralf Wildenhues]

* Vincent Lefevre wrote on Fri, Mar 21, 2008 at 03:01:30AM CET:
> On 2008-03-21 00:24:20 +0100, Ralf Wildenhues wrote:
> > * Vincent Lefevre wrote on Thu, Mar 20, 2008 at 01:26:21PM CET:
> > 
> > > rm -f *.o
> > > rm: invalid option -- .
> > > Try `rm ./-.o' to remove the file `-.o'.
> > 
> > Why would you do that, using non-portable file names?
> 
> Such filenames can appear, even though they are not part of the source.
> In particular, -.o can be generated by gcc. For instance:
> 
>   echo 'void tst(void) { }' | gcc -xc -c -

But you still can't pass such a file to the linker without additional
hassles.  So why not use 'gcc -xc -c -o ... -'?

> In any case, "make clean" should not be confused by such filenames.

I'm not convinced yet.  Also, I don't know if rm understands '--' right
on all weird systems out there (haven't checked though).

> > > mostlyclean-compile:
> > > -rm -f ./*.$(OBJEXT)
> > 
> > FWIW, this wouldn't work (touch ./-a.o ./-b.o).
> 
> No problem here. I don't see why this wouldn't work.

Forget about that, thinko of mine.  Hmm, maybe we can use this idiom.

Cheers,
Ralf

Re: make check failure on old Linux

[Ralf Wildenhues]

Hello Alain,

Thanks for the bug report and patch.

* Alain Guibert wrote on Thu, Apr 03, 2008 at 10:42:07AM CEST:
>
> On my old Linux box (Intel Pentium 200 MMX, Debian bo, kernel 2.0.40,
> gcc 2.7.2.1, libc 5.4.33, GNU ld cygnus-2.7.1, libiconv 1.12, pth 2.0.7,
> i586-pc-linux-gnulibc1, autoconf 2.61, fileutils 3.16, Make 3.75,
> bash 2.0.0(1)) during automake 1.10.1 build, make check fails one test:
> 
> | FAIL: instsh2.test
> 
> The cause is an invalid date format for touch:

Yep.

> Indeed this old touch from fileutils 3.16 used a different format, with
> the year at the end:
> 
> | $ touch --help
> | [...]
> |   -d, --date=STRING  parse STRING and use it instead of current time
> |   -t STAMP   use MMDDhhmm[[CC]YY][.ss] instead of current time
> 
> Once the -t stamp reordered, or replaced by -d "27 Sep 1983 17:35:59 UTC",
> this test succeeds. touch-format.patch attached.

Good.  However, that date format is not backed by Posix, unlike the one
used currently, so that patch will break the test on some other systems.
Since we already put a fix in the git master branch on 2008-03-03 to
skip the test for a touch that does not understand -t at all (old
Solaris one), the test should be skipped for your system now, too.

I will put that patch in branch-1-10 as well, so it will be in 1.10.2.

Cheers,
Ralf

Re: distclean vs. clean order dependency

[Ralf Wildenhues]

Hi Eric,

let me address the easier part first:

* Eric Blake wrote on Sat, Apr 05, 2008 at 02:56:43PM CEST:
>
> # Avoid a race condition that would make parallel "distclean" fail.
[...]
> Or
> is there some other way, using automake 1.10.1, to add the needed
> serialization between clean-local and distclean-generic without triggering
> the automake warning about overriding an Automake target?

You could just punt and put
  AUTOMAKE_OPTIONS = -Wno-override ...

in tests/Makefile.am, or you could fix the issue for GNU make-only by
adding
  .NOTPARALLEL:

to tests/Makefile.am, or by putting
  distclean-generic: | clean-local

in tests/GNUmakefile.  This would require make 3.80 or newer, though.
All untested.

Cheers,
Ralf

Re: distclean vs. clean order dependency

[Ralf Wildenhues]

* Eric Blake wrote on Sat, Apr 05, 2008 at 03:26:44PM CEST:
> According to Ralf Wildenhues on 4/5/2008 7:09 AM:
> |   .NOTPARALLEL:
>
> Negative impact to other parts of the file.  And is anyone likely to do
> parallel make without GNU make?

Sure, parallel builds generally work with BSD make.

> | All untested.
>
> For now, I'll test (and probably use) the first.

Very well.

Thanks,
Ralf

Re: Multiple vars in AC_SUBST not considered

[Ralf Wildenhues]

Hello Jan,

* Jan Engelhardt wrote on Mon, Apr 14, 2008 at 09:21:13AM CEST:
> I observed that with a configure.ac with
> 
>   AC_SUBST([libfoo_CXXFLAGS libfoo_LIBS])

AC_SUBST is documented to only take one variable.  So please do

>   AC_SUBST([libfoo_CXXFLAGS])
>   AC_SUBST([libfoo_LIBS])

or something like
  m4_foreach([myvar], [libfoo_CXXFLAGS, libfoo_LIBS],
[AC_SUBST(myvar)])

Cheers,
Ralf

Re: Wrong linker chosen..

[Ralf Wildenhues]

Hi Behdad,

* Behdad Esfahbod wrote on Tue, Apr 15, 2008 at 07:39:19PM CEST:
> In short, all cairo source is C code, except for the BeOS backend that
> is C++.  So we have a block like this in our Makefile.am:

> However, even if CAIRO_HAS_BEOS_SURFACE is false, the C++ linker is
> chosen to link cairo.  That we want to avoid.  Any hints?

You have to help automake pick the right linker, its linker choosing
algorithm is blissfully unaware of conditionals.  You should be able to
set libcairo_la_LINK or cairo_LINK inside conditionals.  Look in a
Makefile.in how they are typically set (since this is an implementation
detail, beware: this changed between 1.9.6 and 1.10+).

If that Makefile.am otherwise has no other C++ code, and you are not
using cairo_LDFLAGS, you can just override
  CXXLINK = $(LINK)

I guess.

Hope that helps.  Of course somebody writing a patch to lift this
limitation in Automake would help even more.  ;-)

Cheers,
Ralf

Re: Wrong linker chosen..

[Ralf Wildenhues]

* Behdad Esfahbod wrote on Thu, Apr 17, 2008 at 04:14:35AM CEST:
> On Tue, 2008-04-15 at 20:09 +0200, Ralf Wildenhues wrote:
> > 
> > You have to help automake pick the right linker, its linker choosing
> > algorithm is blissfully unaware of conditionals.  You should be able to
> > set libcairo_la_LINK or cairo_LINK inside conditionals.  Look in a
> > Makefile.in how they are typically set (since this is an implementation
> > detail, beware: this changed between 1.9.6 and 1.10+).
> 
> I would have been happy doing that if it was as simple as:
> 
> libcairo_la_LINK = $(LINK)
> and
> libcairo_la_LINK = $(CXXLINK)
> 
> But as it happens now I can't do that, since libcairo_la_LDFLAGS and
> libcairo_la_CFLAGS need to go in the middle of the LINK command.  It
> prolly works if I append at the end, but don't want to change any flag
> orders (yet).

Then do this: Use the latest Automake release (so you don't run into
problems later).  Look at how libcairo_la_LINK are defined with it, with
and without the C++ source file (just omit it from the sources and rerun
automake).  Copy those two definitions and use them in the conditionals.

> > Of course somebody writing a patch to lift this
> > limitation in Automake would help even more.  ;-)
> 
> Shouldn't be too hard.  So this email of your goes to sit in my inbox
> beside two other ones from you, from 2006 and 2007.  Nice :-D.  See you
> in 2009!

I see you posted a ping for one of them.  Can you do so for the other as
well, please?  Let's see if we can avoid discussing these issues next
year.

Thanks,
Ralf