Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS

[Akim Demaille]

Le 1 févr. 2013 à 10:35, Stefano Lattarini  a 
écrit :

> So, is anyone using or playing with Automake-NG, or at least
> contemplating the idea to do so in the short term?  Or should
> we just let the project die?

I subscribe to all the good opinions about NG that have been
made here.  I would definitely use it once there is a release
(I have already been criticized several times for having used
then-CVS versions of the Autotools in Bison, and I don't want
to go in that direction again).  Actually I am eagerly waiting
for a release, I really want to be able to rely (cleanly) on
GNU Make.

I wouldn't split the repository either.

bug#11419: Get rid of ylwrap, and simplify yacc/lex rules: withdrawn this wishlist entry

[Akim Demaille]

On Sat, Jan 12, 2013 at 8:18 PM, Stefano Lattarini
 wrote:
> tags 11419 wontfix
> close 11419
> thanks
>
> Reference:
> 
>
> The improvements to the ylwrap script contributed by Akim in the 1.12.x
> and 1.13 releases have fixed most of the issues or bugs this proposal
> intended to address; even better, they did so in a completely transparent
> and backward-compatible way.
>
> While this proposal could theoretically still provide some enhancement
> in corner cases, those would be very marginal gains, and since I don't
> like the gratuitous proliferation of options and dubious knobs, I'm
> retiring this wishlist entry for now.

Not quite actually.  Currently Automake invoke Bison as yacc, i.e., it
passes the flag -y, --yacc.  This flag is expected to trigger all sorts of
warnings if you use features that are not supported by POSIX Yacc.

Because Bison is frequently invoked with -y but people do use Bison
features in their grammar, I cannot have --yacc properly do its job:
non-Yaccisms are not diagnosed to the user.

I would really like to see -y stop being used so that differences with
Yacc itself can be reported.

Cheers!

dist_noinst_MANS

[Akim Demaille]

Hi all,

Currently Automake accepts happily such a variable name, but it does not use it 
(the files are not dist'ed).  I agree EXTRA_DIST is fine, but I'm used to being 
able to use dist_noinst_* as a kind of over-specification.

Cheers,

Akim

Dependencies bw LTLIBRARIES at install time

[Akim Demaille]

Hi all,

I might have missed the information, but I believe there are no  
instruction about handling the dependencies bw libraries are install  
time (they all live in the same Makefile.am, and I do not want to  
break it).  I have libfoo that depends on libbar, and both are  
installed in different directories.  Too bad, install goes in the  
wrong order, and libtool fails to relink libfoo which it tries to  
install first.  Had both been in the same directory, then according to  
the code, I just have to define then in lib_LTLIBRARIES in the right  
order.


But it is not the case here.  Still, that's easy to fix:

install-execenvLTLIBRARIES: install-libLTLIBRARIES

does it.

But of course it does not work: with a simple warning, Automake throws  
away its own install rule, "overriden" by mine.  My work around: an


@ADDITIONAL_DEPENDENCIES@

line in Makefile.am which I AC_SUBST with the right content.

Are there any recommendations on this regard?

Cheers.

Re: Enhancing nobase_

[Akim Demaille]

Le 19 mars 09 à 14:53, Ralf Corsepius a écrit :


Akim Demaille wrote:

Hi autofriends!
nobase_ is really a nice feature to cope with a structured  
hierarchy of files.  But it does not work well with packages that  
avoid recursive Makefiles.  In my case for instance, my package has  
a hierarchy of files in $(top_srcdir)/include, but it has no  
include/Makefile.am, just $(top_srcdir)/Makefile.am, so I cannot  
use nobase_include_HEADERS, I have to declare a bazillion of  
include subdirs.


Hmm? I don't understand.

nobase_include_HEADERS = foo/far/faz.h
nobase_include_HEADERS += boo/bar/baz.h

just works.


Sorry I was unclear :(  My examples meant to make it clearer.

My top Makefile.am cannot use nobase_, because it would look like

nobase_include_HEADERS = include/foo.hh include/foo/bar.hh include/foo/ 
baz.hh


which would result in

/usr/local/include/include/foo.hh
/usr/local/include/include/foo/bar.hh
/usr/local/include/include/foo/baz.hh

which is not what I wanted (include/include).  The problem of nobase  
is that it forces the path inside the package to be exactly the path  
in DESTDIR.  I'm saying that it would be nice to have include_BASE or  
whatever be the prefix of the paths in the packages compared to the  
path in DESTDIR.  In my example, the include_BASE is include/, because  
that's where all my headers are.  Yet make install must ignore that  
include/ prefix in DESTDIR, as it's already part of includedir.


With this explanation, maybe my initial message is now more  
understandable :(

Enhancing nobase_

[Akim Demaille]

Hi autofriends!

nobase_ is really a nice feature to cope with a structured hierarchy  
of files.  But it does not work well with packages that avoid  
recursive Makefiles.  In my case for instance, my package has a  
hierarchy of files in $(top_srcdir)/include, but it has no include/ 
Makefile.am, just $(top_srcdir)/Makefile.am, so I cannot use  
nobase_include_HEADERS, I have to declare a bazillion of include  
subdirs.


It would be nice if there were a means to use nobase_, but to be able  
to declare the base.  Maybe


include_BASE = include/

or something like that.  Actually, it would leave less clutter in the  
Makefile if the include_BASE was *added* where needed, rather than  
removed for install.  Instead of


include_HEADERS = include/foo.hh include/bar.hh

it would read

base_include_HEADERS = include/
nobase_include_HEADERS = foo.hh bar.hh

and automake would generate include_HEADERS as include/foo.hh include/ 
bar.hh.

Re: [Fakeroot PATCH] Use transformed library name while testing.

[Akim Demaille]

Le 9 déc. 08 à 23:57, Clint Adams a écrit :

[For the automake guys, the question is whether it's possible to have  
a computed name for a (libtool) library.]



On Tue, Dec 09, 2008 at 10:44:44PM +0100, Akim Demaille wrote:
I have written this because that's how it appears in the script  
itself,

see fakeroot.in:

[EMAIL PROTECTED]@@DLSUFFIX@

and in scripts/Makefile:

do_subst = sed -e 's,[EMAIL PROTECTED]@],$(prefix),g' \
   -e 's,[EMAIL PROTECTED]@],$(bindir),g' \
   -e 's,[EMAIL PROTECTED]@],$(libdir),g' \
   -e 's,[EMAIL PROTECTED]@],'`echo fakeroot | sed -e '$
(transform)'`',g' \

But you are right, afaict, the top level Makefile.am does not try to
transform the lib name, so script/Makefile.am can also be simplified.


Ah, hmm.  The libraries are transformed as part of the Debian  
package build

since the `make install` doesn't do it, so of course this is a bug in
scripts/*, but one that works for a single case.

Can libtool be bent to do this easily so I can make it consistent?


I have no idea.  Actually, I doubt it :(

Re: Feature request

[Akim Demaille]

Le 23 sept. 08 à 23:08, Ralf Wildenhues a écrit :


Hi Akim,


Hi Ralf!


* Akim Demaille wrote on Tue, Sep 23, 2008 at 04:35:50PM CEST:


I'm slowly getting rid of my recursive Makefiles.  Instead I have one
local.mk per directory, and a few Makefile.ams that include them.  Of
course I have to prefix all my file names with the name of the
directory, and I find that this explicit name is actually clutter.  I
don't think automake can be educated to guess by itself where to  
prepend

the directory name,


I agree that that would be too much magic, and probably too fragile.


Yet that would be wonderful to have a means to tell Automake to make a  
single large Makefile instead of several ones.  It can't do it all by  
itself, but if the Makefile.ams are sufficiently complete, it might be  
doable.  Then the magic from Automake would be mostly to give a local  
and magic value to $(srcdir) $(builddir) etc.  Which is basically what  
I'm suggesting here.




yet it would be quite easier to have some variable
that would expand to the prefix of the included file.


Sounds like a reasonable wish.  Let's look at an example.
Probably you want a set of these:

- one for the full relative path to the Makefile.am  (%AMSUB%=foo/bar)
 (this one would be '.' if in the same directory)
- likewise, including final slash (%AMPREFIX%=foo/bar/)
 (needed if the prefix can also be empty, to avoid './')
- likewise, but flattened (%AMFLAT%=foo_bar_)
- reverse of the full relative path (%AMREV%=../..)
- maybe a set of these for only the path to the next included snippet?
- would that be enough for all use cases?


Yes, I think it would.

Another option would be to provide local variables, scoped to the  
current local.mk and the one it includes, with traditional scoping.   
Automake itself could rely on this to define these magic variables.



Example:

 --- Makefile.am ---
 include foo/local1.mk

 --- foo/local1.mk ---
 # Yes, it is very ugly and IMNSHO an automake misfeature that
 # the next line requires an %AMPREFIX%.  Unfortunately, fixing
 # it would break user's scripts.
 include %AMPREFIX%bar/local2.mk


Bummer :(


 --- foo/bar/local2.mk ---
 FOO_FLAGS = -I%AMREV%/include


I would not promote too much AMREV.  In my experience it's always  
clearer and safer to start from top_src/builddir rather than trying to  
play these tricks.




 bin_PROGRAMS = %AMPREFIX%bar
 %AMFLAT%bar_SOURCES = %AMPREFIX%bar.c %AMPREFIX%baz.c

Yuck.  That's already quite ugly, nothing I'd want to edit regularly.
We could use even shorter abbreviations.  Suggestions?


For a start, if you really do not want to use the $() syntax, maybe we  
can move to something like %()?  Or $[]?  Provided we give a means to  
the user to write '$[' when she means it, I'm not sure that would be  
really such a problem to infringe on the Make "name space".


%FOO% is hard to read when there are many, braces are much easier to  
read.


Also, we can stick to $(), but within Automake's "namespace".  Say $ 
(AMPREFIX) instead of %AMPREFIX%.



And yes, if the resulting snippets are to be usable also from the same
directory, then most usages need AMPREFIX and not AMSUB, if non-GNU  
make

should work well, too.  This is probably not easy on users.


Agreed.




Thanks for the good work!


Thanks for the feedback, and the suggestion.


[1] whatever the name, but not too long.  Maybe a symbol, $/ for
instance.


I'd really hate to invade make's namespace.  They may come up with  
this

really cool new makefile variable, and we can't use it then.  :-/


Unless we can spell it (read "escape") differently.

Feature request

[Akim Demaille]

Hi friends!

I have a suggestion.

I'm slowly getting rid of my recursive Makefiles.  Instead I have one  
local.mk per directory, and a few Makefile.ams that include them.  Of  
course I have to prefix all my file names with the name of the  
directory, and I find that this explicit name is actually clutter.  I  
don't think automake can be educated to guess by itself where to  
prepend the directory name, yet it would be quite easier to have some  
variable that would expand to the prefix of the included file.


For instance with

include foo/bar/local.mk

I'd like to have something like $(cwd) [1] replaced by foo/bar inside  
local.mk.  Or something like that.  It should be recursive: if foo/bar/ 
local.mk itself includes something else, paths should be appended.


Thanks for the good work!

[1] whatever the name, but not too long.  Maybe a symbol, $/ for  
instance.

Re: parallel testsuite execution

[Akim Demaille]

>>> "RW" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:

 > Hello Akim,

Hi Ralf,

 >> So I would like to be able to write something like
 >> 
 >> TEST_SUITES = foo bar
 >> foo_TESTS = foo1.chk foo2.test foo3
 >> bar_TESTS = bar1.test bar2.sh bar3.c
 >> 
 >> and be able to write on the side rules explaining how to .chk -> .log,
 >> .test -> .log etc.

 > Sounds useful.

 >> Maybe instead of _TESTS we could reuse _SOURCES?  That's not
 >> inconsistent: they are really sources which must be compiled into
 >> *.log files which are then linked together to produce foo.log and
 >> bar.log.

 > Hmm.  That would prevent us to name test suites after programs.
 > As I understand your proposal above, that would be intended though.

Actually the test suite don't really exist, what does exist is the set
of programs to run, their associated logs, and the resulting log of
the test suite.  So actually I could have written:

 TEST_SUITES = foo.log bar.log

and maybe

 foo_log_TESTS = foo1.chk foo2.test foo3
 bar_log_TESTS = bar1.test bar2.sh bar3.c



 > I don't remember whether you turned them off for non-terminal output,
 > but it should be configurable, and default to on only for terminal
 > output.

That's what I do, indeed:

# If stdout is a tty, use colors.  If test -t is not supported, then
# this fails; a conservative approach.  Of course do not redirect
# stdout here, just stderr...
am__tty_colors =\
if test -t 1 2>/dev/null; then  \
  red='ESC[0;31m';  \
  grn='ESC[0;32m';  \
  lgn='ESC[1;32m';  \
  blu='ESC[1;34m';  \
  std='ESC[m';  \
fi


Here is the latest version we use.  Benoît Sigoure has added another
feature: so called "hard errors", errors that cannot be saved by an
XFAIL.  This can be used for instance when you do not tolerate a SEGV,
even if the test is Failed.




check.mk
Description: Binary data


 >> Sure, but who's going to spend some time on this?

 > Which of the two?  The Sun make adjustments are typically not hard.
 > The ?= is really GNU make specific.

These are quite trivial.  The main problem is supporting

 TEST_SUITES = foo.log bar.log
 foo_log_TESTS = foo1.chk foo2.test foo3
 bar_log_TESTS = bar1.test bar2.sh bar3.c

Re: parallel testsuite execution

[Akim Demaille]

>>> "RW" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:

 > Hello Benoit,

Hi Ralf,

Sorry for answering so late...


 > Can you rid it of nonportable constructs, and more importantly, can it
 > be included in Automake (copyright transfered to the FSF etc.)?

Sure, no problems.

 > Hmm, let's see.  Most suffix rules should be trival to convert, unless I
 > missed something, except for the

 >> %.log: %$(EXEEXT)

 > rule.

Yes, it should be straightforward.  In fact the most difficult task is
that I'd like to support multiple test suites in a single directory.
Maybe that's overkill, but in my context it would be quite useful
actually.

So I would like to be able to write something like

TEST_SUITES = foo bar
foo_TESTS = foo1.chk foo2.test foo3
bar_TESTS = bar1.test bar2.sh bar3.c

and be able to write on the side rules explaining how to .chk -> .log,
.test -> .log etc.

Maybe instead of _TESTS we could reuse _SOURCES?  That's not
inconsistent: they are really sources which must be compiled into
*.log files which are then linked together to produce foo.log and
bar.log.

 > I guess as a first approximation it would be ok to do without.  The
 > awk script may require a bit of work for Solaris; I'd just drop the
 > colors;

Nah, please, let's keep them, it's really very useful!

 > $(basename ..) is not portable;

Will be fixed when migrated to Automake.

 > and also it would need adjustment for Sun make's gigantic VPATH
 > rewriting feature; 'TEST_LOGS ?=' would need to be replaced by an
 > override done at 'automake' time.  

Sure, but who's going to spend some time on this?

 > The whole thing should probably be governed by an Automake option
 > parallel-tests, defaulting to off, for backward compatibility.
 > Then some documentation, and about three tests to ensure it works
 > as intended.

We can handle that part.

 > IOW, if nobody else I could probably even volunteer to do the rewrite
 > once the legal situation is clear.

That's a good thing to know :)

Re: prog_LDADD at the end of the linking command line

[Akim Demaille]

Le 19 oct. 07 à 19:16, Ralf Wildenhues a écrit :


Hello Benoit,

* Benoit SIGOURE wrote on Fri, Oct 19, 2007 at 06:48:25PM CEST:


# Add boost libraries.
AM_CXXFLAGS += $(BOOST_CPPFLAGS)
AM_LDFLAGS  += $(BOOST_LDFLAGS) $(BOOST_THREAD_LIB)


Don't put libs (-l...) in LDFLAGS, it messes up the ordering.  Put  
them

in *_LDADD/*_LIBADD or LIBS.  Note that LIBS comes last, so the most
lowlevel ones should be listed there.


Thanks Ralf, that did solve our issue.  Too bad there is still
not AM_LIBADD, that's really the first name that comes to the
mind :)

Re: AM_LIBADD

[Akim Demaille]

>>> "RW" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:

 >> Hi Ralk, I missed your answer :)

 > Hehe, interesting typo.  Ralph is a more common one.  ;-)

How bizarre...  I don't how I managed to get this one kucked up.  The
feys are not even close!


 > Sure.  I think the addition of AM_LIBADD/tgt_LIBADD and
 > AM_LDADD/tgt_LDADD is a good idea.

 > Want to propose a patch?

I'd be happy to, but :)

 > Or rather wait until I have more time for Automake again?  Maybe
 > you have a way to ping Alexandre...

I believe he's writing his PhD manuscript, so...  I can try, but... :)

-- Afim

Re: AM_LIBADD

[Akim Demaille]

>>> "RW" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:

 > Hello Akim,

Hi Ralk, I missed your answer :)

 > * Akim Demaille wrote on Fri, Nov 03, 2006 at 05:56:16PM CET:
 >> 
 >> For the records, I could use AM_LIBADD as a default value of
 >> libfoo_la_LIBADD.  Currently it is not recognized.

 > LIBS is not enough?  (If you care about allowing the user to set it,
 > you could add your stuff to @[EMAIL PROTECTED])

Never thought about LIBS...

But anyway it is inconsistent:

- it does not obey the FOO/AM_FOO rule of ownership of the macros
  (those from the user, and those from the developer)

- it does not spell like libfoo_la_LIBADD.

And anyway, I guess LIBS applies to programs in addition to libraries,
while LIBADD is meant for libraries only.

Re: running tests in parallel

[Akim Demaille]

It would be nice if it were possible to run tests in parallel using
automake.  Waiting for tests to complete on a 4-way box while they  
are run

on a single CPU is annoying.  As most 'make' implementations already
support running in parallel (-j), automake could just utilize this
functionality to runt tests in parallel.


I very much agree.

I have been using for quite a while the following framework which
brings several benefits over the current framework.  I wanted to
have time to write bits in Automake to avoid GNU Make syntax,
but I didn't find enough time.  Maybe someone will want to pick
up the ball.

The features are:

- It can be run in parallel.

- A single run produces the quiet version on screen and
  the verbose version in a log, so you no longer have to
  run the tests twice.  A message similar to Autotest's
  invites the user to send the log to the reporting address.

- It can rely on dependencies, so if you have tests that need
  not be rerun if their sources are not updated, then they are
  not rerun at all.  On a project of mine, this is a significant
  speed up

- It is meant to produce reStructured Text, so if you produce
  logs in RST too, the resulting log file is easy to convert
  into clickable html.

- The display on screen uses colors to catch attention on
  failures.

- It gives the path to the directory that had the failure,
  which is quite handy when there are several test suites.

- The log file is not created if everything went right,
  so a call to find can easily reveal the directories
  where the failures occurred.

- It is meant to support several test-suites in a single
  directory, but this requires help from Automake.  I had in
  mind something like

  TEST_SUITES = test-suite-1 test-suite-2
  test_suite_1_SOURCES = test1.tst test2.chk test3.tst
  test_suite_1_XFAILS = test1.tst

  etc.  But this requires hacking Automake, and I did not take
  time to do it.


Here is the file that provides these features:



check.mk
Description: Binary data


Here is an example of use that supports another extension
than .test or $(EXEEXT):

--
# The test suite is composed of *.chk files.  Each one must create a
# *.log file that we want to keep.
TESTS_ENVIRONMENT = srcdir=$(srcdir) USE_VALGRIND=$(USE_VALGRIND)
TESTS = $(notdir $(wildcard $(srcdir)/checkfiles/*.chk))
XFAIL_TESTS =   \
events.chk  \
lazy-test-eval.chk  \
tag.chk
TEST_LOGS = $(TESTS:.chk=.log)
# .PRECIOUS: $(TEST_LOGS)

# Parallel test framework.
include $(top_srcdir)/build-aux/check.mk

# From a test file to a log file.
%.log: $(srcdir)/checkfiles/%.chk
@$(am__check_pre) $(srcdir)/uconsole-check $${dir}$< $(am__check_post)
EXTRA_DIST += uconsole-check

.PHONY: clean-test-dirs
clean-local: clean-test-dirs
clean-test-dirs:
rm -rf $(TESTS:.chk=.dir)
--


Here is an example of textual log created this way, followed
by its HTML conversion (when running make check-html).  The
idea to use RST was made by Alexandre Duret-Lutz.



test-suite.log
Description: Binary data



Calculator 1.0: tests/test-suite.log

   1 of 34 tests failed.

   Contents
 * [1]FAIL: events.chk (exit: 1)
  + [2]Input
  + [3]output

[4]FAIL: events.chk (exit: 1)

[5]Input

   Input:
1 + 2;
1 + 2;
1 + 2;

[6]output

   Expected output:
3
3
3

   Effective output:
1
2
3

   Diffs on output:
--- Expected output (output.exp)
+++ Effective output (output.eff)
@@ -1,3 +1,3 @@
-3
-3
+1
+2
 3

References

   1. file://localhost/tmp/tmprGS3qn.html#fail-events-chk-exit-1
   2. file://localhost/tmp/tmprGS3qn.html#input
   3. file://localhost/tmp/tmprGS3qn.html#output
   4. file://localhost/tmp/tmprGS3qn.html#id1
   5. file://localhost/tmp/tmprGS3qn.html#id2
   6. file://localhost/tmp/tmprGS3qn.html#id3


I'd be happy to help if I can do something for this to be
included in Automake.

Re: ``install -C'' / unnecessarily updating time stamps

[Akim Demaille]

Le 25 déc. 06 à 11:46, Thomas Schwinge a écrit :

[I added the patch's author, Akim Demaille, to the cc list, as it  
was not

sure if he's still reading the list.]


You're right, I'm not.


Hello!


Hi, and merry Chrismas.



On Sun, Dec 24, 2006 at 04:21:50PM -0800, Paul Eggert wrote:

Benoit Sigoure <[EMAIL PROTECTED]> writes:
http://lists.gnu.org/archive/html/automake-patches/2006-10/ 
msg00070.html


Sorry, I missed that one.  The idea looks reasonable, but that solves
the problem for install-sh only, right?  GNU 'install' still wouldn't
support -C.


This brings up the following question: if `-C' shall be used a) by
default in Autoconf's `AC_PROG_INSTALL' if available or b) if  
requested

by the programmer through setting some flag, and `install-sh' supports
`-C', but the system's `install' executable doesn't (which will, as  
far
as I can tell, be the case on most systems as after this quoted  
patch has

been applied to `install-sh'), which of the two installation programs
shall be chosen: the native `install' for speed or `install-sh' for
feature completeness and to accommodate the programmer's request?


I agree with Paul's answer.  Besides, it is IMHO high time to completely
rewrite AC_PROG_INSTALL to actually check the behavior of "install"
instead of playing dark magic with file names.  It would be nice then
to be able to specify the flags one wants (e.g., -C).





Also, the updated patch proposed in
<http://lists.gnu.org/archive/html/automake-patches/2006-10/ 
msg00077.html>

has some coding-style components along with the substance components.
I plan to split it into two and apply the two pieces.


| +# Maybe we don't need to install the file.  Use diff, not cmp,
| +# to be robust to end-of-line encoding.
| +{ if $copy_on_change &&
| +  $diffprog "$dsttmp" "$dst" >/dev/null 2>&1 &&
| +  new=`ls -l "$dsttmp" | awk '{print $1 ":" $3 ":" $4}'` &&
| +  old=`ls -l "$dst"| awk '{print $1 ":" $3 ":" $4}'` &&
| +  test x"$new" = x"$old"
| +  then
| + # No need to copy, that's the same file.
| + continue
| +  else :; fi; } &&

Is this ``ls -l [...] | awk [...]'' portable enough


Yes.


and is it really
needed?


Either you do that, or chmod afterwards.  But install-sh behaves
quite atomically and either fully does its job, or leaves the
destination untouched.

Besides, if you just happened to have removed some read permissions,
it seems fair that all the files that depend on it no longer
compile.  So the timestamps and Makefiles should not continue
as if nothing happened.

But that's a weak argument, I don't really care.

Another option I was considering was adding -I to be passed to
diff.  For instance to ignore $Id$ keywords etc.  But if no
real "install" support it, who cares.



| http://www.freebsd.org/cgi/man.cgi?query=install
| #v+
| [...]
|  -C  Copy the file.  If the target file already exists  
and the files
|  are the same, then do not change the modification  
time of the
|  target.  If the target's file flags and mode need  
not to be
|  changed, the target's inode change time is also  
unchanged.

| [...]
| #v-


Regards,
 Thomas

AM_LIBADD

[Akim Demaille]

For the records, I could use AM_LIBADD as a default value of
libfoo_la_LIBADD.  Currently it is not recognized.

Re: Best means to override CXXFLAGS locally

[Akim Demaille]

>>> "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:

 > Hello Akim,
 > * Akim Demaille wrote on Sun, Oct 22, 2006 at 01:10:02PM CEST:
 >> >What would be the cleanest means to handle this exception?
 >> 
 >> Here is what I did:

 > I think it's much better to do the munging in configure.ac.  Store the
 > CFLAGS set by the user and/or AC_PROG_CC in AM_CFLAGS, and override
 > CFLAGS.  Depending upon whether the changed flags settings apply to only
 > a few, non-portability-problematic files in your project, the rest of
 > the configure tests should run with the flags set by the user, and you
 > should only override at the end, or the converse.

I agree this is cleaner, but it is also more dangerous: there are many
libraries and programs in there, including several with their own
flags (where I would have to also add C*FLAGS by hand).  So, although
I also considered that option, I chose the other because it is less
dangerous.  The circumlocutions are more local this way.

 > Much cleaner, involves much less changes.  If you have something that
 > works nicely and is reasonably generally useful, post a summary, or
 > even better, a FAQ addition to the manual.  ;-)

Re: EXTRA_PROGRAMS vs. clean

[Akim Demaille]

While we're one that topic, I don't understand why cleaning the tags
is hooked to distclean instead of clean.

EXTRA_PROGRAMS vs. clean

[Akim Demaille]

Sorry if this is a faq, but I have found nothing convincing, excepted
this unanswered message:

 http://sourceware.org/ml/bug-automake/2001/msg00391.html

and

 http://sources.redhat.com/ml/bug-automake/2003/msg00311.html

where adl seems to agree it should be cleaned.

I don't understand why make clean should not clean EXTRA_PROGRAMS.  I
agree EXTRA_PROGRAMS is not hooked on "all", so it makes some sense
not to attach it to "clean".  In fact, Tom extended extra.test in 1996
to include an explicit check that it is not:

http://sources.redhat.com/cgi-bin/cvsweb.cgi/automake/tests/extra.test?annotate=1.2&cvsroot=automake

But I find this inconvenient.

The documentation should at least warn the user about this.

Maybe Tom has an opinion about this?

Re: Best means to override CXXFLAGS locally

[Akim Demaille]

What would be the cleanest means to handle this exception?


Here is what I did:
- Force automake to generate an object specific rule by
  using some foo_CXXFLAGS
- Open Makefile.in, get the specific rules.
- Use LTCOMPILECXX to factor the common part
- Append $(MY_NOPTION_CXXFLAGS) to it
- rename the (object) output file name Automake used
- include all this in the Makefile.am
- remove the foo_CXXFLAGS so that Automake do not
  produce a rule for this object
- and therefore my own rule is obeyed with conflict
- and finally pray for no significant changes in the
  future versions of Automake ;)

# This is an edited copy of Automake's compilation rule so that we can
# insert $(PARSER_CXXFLAGS) *after* $(CXXFLAGS) to override -O2.
# Using foo_CXXFLAGS does not suffice, since CXXFLAGS, a user
# variable, appears last.
ugrammar.lo: ugrammar.cc
@am__fastdepCXX_TRUE@	if $(LTCXXCOMPILE) $(PARSER_CXXFLAGS) -MT  
ugrammar.lo -MD -MP -MF "$(DEPDIR)/ugrammar.Tpo" -c -o ugrammar.lo  
`test -f 'ugrammar.cc' || echo '$(srcdir)/'`ugrammar.cc; \
@am__fastdepCXX_TRUE@	then mv -f "$(DEPDIR)/ugrammar.Tpo" "$(DEPDIR)/ 
ugrammar.Plo"; else rm -f "$(DEPDIR)/ugrammar.Tpo"; exit 1; fi
@AMDEP_TRUE@@am__fastdepCXX_FALSE@	source='ugrammar.cc'  
object='ugrammar.lo' libtool=yes @AMDEPBACKSLASH@
@AMDEP_TRUE@@am__fastdepCXX_FALSE@	DEPDIR=$(DEPDIR) $(CXXDEPMODE) $ 
(depcomp) @AMDEPBACKSLASH@
@am__fastdepCXX_FALSE@	$(LTCXXCOMPILE) $(PARSER_CXXFLAGS) -c -o  
ugrammar.lo `test -f 'ugrammar.cc' || echo '$(srcdir)/'`ugrammar.cc



Is there anything better to do?  Is there a trap I just fell in?

Best means to override CXXFLAGS locally

[Akim Demaille]

I have this cross-compiler at hand that cannot compile some of my
big files (a Bison parser) with -O2.  Stacking -O0 on top of -O2
does the trick.  But I don't know the recommended way to do that.

Since I'd like to the keep the good old -g -O2 for the rest of
the compilation, since I don't want to forbid the user from
passing -O2 in her flags, I'd really like to override this just
for this file.  Compiling it as a library with specific CXXFLAGS
won't do the trick, since CXXFLAGS, of course, appear after
$(libparser_la_CXXFLAGS):

libparser_la-ugrammar.lo: ugrammar.cc
	if $(LIBTOOL) --tag=CXX --mode=compile $(CXX) $(DEFS) $ 
(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $ 
(libparser_la_CXXFLAGS) $(CXXFLAGS) -MT libparser_la-ugrammar.lo -MD - 
MP -MF "$(DEPDIR)/libparser_la-ugrammar.Tpo" -c -o libparser_la- 
ugrammar.lo `test -f 'ugrammar.cc' || echo '$(srcdir)/'`ugrammar.cc; \
	then mv -f "$(DEPDIR)/libparser_la-ugrammar.Tpo" "$(DEPDIR)/ 
libparser_la-ugrammar.Plo"; else rm -f "$(DEPDIR)/libparser_la- 
ugrammar.Tpo"; exit 1; fi


What would be the cleanest means to handle this exception?

Thanks!

AM_EXTRA_DIST

[Akim Demaille]

ISTR that there was a means, via a macro traced by Automake, that
there was a means to ask it to automatically ship some files.
Something similar to AC_LIBSOURCES, but more general.

I can't find anything like this.  Did I dream about it?

install-local -> uninstall-local

[Akim Demaille]

It would probably make sense to have a warning in case a Makefile.am
has install-*-local rules but no uninstall-local.  BTW, I must say I
don't really understand why, at least to keep symmetry, all the
install-*-local targets are mapped to a single uninstall-local one.
That there is one is nice, but I find it clearer to have perfect
symmetry btw install/uninstall.  Just a remark, not a demand :)

Re: Suggestion: AC_DEFINE -> m4_pattern_allow

[Akim Demaille]

>>> "Stepan" == Stepan Kasal <[EMAIL PROTECTED]> writes:

 > Hello,
 >> * Akim Demaille wrote on Wed, May 31, 2006 at 04:26:17PM CEST:
 >> > I suggest that Automake provide the same feature for AM_CONDITIONAL:

 > well, you already implemented it, granting Alexandre one point for
 > his hint:

 > http://lists.gnu.org/archive/html//bug-automake/2004-12/msg00090.html
 > http://lists.gnu.org/archive/html//autoconf-patches/2004-12/msg00075.html

 > We definitely should make releases more frequently.  ;-)

 > Consequently, we should all be very grateful to Ralf for his current
 > hard release-engineering work.

It's great news!

I thought I had sent a message about AM_CONDITIONAL's first argument,
but I lost track of it.  In a few words, since $1 appears in the
expansion of AM_CONDITIONAL, I think it too should be
m4_pattern_allow'ed.  AC_SUBST is called only on $1_FALSE and $1_TRUE.

Re: Suggestion: AC_DEFINE -> m4_pattern_allow

[Akim Demaille]

>>> "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:

 > Hi Akim,
 > * Akim Demaille wrote on Wed, May 31, 2006 at 04:26:17PM CEST:
 >> >>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
 >> 
 >> Some time ago I sent this message for which I had no answer.

 >> > I suggest that the AC_DEFINE family explicitly allow its $1.

 > Not true,

Hm, yes, I have not received answered: apparently I was not in CC.

 > your request has been dealt with:
 > http://lists.gnu.org/archive/html/autoconf/2006-05/msg00087.html

Great news!

 > I agreed with it back then, although I do have a vague feeling that all
 > the m4_pattern_allow make for a significant runtime overhead.

There are not that many AC_DEFINE, AC_SUBST.


 >> I suggest that Automake provide the same feature for AM_CONDITIONAL:

 > But you are not likely to use the first argument of AM_CONDITIONAL
 > elsewhere in your configure.ac, are you?  (I have probably just
 > misunderstood this part.)

I meanr that this first arguments appears in the expansion of
AM_CONDITIONAL, so it should be un-forbidden.

Re: Suggestion: AC_DEFINE -> m4_pattern_allow

[Akim Demaille]

Le 31 mai 06 à 18:38, Stepan Kasal a écrit :


Hello,


* Akim Demaille wrote on Wed, May 31, 2006 at 04:26:17PM CEST:

I suggest that Automake provide the same feature for AM_CONDITIONAL:


well, you already implemented it, granting Alexandre one point for
his hint:

http://lists.gnu.org/archive/html//bug-automake/2004-12/msg00090.html
http://lists.gnu.org/archive/html//autoconf-patches/2004-12/ 
msg00075.html


We definitely should make releases more frequently.  ;-)


:)

However my point about the name of the condition remains.  AC_SUBST
covers only the *_TRUE and *_FALSE part.



Consequently, we should all be very grateful to Ralf for his current
hard release-engineering work.

Have a nice day,
Stepan

Re: Suggestion: AC_DEFINE -> m4_pattern_allow

[Akim Demaille]

>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:

Hi!

Some time ago I sent this message for which I had no answer.

 > I have this package at hand, say FooBar, which installs a prefixed
 > form of config.h.  Its own macros are, of course, named FB_*, which is
 > m4_pattern_forbidden.  But then I have to explicitly m4_pattern_allow
 > all my FB_PACKAGE_VERSION etc.

 > I suggest that the AC_DEFINE family explicitly allow its $1.

 > Thanks.

I suggest that Automake provide the same feature for AM_CONDITIONAL:

| AC_DEFUN([AM_CONDITIONAL],
| [AC_PREREQ(2.52)dnl
|  ifelse([$1], [TRUE],  [AC_FATAL([$0: invalid condition: $1])],
|   [$1], [FALSE], [AC_FATAL([$0: invalid condition: $1])])dnl
| AC_SUBST([$1_TRUE])
| AC_SUBST([$1_FALSE])
| if $2; then
|   $1_TRUE=
|   $1_FALSE='#'
| else
|   $1_TRUE='#'
|   $1_FALSE=
| fi
| AC_CONFIG_COMMANDS_PRE(
| [if test -z "${$1_TRUE}" && test -z "${$1_FALSE}"; then
|   AC_MSG_ERROR([[conditional "$1" was never defined.
| Usually this means the macro was only invoked conditionally.]])
| fi])])

Sadly enough $1 does appear here... only in the (last) error message.
But still, if I AM_CONDITIONAL([FB_BAZ_USED], ...), I will be warned
by autoconf from terrible m4_pattern_* things.

Of course in the present case one would like to flag this precise
occurrence of $1.  Maybe something like m4_patsubst([$1],
[^\(.\)\(.*\)$], [\1@&[EMAIL PROTECTED]) (untested) should be it.  Or
m4_patsubst(quote($1)...) instead (usual dirty issues with M4 not
providing means to safely evaluate...).

Actually it might be useful to introduce m4_pattern_protect in
m4sugar, defined as above, as it is quite useful to disarm a specific
occurrence of a nasty token.

Re: texi2dvi: A more pleasant way to compile

[Akim Demaille]

>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:

 Akim> is there really any point?

 > It's simple to implement and it's cleaner to use.  It also shows a
 > good example of an interface we would both like to see in many
 > other tools.

Of course you're right.  Thanks for keeping me away from the dark side.

Re: texi2dvi: A more pleasant way to compile

[Akim Demaille]

>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:

>>> "Karl" == Karl Berry <[EMAIL PROTECTED]> writes:
 >>> So the new work is merely to add *.t2d in .cvsignore (or whatever), and
 >>> CLEANFILES = *.t2d in Makefile.am, until Automake is updated?

 > Can we work on an interface that will not require any change in
 > Automake the next time texi2dvi invents new files or
 > directories?

That's the whole point: now there is no reason for additional
files/directories to be created.

 > Having an operation mode where texi2dvi cleans itself the
 > auxiliary files that it would otherwise create sounds right to
 > me.  In other words, I'd like `make mostlyclean' to call
 > `texi2dvi --mostlyclean input.texi' for all `input.texi',
 > instead of having to know how texi2dvi works internally.

 > (I think that's an old idea from Akim.)

That's right :) But that's already too late for older texi2dvi, so I
think you will most probably never use this feature in Automake (just
as you will most probably not get rid of the silly list of hard coded
extensions that Texinfo files might create)

Sure, you can affort to

  -texi2dvi --mostlyclean
  rm -rf ...

but is there really any point?  I'm fine with implementing this, I'm
merely asking whether it will be used.

Re: texi2dvi: A more pleasant way to compile

[Akim Demaille]

>>> "Karl" == Karl Berry <[EMAIL PROTECTED]> writes:

[The thread starts in 
http://lists.gnu.org/archive/html/bug-texinfo/2005-05/msg00019.html]

 > finding the xref files is much easier, 
 > That's a good point.  Finding all those aux files has always been a drag.

 > Still wanna keep the old scheme?

 > I'm not sure yet.

 > So the new work is merely to add *.t2d in .cvsignore (or whatever), and
 > CLEANFILES = *.t2d in Makefile.am, until Automake is updated?  Anything
 > else?

Yes: CLEANFILES is for files only.  So it's either

# Heek.
CLEANFILES = -rf *.t2d

or

clean-local:
rm -rf *.t2d

Re: AM_LDFLAGS vs. maude_la_LDFLAGS

[Akim Demaille]

>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:

 > Whether using libtcswigpy_la_LDFLAGS in addition to AM_LDFLAGS is
 > an error I don't know.

It is not nice: (i) it is a different semantics than the other
variables, and (ii) the more common semantics is more flexible.

 > OTOH, the current behavior of AM_LDFLAGS vs. maude_LDFLAGS
 > sounds very counterintuitive to me.  Even if it breaks some
 > package, I'd rather fix this to match the handling of the other
 > flag variables than document and carry over this exception.

100% agreed.

Nice patch, many thanks!

AM_LDFLAGS vs. maude_la_LDFLAGS

[Akim Demaille]

It is my understanding (after having re-read the doc ;) that these
flags are exclusive: either one of the two is used.  So I have in a
Makefile.am of mine:

| AM_LDFLAGS = -avoid-version -module -shared
| ...
| # Override AM_LDFLAGS: this guy must not be a module.
| libtcswigpy_la_LDFLAGS =

and Makefile.in does contain:

libtcswigpy.la: $(libtcswigpy_la_OBJECTS) $(libtcswigpy_la_DEPENDENCIES) 
$(CXXLINK) -rpath $(pyexecdir) $(libtcswigpy_la_LDFLAGS) 
$(libtcswigpy_la_OBJECTS) $(libtcswigpy_la_LIBADD) $(LIBS)

but CXXLINKS is:

CXXLINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
--mode=link $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS) $(AM_LDFLAGS) \
$(LDFLAGS) -o $@

so I'm stuck with AM_LDFLAGS although I meant to escape from it.  Of
course I'll get rid of AM_LDFLAGS, but I'm not sure I was an outlaw
according to the documentation.

And shouldn't the LDFLAGS be last?  It is in CXXLINKS, but in the
command line.

filename-length-max=99

[Akim Demaille]

Why isn't it enabled when using tar-v7?

Re: Error because README is missing

[Akim Demaille]

>>> "Paul" == Paul Smith <[EMAIL PROTECTED]> writes:

 > %% Akim Demaille <[EMAIL PROTECTED]> writes:
 >>> I need a way to have a file marked as a config file, but not have
 >>> configure (or automake) fail if the .in input file doesn't exist.

 ad> Hm...  What is the service you are expecting?  You say that
 ad> configure shouldn't fail, but if it's a config file, configure is
 ad> expected to fail.  Unless you do mean configure, and not
 ad> config.status?

 > When I first check out my code from CVS, I don't have a build.sh.in
 > file.  That file is autogenerated as part of the build process, from a
 > template file.

If you have a bootstrap script, why wouldn't it create a fake file,
run autoreconf, and them create the right file?

Do you run autoreconf several times?  It seems so, since that's what
implied Andreas' solution.

Finally, note that you are allowed to ask config.status to perform
substitutions on files it doesn't know[1].  In your case, I'm unsure
binding the instantiation to configure instead of make is right.

An example: in autoconf's tree.

src/ace/_build % ./config.status --help  nostromo 17:45
`config.status' instantiates files from templates according to the
current configuration.

Usage: ./config.status [OPTIONS] [FILE]...

  -h, --help   print this help, then exit
  -V, --versionprint version number, then exit
  -q, --quiet  do not print progress messages
  -d, --debug  don't remove temporary files
  --recheckupdate config.status by reconfiguring in the same conditions
  --file=FILE[:TEMPLATE]
   instantiate the configuration file FILE

Configuration files:
 config/Makefile tests/Makefile tests/atlocal tests/autoconf:tests/wrapper.in 
tests/autoheader:tests/wrapper.in tests/autom4te:tests/wrapper.in 
tests/autoreconf:tests/wrapper.in tests/autoscan:tests/wrapper.in 
tests/autoupdate:tests/wrapper.in tests/ifnames:tests/wrapper.in man/Makefile 
lib/emacs/Makefile Makefile doc/Makefile lib/Makefile lib/Autom4te/Makefile 
lib/autoscan/Makefile lib/m4sugar/Makefile lib/autoconf/Makefile 
lib/autotest/Makefile bin/Makefile

Configuration commands:
 tests/atconfig

Report bugs to <[EMAIL PROTECTED]>.
src/ace/_build % echo "@srcdir@" > foo.innostromo 17:45
src/ace/_build % ./config.status --file=foo  nostromo 17:45
config.status: creating foo
src/ace/_build % cat foo nostromo 17:45
..

dist_TESTS

[Akim Demaille]

I'd like that!

Re: Error because README is missing

[Akim Demaille]

>>> "Paul" == Paul Smith <[EMAIL PROTECTED]> writes:

 > %% Akim Demaille <[EMAIL PROTECTED]> writes:
 >>>>> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes:
 >>> Untested code ahead.

 >>> m4_syscmd([test -f build.sh.in])dnl
 >>> m4_if(m4_sysval, 0, [AC_CONFIG_FILES(build.sh)])

 ad> Bad idea: side effects are incompatible with the (autom4te) cache.
 ad> If the environment changes but not the sources of configure, it
 ad> won't be regenerated.  Similarly with what Automake needs to
 ad> trace.

 > OK :-(.

 > I need a way to have a file marked as a config file, but not have
 > configure (or automake) fail if the .in input file doesn't exist.


 > How can I do this?

Hm...   What is the service you are expecting?  You say that configure
shouldn't fail, but if it's a config file, configure is expected to
fail.  Unless you do mean configure, and not config.status?

Re: Error because README is missing

[Akim Demaille]

>>> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes:

 > Untested code ahead.

 > m4_syscmd([test -f build.sh.in])dnl
 > m4_if(m4_sysval, 0, [AC_CONFIG_FILES(build.sh)])

Bad idea: side effects are incompatible with the (autom4te) cache.  If
the environment changes but not the sources of configure, it won't be
regenerated.  Similarly with what Automake needs to trace.

Re: Shipping generated file from generated generator

[Akim Demaille]

>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:

>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
 > [...]

 Akim> I don't know how to do that without using .SECONDARY,
 Akim> which doesn't appear to be universal amongst makes.  Is
 Akim> there a more portable solution?

 > I don't know of any, and I recommend against it.  A distributed
 > file should never depend upon a non-distributed built file (see
 > also node distcleancheck in the FAQ).

This limitation is a problem in our case, since our build time is
already way too long for the typical user, so we do want to pre-build
as much as possible.  In addition, the files I am referring to (those
that are generated) are demo-files (that also serve as test cases).
It is weird for demo-files not to be in srcdir.

But the suggested workaround (running $(MAKE)) is probably just what
we need.  Thanks!

Re: Shipping generated file from generated generator

[Akim Demaille]

>>> "Stepan" == Stepan Kasal <[EMAIL PROTECTED]> writes:

 > I guess the following should fix it:

 > $(generated_sources): $(makedoc_SOURCES) $(cmd_sources)
 >  make $(AM_MAKEFLAGS) makedoc$(EXEEXT)

$(MAKE)

 >  rm -f $(generated_sources)
 >  ./makedoc $(cmd_sources)

 > This way the generated_sources shouldn't be regenerated, if they are new
 > enough.


 >> Hm, reading more carefully, I see no connection between the
 >> generated_sources and what they are used to.

 > The dependency of the wole program on eg. key.c is done by the automake
 > variable infokey_SOURCES.

Ah, I was looking for generated_sources itself, not its contents.

 >> Also, I see no provision to generate these files in srcdir.  Are you
 >> really sure you ship and use them?

 > I guess ``make dist'' was always called in the main tree, so this
 > was not a problem. [*]

Nope, it was: distcheck always does a src != build configuration.
Unless distcheck was never used (booh :).

Re: Shipping generated file from generated generator

[Akim Demaille]

Hm, reading more carefully, I see no connection between the
generated_sources and what they are used to.  I would say your
Makefile is missing dependencies, that's why it 'works'.  But an
update of one of the cmd_sourcs will probably not update the whole
set, as it should.

Re: Shipping generated file from generated generator

[Akim Demaille]

>>> "Stepan" == Stepan Kasal <[EMAIL PROTECTED]> writes:

 > Hello Akim,

Hi!

 > --
 > noinst_PROGRAMS = makedoc
 > bin_PROGRAMS = ginfo infokey

 > makedoc_SOURCES = makedoc.c
 > ginfo_SOURCES = echo-area.c echo-area.h ... \
 >   doc.c funs.h
 > infokey_SOURCES = infokey.c infokey.h key.c key.h funs.h

 > generated_sources = doc.c key.c funs.h

 > $(generated_sources): makedoc$(EXEEXT) $(cmd_sources)
 >  rm -f $(generated_sources)
 >  $(top_builddir)/$(native_tools)/info/makedoc $(cmd_sources)

Warning: Read the node `Multiple Outputs' in Automake.texi.

 > cmd_sources = $(srcdir)/session.c $(srcdir)/echo-area.c $(srcdir)/infodoc.c \
 >   $(srcdir)/m-x.c $(srcdir)/indices.c $(srcdir)/nodemenu.c \
 >   $(srcdir)/footnotes.c $(srcdir)/variables.c

 > # The following hack is necessary to hint make before the automatic
 > # dependencies are built.  See the automake manual for a detailed explanation.
 > BUILT_SOURCES = funs.h
 > --

Do this work?  The sources are never re-generated on the user side?  I
don't see the difference with my case actually, but for me, it builds
the generator and rebuilds the generated-output.

Also, I see no provision to generate these files in srcdir.  Are you
really sure you ship and use them?

Shipping generated file from generated generator

[Akim Demaille]

Suppose you have a file generated-output that's built from feeding
generator with input.  generator itself is built from
generator.sources.

I would like to ship generated-output (hence it's in srcdir), to spare
the user the need to build it.  I don't know how to do that without
using .SECONDARY, which doesn't appear to be universal amongst makes.
Is there a more portable solution?

Here is a test case, under the form of a... test case :)



interm.test
Description: Binary data

It fails without the .SECONDARY.

nodist_info_TEXINFOS

[Akim Demaille]

How is one expected to request to ship some Texinfo files, but not the
info files, as these are to be built?

I found nothing in the documentation, and a naive

nodist_info_TEXINFOS = assignments.texi tiger.texi

does not ship the texi files (of course...).  And this, naive also,
approach does not solve the problem.

EXTRA_TEXINFOS = $(nodist_info_TEXINFOS)

Re: Mac OSX vs. VPATH vs. Automake's auto disted files

[Akim Demaille]

Le 23 août 04, à 18:58, Paul D. Smith a écrit :
%% Akim Demaille <[EMAIL PROTECTED]> writes:
  ad> I met a problem on Mac OSX, and diagnosed it as follows.  I 
would not
  ad> call this a problem in Automake.  Probably GNU Make 3.79 is the 
most
  ad> likely culprit, but at least I wanted to describe this issue in 
case
  ad> someone else finds it.

  ad> The problem is that
  ad> - Mac OSX (by default) is case preserving, but case insensitive
  ad> - Make, when looking for dependencies correctly understands this
This is not true.  Unless you are setting some special flags in the
build of GNU make (please let me know what they are if so) GNU make
always assumes normal UNIX filesystem semantics: that is, 
case-sensitive
and case-preserving.
Any means to get the flags from make itself?  I don't know how
Apple built it: that's stock Make.
What is probably happening here is that make is looking up the filename
and the underlying operating system sees that it does exist (because
it's case-insensitive).
But make does not understand this.
  ad> - but Make no longer understands this properly when meeting
  ad>   dependencies requires walking the VPATH and when the case is
  ad>   not exactly the same.
In this case what's probably happening is that VPATH is causing make to
read the directory structure into its directory cache, and then make is
looking through the list of files in the directory and doing string
comparisons to find the filename.  In this case, of course, the strings
will not match so the VPATH lookup fails.
OK.
There is a #define in the GNU make code called HAVE_CASE_INSENSITIVE_FS
which you can set if your filesystem is case-insensitive.  Set it in
config.h after the configure script has run; that might help.  If so we
can think about whether this is something that should always be set for
OSX.
I'm not sure about the "always".  It is my understanding that not all 
the FS
on MacOSX are case insensitive.

Re: .texi.html: Add a touch?

[Akim Demaille]

>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:

>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
 >> makeinfo does not update timestamps of directories:

 > Is there a problem with this patch?

Ping!

Re: .texi.html: Add a touch?

[Akim Demaille]

>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:

 > makeinfo does not update timestamps of directories:

Is there a problem with this patch?

Installing split Texinfo HTML files

[Akim Demaille]

Hi!

What is the recommended way to install split HTML documentation from
Texinfo?  It would be nice if Automake had the bit of magic to copy
directories, instead of simple files, in this precise.  In addition,
there is a small catch when the user does it by herself:  I had the
following in my Makefile.am:

install-data-local:
cp -r $(HTMLS) $(DESTDIR)$(htmldir)

And unfortunately this -local target is triggered before Automake's
code, which results in:

~/lectures/maintain % sudo -u doc make install   nostromo 14:46
make[1]: entrant dans le répertoire « /home/akim/lectures/maintain »
make[1]: Rien à faire pour « install-exec-am ».
cp -r maintain.html /mnt/dload/maintain
test -z "/mnt/dload/maintain" || mkdir -p -- . "/mnt/dload/maintain"
...

in other words, the directory is created after I meant to use it.  And
thanks to the changing semantics of cp, I obtained the content in
../maintain instead of ../maintain/maintain.html :)

Thanks in advance!

.texi.html: Add a touch?

[Akim Demaille]

makeinfo does not update timestamps of directories:


% ls -dltr maintain.{texi,html}  nostromo 15:12
drwxr-xr-x2 akim lrde 4096 2004-05-25 14:38 maintain.html/
-rw-r--r--1 akim lrde16132 2004-05-25 15:01 maintain.texi
% LC_ALL=C /bin/sh /home/akim/lectures/maintain/config/missing --run makeinfo --html 
--enable-encoding --number-sections --fill-column=76  -I . \
>  -o maintain.html maintain.texi
% ls -dltr maintain.{texi,html}
drwxr-xr-x2 akim lrde 4096 2004-05-25 14:38 maintain.html/  
-rw-r--r--1 akim lrde16132 2004-05-25 15:01 maintain.texi


which keeps this rule unsatisfied:

.texi.html:
$(MAKEINFOHTML) $(AM_MAKEINFOHTMLFLAGS) $(MAKEINFOFLAGS) -I $(srcdir) \
 -o $@ $<
if test ! -d $@ && test -d $(@:.html=); then \
  mv $(@:.html=) $@; else :; fi


This can cause bad problems when trying to install under a different
identity:

% sudo -u doc make install   nostromo 15:06
LC_ALL=C /bin/sh /home/akim/lectures/maintain/config/missing --run makeinfo --html 
--enable-encoding --number-sections --fill-column=76  -I . \
 -o maintain.html maintain.texi
/home/akim/lectures/maintain/maintain.html/index.html: Permission denied
make: *** [maintain.html] Erreur 1


so I suggest the following change:

Index: ChangeLog
from  Akim Demaille  <[EMAIL PROTECTED]>

* lib/am/texibuild.am (.texi.html): Touch the output to update its
timestamp, which is not performed by makeinfo when producing a
directory.

Index: lib/am/texibuild.am
===
RCS file: /cvs/automake/automake/lib/am/texibuild.am,v
retrieving revision 1.21
diff -u -u -r1.21 texibuild.am
--- lib/am/texibuild.am 15 May 2004 16:12:07 - 1.21
+++ lib/am/texibuild.am 25 May 2004 13:21:50 -
@@ -87,6 +87,8 @@
 ## instead of foo.html/).
if test ! -d $@ && test -d $(@:.html=); then \
  mv $(@:.html=) $@; else :; fi
+## makeinfo does not update the timestamp of the directory.
+   touch $@
 
 ## If we are using the generic rules, we need separate dependencies.
 ## (Don't wonder about %DIRSTAMP% here, this is used only by non-generic

Texi2Text

[Akim Demaille]

[Sorry for the delays, I have suffered sysadmin issues.]

1BGDpl-0001aY-Fa-D

Are there any plans of texi->text support?  The recent very welcome
addition of pdf and html targets seem to call for other outputs: plain
text, XML and so forth.

Automatic source filename computation

[Akim Demaille]

The fact that Automake infers some source file names from

check_PROGRAMS = test-foo

is really nice.  Nevertheless, it is nice to people who program in C,
and less to other languages.  Couldn't we look for test-foo.EXT with
EXT ranging a well defined series instead of the hard coded `c'?

I know it's a bit of magic, and it could be compared to globbing
support.  I find it weaker though, so more admissible.  An alternative
would be a DEFAULT_EXTENSION variable, that's more controlled.

Python & Automake

[Akim Demaille]

Hi!

I'm looking for the recommended way to handle Python executables.
I've read the current documentation, but it refers only to Python
libraries (unless I'm mistaken).

Looking for some inspiration, I found this old piece of code from
François Pinard, but it's problem completely outdated.



AUTOMAKE_OPTIONS = gnits
bin_SCRIPTS = libitize
pkgdata_DATA = libit.pyc

EXTRA_DIST = libitize.in libit.py

PYTHON = @PYTHON@

SUFFIXES = .py .pyc

.py.pyc:
@echo "Compiling $<..."
@$(PYTHON) -c "import py_compile; py_compile.compile('$<', '$*.pyc')"



[EMAIL PROTECTED]@
# Update a distribution by using libit files.
# Copyright © 2000 Progiciels Bourbeau-Pinard inc.
# François Pinard <[EMAIL PROTECTED]>, 2000.

# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.

# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.

# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

import string, sys
sys.path.insert(0, '@prefix@/share/@PACKAGE@')

package = '@PACKAGE@'
version = '@VERSION@'
prefix = '@prefix@'
datadir = string.replace('@datadir@', '${prefix}', prefix)
pkgdatadir = string.replace('@pkgdatadir@', '${datadir}', datadir)

import libit
apply(libit.main, tuple(sys.argv[1:]))


Aside from the needed update for the Makefile.am machinery, is the top
level generation and redirection the recommended way?

Re: RFC: doc for `Handling Tools that Produce Many Outputs'

[Akim Demaille]

 > Personally, I positively *like* "witness" - it describes what it is
 > in a colourful way.

For the records, this is the official English word for the same
concept in logic.  A witness of an existential quantifier \exists
x. P(x) is precisely a t such that P(t).  So I believe witness is
perfect for the current job.

I remember we had a similar debate for Autoconf years ago.  I can't
remember the point though.  Any witness?

Re: about requiring Perl 5.6 in Automake 1.9

[Akim Demaille]

 > I'm considering dropping support for Perl 5.005 in the future
 > Automake 1.9, and require at least Perl 5.6.  Perl 5.6 will be 4
 > years old next month, so it does not sound like asking for the
 > moon.

Actually, why not jumping to something really more recent.  Some
people will have to upgrade their Perl installation, so they probably
won't install 5.6 anyway.

Sarathy  5.6.1-TRIAL1  2000-Dec-18 The 5.6 maintenance track.
 5.6.1-TRIAL2  2001-Jan-31
 5.6.1-TRIAL3  2001-Mar-19
 5.6.1-foolish 2001-Apr-01 The "fools-gold" release.
 5.6.1 2001-Apr-08
Rafael   5.6.2-RC1 2003-Nov-08
 5.6.2 2003-Nov-15 Fix new build issues

Jarkko   5.7.0 2000-Sep-02 The 5.7 track: Development.
 5.7.1 2001-Apr-09
 5.7.2 2001-Jul-13 Virtual release candidate 0.
 5.7.3 2002-Mar-05
 5.8.0-RC1 2002-Jun-01
 5.8.0-RC2 2002-Jun-21
 5.8.0-RC3 2002-Jul-13
 5.8.0 2002-Jul-18
 5.8.1-RC1 2003-Jul-10
 5.8.1-RC2 2003-Jul-11
 5.8.1-RC3 2003-Jul-30
 5.8.1-RC4 2003-Aug-01
 5.8.1-RC5 2003-Sep-22
 5.8.1 2003-Sep-25
Nicholas 5.8.2-RC1 2003-Oct-27
 5.8.2-RC2 2003-Nov-03
 5.8.2 2003-Nov-05
 5.8.3-RC1 2004-Jan-07
 5.8.3 2004-Jan-14

Hugo 5.9.0 2003-Oct-27

How about 5.8?  What's the version shipped with current RedHats etc.?

Re: Current versions of automake and autoconf

[Akim Demaille]

 > (Answering only for Automake, because I've also been confused by
 > Akim's last statements about announcements that shouldn't be
 > considered official.)

Sorry about this.  I was trying to make a difference bw pre-released
on my web site, and really released on GNU site.  Maybe that was wrong
:(

It turns out that a beta, even if you emphasize the need to test it,
is not tested as thoroughly as a real release.  So I was finally quite
happy with having a (pre-)release spread in our community first, then
have some real feedback before making the real release.  This caught a
couple of weak releases by the past, but I realize that this releasing
scheme is a bit obscure.  Unfortunately it relied on this obscurity:
it is important, if you want some real feedback, that many people use
it as a real release.  So if I flag it as a pre-release, I doubt it
will be tested as thoroughly :(

In the future I'll try to be clearer.

And I'm open to suggestions on how to improve the feedback on Autoconf :)

Re: automake and i18n

[Akim Demaille]

 > Hi,
 > Akim Demaille wrote:
 >> > It is possible to do the internationalization in such a way, that
 >> > automake would still run without libintl-perl being installed.
 >> > License problems should not be an issue, libintl-perl is distributed
 >> > under the LGPL.  As for the required Perl version, Perl 5.004 is
 >> > sufficient for libintl-perl.
 >> > Comments?
 >> Do you know any maintainer that does not know English?  In other
 >> words, what's the use?  Will you translate the documentation too?

 > Why are other GNU developer packages like "make" or "gcc"
 > internationalized? 

Because they are already heavily documented elsewhere.  The two
precise examples you chose are GNU versions of world wide spread
utilities.

But I hear your point, I just beg to differ on the relative
importance.  And I'm waiting for requests to internationalize
configure, and the messages embedded in the Makefile rules :)

Re: automake and i18n

[Akim Demaille]

 > Hi,
 > beginning with version 0.13, GNU gettext has full support for Perl
 > scripts, with libintl-perl (http://search.cpan.org/dist/libintl-perl/)
 > there is a stable runtime environment for gettext like message
 > translation in Perl, and with yours truly there is somebody available
 > that would volunteer to make the necessary modifications for
 > internationalizing automake.

 > It is possible to do the internationalization in such a way, that
 > automake would still run without libintl-perl being installed.
 > License problems should not be an issue, libintl-perl is distributed
 > under the LGPL.  As for the required Perl version, Perl 5.004 is
 > sufficient for libintl-perl.

 > Comments?

Do you know any maintainer that does not know English?  In other
words, what's the use?  Will you translate the documentation too?

Re: RFE: Restricting a package to a particular automake version

[Akim Demaille]

 > When having several dozens of configure.ac's in source tree and even
 > more custom aclocal macros, causing 100's of warnings, you may relate
 > why I don't share your opinion.

perl -pi.bak -e 's/(AC_DEFUN\()(\w+\),/$1[$2],g' **/*.{ac,m4}

should make it!

Re: RFE: Restricting a package to a particular automake version

[Akim Demaille]

 > Hi,
 > With the release of automake-1.8 ahead, a request for enhancement:

 > automake-1.8 probably will be incompatible to automake-1.7

 > Up to now I have encountered 2 incompatiblities:
 > * The generating info files in $srcdir issue.

 > * aclocal complaining about underquoting in custom macros.

You can't call this an incompatibility!  It is only a warning, and a
very good warning: pacifying it means being on the safe side whatever
the version of Autoconf and/or Automake.

Re: Current versions of automake and autoconf

[Akim Demaille]

 > Anyway, back to Dalibor's question:

 >   2.57 is the last version announced to [EMAIL PROTECTED]
 >   2.58 is the last version available on ftp.gnu.org
 >   2.59 is the last version (pre-)announced to [EMAIL PROTECTED]

 > Which one is to be considered the last official release?  I
 > understand it's not 2.59; and you disgraced 2.58 in another
 > mail.  Next Automake needs at least 2.58, but if this is not an
 > official release we have to wait.

I'd like to see 2.59 uploaded asap.  Consider they are all official
releases now.  But I meant to avoid advertising 2.58 too much since it
has flaws that make it troublesome with Automake 1.8, while 2.59 is
OK.

But the release process at GNU has changed again, and I'm stuck with
my tarballs on my site.  I don't have enough time to learn yet another
uploading scheme, and I don't know whether Paul could make progress.

Other than that, 2.59 was released.  I'm just waiting for ftp.gnu.org
before sending the announcement to all the list, especially info-gnu.

Re: GNU Automake 1.7.9 released

[Akim Demaille]

>>> "Chuck" == Charles Wilson <[EMAIL PROTECTED]> writes:
 Chuck> What is this "Autoconf 2.59" of which you speak? I saw this
 Chuck> http://mail.gnu.org/archive/html/autoconf-patches/2003-11/msg00010.html
 Chuck> But there does not yet appear to be a tarball available.

 > I'm using the AUTOCONF-2_59 tag from CVS.  I didn't know it
 > hasn't been announced yet.  All I can say is that Akim is away
 > today and tomorrow, so you'll have to wait if you want an
 > official tarball.

I have a problem on my machine that prevents me from finishing the
releasing process :(

/tmp % cat foo.c  nostromo 9:16
int
main ()
{
  return 42;
}
/tmp % gcc foo.c  nostromo 9:49
/usr/bin/ld: cannot open crt1.o: No such file or directory
collect2: ld returned 1 exit status

When I have some time, I fix this, and finish the release :(

Re: Should -i mkdir?

[Akim Demaille]

 > On Sat, 2003-09-27 at 02:20, Alexandre Duret-Lutz wrote:
 adl> autopoint and libtoolize usually run before automake
 adl> and put things into this directory too.  So if some tools has to
 adl> create the directory, I think it should be autopoint.
 >> 
 >> Sorry, I meant "it should be autoreconf".

 > /if it's used/

I'm installing the following.  Thanks.

Index: ChangeLog
from  Akim Demaille  <[EMAIL PROTECTED]>

* lib/autom4te.in (Autoreconf-preselections): Trace AC_CONFIG_AUX_DIR.
* bin/autoreconf.in (autoreconf_current_directory): Create the
AUX_DIR if needed, for sake of automake --add-missing etc.
Suggested by Alexandre Duret-Lutz.

Index: NEWS
===
RCS file: /cvsroot/autoconf/autoconf/NEWS,v
retrieving revision 1.311
diff -u -u -r1.311 NEWS
--- NEWS 1 Oct 2003 10:29:39 - 1.311
+++ NEWS 3 Oct 2003 07:28:59 -
@@ -1,4 +1,10 @@
-* Major changes in Autoconf 2.57f   -*- outline -*-
+* Major changes in Autoconf 2.57g   -*- outline -*-
+
+** autoreconf and auxiliary directory
+  Autoreconf creates the auxiliary directory if needed.  This is
+  especially useful for initial "bootstrapping" of fresh CVS checkouts.
+
+* Major changes in Autoconf 2.57f
 
   Released 2003-10-01, by Akim Demaille.
 
Index: bin/autoreconf.in
===
RCS file: /cvsroot/autoconf/autoconf/bin/autoreconf.in,v
retrieving revision 1.119
diff -u -u -r1.119 autoreconf.in
--- bin/autoreconf.in 25 Aug 2003 06:38:39 - 1.119
+++ bin/autoreconf.in 3 Oct 2003 07:28:59 -
@@ -423,6 +423,7 @@
   # Perform a single trace reading to avoid --force forcing a rerun
   # between two --trace, that's useless.  If there is no AC_INIT, then
   # we are not interested: it looks like a Cygnus thingy.
+  my $aux_dir;
   my $uses_gettext_via_traces;
   my $uses_libtool;
   my $uses_autoheader;
@@ -433,6 +434,7 @@
  . join (' --trace=', '',
 # If you change this list, update the
 # `Autoreconf-preselections' section of autom4te.in.
+'AC_CONFIG_AUX_DIR:AC_CONFIG_AUX_DIR:\$1',
 'AC_CONFIG_HEADERS',
 'AC_CONFIG_SUBDIRS:AC_CONFIG_SUBDIRS:\$1',
 'AC_INIT',
@@ -442,6 +444,7 @@
  . ' |');
   while ($_ = $traces->getline)
 {
+  $aux_dir = $1 if /AC_CONFIG_AUX_DIR:(.*)/;
   $uses_autoconf = 1if /AC_INIT/;
   $uses_gettext_via_traces = 1  if /AM_GNU_GETTEXT/;
   $uses_libtool = 1 if /AC_PROG_LIBTOOL/;
@@ -468,6 +471,24 @@
 if $uses_gettext_via_traces && ! $uses_gettext;
   error "$configure_ac: AM_GNU_GETTEXT_VERSION is used, but not AM_GNU_GETTEXT"
 if $uses_gettext && ! $uses_gettext_via_traces;
+
+
+  #  #
+  # Setting up the source tree.  #
+  #  #
+
+  # libtoolize, automake --add-missing etc. will drop files in the
+  # $AUX_DIR.  But these tools fail to install these files if the
+  # directory itself does not exist, which valid: just imagine a CVS
+  # repository with hand written code only (there is not even a need
+  # for a Makefile.am!).
+
+  if (defined $aux_dir && ! -d $aux_dir)
+{
+  verb "$configure_ac: creating directory $aux_dir";
+  mkdir $aux_dir
+   or error "cannot create $aux_dir: $!";
+}
 
 
   #  #
Index: lib/autom4te.in
===
RCS file: /cvsroot/autoconf/autoconf/lib/autom4te.in,v
retrieving revision 1.20
diff -u -u -r1.20 autom4te.in
--- lib/autom4te.in 19 Aug 2003 07:58:37 - 1.20
+++ lib/autom4te.in 3 Oct 2003 07:28:59 -
@@ -61,6 +61,7 @@
 ## -- ##
 
 begin-language: "Autoreconf-preselections"
+args: --preselect AC_CONFIG_AUX_DIR
 args: --preselect AC_CONFIG_HEADERS
 args: --preselect AC_CONFIG_SUBDIRS
 args: --preselect AC_INIT

Re: Thanks for real good thing!

[Akim Demaille]

 > Hello, GNU autotools contributors!
 > Im just ajust my package for realy good building. And I would like to
 > thank you for realy powerful and useful tool :)

This is probably the wrong list: you are probably not referring to the
Autotools: Autoconf, Automake, and Libtool.

Or else, you're one of a kind :)

Autoconf 2.57f is released

[Akim Demaille]

This is our candidate release for Autoconf 2.58.  We plan to release
it soon, so that Automake 1.8 can be released, hence Libtool 1.6, so
that GNU M4 2.0 can be shipped, enabling Autoconf 2.60 ;)

Please, test it thoroughly.

Akim, Alexandre, Jim, Paul, and Tom.


Here are the compressed sources:
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57f.tar.gz   (1.2MB)
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57f.tar.bz2  (837KB)

And here are xdelta-style diffs:
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57d-2.57f.xdelta   (10KB)

Here are GPG detached signatures:
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57f.tar.gz.asc
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57f.tar.bz2.asc

Here are the MD5 and SHA1 signatures:

dd48fe8cf425f7068d729aa432df4527  autoconf-2.57f.tar.gz
385a923859a0e02e4c6f0ccc4f29b137  autoconf-2.57f.tar.bz2
4f342dbfbcee2648e7426c3f46f59fb8  autoconf-2.57d-2.57f.xdelta
9b1f3a2bfeb21e80813619e86cc5a52b7edaffbb  autoconf-2.57f.tar.gz
5dd5018ae395ed627384caf69460fea5006a037e  autoconf-2.57f.tar.bz2
2cda92c4f05799ace152744927152a1645030287  autoconf-2.57d-2.57f.xdelta

NEWS

* Major changes in Autoconf 2.57f

  Released 2003-10-01, by Akim Demaille.

* Major changes in Autoconf 2.57e

  Released 2003-09-29, by Akim Demaille.

** AC_CONFIG_COMMANDS
  The directory for its first argument is automatically created.  For
  instance, with

  AC_CONFIG_COMMANDS([src/modules.hh], [...])

  $top_builddir/src/ is created if needed.


ChangeLog entries:

**
ChangeLog
**
2003-10-01  Akim Demaille  <[EMAIL PROTECTED]>

Version 2.57f.

2003-09-30  Paul Eggert  <[EMAIL PROTECTED]>

* lib/Autom4te/XFile.pm: Use Errno.
(lock): Ignore ENOLCK errors.  Problem reported Andreas Schwab in
<http://mail.gnu.org/archive/html/bug-autoconf/2003-09/msg00141.html>.

2003-09-30  Akim Demaille  <[EMAIL PROTECTED]>

* config/announce-gen (&print_news_deltas): Extracted from...
(&print_changelog_deltas): here.
(&news_file): Rename as...
(@news_file): this.

2003-09-30  Nicolas Joly  <[EMAIL PROTECTED]>

* lib/autoconf/fortran.m4 (_AC_PROG_FC): Remove files which might
have been created when invoking the compiler.
* tests/fortran.at (GNU Fortran 77): Quote $G77.

2003-09-29  Akim Demaille  <[EMAIL PROTECTED]>

Version 2.57e.

* config/mkinstalldirs: Upgrade.

2003-09-28  Paul Eggert  <[EMAIL PROTECTED]>

* lib/m4sugar/m4sh.m4 (AS_SHELL_SANITIZE): Set DUALCASE=1, for MKS sh.
Problem reported by Lars J. Aas in
<http://mail.gnu.org/archive/html/autoconf/2003-07/msg00042.html>.
(_AS_MKDIR_P_PREPARE): Change "rm -fr ./-p" to the more-conservative
"test -d ./-p && rmdir ./-p".  Suggested by Andreas Schwab in:
    http://mail.gnu.org/archive/html/autoconf-patches/2003-09/msg00039.html

2003-09-26  Akim Demaille  <[EMAIL PROTECTED]>

* lib/autoconf/status.m4 (_AC_OUTPUT_COMMANDS): Make sure the
directory for AC_CONFIG_COMMANDS' first argument exists.
This makes valid the invocation of _AC_SRCPATH that follows.
Reported by Eric Sunshine.
* doc/autoconf.texi (Configuration Commands): Adjust.

2003-09-26  Akim Demaille  <[EMAIL PROTECTED]>

* bin/autoscan.in (Autom4te::FileUtils): Use it for find_file.
Reported by Ralf Corsepius.

2003-09-26  Akim Demaille  <[EMAIL PROTECTED]>

* lib/autoconf/general.m4 (AC_HELP_STRING): Don't overquote the
arguments.
Actually, use AU_ALIAS.
From Bruno Haible.

2003-09-26  Paul Eggert  <[EMAIL PROTECTED]>

* lib/m4sugar/m4sh.m4 (_AS_MKDIR_P_PREPARE): If mkdir -p . fails,
rm -fr ./-p to remove junk left behind on NextStep and OpenStep.
Problem reported by Eric Sunshine in:
http://mail.gnu.org/archive/html/autoconf-patches/2002-12/msg00014.html

2003-09-26  Akim Demaille  <[EMAIL PROTECTED]>

The test suite are sometimes assigning timings incorrectly.
Reported by Henk Krus.
Diagnosed by Nicolas Joly.

* lib/autotest/general.m4 (AT_CLEANUP): Rename AT_help as
AT_help_all.
Instead of making AT_help a sequence of assignments to grow
$at_help_all, just make AT_help_all be the growing contents of
$at_help_all, and make a single assignment in...
(AT_INIT): here.
(at_times_skip): Flip the meaning and rename as...
(at_times_p): this.
(AT_INIT): When summarizing the test that ran, remove
$at_times_file after use, and check it is present before trying to
use it.

Autoconf 2.57d released

[Akim Demaille]

<#secure method=pgpmime mode=sign>

This is our candidate release for Autoconf 2.58.  We plan to release
it soon, so that Automake 1.8 can be released, hence Libtool 1.6, so
that GNU M4 2.0 can be shipped, enabling Autoconf 2.60 ;)

Please, test it thoroughly.

Akim, Alexandre, Jim, Paul, and Tom.

Here are the compressed sources:
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57d.tar.gz   (1.2MB)
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57d.tar.bz2  (837KB)

And here are xdelta-style diffs:
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57b-2.57d.xdelta   (26KB)

Here are GPG detached signatures:
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57d.tar.gz.asc
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57d.tar.bz2.asc

Here are the MD5 and SHA1 signatures:

2fd6b2ce93c20272114580696b873b13  autoconf-2.57d.tar.gz
11283066884ee9dac83b9e6d9a7870f4  autoconf-2.57d.tar.bz2
f1bf3224ee351de53229c8e3957ac888  autoconf-2.57b-2.57d.xdelta
810ea71de4c866970f76079036847c63ad605d77  autoconf-2.57d.tar.gz
be65e491f94df9e1fa0aa272df78848d0ef2ac84  autoconf-2.57d.tar.bz2
92306a504a352c140c7795839cfe374f7e931046  autoconf-2.57b-2.57d.xdelta

NEWS

* Major changes in Autoconf 2.57d

* Major changes in Autoconf 2.57b

  Released 2003-08-24, by Akim Demaille.

** Autotest and local.at
  The optional file local.at is always included in Autotest test suites.

** Warnings
  The warnings are always issued, including with cached runs.
  This became a significant problem since aclocal and automake can
  run autoconf behind the scene.

** autoheader warnings
  The warnings of autoheader can be turned off, using --warning.
  For instance, -Wno-obsolete disables the complaints about acconfig.h
  and other deprecated constructs.

* Major changes in Autoconf 2.57a

** New macros
  AC_C_RESTRICT, AC_INCLUDES_DEFAULT.

** AC_DECL_SYS_SIGLIST
  Works again.

** AC_FUNC_MKTIME
  Now checks that mktime is the inverse of localtime.

** Improve DJGPP portability
  The Autoconf tools and configure behave better under DJGPP.

** Present But Cannot Be Compiled
  New FAQ section dedicated to the mystic

configure: WARNING: pi.h: present but cannot be compiled
configure: WARNING: pi.h: check for missing prerequisite headers?
configure: WARNING: pi.h: proceeding with the preprocessor's result
  messages.

** Concurrent executions of autom4te
  autom4te now locks its internal files, which enables concurrent
  executions of autom4te, likely to happen if automake, autoconf,
  autoheader etc. are run simultaneously.

** Libtool
  Use of Libtool 1.5 and higher is encouraged.  Compatibility with
  Libtool pre-1.4 is not checked.

** Autotest
  Testsuites no longer rerun failed tests in verbose mode; instead,
  failures are logged while the test is run.

  In addition, expected failures can be marked as such.



ChangeLog entries:

**
ChangeLog
**
2003-09-25  Akim Demaille  <[EMAIL PROTECTED]>

Version 2.57d.

* bin/Makefile.am (edit): Handle '@configure_input@'.
(autoconf, autoheader, autom4te, autoreconf, autoscan, autoupdate)
(ifnames): chmod -w.
* tests/wrapper.as (AUTOCONF, AUTOM4TE, ): Point to tests/
executables, not bin/ executables!  Otherwise all the magic needed
to find non installed files is turned off.  This caused a failure
of test 40 and 41 that ran aclocal 1.8 which in turn ran autom4te
as found in its environment (sent by tests/autoreconf): pointing
to bin/autom4te that could not find its files.
* tests/mktests.sh: Force the replacement of generated files, for
the sake of "mv" program that are interactive when overwriting a
-w file.
* config/install-sh: Upgrade from CVS Automake.

2003-09-23  Paul Eggert  <[EMAIL PROTECTED]>

* doc/autoconf.texi (Limitations of Builtins): Document test -h
versus test -L issues.

2003-09-23  Daniel Jacobowitz  <[EMAIL PROTECTED]> and
Paul Eggert <[EMAIL PROTECTED]>

Trivial change to support GCC's configuration procedure.
* lib/autoconf/c.m4 (AC_PROG_CPP_WERROR): New macro.
* lib/autoconf/headers.m4 (_AC_CHECK_HEADER_MONGREL): Don't warn
about inconsistency if the preprocessor is set to give errors for
any warning.
* doc/autoconf.texi (C Compiler Characteristics): Document this.

2003-09-13  Alexandre Duret-Lutz  <[EMAIL PROTECTED]>

* Makefile.am (autom4te-update, autom4te_files): Fetch Struct.pm
and XFile.pm from Automake.
    * lib/Autom4te/XFile.pm: Update from Automake.

2003-09-12  Akim Demaille  <[EMAIL PROTECTED]>

Version 2.57c.

2003-09-12  Akim Demaille  <[EMAIL PROTECTED]>

* config/config.guess, 

Should -i mkdir?

[Akim Demaille]

Several projects used config/ without any hand written file in it,
thanks to Automake's wonderful ability to ship the files all by
itself.  But then, often, such projects, when just checked out, or
de-tar'ed by hand, don't have a config/.  Et soudain, c'est
l'accident :

~/src/vampire % autoreconf -fvi   nostromo 9:55
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/local/bin/autoconf --force
autoreconf: configure.ac: not using Autoheader
autoreconf: running: automake --add-missing --copy --force-missing
cp: cannot create regular file `config/install-sh': No such file or directory
configure.ac: installing `config/install-sh'
configure.ac: error while copying
cp: cannot create regular file `config/mkinstalldirs': No such file or directory
configure.ac: installing `config/mkinstalldirs'
configure.ac: error while copying
cp: cannot create regular file `config/missing': No such file or directory
configure.ac: installing `config/missing'
configure.ac: error while copying
cp: cannot create regular file `config/mdate-sh': No such file or directory
doc/texinfo/Makefile.am:20: installing `config/mdate-sh'
doc/texinfo/Makefile.am:20: error while copying
cp: cannot create regular file `config/texinfo.tex': No such file or directory
doc/texinfo/Makefile.am:20: installing `config/texinfo.tex'
doc/texinfo/Makefile.am:20: error while copying
autoreconf: automake failed with exit status: 1



So, should automake -i make sure the directory exists and create it if
needed?  Or that would be considered unsafe (a typo in the name, et
voilà, a nasty dir pollutes your codeshore).

Re: Copying vs m4_including macro files

[Akim Demaille]

 > On Wed, Sep 24, 2003 at 02:19:06PM +0200, Akim Demaille wrote:
 >> At the origin I was considering that AC_CONFIG_M4_DIR was
 >> automatically passed to m4 as a -I, so instead of
 >> m4_include([config/init.m4]) etc. you'd have m4_include([init.m4]).

 > Isn't there a chicken'n'egg problem?  How can you trace for
 > AC_CONFIG_M4_DIR if you need the result to run m4 properly?

Right, there was something like that :)

Re: Copying vs m4_including macro files

[Akim Demaille]

 >> The autoconf part of this feature is trivial (I can provide a patch if
 >> that's useful), but I suspect I'd need to be able to write perl to
 >> implement the aclocal end :-)

 > Fortunately, if we consider relative directories as local, we don't
 > need to look at AC_CONFIG_M4_DIR.  Adding this macro to Autoconf is
 > probably a good thing for the future, though.

At the origin I was considering that AC_CONFIG_M4_DIR was
automatically passed to m4 as a -I, so instead of
m4_include([config/init.m4]) etc. you'd have m4_include([init.m4]).

Re: Variable substitution in source files

[Akim Demaille]

 > I have a number of files that need variable substitution, so I do this in 
 > a Makefile.am:

 > foo: foo.in
 > @rm -f foo
 > @sed \
 > -e 's,@@perlmoduledir@@,$(libexecdir)/perl,' \
 > -e 's,@@swishbindir@@,$(bindir),' \
 > -e 's,@@perlbinary@@,$(PERL),' \
 > $(srcdir)/foo.in > foo

 > But I'm doing that in more and more Makefile.am files in my project 
 > tree -- and sometimes I need to do it to a file where there isn't a 
 > Makefile in that directory.

 > I'm feeling like I'm using the same bit of sed code in too many places.
 > Is there a better way to manage this?  I'd like to have the sed code 
 > (above) defined in one place and then maybe list all the files that need 
 > to be operated on.

Use "include"?

Re: Help - I'm going mad!!! /bin/bash: --gnu: command not found

[Akim Demaille]

 > %% "Dr. David Kirkby" <[EMAIL PROTECTED]> writes:
 dk> make[1]: Entering directory `/export/home/davek/atlc/src'
 dk> cd .. && \
 dk> --gnu  src/Makefile
 dk> /bin/bash: --gnu: command not found

This mean AUTOMAKE is empty.

Autoconf 2.57b released

[Akim Demaille]

rm -f autoconf-2.57b.tar.bz2.asc
gpg --armor --detach-sign -o autoconf-2.57b.tar.bz2.asc autoconf-2.57b.tar.bz2
rm -f autoconf-2.57b.tar.gz.asc
gpg --armor --detach-sign -o autoconf-2.57b.tar.gz.asc autoconf-2.57b.tar.gz

<#secure method=pgpmime mode=sign>

The team is happy to make a long overdue step forward a release of
Autoconf 2.58.  Unfortunately, many of the submitted new features will
not make it into the next release, but, if time permits, one may
expect a 2.59 to include these.

Because Automake 1.8 is making significant progress, because it needs
Autoconf to fix some issue, 2.58 should be released in the near future.
Please, test it intensively.

I invite the people who participated to this release to submit some
NEWS.

Note that:

- I'm new to this release process, so there is plenty of information
  on this generated template announcement I'm not sure what I should
  do with (such as the four first lines).  Ignore them...

- My Fencepost account is not reactivated yet, so you might have to
  download from

  http://www.lrde.epita.fr/~akim/download/autoconf-2.57b.tar.gz   (1.1MB)
  http://www.lrde.epita.fr/~akim/download/autoconf-2.57b.tar.bz2  (836KB)

Enjoy!

Akim, Alexandre, Jim, Paul, and Tom.

--

Here are the compressed sources:
  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.57b.tar.gz   (1.1MB)
  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.57b.tar.bz2  (836KB)

And here are xdelta-style diffs:
  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.57a-2.57b.xdelta   (37KB)

Here are GPG detached signatures:
  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.57b.tar.gz.asc
  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.57b.tar.bz2.asc

Here are the MD5 and SHA1 signatures:

938f2f34126a9f243c6613ad86f4c117  autoconf-2.57b.tar.gz
3e5b20067bcc34b4621c35f7b517f1c4  autoconf-2.57b.tar.bz2
af930258b7157194b930c2abe5fae706  autoconf-2.57a-2.57b.xdelta
dff9f703b12a8d2d0db5f2aa01fac3734d35c0c5  autoconf-2.57b.tar.gz
c2a8c7e1ae802ae202ce1e0439413e100e43b1c9  autoconf-2.57b.tar.bz2
10b6db255bbb5e97821f15f195d08b1c888d0edc  autoconf-2.57a-2.57b.xdelta

NEWS

* Major changes in Autoconf 2.57b   -*- outline -*-

** Autotest and local.at
  The optional file local.at is always included in Autotest test suites.

** Warnings
  The warnings are always issued, including with cached runs.
  This became a significant problem since aclocal and automake can
  run autoconf behind the scene.


ChangeLog entries:

**
ChangeLog
******
2003-08-22  Akim Demaille  <[EMAIL PROTECTED]>

Version 2.57b.

* Makefile.cfg (local-checks-to-skip): New.
* Makefile.maint (local-check): Rename as...
(local-checks-available): this.
(local-check): New.

* Makefile.am (EXTRA_DIST): Add Makefile.cfg.
* configure.ac: Require Automake 1.7.6.

2003-08-22  Akim Demaille  <[EMAIL PROTECTED]>

Output stack traces in warnings.

* lib/m4sugar/m4sugar.m4 (_m4_warn): New.
Replace the former...
(m4_warn): Pass the call stack to _m4_warn.
* bin/autom4te.in: Adjust to output the call stack.
* tests/m4sugar.at (m4@&[EMAIL PROTECTED]): Adjust.

2003-08-22  Akim Demaille  <[EMAIL PROTECTED]>

* lib/Autom4te/Request.pm, lib/Autom4te/C4che.pm: New.
* bin/autom4te.in: Adjust.

2003-08-21  Akim Demaille  <[EMAIL PROTECTED]>

* lib/Autom4te/General.pm (&file_name_is_absolute): Remove.
(&verbose): Remove.
(&getopt): Adjust the note and verb channels, depending upon
--verbose.
* bin/autoheader.in, bin/autom4te.in, bin/autoscan.in,
* bin/autoupdate.in: Adjust.
    Use &verb, not &verbose.

2003-08-21  Akim Demaille  <[EMAIL PROTECTED]>

* bin/autoheader.in (&parse_args): Use &parse_warnings and
&parse_WARNINGS.
($help): Use Autom4te::ChannelDefs::usage.
* bin/autoscan.in: Use Autom4te::ChannelDefs.
* lib/Autom4te/General.pm: Don't export error: you don't own it.

2003-08-21  Akim Demaille  <[EMAIL PROTECTED]>

First stab at preserving warnings between calls to autom4te,
including when the cache is used.

There are still several issues: (i) there are too many runs of m4
(one for include, one for warnings, and some more), (ii) warnings
spreading on several lines are not handled gracefully, (iii) the
code meant to have the call stack display for errors does not work
(its handling should move from m4 to autom4te).

* bin/autom4te.in Autom4te::Channels, Autom4te::ChannelDefs):
Use them.
(@preselect): Add m4_warn.
($exit_status): Remove, use $exit_code.
   

Re: txinfo trivial failures

[Akim Demaille]

Alexandre:
 > Texi2dvi runs something like

 >   tex --help &1

 > On your system it seems to print "fflush error on stdout" and create
 > texput.log as a side effect.  On mine it works just fine (i.e. it
 > prints the help -- I have TeX (Web2C 7.4.5) 3.14159).

 > So I think texi2dvi should be changed to clean texput.log
 > afterwards (or run tex --help in a temporary directory).

I suggest this patch, which includes another one pending for Texinfo.

Index: ChangeLog
from  Akim Demaille  <[EMAIL PROTECTED]>

Workaround a TeX bug: --file-line-error-style '\nonstopmode'
does not honor the non stop mode request.
Also, make sure 'tex --help' is run in tmp to avoid leaving
texput.log.

* util/texi2dvi (tex_help): New.
(tex_args): Instead of using '\nonstopmode', pass
'--interaction=nonstopmode'.

Index: util/texi2dvi
===
RCS file: /cvsroot/texinfo/texinfo/util/texi2dvi,v
retrieving revision 1.24
diff -u -u -r1.24 texi2dvi
--- util/texi2dvi 2 Jul 2003 14:23:28 - 1.24
+++ util/texi2dvi 22 Aug 2003 08:15:55 -
@@ -491,15 +491,21 @@
   ;;
   esac
 
+  # Not all TeX handle --help gracefully.
+  tex_help=`cd $tmpdir >/dev/null && $tex --help &1`
+
   # If possible, make TeX report error locations in GNU format.
   tex_args=
-  case `$tex --help &1` in
-   *file-line-error-style*) tex_args='--file-line-error-style';;
+  case $tex_help in
+   *file-line-error-style*) tex_args="$tex_args --file-line-error-style";;
   esac
 
   # Tell TeX to be batch if requested.  (\batchmode does not show
   # terminal output at all, so we don't want that.)
-  $batch && tex_args="$tex_args ${escape}nonstopmode ${escape}input"
+  $batch &&
+case $tex_help in
+ *interaction*) tex_args="$tex_args --interaction=nonstopmode";;
+esac
 
   # Expand macro commands in the original source file using Makeinfo.
   # Always use `end' footnote style, since the `separate' style

Re: INSTALL_SCRIPT

[Akim Demaille]

 > On Tue, 2003-07-15 at 08:57, Ralf Corsepius wrote:
 >> On Tue, 2003-07-15 at 08:25, Alexandre Duret-Lutz wrote:

 >> I'll try to contact the original reporter, but currently would assume
 >> this to be a local bug in the package or a miss-understanding by the
 >> original reporter.

 > This problem seemed to be caused by a broken install script reportedly
 > shipped with OpenAFS, the user accidentally had in $PATH.

 > For the full story, cf.
 > http://www.oarcorp.com/rtems/maillistArchives/rtems-users/2003/july/msg00053.html

Isn't this another clear sign that the existing AC_PROG_INSTALL is
pure junk?  That we should really test for the feature we _desire_,
i.e., "install FILES DIR".

Re: distdir.am v1.47

[Akim Demaille]

 > I am getting
 > sed: 1: "1{h;s/./=/g;p;x}": extra characters at the end of x command
 > gmake: *** [distcheck] Error 1

 > which I think comes from

 > RCS file: /cvs/automake/automake/lib/am/distdir.am,v
 > retrieving revision 1.46
 > retrieving revision 1.47
 > diff -r1.46 -r1.47
 > ...
 > 348,350c351,353
 > <   $(am__remove_distdir)
 > <   @echo "$(distdir).tar.gz is ready for distribution" | \
 > < sed 'h;s/./=/g;p;x;p;x'
 > ---
 >> @(echo "$(distdir) archives ready for distribution: "; \
 >> for i in $(DIST_ARCHIVES); do echo $$i; done) | \
 >> sed -e '1{h;s/./=/g;p;x}' -e '$${p;x}'


 > This seems to make my NetBSD sed unhappy... Thoughts?

I'm installing the following.

Index: ChangeLog
from  Akim Demaille  <[EMAIL PROTECTED]>

* lib/am/distdir.am: Use ';' as a terminator, not a separator, for
sed complex commands, as required by NetBSD sed.
Reported by Patrick Welche.

Index: Makefile.in
===
RCS file: /cvs/automake/automake/Makefile.in,v
retrieving revision 1.438
diff -u -u -r1.438 Makefile.in
--- Makefile.in 3 Jul 2003 18:58:49 - 1.438
+++ Makefile.in 5 Jul 2003 08:21:36 -
@@ -585,7 +585,7 @@
$(am__remove_distdir)
@(echo "$(distdir) archives ready for distribution: "; \
  list='$(DIST_ARCHIVES)'; for i in $$list; do echo $$i; done) | \
- sed -e '1{h;s/./=/g;p;x}' -e '$${p;x}'
+ sed -e '1{h;s/./=/g;p;x;}' -e '$${p;x;}'
 distuninstallcheck:
@cd $(distuninstallcheck_dir) \
&& test `$(distuninstallcheck_listfiles) | wc -l` -le 1 \
Index: stamp-vti
===
RCS file: /cvs/automake/automake/stamp-vti,v
retrieving revision 1.252
diff -u -u -r1.252 stamp-vti
--- stamp-vti 4 Jul 2003 22:13:52 - 1.252
+++ stamp-vti 5 Jul 2003 08:21:36 -
@@ -1,4 +1,4 @@
[EMAIL PROTECTED] UPDATED 4 July 2003
[EMAIL PROTECTED] UPDATED 5 July 2003
 @set UPDATED-MONTH July 2003
 @set EDITION 1.7a
 @set VERSION 1.7a
Index: version.texi
===
RCS file: /cvs/automake/automake/version.texi,v
retrieving revision 1.324
diff -u -u -r1.324 version.texi
--- version.texi 4 Jul 2003 22:13:52 - 1.324
+++ version.texi 5 Jul 2003 08:21:36 -
@@ -1,4 +1,4 @@
[EMAIL PROTECTED] UPDATED 4 July 2003
[EMAIL PROTECTED] UPDATED 5 July 2003
 @set UPDATED-MONTH July 2003
 @set EDITION 1.7a
 @set VERSION 1.7a
Index: lib/am/distdir.am
===
RCS file: /cvs/automake/automake/lib/am/distdir.am,v
retrieving revision 1.49
diff -u -u -r1.49 distdir.am
--- lib/am/distdir.am 2 Jul 2003 20:53:07 - 1.49
+++ lib/am/distdir.am 5 Jul 2003 08:21:36 -
@@ -351,7 +351,7 @@
$(am__remove_distdir)
@(echo "$(distdir) archives ready for distribution: "; \
  list='$(DIST_ARCHIVES)'; for i in $$list; do echo $$i; done) | \
- sed -e '1{h;s/./=/g;p;x}' -e '$${p;x}'
+ sed -e '1{h;s/./=/g;p;x;}' -e '$${p;x;}'
 
 ## Define distuninstallcheck_listfiles and distuninstallcheck separately
 ## from distcheck, so that they can be overridden by the user.

Re: icc dependency generation

[Akim Demaille]

 > On Thu, Jun 26, 2003 at 11:23:04AM +0200, Ralf Wildenhues wrote:
 >> Intel compiler icc version 7.1 handles the -MF option inconsistently.
 >> Documentation states that it has to be used together with -M or -MM.
 >> If used with -MD, for example, it will replace the file ending with .d:
 > [...]
 >> Subsequently, the depcomp 'icc' mode will not be detected correctly
 >> during the ./configure run, since it uses '-MD -MF'.

 > This sucks.  If -MF cannot work with -MD, depcomp will have to call icc
 > twice: one time to get dependency information, and another time to do
 > the actual compilation.  This will be slower.

 > Or we could use -MD alone, but as ICC does respect subdirectories (at
 > least with ICC 7.0, compiling foo/bar.c with -MD would create ./bar.d
 > instead of foo/bar.d -- could you check this with 7.1?) we'd need to
 > implement some locking scheme in depcomp so that compiling foo/bar.c
 > and baz/bar.c in parallel do not write the same bar.d.

 >> Any suggestions?

 > Complain to Intel, if not already done.

 >> Which compiler version is the current depcomp supposed
 >> to work with?

 > 7.0

Err, maybe my message went unnoticed, but you might find additional
information here too.

From: Akim Demaille <[EMAIL PROTECTED]>
Subject: Re: Icc 7.0, distcc, Automake
To: [EMAIL PROTECTED]
cc: Automake List <[EMAIL PROTECTED]>
Date: Thu, 26 Jun 2003 11:01:12 +0200
X-Sent: 3 hours, 45 minutes, 35 seconds ago


For the records, I'm using the following script.  It results in a
correct compilation with Automake, Icc, and Distcc.

[4. text/x-sh; dicc]

#! /bin/sh

icc=/home/lrde/lrde/usr/bin/icc

# ICC needs to be taught that *.ii is C++.
# The wonderful news is that:
#
# % /home/lrde/lrde/usr/bin/icc I-dont-exist
# ld: cannot open I-dont-exist: No such file or directory
# % /home/lrde/lrde/usr/bin/icc -c I-dont-exist
#
# icc per se does not complain about missing files...  That's
# why understanding the problems takes so long
case "$@" in
  *.cc*|*.cpp*) set -- -Kc++ "$@" ;;
esac

# ICC is not able to honor both -E and -M, but Automake wants -M,
# and -E will be added by distcc.
case "$@" in
  *-M*)
  # Push a token among the arguments that will be used to notice when we
  # ended options/arguments parsing.
  arg_sep="$$--$$"
  set -- "$@" "$arg_sep"
  
  # 
  # Parse command line arguments.
  while test x"$1" != x"$arg_sep"; do
case "$1" in
  -MF) shift
   minus_M_args="$minus_M_args -MF$1" ;;   
  -M*) minus_M_args="$minus_M_args $1" ;;
  -E)  minus_E=-E;;
  *) set -- "$@" "$1";;
 esac
 shift
  done
  # Pop the token
  shift
  ;;
esac
if test "x$minus_E" != x; then
  echo "$0: don't know what to do with -E" >&2
fi

if test "x$minus_M_args" != x; then
  $icc $minus_M_args "$@"
fi
exec /usr/bin/distcc $icc "$@"

But the speedup is really miserable: none AFAICS (on several runs).  I
must say that my src hierarchy is poor for -j, as it heavily uses
Automake and many small modules compiled sequentially.  Here are the
figure I get:

make -j4 CC=icc CXX=icc  250,09s user 17,22s system 46% cpu 9:38,68 total

make -j4 CC=dicc CXX=dicc  257,89s user 22,69s system 55% cpu 8:22,51 total
--

Re: Icc 7.0, distcc, Automake

[Akim Demaille]

For the records, I'm using the following script.  It results in a
correct compilation with Automake, Icc, and Distcc.

#! /bin/sh

icc=/home/lrde/lrde/usr/bin/icc

# ICC needs to be taught that *.ii is C++.
# The wonderful news is that:
#
# % /home/lrde/lrde/usr/bin/icc I-dont-exist
# ld: cannot open I-dont-exist: No such file or directory
# % /home/lrde/lrde/usr/bin/icc -c I-dont-exist
#
# icc per se does not complain about missing files...  That's
# why understanding the problems takes so long
case "$@" in
  *.cc*|*.cpp*) set -- -Kc++ "$@" ;;
esac

# ICC is not able to honor both -E and -M, but Automake wants -M,
# and -E will be added by distcc.
case "$@" in
  *-M*)
  # Push a token among the arguments that will be used to notice when we
  # ended options/arguments parsing.
  arg_sep="$$--$$"
  set -- "$@" "$arg_sep"
  
  # 
  # Parse command line arguments.
  while test x"$1" != x"$arg_sep"; do
case "$1" in
  -MF) shift
   minus_M_args="$minus_M_args -MF$1" ;;   
  -M*) minus_M_args="$minus_M_args $1" ;;
  -E)  minus_E=-E;;
  *) set -- "$@" "$1";;
 esac
 shift
  done
  # Pop the token
  shift
  ;;
esac
if test "x$minus_E" != x; then
  echo "$0: don't know what to do with -E" >&2
fi

if test "x$minus_M_args" != x; then
  $icc $minus_M_args "$@"
fi
exec /usr/bin/distcc $icc "$@"

But the speedup is really miserable: none AFAICS (on several runs).  I
must say that my src hierarchy is poor for -j, as it heavily uses
Automake and many small modules compiled sequentially.  Here are the
figure I get:

make -j4 CC=icc CXX=icc  250,09s user 17,22s system 46% cpu 9:38,68 total

make -j4 CC=dicc CXX=dicc  257,89s user 22,69s system 55% cpu 8:22,51 total

ICC 7.0 and distcc

[Akim Demaille]

I make some progress understanding why I find it hard to use Icc with
distcc.  I face several problems, some of them might be already known.

Currently, I use the following wrapper to make sure Icc understands
what .ii is about:

/tmp % cat =icc  nostromo 18:54
#! /bin/sh

# ICC needs to be taught that *.ii is C++.
# The wonderful news is that:
#
# % /home/lrde/lrde/usr/bin/icc I-dont-exist
# ld: cannot open I-dont-exist: No such file or directory
# % /home/lrde/lrde/usr/bin/icc -c I-dont-exist
#
# icc per se does not complain about missing files...  That's
# why understanding the problems takes so long
case "$@" in
  *.cc*|*.cpp*) set -- -Kc++ "$@" ;;
esac
exec /usr/bin/distcc /home/lrde/lrde/usr/bin/icc "$@"


But I face another problem, related to Automake's depcomp.  I don't
know if the issue is known:

| /tmp % cat error.cc  nostromo 18:55
| int foo () { return 1;}
| int foo () { return 1;}

A broken source.

| /tmp % /home/lrde/lrde/usr/bin/icc error.cc  -c  nostromo 18:55
| error.cc(2): error: function "foo" has already been defined
|   int foo () { return 1;}
|   ^

An expected failure when attacking directly the compiler.

| /tmp % /home/lrde/lrde/usr/bin/icc error.cc  -c -MD -MF foo.Po   nostromo Err 2
| error.cc(2): error: function "foo" has already been defined
|   int foo () { return 1;}
|   ^

Likewise with Automake's flags to compute the dependencies.


But when I used distcc, all is lost with the -MD flags

| /tmp % distcc /home/lrde/lrde/usr/bin/icc -Kc++ error.cc  -c nostromo 18:58
| error.cc(2): error: function "foo" has already been defined
|   int foo () { return 1;}
|   ^
| 
| compilation aborted for /tmp/distcc_106/server_031068.ii (code 2)
| distcc[31066] ERROR: compile on nostromo failed with exit code 2
| /tmp % distcc /home/lrde/lrde/usr/bin/icc -Kc++ error.cc  -c -MD -MF foo.Po   
| /tmp %


If someone has an idea...

ICC 7.0 and distcc

[Akim Demaille]

| But when I used distcc, all is lost with the -MD flags
| 
| | /tmp % distcc /home/lrde/lrde/usr/bin/icc -Kc++ error.cc  -c nostromo 18:58
| | error.cc(2): error: function "foo" has already been defined
| |   int foo () { return 1;}
| |   ^
| | 
| | compilation aborted for /tmp/distcc_106/server_031068.ii (code 2)
| | distcc[31066] ERROR: compile on nostromo failed with exit code 2
| | /tmp % distcc /home/lrde/lrde/usr/bin/icc -Kc++ error.cc  -c -MD -MF foo.Po   
| | /tmp %
| 
| 
| If someone has an idea...

Actually, I'm not sure one can get both a CPP output together with
dependencies.  Distcc wants -E, and Automake wants -MD -MF:

-M generate makefile dependency information
-MMsimilar to -M, but do not include system header files
-MGsimilar to -M, but treat missing header files as generated files
-MDpreprocess and compile, generating output file containing
   dependency information ending with extension .d
-MMD   similar to -MD, but do not include system header files
-MF  generate makefile dependency information in file (must specify -M
   or -MM)


It results in:

/tmp % cat correct.ccnostromo 19:21
int foo () { return 1;}
/tmp % /home/lrde/lrde/usr/bin/icc -Kc++ -E correct.cc   nostromo 19:22
#line 1 "correct.cc"
int foo () { return 1;}
/tmp % /home/lrde/lrde/usr/bin/icc -Kc++ -E -MD -MFoutput.d correct.cc
/tmp % cat output.d  nostromo 19:22
correct.o: correct.cc

I did not find a means to get the -E part...

/tmp % /home/lrde/lrde/usr/bin/icc -Kc++ -MD -MFoutput.d -E -o output.i correct.cc 

/tmp % cat output.i  nostromo 19:23
cat: output.i: No such file or directory

Re: nodist => CLEANFILES, no?

[Akim Demaille]

 >> But how about making automake even smarter?
 >> 1. AC_CONFIG_FILES etc. are to be DISTCLEANED (aren't they already?)
 >> 2. nodist_ and target of a rule => CLEAN

 > What if the file is in both? I have package-config file which is
 > generated by configure (AC_CONFIG_FILES) and then installed via
 > nodist_bin_SCRIPTS. 

That's not both, it's only the first one: it is not one of your target.

Re: nodist => CLEANFILES, no?

[Akim Demaille]

 > Earnie Boyd wrote:
 >> Akim Demaille wrote:
 >> 
 >>> > On Tue, Jun 24, 2003 at 02:02:25PM +0200, Akim Demaille wrote:
 >>> >>  >> Why wouldn't nodist_ stuff be automatically included into
 >>> CLEANFILES?
 >>> 
 >>> > I think it would make sense.
 >>> 
 >>> > http://www.cygwin.com/ml/bug-automake/2002/msg01693.html
 >>> 
 >>> I would love this.  The only issue is where to bind the
 >>> cleaning. DISTCLEAN or CLEAN :(
 >>> 
 >> Me thinks, DISTCLEAN the better choice.

 > Me too, since sometimes nodist_ files are created by configure, not make.

Actually, this does not fit my needs, since my files are "make" files,
not "configure" files.

But how about making automake even smarter?

1. AC_CONFIG_FILES etc. are to be DISTCLEANED (aren't they already?)
2. nodist_ and target of a rule => CLEAN

New aclocal happiness message

[Akim Demaille]

~/src/tc % make  nostromo Err 2
cd . && /bin/sh /home/akim/src/tc/config/missing --run aclocal-1.7a -I config
 cd . && /bin/sh /home/akim/src/tc/config/missing --run automake-1.7a --foreign
/usr/local/bin/m4: config/warning.m4:23: EOF in string
autom4te: /usr/local/bin/m4 failed with exit status: 1


It is so great to read the real guilty M4 source, and no longer
aclocal.m4...  Thanks a lot for this magical change!

Re: nodist => CLEANFILES, no?

[Akim Demaille]

 > On Tue, Jun 24, 2003 at 02:02:25PM +0200, Akim Demaille wrote:
 >> 
 >> Why wouldn't nodist_ stuff be automatically included into CLEANFILES?

 > I think it would make sense.

 > http://www.cygwin.com/ml/bug-automake/2002/msg01693.html

I would love this.  The only issue is where to bind the
cleaning. DISTCLEAN or CLEAN :(

nodist => CLEANFILES, no?

[Akim Demaille]

Why wouldn't nodist_ stuff be automatically included into CLEANFILES?
I often find myself repeating things because of this.

Re: Makefileless AC_CONFIG_AUX_DIR

[Akim Demaille]

 > On Mon, Jun 02, 2003 at 09:09:23AM +0200, Akim Demaille wrote:
 >> 
 >> I discovered a nice property of AC_CONFIG_AUX_DIR and (CVS) Automake:
 >> you can use the Autoconf macro, and not provide a Makefile.am for this
 >> directory.  The content is properly shipped, everything works fine,
 >> and you saved one AC_CONFIG_FILES, one Makefile.am, one SUBDIRS.
 >> 
 >> I don't know if this is will be preserved

 > I think this has worked since utomake 1.5 and that this is covered by
 > the test suite.  I'll check tonight to be sure.  Where would you like
 > this to be documented?

Next to AC_CONFIG_AUX_DIR :)

Makefileless AC_CONFIG_AUX_DIR

[Akim Demaille]

I discovered a nice property of AC_CONFIG_AUX_DIR and (CVS) Automake:
you can use the Autoconf macro, and not provide a Makefile.am for this
directory.  The content is properly shipped, everything works fine,
and you saved one AC_CONFIG_FILES, one Makefile.am, one SUBDIRS.

I don't know if this is will be preserved, but I would suggest that
the decision to support or not to support this feature be specified.
If positive, then let's document, if not, let's add a warning
somewhere.

Re: tarball checksum/signature targets?

[Akim Demaille]

 Harlan> Thanks - my goal is to produce some number of checksum files
 Harlan> (md5, "sum", pgp, gpg, whatever) at the time I produce the
 Harlan> distribution *balls.

 Harlan> I'd then "publish" the *balls and checksum files.

 Harlan> I'm not sure I care about validating this on the user's side
 Harlan> yet, but I can see that it would be Useful to have utility
 Harlan> that would compare a *ball with the distributed checksum
 Harlan> files as well.

Have a look at the Coreutils Makefile.maint/GNUMakefile's "alpha"
target.

Re: make -j and touching configure.in, with automake

[Akim Demaille]

| >  Aharon> Thanks Tom.  I'll wait for Akim to reply and/or forward to Andre.
| >  Aharon> Akim, this happens pretty consistently for me with automake 1.7.3,
| >  Aharon> autoconf 2.57 and current gawk; just touch configure.in in that dist
| >  Aharon> and type make.
| >
| > Hi Aharon,
| >
| > I don't exactly how the dependencies are output but Automake, but the
| > "logical" order is indeed running autoconf first.  As a matter of
| > fact, because there is a cache sharing the results of the runs, it
| > shouldn't matter.  But running Autoconf and Automake concurrently
| > doesn't make a lot of sense, indeed, except if the cache is up to date.
| 
| What happens in a straight run is
| 
|   aclocal -I m4
|   automake
|   autoconf
|   configure --recheck # or whatever it is
| 
| When the first three run in parallel, things go nuts.
| 
| This is real easy to duplicate; get the gawk dist, configure, make.
| Then edit the version in configure.in (in both marked places), save
| the file, and type `make'.  Watch it all fall apart.

I don't trust myself on this issue: I don't spend enough time on the
Autotools to track this down and fix.  I'm Cc'ing this to Automake
folks, as they are the one(s) who do currently the real work.

Salut le Automake folk :)

Re: automake & flex's -P option

[Akim Demaille]

 Richard> But won't that break the automake rules? They expect the lex
 Richard> output file to be called $LEX_OUTPUT_ROOT. $LEX_OUTPUT_ROOT
 Richard> is different on Linux than DJGPP (lex.yy vs. lexyy). If I
 Richard> use %option outfile and %option prefix, it will work on one
 Richard> platform, but not the other. I thought about getting
 Richard> config.status to do some substitution on the lexer sources,
 Richard> but that's just horrible and it means that the user would
 Richard> have to have (f)lex installed.

I think a lot could be done to improve the interface provided that we
require Bison and Flex.  The problem here stems on the willingness to
be yacc/lex portable.

 Richard> So, back to my original suggestion: Modify the automake
 Richard> rules to invoke lex with the -t option and pipe the output
 Richard> to $LEX_OUTPUT_FILE. Then the use -P or %option prefix will
 Richard> not break the automake rule. But how portable is 'lex -t'?

I don't think this is the right track, since flex and bison now
generate more that just one file.  Relying on something like -o is
saner, but stdout is a dead end.

Re: automake & flex's -P option

[Akim Demaille]

| Hello.

Hi!

| I recently converted one of my projects to autoconf 2.57 & automake
| 1.7.3. I'm not bothered about portability to systems other than
| DJGPP or Linux. In particular I've been using switches that are
| particular to flex and bison: those to set the prefix of the lexer
| and parser's function and varibable names. This works fine with
| bison. But not with flex, because it modifies the output file name
| from lexyy.c to lexfoo.c. ($LEX_OUTPUT_ROOT == lexyy for DJGPP.)

Nope, use %option outfile in addition to %option prefix.

Re: ylwrap fails with flex 2.5.4 and prefix

[Akim Demaille]

| Hi,
| I'm using flex as the lexer, and I'm using flex's
| support for prefixes. So when I put a 
| 
| %option prefix="dfg_"

Use prefix and outfile to please Automake.

src/bison/src % fgrep %option scan-gram.l nostromo 9:59
%option debug nodefault noyywrap never-interactive
%option prefix="gram_" outfile="lex.yy.c"

Re: Automake and no-gzip-dist

[Akim Demaille]

 Olaf> Hello automake team,
 Olaf> I'm using

 Olaf> AM_INIT_AUTOMAKE([foreign 1.5 no-define dist-bzip2])

 Olaf> which will create a tar.gz and tar.bz2 dist. How can I prevend
 Olaf> automake from building the tar.gz dist, since there isn't a
 Olaf> target like no-gzip-dist.

By submitting a patch that implements it :)

Autoconf 2.56 is released

[Akim Demaille]

The Autoconf team -- Akim, Alexandre, Jim, Paul, and Tom -- is happy
to annonce the birth of Autoconf 2.56, aka 2.55 with a packaging
problem fixed.

  - Why should I upgrade from 2.54?

A few bug fixes, improved portability, no known incompatibility with
2.54 and 2.55, forthcoming Gettext release might require 2.55.  See
below for the list of user visible changes.

Running `autoreconf -fv' should be enough.


   - Why should I upgrade from 2.13?

This version is no longer maintained.  It does not address recent
architectures, recent compilers etc.  We know that upgrading from 2.13
to 2.5x is not an easy task, especially because the Autoconf 2.13 was
extremely tolerant to incorrect macro invocations, but waiting longer
endangers the portability of your package and only delays the
conversation to newer Autoconf versions.  Worse: some maintainers now
spend a significant amount of time fixing bugs in 2.13 or backporting
macros from 2.55.


   - Where can I find it?

  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.56.tar.gz   (1.1 MB)
  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.56.tar.bz2  (795 KB)
  ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.54-2.56.delta   (7 KB)

and soon from the mirrors listed on http://www.gnu.org/order/ftp.html.


Here are the MD5 and SHA1 signatures:

0e142e9bc890786845950e84ffb52adf  autoconf-2.56.tar.gz
1b0ecb66f03af3f745981c7d8bfc2a91  autoconf-2.56.tar.bz2
edcb98aa66f5c74a579109aef9cf3270  autoconf-2.55-2.56.xdelta
afff4a43d0b71a05de7b72e5a493a3e94219160c  autoconf-2.56.tar.gz
5d2b082c2c76476a28a3b7bc0b537ccf6b5ad6f6  autoconf-2.56.tar.bz2
e1befdcb8d1032964021e29d6ad17975a766aa13  autoconf-2.55-2.56.xdelta


NEWS:

Release tips:

   Have your configure.ac checked by autoscan ("autoscan").
   Try the warning options ("autoreconf -fv -Wall").

** Documentation

- AC_CHECK_HEADER, AC_CHECK_HEADERS
  More information on proper use.

- Writing Test Programs

  This sections explains how to write good test sources to use with
  AC_COMPILE_IFELSE etc.  It documents AC_LANG_PROGRAMS and so forth.

- AC_FOO_IFELSE vs. AC_TRY_FOO

  Explains why Autoconf moves from AC_TRY_COMPILE etc. to
  AC_COMPILE_IFELSE and AC_LANG_PROGRAM etc.

** autoreconf

- Is more robust to different Gettext installations.

- Produces messages (when --verbose) to be understood by Emacs'
  compile mode.

- Supports -W/--warnings.

- -m/--make
  Once the GNU Build System reinstalled, run `./config.status
  --recheck && ./config.status && make' if possible.

** autom4te

- Supports --cache, and --no-cache.

- ~/.autom4te.cfg makes it possible to disable the caching mechanism
  (autom4te.cache).  See `Customizing autom4te' in the documentation.

** Obsolete options

  Support for the obsoleted options -m, --macrodir, -l, --localdir is
  dropped in favor of the safer --include/--prepend-include scheme.

** Macros

- New macros
  AC_COMPILER_IFELSE, AC_FUNC_MBRTOWC, AC_HEADER_STDBOOL,
  AC_LANG_CONFTEST, AC_LANG_SOURCE, AC_LANG_PROGRAM, AC_LANG_CALL,
  AC_LANG_FUNC_TRY_LINK, AC_MSG_FAILURE, AC_PREPROC_IFELSE.

- Obsoleted
  Obsoleted macros are kept for Autoconf backward compatibility, but
  should be avoided in configure.ac.  Running autoupdate is advised.
  AC_DECL_SYS_SIGLIST.

** Bug Fixes

- Portability of the Autoconf package to Solaris.

- Spurious warnings caused by config.status.
  This bug is benign, but painful: on some systems (typically
  FreeBSD), warnings such as:

 config.status: creating Makefile
 mv: Makefile: set owner/group (was: 1357/0): Operation not permitted

  could be issued.  This is fixed.

- Parallel Builds
  Simultaneous executions of config.status are possible again.

- Precious variables accumulation

  config.status could stack several copies of the precious variables
  assignments.


** Plans for 2.57

- ./configure 

  The compatibility hooks with the old scheme will be completely
  removed.  Please, advice/use `--build', `--host', and `--target'
  only.

- AC_CHECK_HEADER, AC_CHECK_HEADERS

  The tests will be stricter, please make sure your invocations are
  valid.

- shell functions

  Shell functions will gradually be introduced, probably starting with
  Autotest.  If you know machines which are in use that you suspect
  *not* to support shell functions, please run the test suite of
  Autoconf 2.55 on it, and report the results to
  [EMAIL PROTECTED]

Autoconf 2.55 is released!

[Akim Demaille]

The Autoconf team -- Akim, Alexandre, Jim, Paul, and Tom -- is happy
to annonce the birth of Autoconf 2.55.  Download, compile, install,
torture, and enjoy!


  - Why should I upgrade from 2.54?

A few bug fixes, improved portability, no known incompatibility with
2.54 and 2.55, forthcoming Gettext release might require 2.55.

Running `autoreconf -fv' should be enough.


   - Why should I upgrade from 2.13?

This version is no longer maintained.  It does not address recent
architectures, recent compilers etc.  We know that upgrading from 2.13
to 2.5x is not an easy task, especially because the Autoconf 2.13 was
extremely tolerant to incorrect macro invocations, but waiting longer
endangers the portability of your package and only delays the
conversation to newer Autoconf versions.  Worse: some maintainers now
spend a significant amount of time fixing bugs in 2.13 or backporting
macros from 2.55.


   - Where can I find it?

  ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.55.tar.gz (1.1 MB)
  ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.55.tar.bz2(794 KB)
  ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.54-2.55.delta  (70 KB)

and soon from the mirrors listed on http://www.gnu.org/order/ftp.html.


Here are the MD5 and SHA1 signatures:

d3e8ad97aa69853778125177967ed573  autoconf-2.55.tar.gz
4517bb0669b949935967f31329a29c0c  autoconf-2.55.tar.bz2
c991edb76acbf686bed4ce1cb7a35cc2  autoconf-2.54-2.55.xdelta
69554487aec8606a17c53db2c7c7964be7138946  autoconf-2.55.tar.gz
d6d7cf9a2df8736c2930d1e6104de9c7a8ccbaff  autoconf-2.55.tar.bz2
717df2957e85ad4de9c3c651a5b3eff1b01e3857  autoconf-2.54-2.55.xdelta

NEWS:

Release tips:

   Have your configure.ac checked by autoscan ("autoscan").
   Try the warning options ("autoreconf -fv -Wall").

** Documentation

- AC_CHECK_HEADER, AC_CHECK_HEADERS
  More information on proper use.

- Writing Test Programs

  This sections explains how to write good test sources to use with
  AC_COMPILE_IFELSE etc.  It documents AC_LANG_PROGRAMS and so forth.

- AC_FOO_IFELSE vs. AC_TRY_FOO

  Explains why Autoconf moves from AC_TRY_COMPILE etc. to
  AC_COMPILE_IFELSE and AC_LANG_PROGRAM etc.

** autoreconf

- Is more robust to different Gettext installations.

- Produces messages (when --verbose) to be understood by Emacs'
  compile mode.

- Supports -W/--warnings.

- -m/--make
  Once the GNU Build System reinstalled, run `./config.status
  --recheck && ./config.status && make' if possible.

** autom4te

- Supports --cache, and --no-cache.

- ~/.autom4te.cfg makes it possible to disable the caching mechanism
  (autom4te.cache).  See `Customizing autom4te' in the documentation.

** Obsolete options

  Support for the obsoleted options -m, --macrodir, -l, --localdir is
  dropped in favor of the safer --include/--prepend-include scheme.

** Macros

- New macros
  AC_COMPILER_IFELSE, AC_FUNC_MBRTOWC, AC_HEADER_STDBOOL,
  AC_LANG_CONFTEST, AC_LANG_SOURCE, AC_LANG_PROGRAM, AC_LANG_CALL,
  AC_LANG_FUNC_TRY_LINK, AC_MSG_FAILURE, AC_PREPROC_IFELSE.

- Obsoleted
  Obsoleted macros are kept for Autoconf backward compatibility, but
  should be avoided in configure.ac.  Running autoupdate is advised.
  AC_DECL_SYS_SIGLIST.

** Bug Fixes

- Portability of the Autoconf package to Solaris.

- Spurious warnings caused by config.status.
  This bug is benign, but painful: on some systems (typically
  FreeBSD), warnings such as:

 config.status: creating Makefile
 mv: Makefile: set owner/group (was: 1357/0): Operation not permitted

  could be issued.  This is fixed.

- Parallel Builds
  Simultaneous executions of config.status are possible again.

- Precious variables accumulation

  config.status could stack several copies of the precious variables
  assignments.


** Plans for 2.56

- ./configure 

  The compatibility hooks with the old scheme will be completely
  removed.  Please, advice/use `--build', `--host', and `--target'
  only.

- AC_CHECK_HEADER, AC_CHECK_HEADERS

  The tests will be stricter, please make sure your invocations are
  valid.

- shell functions

  Shell functions will gradually be introduced, probably starting with
  Autotest.  If you know machines which are in use that you suspect
  *not* to support shell functions, please run the test suite of
  Autoconf 2.55 on it, and report the results to
  [EMAIL PROTECTED]

Re: weird flags set by configure

[Akim Demaille]

> "Bob" == Bob Proulx <[EMAIL PROTECTED]> writes:

Bob> If you want to change this you can set CXXFLAGS at configure
Bob> time.

Bob>   CFLAGS=-O CXXFLAGS=-O ./configure

./configure CFLAGS=-O CXXFLAGS=-O

is better.

Autoconf 2.54c is relased

[Akim Demaille]

The Autoconf team -- Akim, Alexandre, Jim, Paul, and Tom -- is happy
to annonce the second beta of forthcoming Autoconf 2.55.  Download,
compile, install, torture, and enjoy!


  - Why should I upgrade from 2.54?

A few bug fixes, improved portability, no known incompatibility with
2.54 and 2.55, forthcoming Gettext release might require 2.55.

Running `autoreconf -fv' should be enough.


   - Why should I upgrade from 2.13?

This version is no longer maintained.  It does not address recent
architectures, recent compilers etc.  We know that upgrading from 2.13
to 2.5x is not an easy task, especially because the Autoconf 2.13 was
extremely tolerant to incorrect macro invocations, but waiting longer
endangers the portability of your package and only delays the
conversation to newer Autoconf versions.  Worse: some maintainers now
spend a significant amount of time fixing bugs in 2.13 or backporting
macros from 2.55.


   - Where can I find it?

  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.54c.tar.gz   (1.1 MB)
  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.54c.tar.bz2  (792 KB)

And here are xdelta-style diffs

  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.54b-2.54c.xdelta   (17 KB)

Here are the MD5 and SHA1 signatures:

ab431fb26babf82de8fda486afb94350  autoconf-2.54c.tar.gz
db32dbbcd1bf2f8ca7713faa58bc905e  autoconf-2.54c.tar.bz2
39bdbfc39b0581bda303e3b42a550714  autoconf-2.54b-2.54c.xdelta
807d67c59445ddac573dd8c9a42ac668b83020f0  autoconf-2.54c.tar.gz
9968922141aaf313ed145fe19d27669fd5f89189  autoconf-2.54c.tar.bz2
dd01917057f9f456e96259734ebc56a2b22f11ef  autoconf-2.54b-2.54c.xdelta

NEWS:

Release tips:

   Have your configure.ac checked by autoscan ("autoscan").
   Try the warning options ("autoreconf -fv -Wall").

** Documentation

- AC_CHECK_HEADER, AC_CHECK_HEADERS
  More information on proper use.

- Writing Test Programs

  This sections explains how to write good test sources to use with
  AC_COMPILE_IFELSE etc.  It documents AC_LANG_PROGRAMS and so forth.

- AC_FOO_IFELSE vs. AC_TRY_FOO

  Explains why Autoconf moves from AC_TRY_COMPILE etc. to
  AC_COMPILE_IFELSE and AC_LANG_PROGRAM etc.

** autoreconf

- Is more robust to different Gettext installations.

- Produces messages (when --verbose) to be understood by Emacs'
  compile mode.

- Supports -W/--warnings.

- -m/--make
  Once the GNU Build System reinstalled, run `./config.status
  --recheck && ./config.status && make' if possible.

** autom4te

- Supports --cache, and --no-cache.

- ~/.autom4te.cfg makes it possible to disable the caching mechanism
  (autom4te.cache).  See `Customizing autom4te' in the documentation.

** Obsolete options

  Support for the obsoleted options -m, --macrodir, -l, --localdir is
  dropped in favor of the safer --include/--prepend-include scheme.

** Macros

- New macros
  AC_COMPILER_IFELSE, AC_FUNC_MBRTOWC, AC_HEADER_STDBOOL,
  AC_LANG_CONFTEST, AC_LANG_SOURCE, AC_LANG_PROGRAM, AC_LANG_CALL,
  AC_LANG_FUNC_TRY_LINK, AC_MSG_FAILURE, AC_PREPROC_IFELSE.

- Obsoleted
  Obsoleted macros are kept for Autoconf backward compatibility, but
  should be avoided in configure.ac.  Running autoupdate is advised.
  AC_DECL_SYS_SIGLIST.

** Bug Fixes

- Portability of the Autoconf package to Solaris.

- Spurious warnings caused by config.status.
  This bug is benign, but painful: on some systems (typically
  FreeBSD), warnings such as:

 config.status: creating Makefile
 mv: Makefile: set owner/group (was: 1357/0): Operation not permitted

  could be issued.  This is fixed.

- Parallel Builds
  Simultaneous executions of config.status are possible again.

- Precious variables accumulation

  config.status could stack several copies of the precious variables
  assignments.


** Plans for 2.56

- ./configure 

  The compatibility hooks with the old scheme will be completely
  removed.  Please, advice/use `--build', `--host', and `--target'
  only.

- AC_CHECK_HEADER, AC_CHECK_HEADERS

  The tests will be stricter, please make sure your invocations are
  valid.

- shell functions

  Shell functions will gradually be introduced, probably starting with
  Autotest.  If you know machines which are in use that you suspect
  *not* to support shell functions, please run the test suite of
  Autoconf 2.55 on it, and report the results to
  [EMAIL PROTECTED]


ChangeLog entries:

**
ChangeLog   4 Nov 2002 08:47:39 -   1.2092
**
2002-11-04  Akim Demaille  <[EMAIL PROTECTED]>

Version 2.54c.

* Makefile.maint (update, cvs-update, po-update, do-po-update):
New.
* config/texinfo.tex: Update.

2002-11-03  Akim Demaille  <[EMAIL PROTECTED]>

* bin/autoreconf.in (&autoreconf_current_directory): New, extracted
from...
   

Re: back quotes and double quotes must not be escaped?

[Akim Demaille]

|  Since upgrading from autoconf 2.54 to 2.54b, automake 1.7.1 gives me tons
|  of warnings:
| 
| configure.ac:27: warning: back quotes and double quotes must not be escaped in: 
|$as_me:$LINENO: WARNING: \`$CC' requires \`$lt_cv_prog_cc_shlib' to build shared 
|libraries
| configure.ac:27: warning: back quotes and double quotes must not be escaped in: 
|$as_me: WARNING: \`$CC' requires \`$lt_cv_prog_cc_shlib' to build shared libraries
| configure.ac:27: warning: back quotes and double quotes must not be escaped in: 
|$as_me:$LINENO: WARNING: add \`$lt_cv_prog_cc_shlib' to the CC or CFLAGS env variable 
|and reconfigure
| 
|  This is configure.ac line 27:
| 
| AC_PROG_LIBTOOL
| 
|  What's the problem? libtool is version 1.4.3.

This is not automake, but autoconf speaking.  2.55 will re-disable
this warning until Libtool has this fixed :(  Sorry.

Re: automake/44: conditional redefinitions (Was: Re: Automake 1.6.3 issue)

[Akim Demaille]

| This also works for things like
| 
|   foo = mumble
|   foo = blurgle
| 
| which would be interpreted as
| 
|   foo = blurgle
|   if FALSE
| foo = mumble
|   endif

I've always thought this is wrong.  I still think we should not
support such ``feature'', which is a form of laxism to me, comparable
to globbing.

Nevertheless, I agree a means to install defaults would be most
welcome.

I suggest introducing

foo ?= bar

Which is always valid, but with a clear semantics.

Also, maybe we want to introduce something like (hold you breath):

ifndef foo
foo = bar
endif

Autoconf 2.54b released

[Akim Demaille]

The Autoconf team -- Akim, Alexandre, Jim, Paul, and Tom -- is happy
to annonce the second beta of forthcoming Autoconf 2.55.  Download,
compile, install, torture, and enjoy!


  - Why should I upgrade from 2.54?

A few bug fixes, improved portability, no known incompatibility with
2.53 and 2.54, forthcoming Gettext release might require 2.54.

Running `autoreconf -fv' should be enough.


   - Why should I upgrade from 2.13?

This version is no longer maintained.  It does not address recent
architectures, recent compilers etc.  We know that upgrading from 2.13
to 2.5x is not an easy task, especially because the Autoconf 2.13 was
extremely tolerant to incorrect macro invocations, but waiting longer
endangers the portability of your package and only delays the
conversation to newer Autoconf versions.  Worse: some maintainers now
spend a significant amount of time fixing bugs in 2.13 or backporting
macros from 2.55.


   - Where can I find it?

  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.54b.tar.gz   (1.1 MB)
  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.54b.tar.bz2  (787 KB)

And here are xdelta-style diffs

  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.54a-2.54b.xdelta   (23 KB)

Here are the MD5 and SHA1 signatures:

3389f90c4b56a6e82b89292588080029  autoconf-2.54b.tar.gz
18b1b2c98de8614368ea248f9df60d8f  autoconf-2.54b.tar.bz2
322df1a0e93e28a97329714f5b8965f9  autoconf-2.54a-2.54b.xdelta
ca32ca028228210f0ea97e27cf364bd08e1b7efa  autoconf-2.54b.tar.gz
fe186e6025e1fe9e1de8055b65ef81bd4289ee5b  autoconf-2.54b.tar.bz2
50ab7a46b147c92fd066a6c8c40156d2796b935e  autoconf-2.54a-2.54b.xdelta

NEWS:

Release tips:

   Have your configure.ac checked by autoscan ("autoscan").
   Try the warning options ("autoreconf -fv -Wall").

** Documentation

- AC_CHECK_HEADER, AC_CHECK_HEADERS
  More information on proper use.

- Writing Test Programs

  This sections explains how to write good test sources to use with
  AC_COMPILE_IFELSE etc.  It documents AC_LANG_PROGRAMS and so forth.

- AC_FOO_IFELSE vs. AC_TRY_FOO

  Explains why Autoconf moves from AC_TRY_COMPILE etc. to
  AC_COMPILE_IFELSE and AC_LANG_PROGRAM etc.

** autoreconf

- Is more robust to different Gettext installations.

- Produces messages (when --verbose) to be understood by Emacs'
  compile mode.

** Obsolete options

  Support for the obsoleted options -m, --macrodir, -l, --localdir is
  dropped in favor of the safer --include/--prepend-include scheme.

** Customization

- ~/.autom4te.cfg makes it possible to disable the caching mechanism
  (autom4te.cache).  See `Customizing autom4te' in the documentation.

** Macros

- New macros
  AC_COMPILER_IFELSE, AC_FUNC_MBRTOWC, AC_HEADER_STDBOOL,
  AC_LANG_CONFTEST, AC_LANG_SOURCE, AC_LANG_PROGRAM, AC_MSG_FAILURE,
  AC_PREPROC_IFELSE.

- Obsoleted
  Obsoleted macros are kept for Autoconf backward compatibility, but
  should be avoided in configure.ac.  Running autoupdate is advised.
  AC_DECL_SYS_SIGLIST.

** Bug Fixes

- Portability of the Autoconf package to Solaris.

- Spurious warnings caused by config.status.
  This bug is benign, but painful: on some systems (typically
  FreeBSD), warnings such as:

 config.status: creating Makefile
 mv: Makefile: set owner/group (was: 1357/0): Operation not permitted

  could be issued.  This is fixed.

- Parallel Builds
  Simultaneous executions of config.status are possible again.

- Precious variables accumulation

  config.status could stack several copies of the precious variables
  assignments.


** Plans for 2.56

- ./configure 

  The compatibility hooks with the old scheme will be completely
  removed.  Please, advice/use `--build', `--host', and `--target'
  only.

- AC_CHECK_HEADER, AC_CHECK_HEADERS

  The tests will be stricter, please make sure your invocations are
  valid.

- shell functions

  Shell functions will gradually be introduced, probably starting with
  Autotest.  If you know machines which are in use that you suspect
  *not* to support shell functions, please run the test suite of
  Autoconf 2.55 on it, and report the results to
  [EMAIL PROTECTED]

ChangeLog entries:

**
ChangeLog   28 Oct 2002 08:57:40 -  1.2075
**
2002-10-28  Akim Demaille  <[EMAIL PROTECTED]>

Version 2.54b.

* tests/foreign.at (Libtool): Adjust to broken libtoolize.

2002-10-28  Akim Demaille  <[EMAIL PROTECTED]>

* tests/atspecific.m4 (AT_CHECK_AUTOM4TE): Be robust to different
m4 executable names, and different GNU M4 version.
    Reported by Ezra Peisach and Paul Jarc.

2002-10-27  Akim Demaille  <[EMAIL PROTECTED]>

* lib/autoconf/functions.m4 (_AC_FUNC_VFORK): Really use
AC_RUN_IFELSE.

2002-10-27  Akim Demaille  <[EMAIL PROTECTED]>

* doc/autoconf.texi: More AC_MSG_F

Autoconf 2.54a is released

[Akim Demaille]

The Autoconf team is happy to annonce the first beta of forthcoming
Autoconf 2.55.  Download, compile, install, torture, and enjoy!

Akim, Alexandre, Jim, Paul, and Tom

  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.54a.tar.gz   (1.1 MB)
  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.54a.tar.bz2  (779 KB)

And here are xdelta-style diffs

  ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.54-2.54a.xdelta   (44 KB)

Here are the MD5 and SHA1 signatures:

3c5ae43575fd82eede45285c4e993d9b  autoconf-2.54a.tar.gz
921076ed637757bcedf6aac4a072e3f8  autoconf-2.54a.tar.bz2
e612de9ceb46d8561c5f81e424a6b39d  autoconf-2.54-2.54a.xdelta
2168b9280a31e516b5b3a807c7d234adc23247d3  autoconf-2.54a.tar.gz
a0703a4829bdc1249ee775ac3a4123c6c85a84fb  autoconf-2.54a.tar.bz2
17ed07dc238d8b369d61bad8fbd852733fc79760  autoconf-2.54-2.54a.xdelta

NEWS:

** Documentation

- AC_CHECK_HEADER, AC_CHECK_HEADERS
  More information on proper use.

** autoreconf

- Is more robust to different Gettext installations.

- Produces messages (when --verbose) to be understood by Emacs'
  compile mode.

** Obsolete options
  Support for the obsoleted options -m, --macrodir, -l, --localdir is
  dropped in favor of the safer --include/--prepend-include scheme.

** Customization

- ~/.autom4te.cfg makes it possible to disable the caching mechanism
  (autom4te.cache).  See `Customizing autom4te' in the documentation.

** Macros

- New macros
  AC_FUNC_MBRTOWC, AC_HEADER_STDBOOL.

- Obsoleted
  Obsoleted macros are kept for Autoconf backward compatibility, but
  should be avoided in configure.ac.  Running autoupdate is advised.
  AC_DECL_SYS_SIGLIST.

** Bug Fixes

- Portability of the Autoconf package to Solaris.

- Spurious warnings caused by config.status.
  This bug is benign, but painful: on some systems (typically
  FreeBSD), warnings such as:

 config.status: creating Makefile
 mv: Makefile: set owner/group (was: 1357/0): Operation not permitted

  could be issued.  This is fixed.

- Parallel Builds
  Simultaneous executions of config.status are possible again.

- Precious variables accumulation

  config.status could stack several copies of the precious variables
  assignments.


** Plans for 2.56

- ./configure 

  The compatibility hooks with the old scheme will be completely
  removed.  Please, advice/use `--build', `--host', and `--target'
  only.

- AC_CHECK_HEADER, AC_CHECK_HEADERS

  The tests will be stricter, please make sure your invocations are
  valid.

- shell functions

  Shell functions will gradually be introduced, probably starting with
  Autotest.  If you know machines which are in use that you suspect
  *not* to support shell functions, please run the test suite of
  Autoconf 2.55 on it, and report the results to
  [EMAIL PROTECTED]

ChangeLog entries:

2002-10-25  Akim Demaille  <[EMAIL PROTECTED]>

Version 2.54a.

* Makefile.maint: Update from the Coreutils.
(AMTAR): Remove, obsolete.
(automake_repo): Update to redhat.com.
(cvs_file): New.
Adjust to the fact that ansi2knr is now hosted by Automake.
* Makefile.am (cvs_files): Add install-sh and mkinstalldirs.
* config/config.guess, config/mkinstalldirs, config/texinfo.tex:
Update from masters.
* lib/autoscan/Makefile.am (EXTRA_DIST, nodist_autoscanlib_DATA):
autoscan.pre is not to be installed, and autoscan.list is not to
be shipped.
(CLEANFILES): Add autoscan.list.
(autoscan.list): Disable the cache.
* bin/Makefile.am: Include freeze.mk.

2002-10-25  Akim Demaille  <[EMAIL PROTECTED]>

* bin/autom4te.in (&load_configuration): Take the file as
argument.
(&parse_args): Handle -C, --cache.
($help): Adjust.
(MAIN): Load ~/.autom4te.cfg and ./.autom4te.cfg.
* lib/autom4te.in (Autoconf): Pass --cache=autom4te.cache.
* doc/autoconf.texi (Invoking autom4te): Document --cache.
Now a subsection of...
(Using autom4te): This new section.
(Customizing autom4te): New.
    (autom4te.cache): Adjust.

2002-10-25  Akim Demaille  <[EMAIL PROTECTED]>

* doc/autoconf.texi (Generic Headers): More information on how to
    use AC_CHECK_HEADERS.

2002-10-25  Akim Demaille  <[EMAIL PROTECTED]>

* bin/autoconf.as, bin/autoconf.in, bin/autoupdate.in ($help):
Space changes.

2002-10-25  Akim Demaille  <[EMAIL PROTECTED]>

* bin/autoscan.in (output): Output AC_PREREQ.
(%needed_macros): Add AC_PREREQ so that configure.ac without one
be reported.

2002-10-23  Akim Demaille  <[EMAIL PROTECTED]>

* doc/autoconf.texi (Particular Headers): In AC_HEADER_STDBOOL,
document _Bool.

2002-10-23  Akim Demaille  <[EMAIL PROTECTED]>

* bin/autom4te.in (handle_traces): Handle @&t@ in traces.
Reported by Peter Eisentraut.

2002-10-23  Akim Dema

Re: basic help for bare-boned newbie

[Akim Demaille]

| hi akim,
| first, thank you for responding!
| 
| i finally did find out what was wrong: autoconf 2.5x and 2.13 debian
| packages were both installed on my system.  the *packages* don't
| conflict but the programs do.  inadvertantly, some of what i did used
| the 2.5 tools and some used the 2.13 tools.

Arg...  I'm applying the following patch.  It should help avoiding
such pitfalls, plus anyway it is better this way.

Index: ChangeLog
from  Akim Demaille  <[EMAIL PROTECTED]>

* bin/autoscan.in (output): Output AC_PREREQ.
(%needed_macros): Add AC_PREREQ so that configure.ac without one
be reported.

Index: bin/autoscan.in
===
RCS file: /cvsroot/autoconf/autoconf/bin/autoscan.in,v
retrieving revision 1.87
diff -u -u -r1.87 autoscan.in
--- bin/autoscan.in 28 Sep 2002 14:03:14 - 1.87
+++ bin/autoscan.in 25 Oct 2002 08:19:12 -
@@ -73,7 +73,10 @@
 # $NEEDED_MACROS{MACRO} is an array of locations requiring MACRO.
 # E.g., $NEEDED_MACROS{AC_FUNC_ALLOC} the list of `file:line' containing
 # `alloca (...)'.
-my %needed_macros = ();
+my %needed_macros =
+  (
+   'AC_PREREQ' => [$me],
+  );
 
 my $configure_scan = 'configure.scan';
 my $log = new Autom4te::XFile ">$me.log";
@@ -98,6 +101,8 @@
   -V, --version   print version number, then exit
   -v, --verbose   verbosely report processing
   -d, --debug don't remove temporary files
+
+Library directories:
   -B, --prepend-include=DIR  prepend directory DIR to search path
   -I, --include=DIR  append directory DIR to search path
 
@@ -496,8 +501,11 @@
   my $file = new Autom4te::XFile ">$configure_scan";
 
   print $file
-("# Process this file with autoconf to produce a configure script.\n"
- . "AC_INIT(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS)\n");
+("#   -*- Autoconf -*-\n" .
+ "# Process this file with autoconf to produce a configure script.\n" .
+ "\n" .
+ "AC_PREREQ(@VERSION@)\n" .
+ "AC_INIT(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS)\n");
   if (defined $cfiles[0])
 {
   print $file "AC_CONFIG_SRCDIR([$cfiles[0]])\n";


| configure script was generated and it almost ran to completion.
| 
|checking whether gcc accepts -g... yes
|checking for gcc option to accept ANSI C... none needed
|configure: error: cannot find install-sh or install.sh in . ./.. ./../..
| 
| /usr/bin/install is on my system, and is also in my PATH.  but according
| to the autoconf info page:
| 
| - Macro: AC_PROG_INSTALL
| 
|  Set output variable `INSTALL' to the path of a BSD compatible
|  `install' program, if one is found in the current `PATH'.
|  Otherwise, set `INSTALL' to `DIR/install-sh -c', checking the
|  directories specified to `AC_CONFIG_AUX_DIR'
| 
| the info page also says that AC_PROG_INSTALL filters out "install"
| implementations that are known to be buggy, but i doubt GNU install is
| buggy.
| 
| i was able to get configure to complete successfully by commenting out
| AC_PROG_INSTALL in configure.in, but that's a bandaid fix.   how can i
| get configure to recognize /usr/bin/install?

That's not the problem.  Autoconf *wants* to have the script named
install-sh in the top level (or AC_CONFIG_AUX_DIR).  Because *your*
machine is not what matters: the machines of other people are
Autoconf's targets.