Re: Per-object *FLAGS or workaround?
>>> "Lars" == Lars Hecking <[EMAIL PROTECTED]> writes: [...] Lars> Does anyone have any better suggestions? Maybe you could group these objects in a convenience library in order to use per-target flags. -- Alexandre Duret-Lutz
Re: How to specify 2 stage build in Makefile.am
>>> "Duncan" == Duncan Gibson <[EMAIL PROTECTED]> writes: [...] About "multiple" implicit rules such as .a.b .c.d: ... Duncan> It's not obvious (or necessarily documented) that some Duncan> common 'make' constructions don't convert directly to Duncan> 'automake'. I've filled two PR for this: PR/371: to fix Automake so it understand this construct PR/372: to warn about this construct, because it's disallowed by POSIX [...] -- Alexandre Duret-Lutz
Re: Conditionals in Makefile.am
>>> "Pekka" == Pekka Riikonen <[EMAIL PROTECTED]> writes: [...] Pekka> I don't think changing this would be hard (haven't Pekka> looked at code though), and it doesn't cause Pekka> compatibility problems, and would make the conditionals Pekka> a lot more flexible. Ideas? I think this would be nice; however it's probably more difficult than you might think... -- Alexandre Duret-Lutz
Re: Conditionals in Makefile.am
>>> "Pekka" == Pekka Riikonen <[EMAIL PROTECTED]> writes: [...] Pekka> FILES = \ Pekka> somefile.c \ Pekka> if HAVE_SOMETHING Pekka> someotherfile.c \ Pekka> endif Pekka> if HAVE_SOMETHING_ELSE Pekka> somethingelse.c \ Pekka> endif Pekka> something.c Pekka> This sort of thing is not possible now and makes it Pekka> really ugly to use the conditionals in makefiles, imo. Pekka> Currently only way to do this is to conditionalize the Pekka> entire FILES variable. Alternatively it could just Pekka> remove the lines not to be included. Sorry, I forgot to reply to this. A simpler solution is to use a sub-variable. FILES = somefile.c $(FILES_IF_SOMETHING) $(FILES_IF_SOMETHING_ELSE) something.c if HAVE_SOMETHING FILES_IF_SOMETHING = someotherfile.c endif if HAVE_SOMETHING_ELSE FILES_IF_SOMETHING_ELSE = somethingelse.c endif [...] -- Alexandre Duret-Lutz
Re: automake/374: Problems with ansi2knr
>>> "pds" == Paul Smith <[EMAIL PROTECTED]> writes: [...] Paul> loadavg.c: $(srcdir)/getloadavg.c Paul> cp $(srcdir)/getloadavg.c loadavg.c [...] pds> OK, I tried automake 1.7.1 where this is fixed. It does fix this pds> problem but unfortunately there are other problems lurking. Thanks for the detailed analysis. I've submitted this is PR/374 because it doesn't look easy to fix. As a workaround I think you could use `cpp' instead of `cp' in the above rule. [...] -- Alexandre Duret-Lutz
Re: Problems executing ./configure on Solaris
>>> "Lorrie" == Lorrie Wood <[EMAIL PROTECTED]> writes: Lorrie> On Wed, Oct 23, 2002 at 11:26:15AM -0700, Lorrie Wood wrote: >> Hello, I'm having trouble using scripts generated by autoconf >> on Solaris 8. No matter what package is involved (I've tried mutt, >> ncurses, and slocate so far), the ./configure process hangs when attempting >> to create config.status. It was suggested to me that I try changing all >> instances of /bin/sh to one of the existing bash instances on my >> system, but this did not fix anything. Trussing the process shows it has >> gone to sleep, config.log shows nothing out of the ordinary -- there just >> aren't any error messages to be found! Hi Lorrie, You are not talking to the right list. If you still think its a portability issue in ./configure, please trace this script with `sh -x ./configure --your-flags...' and send the output to [EMAIL PROTECTED] -- Alexandre Duret-Lutz
Re: Help with @some_configure_var@ variables in automake files.
>>> "Jerry" == Iseri, Jerry <[EMAIL PROTECTED]> writes: Jerry> Is there documentation on where configuration variables are Jerry> allowed in automake files? Not in a single place. You can use them almost anywhere. Using them is tricky in a few places where they hide useful information to Automake. E.g., Automake needs to know all sources that will be compiled, but cannot guess the possible values of @MUMBLE@. In such cases you have to list the hidden values using an EXTRA_ variable (for instance grep the manual for EXTRA_hello_SOURCES or EXTRA_PROGRAMS). Jerry> Here's a small example: Jerry> #Is this supported? Jerry> AM_CPPFLAGS = @MY_EXTRA_FLAGS@ Automake doesn't care about the content of AM_CPPFLAGS, so you can set it as you wish. Jerry> noinst_PROGRAMS = foo Jerry> # This is documented as not allowed. Jerry> foo_SOURCES = @MY_SOURCES@ You can do this if you list the possible values of @MY_SOURCES@ in EXTRA_foo_SOURCES = foo.c foo.h ... Jerry> foo_LDADD = @HOW_ABOUT_THIS@ If @HOW_ABOUT_THIS@ contains object or libraries, you'll also want to redefine foo_DEPENDENCIES (grep the manual for maude_DEPENDENCIES). -- Alexandre Duret-Lutz
Re: automake/44: conditional redefinitions (Was: Re: Automake 1.6.3issue)
>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: [...] Akim> Nevertheless, I agree a means to install defaults would Akim> be most welcome. Akim> I suggest introducing Akim> foo ?= bar Akim> Which is always valid, but with a clear semantics. Assuming your semantic is that of BSD make: "assign unless set" [*], I can see how this help in if COND1 foo = mumble endif if COND2 foo = blurgle endif foo ?= else But I fail to see how you'd use this to override a default value whose definition has been included from elsewhere. (Unless inclusions of fragments defining default variables are done at the end of Makefile.am -- but this raises a few other issues.) [...] [*] IIRC someone once sent a patch against Automake to introduce `?=' as "assign and allow future redefinitions". -- Alexandre Duret-Lutz
Re: making a package install in a nonconventional dir
>>> "miki" == miki shapiro <[EMAIL PROTECTED]> writes: [...] miki> How do I kindly ask automake (in Makefile.am) to install miki> mypackage_PROGRAMS, mypackage_LIBRARIES, et cetra - into one directory - miki> /opt/mypackage for instance mypackagedir = /opt/mypackage It's probably best that you use bin_PROGRAMS, lib_PROGRAMS, or similar standard directories, and let the user relocate these directory where (s)he wants using ./configure --bindir=/opt/mypackage --libdir=/opt/mypackage ... Not everybody has/wants `/opt' on his system. Here is the doc about the custom *dir variables: |Sometimes the standard directories--even as augmented by Automake-- | are not enough. In particular it is sometimes useful, for clarity, to | install objects in a subdirectory of some predefined directory. To this | end, Automake allows you to extend the list of possible installation | directories. A given prefix (e.g. `zar') is valid if a variable of the | same name with `dir' appended is defined (e.g. `zardir'). | |For instance, until HTML support is part of Automake, you could use | this to install raw HTML documentation: | | htmldir = $(prefix)/html | html_DATA = automake.html -- Alexandre Duret-Lutz
Re: weird flags set by configure
>>> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes: Tim> On Wed, 2002-11-06 at 11:11, [EMAIL PROTECTED] wrote: >> DEFAULT_INCLUDES = -I. -I$(srcdir) -I. >> >> This raises 2 questions in itself: >> a. what's wrong with "DEFAULT_INCLUDES = -I. -I$(srcdir)" Tim> Don't know that, The third -I gives the search path for config.h. [...] Tim> There's no harm in -I . -I . -I . as far as I know. FWIW, spaces between `-I' and `.' are not portable. For instance in this case OSF's cc will handle `.' as a source file. [...] -- Alexandre Duret-Lutz
Re: cxx + cpp
>>> "Jean-Eric" == Jean-Eric Cuendet <[EMAIL PROTECTED]> writes: [...] Jean-Eric> Thus the question how to tell automake not to doubly define that. I think upgrading the Automake 1.7.1 should be enough. The last time this issue was reported the conclusion was it was fixed in Automake 1.7 (If you have www access you can find this thread by searching the list archive for your error message). -- Alexandre Duret-Lutz
Re: docbook support
>>> "Siegfried" == Siegfried Keusch <[EMAIL PROTECTED]> writes: [...] Siegfried> another point is that i had to change the clear.am to this Siegfried> ... Siegfried> clean-generic: Siegfried> CLEAN -test -z "$(CLEANFILES)" || rm -f $(CLEANFILES) Siegfried> MAINTAINERCLEAN -test -z "@MCFILES@" || rm -f @MFILES@ Siegfried> $(RM) -f $(SGMLFILES:.sgml=.pdf) $(SGMLFILES:.sgml=.ps) Siegfried> ... It's easier to define a `clean-local' target. This will be called by `make clean'. Just add something like this to your docbook.am: clean-local: $(RM) -f $(SGMLFILES:.sgml=.pdf) $(SGMLFILES:.sgml=.ps) Siegfried> the thing i wanted was to simply add Siegfried> SGMLFILES=architecture.sgml glossary.sgml Siegfried> to any makefile.am and then the proper documentation Siegfried> is created. Someone would have to add DocBook support to Automake. Would you be the guy? http://sources.redhat.com/automake/contribute.html -- Alexandre Duret-Lutz
Re: problem with variables
>>> "Roger" == Roger D Vargas <[EMAIL PROTECTED]> writes: Roger> I have created my Makefiles using other projects as Roger> examples. But always I got Invalid unused variable, no Roger> matter what name i use for the sources/headers list. It Roger> worked perfectly when my project was in a single dir, Roger> but when i try to separate sources from headers i cant Roger> find a way to make scripts work. Roger> What I doing wrong? Something you could try is to upgrade to Automake 1.7.1. The 1.7.x series is a bit more helpful in its diagnostics. If that doesn't help please send details about what you do; it's hard to guess what could be wrong... (If you have no idea what kind of details we'd like to see, read http://www.chiark.greenend.org.uk/~sgtatham/bugs.html) -- Alexandre Duret-Lutz
Re: Disabling dependency tracking - how?
>>> "miki" == miki shapiro <[EMAIL PROTECTED]> writes: [...] miki> Also, I looked inside this autogenerated rule (in miki> .deps/cppfilename.Po) , for some reason automake sticks miki> all 40 header files in the rule. Why? So that cppfilename.o gets recompiled if any of these files change. That's the purpose of dependency tracking. miki> AFAIK, it's not mandatory to mention them during compilation Huh? We don't do this. dependencies != sources [...] -- Alexandre Duret-Lutz
Re: bootstrap prob
>>> "Patrick" == Patrick Welche <[EMAIL PROTECTED]> writes:
[...]
Patrick> Bareword "am__installdirs" not allowed while "strict
Patrick> subs" in use at ./automake.tmp line 4742. BEGIN not
Patrick> safe after errors--compilation aborted at
Patrick> ./automake.tmp line 7682.
>> Which version of Perl is this?
Patrick> v5.6.0, and you guessed right: everything passes/works
Patrick> happily on a perl v5.8.0rc2 machine.
Thanks! Here is what I've found in the Perl 5.6.1 changelog:
[ 7283] By: gsar on 2000/10/16 03:52:14
Log: integrate change#5977 from mainline
autoquote barewords followed by newline and arrow properly
(variant of fix suggested by Rick Delaney and M.J.T. Guy)
Branch: maint-5.6/perl
!> t/pragma/warn/toke toke.c
So the bug is that Perl 5.6.0's "=>" operator doesn't quote the previous
word if separated by a new line.
I'm installing the following change.
2002-11-14 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* automake.in (handle_installdirs): Reindent to workaround a
parsing bug in Perl 5.6.0.
Reported by Patrick Welche.
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.1386
diff -u -r1.1386 automake.in
--- automake.in 14 Nov 2002 16:11:55 - 1.1386
+++ automake.in 14 Nov 2002 16:31:25 -
@@ -4736,14 +4736,12 @@
# Deal with installdirs target.
sub handle_installdirs ()
{
-$output_rules .=
- &file_contents ('install',
- new Automake::Location,
- am__installdirs
- => variable_value ('am__installdirs') || '',
- 'installdirs-local'
- => (target_defined ('installdirs-local')
- ? ' installdirs-local' : ''));
+ $output_rules .= &file_contents
+('install',
+ new Automake::Location,
+ am__installdirs => variable_value ('am__installdirs') || '',
+ 'installdirs-local' => (target_defined ('installdirs-local')
+? ' installdirs-local' : ''));
}
--
Alexandre Duret-Lutz
Re: LEX & YACC support
>>> "Alexandros" == Alexandros Karypidis <[EMAIL PROTECTED]> writes: Alexandros> Hi all, Alexandros> I am unsatisfied with the "Makefile.am" I have Alexandros> built, due to the fact that whenever I change my Alexandros> bison file to add a %token, I have to run make Alexandros> TWICE to get a correct build. This is because the Alexandros> header file with token declarations which is Alexandros> generated when yacc is run, also affects the Alexandros> lexical scanner -- therfore it needs to be rebuilt Alexandros> as well. However, this is only detected after the Alexandros> fist "make" command. Generated headers are almost always an issue for dependency tracking. Try adding the following and see if that helps. BUILT_SOURCES = parser.h [...] -- Alexandre Duret-Lutz
Re: Linking in C++ mode
>>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: [...] Ralf> 2. Finding a way to convince automake to using "g++" to link a you Ralf> program. Ralf> Automake guesses upon the linker by using file name extensions. Your Ralf> "main" is called "*.c", so it tries to use "gcc" instead of "g++". Ralf> One way to work around this problem is renaming your "main" a c++ file Ralf> name. Another way is to dive into automake internals and to override the Ralf> linker (CXXLINK and CXXLD vs CCLINK and CCLD). You can override the LINK command on a per-program basis: bin_PROGRAMS = foo foo_SOURCES = foo.c foo_LINK = $(CXX) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@ -- Alexandre Duret-Lutz
Re: problem with variables
>>> "Roger" == Roger D Vargas <[EMAIL PROTECTED]> writes: [...] Roger> The problem with details is that i have asked here a Roger> couple of times, the first time i included my scripts Roger> and my message is still awaiting for approval. Nobody has the time to moderate the list. If your mail was blocked, it's lost. [...] -- Alexandre Duret-Lutz
Re: bootstrap prob
>>> "Patrick" == Patrick Welche <[EMAIL PROTECTED]> writes: [...] Patrick> That was quick! Now it has gone past am__include, but is failing at: Patrick> % ./automake Patrick> Can't locate object method "TIEHASH" via package "Tie::RefHash::Nestable" at ./automake line 512. [Nestable is new in 5.6.1] Patrick> Is this beginning to sound like an argument for "we Patrick> don't support 5.6.0"? No. This Nestable stuff is only temporary, until further work on the way variables and targets are stored is done. See the following if you want an explanation why we need Netstable at the moment. http://mail.gnu.org/pipermail/automake-patches/2002-October/001239.html I don't know what you use CVS Automake for. Wouldn't tracking branch-1-7 be more appropriate? -- Alexandre Duret-Lutz
Re: bootstrap prob
>>> "Patrick" == Patrick Welche <[EMAIL PROTECTED]> writes:
Patrick> With cvs code from now:
Patrick> % sh bootstrap
Patrick> Bareword "am__installdirs" not allowed while "strict subs" in use at
./automake.tmp line 4742.
Patrick> BEGIN not safe after errors--compilation aborted at ./automake.tmp line 7682.
Hi Patrick,
Which version of Perl is this?
[...]
Patrick> am__installdirs
Patrick> => variable_value ('am__installdirs') || '',
[...]
Patrick> I don't see how that should work...
Patrick> &variable_value('MAKEFILE-AM-INSTALLDIRS'), then
Patrick> 'MAKEFILE-AM-INSTALLDIRS' => variable_value('am__installdirs').. ?
Patrick> ?
I don't understand what you mean.
I think Perl is just asking for quote around am__installdirs,
although I don't know why.
--
Alexandre Duret-Lutz
Re: getting a locally built library
>>> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes: Bruce> David Bacher wrote: [...] >> /bin/sh ../libtool --mode=link gcc -g -O2 -L/sw/lib -o autogen \ >> -export-dynamic -lguile *.o -L/sw/lib -lguile -lm \ >> -L../autoopts/.libs -lopts -ldl >> ld: Undefined symbols: >> _aopts_alloc >> _aopts_realloc >> _aopts_strdup >> make[1]: *** [autogen] Error 1 Where does this command comes from? This doesn't look like an Automake-generated call to libtool. First, Automake should not generate something like `*.o'; second, it should not output `-L../autoopts/.libs -lopts' but `../autoopts/libopts.la' since Bruce said `autogen_LDADD = $(top_builddir)/autoopts/libopts.la'. I'm tempted to think that the link rule was hand-edited (either in the Makefile(|.in|.am), or in the output). [...] -- Alexandre Duret-Lutz
Re: getting a locally built library
>>> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes: Bruce> Alexandre Duret-Lutz wrote: >> >> /bin/sh ../libtool --mode=link gcc -g -O2 -L/sw/lib -o autogen \ >> >> -export-dynamic -lguile *.o -L/sw/lib -lguile -lm \ >> >> -L../autoopts/.libs -lopts -ldl >> >> ld: Undefined symbols: >> >> _aopts_alloc >> >> _aopts_realloc >> >> _aopts_strdup >> >> make[1]: *** [autogen] Error 1 [...] >> it should not output >> `-L../autoopts/.libs -lopts' but `../autoopts/libopts.la' >> since Bruce said `autogen_LDADD = $(top_builddir)/autoopts/libopts.la'. [...] Bruce> That part I did not change from David's email. David, could you explain where `-L../autoopts/.libs -lopts' comes from? [...] -- Alexandre Duret-Lutz
Re: ccache and autotools
>>> "Jean-Eric" == Jean-Eric Cuendet <[EMAIL PROTECTED]> writes: [...] Jean-Eric> In fact, ccache tells in logfile that -MT is not supported. Jean-Eric> What does -MT do? Dependency tracking, see the GCC 3.x manual. Jean-Eric> And why dows autoconf use it? Can we not use it safely? Automake uses -MT for dependency tracking. But Automake knows many way to track dependencies, including some that don't use -MT; so I'm surprized that it choose this mode (called "gcc3") if ccache doesn't support it. How do you configure your project to use ccache? Do you tell ./configure that you want to use ccache as the compiler? (you should). -- Alexandre Duret-Lutz
Re: SWIG and Python support of Automake
>>> "Sebastian" == Sebastian Huber <[EMAIL PROTECTED]> writes: Sebastian> Hello, Sebastian> SWIG generates a Python module for me. This works Sebastian> fine with Automake 1.7 except that a 'make Sebastian> distcheck' fails: Sebastian> No files given to ../config/py-compile Sebastian> make[2]: *** [install-nodist_pythonPYTHON] Error 1 This as fixed in Automake 1.7.1. (See PR/369 for details.) [...] -- Alexandre Duret-Lutz
Re: AUTOMAKE: version numbering scheme?
>>> "Alexei" == Alexei Lioubimov <[EMAIL PROTECTED]> writes: Alexei> Hello, Alexei> Is there any document describing AUTOMAKE version numbering scheme? http://sources.redhat.com/ml/automake/2002-08/msg6.html -- Alexandre Duret-Lutz
Re: automake/376: Controlling the order of installation
>>> "Philip" == Philip Willoughby <[EMAIL PROTECTED]> writes: Philip> I have: Philip> lib_LTLIBRARIES=libaptttest.la Philip> libaptttest_la_SOURCES=aptt/test/test.c Philip> libaptttest_la_LIBADD=libapttlog.la @LTLIBINTL@ Philip> pkglib_LTLIBRARIES=libapttlog.la Philip> libapttlog_la_SOURCES=aptt/log/log.c Philip> libapttlog_la_LIBADD=@LIBLTDL@ Philip> in a Makefile.am. Unfortunately, automake does not recognise that Philip> libapttlog.la must be installed prior to the installation of Philip> libaptttest.la. Philip> Is there a way to hint to automake that the order is Philip> important without moving to recursive make? Maybe you could try using the same dir-prefix for both libraries. Something like nobase_lib_LTLIBRARIES = yourpkg/libapttlog.la libaptttest.la libaptttest_la_SOURCES = aptt/test/test.c libaptttest_la_LIBADD = libapttlog.la @LTLIBINTL@ yourpkg_libapttlog_la_SOURCES = aptt/log/log.c yourpkg_libapttlog_la_LIBADD = @LIBLTDL@ then libraries should be installed in the order they appear in nobase_lib_LTLIBRARIES. Philip> Alternatively, does anyone have a patch to Philip> automagically do the right thing? Right now this seems hard. I've submitted this as PR/376, so we don't forget about it eventually. Fortunatelly it's more frequent that dependent libraries get installed in the same directory. -- Alexandre Duret-Lutz
Re: Patch: Too many files in AC_OUTPUT cause M4 error
[M-F-T: [EMAIL PROTECTED]]
>>> "Martin" == Martin Frydl <[EMAIL PROTECTED]> writes:
[...]
Martin> I've created a patch which is aware of M4 problem and
Martin> separates the task into two expressions - first removes the
Martin> terminating space, then strips the leading one and puts brackets
Martin> around.
[...]
Martin> + [at_patsubst(at_patsubst(at_patsubst(at_patsubst($1, [\\\n]),
Martin> + [[\n\t ]+], [ ]),
Martin> + [ *\(.\)$],[\1]),
Martin> + [^ *\(.*\)], [[\1]])])
This doesn't seem to do what you want. `[ *\(.\)$],[\1]' will leave the
last trailing space, or strip non trailing whitespaces.
How about something like
[at_patsubst(at_patsubst(at_patsubst(at_patsubst($1, [\\\n]),
[[\n\t ]+], [ ]),
[ *$]),
[^ *\(.*\)], [[\1]])])
--
Alexandre Duret-Lutz
Re: error 'traces.m4' running automake-1.7
>>> "Martin" == Martin Frydl <[EMAIL PROTECTED]> writes: Martin> Hello Dave, Martin> I've created a patch file for Autoconf fixing this problem. I've Martin> posted it to Autoconf but noone responded yet. Can you try it and let Martin> me know? Martin> Martin Martin> http://mail.gnu.org/pipermail/automake/2002-November/012234.html I've found other similar reports while reading my backlog of mail today. Until an Autoconf maintainer processes your patch, another solution (apparently) is to use the development version of GNU M4. See http://sources.redhat.com/ml/bug-automake/2002/msg02090.html -- Alexandre Duret-Lutz
Re: Problem with Makefile.am
Hi! >>> "Roger" == Roger D Vargas <[EMAIL PROTECTED]> writes: [...] Roger> It worked fine until a couple of hour ago. Now one of Roger> the developers added some files and removed Is this still an issue? If so, could you show us the problem you have? Your mail stops at this point in the middle of a sentence. -- Alexandre Duret-Lutz
Automake 1.7.1b prerelease available (beta for Automake 1.7.2)
Hi people! Here is a snapshot of the 1.7.x branch of Automake. ftp://sources.redhat.com/pub/automake/automake-1.7.1b.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.7.1b.tar.gz This should be reasonably close to what 1.7.2 will be. Please test it and report any problem you have, so we can release 1.7.2 soon. There have been a couple of ansi2knr changes, so it would be nice to hear from people that are (still) using this. Please send bug reports to <[EMAIL PROTECTED]>, or using the Gnats interface at http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=automake Bugs fixed in 1.7.1b: * Fix ansi2knr rules for LIBOBJS sources. * Clean all known Texinfo index files, not only those which appear to be used, because we cannot know wich indexes are used in included files. (PR/375, Debian Bug #168671) * Honor only the first @setfilename seen in a Texinfo file. * Treat "required file X not found" diagnostics as errors (exit status 1). * Don't complain that a required file is not found when it is a Makefile target. (PR/357) * Don't use single suffix inference rules when building `.info'-less Info files, for the sake of Solaris make. * The `check' target now depends on `$(BUILT_SOURCES)'. (PR/359) * Recognize multiple inference rules such as `.a.b .c.d:'. (PR/371) * Warn about multiple inference rules when -Wportability is used. (PR/372) * Fix building of deansified files from subdirectories. (PR/370) * Add missing `fi' in the .c->.obj rules. * Improve install-sh to work even when names contain spaces or certain (but not all) shell metachars. * Fix the following spurious failures in the test suite: gnits2.test, gnits3.test, python3.test, texinfo13.test
Re: Automake 1.7.1b prerelease available (beta for Automake 1.7.2)
>>> "chuck" == Charles Wilson <[EMAIL PROTECTED]> writes:
[...]
chuck> 1.7.1b fixes the gnits2 failure on cygwin, but not the gnits3 failure
chuck> (it's possible that gnits3 exhibited two problems on cygwin, and the
chuck> recent patch only fixed one of them?)
[...]
Yep. Thanks! I'm installing the following patch on HEAD and branch-1-7.
2002-12-02 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* automake.texi (Options): Programs listed in
AM_INSTALLCHECK_STD_OPTIONS_EXEMPT should have $(EXEEXT) appended.
* tests/gnits3.test (AM_INSTALLCHECK_STD_OPTIONS_EXEMPT):
Append $(EXEEXT).
Reported by Charles Wilson.
Index: automake.texi
===
RCS file: /cvs/automake/automake/automake.texi,v
retrieving revision 1.305.2.4
diff -u -r1.305.2.4 automake.texi
--- automake.texi 29 Nov 2002 22:07:33 - 1.305.2.4
+++ automake.texi 2 Dec 2002 08:03:58 -
@@ -4509,6 +4509,17 @@
test. For instance @command{false} (from GNU sh-utils) is never
successful, even for @code{--help} or @code{--version}. You can
list such programs in the variable @code{AM_INSTALLCHECK_STD_OPTIONS_EXEMPT}.
+Programs (not scripts) listed in this variable should be suffixed by
+@code{$(EXEEXT)} for the sake of Win32 or OS/2. For instance suppose we
+build @code{false} as a program, @code{true.sh} as a script, and that
+none of them support @code{--help} and @code{--version}:
+
+@example
+AUTOMAKE_OPTIONS = std-options
+bin_PROGRAMS = false ...
+bin_SCRIPTS = true.sh ...
+AM_INSTALLCHECK_STD_OPTIONS_EXEMPT = false$(EXEEXT) true.sh
+@end example
@item @code{subdir-objects}
If this option is specified, then objects are placed into the
Index: tests/gnits3.test
===
RCS file: /cvs/automake/automake/tests/gnits3.test,v
retrieving revision 1.3.2.1
diff -u -r1.3.2.1 gnits3.test
--- tests/gnits3.test 30 Nov 2002 20:41:39 - 1.3.2.1
+++ tests/gnits3.test 2 Dec 2002 08:03:59 -
@@ -40,7 +40,7 @@
nobase_bin_SCRIPTS = nok.sh sub/nok.sh
-AM_INSTALLCHECK_STD_OPTIONS_EXEMPT = nok nok.sh
+AM_INSTALLCHECK_STD_OPTIONS_EXEMPT = nok$(EXEEXT) nok.sh
grep-stderr:
grep 'sub/pnok$(EXEEXT) does not support' stderr
--
Alexandre Duret-Lutz
Re: Automake 1.7.1b prerelease available (beta for Automake 1.7.2)
| 2002-12-02 Charles Wilson <[EMAIL PROTECTED]> | | * tests/gnits3.test (AM_INSTALLCHECK_STD_OPTIONS_EXEMPT): | Append $(EXEEXT) again. Thank you. It's committed. -- Alexandre Duret-Lutz
Re: automake 1.7
Hi! >>> "DB" == DB Troll <[EMAIL PROTECTED]> writes: DB> Can someone please help me. I am trying to install automake-1.7 DB> because another app says that it cannot use 1.5. Whentrying to DB> configure I get the reply no te and autoconf 2.5> not found. I DB> downloaded and installed autoconf2.57, rebooted but still the same DB> msgs. I am new at linux and runnong SuSE 8.0 Pro. Is the new autoconf in your PATH? What does `autoconf --version' print? -- Alexandre Duret-Lutz
Re: automake 1.7.1 hangs while processing Makefile.am
>>> "Jason" == Jason Jordan <[EMAIL PROTECTED]> writes: [...] Jason> One thing I noticed is that if I remove either all of Jason> the 'if MODE_*' OR all of the 'if FORMAT_*' clauses, Jason> then automake doesn't hang. I'm not sure whether that's Jason> helpful, but it was interesting. :) Jason> Can anyone tell me if I am doing something wrong? Nothing, unfortunately. Many of the Automake functions that deal with conditionals in Automake rely on an aglorithm that compute all possible combinations of conditionals involved in a variable definition (a conditionals can be either TRUE or FALSE). Each time you add a conditional, Automake gets twice slower. At some point it gets too slow to be of any use. Here Automake is just computing all the 2^17 combinations of your MODE_* and FORMAT_* conditionals... Recently there have been some work to improve the way Conditionals are handled (in what will become Automake 1.8, do not expect this in the 1.7.x branch). This explosive algorithm is still used in two places, but we have all the machinery to get rid of it. I hope this will improve things. As a workaround I suggest you use _LDADD substitutions as suggested in the `Conditional Sources' section of the manual. Basically instead of playing with conditionals, you should just fill an AC_SUBSTed variable with the objects you want. test "x$needs_mode_cat" = xyes && condobjs="$condobj mod_cat.$(OBJEXT)" test "x$needs_mode_cmp" = xyes && condobjs="$condobj mod_cmp.$(OBJEXT)" test "x$needs_mode_fix" = xyes && condobjs="$condobj mod_fix.$(OBJEXT)" ... AC_SUBST([condobjs]) Then use $(condobjs) to fill shntool_LDADD and shntool_DEPENDENCIES in Makefile.am. -- Alexandre Duret-Lutz
Automake 1.7.2 released
We're pleased to announce the release of Automake 1.7.2 This is a bug fix release. The list of bug fixes is appended. You can find the new release here: ftp://ftp.gnu.org/gnu/automake/automake-1.7.2.tar.bz2 ftp://ftp.gnu.org/gnu/automake/automake-1.7.2.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.7.2.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.7.2.tar.gz Soon it will also appear on the sources and GNU mirrors listed here: http://www.gnu.org/order/ftp.html http://sources.redhat.com/mirrors.html Here are the MD5 checksums: 8cfa661dca69271b862bee4f841fcd80 automake-1.7.2.tar.bz2 753647afe9db0ec52c69c6b9bb7dd106 automake-1.7.2.tar.gz Please report bugs to <[EMAIL PROTECTED]>. - Akim, Alexandre, and Tom Bugs fixed in 1.7.2: * Fix installation and uninstallation of Info files built in subdirectories. * Do not run `./configure --with-included-gettext' during `make distcheck' if AM_GNU_GETTEXT([external]) is used. * Correctly uninstall renamed man pages. * Do not strip escaped newline in variables defined in one condition and augmented in another condition. * Fix ansi2knr rules for LIBOBJS sources. * Clean all known Texinfo index files, not only those which appear to be used, because we cannot know wich indexes are used in included files. (PR/375, Debian Bug #168671) * Honor only the first @setfilename seen in a Texinfo file. * Treat "required file X not found" diagnostics as errors (exit status 1). * Don't complain that a required file is not found when it is a Makefile target. (PR/357) * Don't use single suffix inference rules when building `.info'-less Info files, for the sake of Solaris make. * The `check' target now depends on `$(BUILT_SOURCES)'. (PR/359) * Recognize multiple inference rules such as `.a.b .c.d:'. (PR/371) * Warn about multiple inference rules when -Wportability is used. (PR/372) * Fix building of deansified files from subdirectories. (PR/370) * Add missing `fi' in the .c->.obj rules. * Improve install-sh to work even when names contain spaces or certain (but not all) shell metachars. * Fix the following spurious failures in the test suite: depcomp2.test, gnits2.test, gnits3.test, python3.test, texinfo13.test * Noteworthy manual updates: - Augment the section about BUILT_SOURCES. - Mention that AM_PROG_CC_STDC is a relic that is beter avoided today.
Re: make distcheck fails: permission denied
>>> "Dan" == Dan Christian <[EMAIL PROTECTED]> writes: [...] Dan> First, why is it trying to re-create the config stuff? It *copies* these files because it's trying to build a distribution. Dan> Second, why didn't it fix the permissions? No idea, Automake 1.5 is old. Does it still fail with Automake 1.7.2? [...] -- Alexandre Duret-Lutz
Re: Specifying include directories for groups of source files
>>> "William" == William S Fulton <[EMAIL PROTECTED]> writes: William> A question about groups of files in subdirectories. I William> would like Automake's generated Makefiles to compile William> groups of files using different include directories, William> that is, different INCLUDES (AM_CFLAGS) for each William> group. Each group is in a different subdirectory. Is William> this possible without using the _LIBRARIES or William> _LTLIBRARIES primary? Can't think of any other way. William> Motivation: We don't want to use libtool and having a William> separate Makefile.am each with its own _LIBRARIES does William> not work on all platforms, notably using native William> Windows compilers. (This doesn't necessarily require separate Makefile.ams: you can build the subdir libraries from the parent directory.) What's wrong with Windows compilers? Is there anything we could fix in Automake to make generated Makefiles more portable? [...] -- Alexandre Duret-Lutz
Re: automake 1.7.1 hangs while processing Makefile.am
>>> "Jason" == Jason Jordan <[EMAIL PROTECTED]> writes: [...] Jason> Thank you, this worked like a charm. I also had to add all possible Jason> format source files to EXTRA_DIST so they would be included in the Jason> distribution. :) Generally it's better to list these files in EXTRA_shntool_SOURCES. This will help Automake to generate compilation rules and setup automatic dependency tracking for these files, or chose the right linker to use for shntool. [...] -- Alexandre Duret-Lutz
automake/380: User produced dependency files - possible to usethem?
>>> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes: Alex> Hi, Alex> As part of my project I have some suffix rules to produce built sources Alex> from which I can produce automatic dependency information. Alex> My question is - is it possible to get automake to take these user Alex> defined auto dependencies into consideration? No. This sounds like something Automake ought to support -- I've submitted a PR for this. Right now I believe you have to do yourself what Automake does: * fill Makefile.am with a series of @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/foo.Po@am__quote@ * create empty dependency files from config.status [...] -- Alexandre Duret-Lutz
Re: make distcheck fails: permission denied
>>> "Dan" == Dan Christian <[EMAIL PROTECTED]> writes: [...] Dan> I tried 1.6.3. That worked OK. Great. Dan> However, when I do a "make check" on 1.6.3 it fails test "lex5.test". Dan> Any ideas what is going wrong? No. There has been a lex5 failure reported against 1.7.2 recently, but it's pending details. Maybe this is the same. Could you send the output of the following command? make TESTS=lex5.test VERBOSE=x check -- Alexandre Duret-Lutz
Re: Passing configure options to make distcheck
>>> "John" == John Levon <[EMAIL PROTECTED]> writes: [...] John> make distcheck fails by default, but if I could pass in a configure John> option, it would work. Can I do this ? Starting with Automake 1.6 you can set DISTCHECK_CONFIGURE_FLAGS. [...] -- Alexandre Duret-Lutz
Re: Modifying installed script names ?
>>> "John" == John Levon <[EMAIL PROTECTED]> writes: [...] John> If a condition is set, then op_start_25,op_dump_25,op_stop_25 need to John> be installed as op_start,op_dump,op_stop, otherwise we can just install John> the existing op_start/dump/stop in the source tree. You could declare everybody using `noinst_SCRIPTS', and install them using a custom `install-exec-local' rule. [...] -- Alexandre Duret-Lutz
Re: version7.test
>>> "Patrick" == Patrick Welche <[EMAIL PROTECTED]> writes: Patrick> Just got (fresh cvs): Patrick> ERROR: files left in build directory after distclean: Patrick> ./version7-3.141.tar.gz Thank you. I'm checking this in. 2002-12-13 Alexandre Duret-Lutz <[EMAIL PROTECTED]> * tests/version7.test: Require GNU make. Reported by Patrick Welche. --- tests/version7.test 10 Oct 2002 17:37:38 - 1.1 +++ tests/version7.test 13 Dec 2002 21:55:40 - @@ -19,9 +19,11 @@ # Boston, MA 02111-1307, USA. # Test for a special setup where the package's version isn't defined -# in configure.in. +# in configure.in. We want GNU Make for this test (part of the test +# is to make sure Makefile.ins get rebuilt when a m4_included file +# changes -- we don't support this feature on non-GNU Makes). -required='makeinfo tex' +required='makeinfo tex GNUmake' . ./defs || exit 1 set -e -- Alexandre Duret-Lutz
Re: configure and intel's C++: inappropriate flags -MT -MD -MP -MF
>>> "Markus" == Markus Werle <[EMAIL PROTECTED]> writes: Markus> Hi! Markus> I have a problem with the latest autotools: Markus> From somewhere behind the scenes automake/autoconf Markus> decides to insert the following options to the compiler Markus> flags; -MT -MD -MP -MF depcomp adds these options, and ./configure makes the decision based on the compiler found (or that you specified). ./configure prints something like `checking dependency style of XXX' at this point. Markus> these are not recognized, say ignored ith annoying warnings by Markus> intel's C++ 7.0. Any idea how to remove these via Markus> configure.in or Makefile.am? Maybe your are not setting the compiler early enough? Since ./configure decides which flags to use it must know the compiler. Therefore you should run ./configure CC=mycc; make not ./configure; make CC=mycc -- Alexandre Duret-Lutz
Re: automake 1.6 on solaris
>>> "Thomas" == Thomas Vander Stichele <[EMAIL PROTECTED]> writes: Thomas> Hello, Thomas> I'm trying to get GStreamer to autogen properly on Thomas> Solaris, but automake fails. Thomas> I get a lot these warnings: Thomas> configure.ac:425: invalid unused variable name: `GST_PLUGIN_LDFLAGS' Hi Thomas, This was fixed in Automake 1.6.1. [...] -- Alexandre Duret-Lutz
Re: per-file compiler flags?
>>> "gd" == Guido Draheim <[EMAIL PROTECTED]> writes: [...] gd> (a) per file compile flags: gd> - it's an faq and later automake supports it natively This has yet to be implemented (any taker?). What Automake supports presently is per-target flags. The usual way to emulate per-object flags is to compile the file in a static library and use per-libary flags. [...] -- Alexandre Duret-Lutz
Re: Change in dejagnu generated rules?
>>> "Phil" == Phil Edwards <[EMAIL PROTECTED]> writes: Phil> When AUTOMAKE_OPTIONS contains dejagnu, one of the generated rules is Phil> check-am: Phil> $(MAKE) $(AM_MAKEFLAGS) check-DEJAGNU Phil> I could have sworn that at some time in the not-too-distant past, the -k Phil> flag would also be automatically passed to the sub-make, Phil> $(MAKE) -k $(AM_MAKEFLAGS) check-DEJAGNU Phil> due to dejagnu's annoyung habit regarding exit codes. Phil> Am I smoking something? Did this change recently? Looking at Automake 1.4's code, it seems it would not output -k either. I don't think it should. Some make implementation will always terminate with exit code 0 when `-k' is used, hiding any failure. -- Alexandre Duret-Lutz
Re: automake not seeing AM_INIT_AUTOMAKE
>>> "jlm" == jlm <[EMAIL PROTECTED]> writes: [...] jlm> automake-1.5: configure.ac: `AM_INIT_AUTOMAKE' must be used [...] jlm> AM_INIT_AUTOMAKE([no-define]) You need Automake 1.6 or greater to use this syntax. If for some reason you want to stick to 1.5, use AM_INIT_AUTOMAKE([libgtkbonus], [0.1], [non-empty-argument--see-manual]) [...] -- Alexandre Duret-Lutz
Re: configure and intel's C++: inappropriate flags -MT -MD -MP -MF
[...] | The problem is that Intel's C++ _accepts_ these flags and | only emits a warning. This might confuse the autotools here: Yep. | make[1]: Entering directory `/work/tresca/markus/DORIS/doris-0.0.1' | if icpc -DHAVE_CONFIG_H -I. -I. -I. -I. -I./src -I/opt/boost-1.29.0 -I/work/tr | esca/markus/DIET -ansi -MT TestPDEs.o -MD -MP -MF ".deps/TestPDEs.Tpo" \ | -c -o TestPDEs.o `test -f 'src/test/TestPDEs.C' || echo './'`src/test/TestPDEs | .C; \ | then mv ".deps/TestPDEs.Tpo" ".deps/TestPDEs.Po"; \ | else rm -f ".deps/TestPDEs.Tpo"; exit 1; \ | fi | icpc: Command line warning: ignoring option '-M'; no argument required | icpc: Command line warning: ignoring option '-M'; no argument required | icpc: Command line warning: no action performed for specified object file(s) | icpc -ansi -o euler TestPDEs.o SimpleRectangularStructured.o | make[1]: Leaving directory `/work/tresca/markus/DORIS/doris-0.0.1' What does .deps/TestPDEs.Po contains after this? Do you understand which -Mx options this diagnotic is referring to (there is only two warnings, but four -Mx options). How does icpc's -M option work? Are these warnings output to stdout or stderr? Is there any icpc-specific environment variable that can be set to turn warnings into errors? -- Alexandre Duret-Lutz
FYI: Re: aclocal in tests/defs.in
>>> "imacat" == imacat <[EMAIL PROTECTED]> writes: Sorry for the delay. [...] imacat> I was building automake 1.7.2 on a minimal-installed imacat> Debian Linux 3.0r0, which had no automake yet. When I imacat> did a "make check", I noticed that a part of tests were imacat> skipped. But most of them would be performed after I imacat> did a "make install". [...] imacat> After tracing into the test process, I found that some imacat> tests were depending on an aclocal that has no path imacat> specified, in tests/defs (tests/defs.in). This will imacat> run the aclocal in $PATH, usually the imacat> currently-installed aclocal, but not the newly-built imacat> one. [...] Thanks for the report and the patch. I've installed the following on HEAD and branch-1-7. This gets rid of the aclocal call entirely. Index: ChangeLog === RCS file: /cvs/automake/automake/ChangeLog,v retrieving revision 1.2024.2.69 diff -u -r1.2024.2.69 ChangeLog --- ChangeLog 31 Dec 2002 21:25:34 - 1.2024.2.69 +++ ChangeLog 5 Jan 2003 21:51:02 - @@ -1,3 +1,12 @@ +2003-01-05 Alexandre Duret-Lutz <[EMAIL PROTECTED]> + + * tests/defs.in: Substitute aclocaldir instead of running + the installed aclocal. Otherwise Libtool and Gettext + tests get skipped when aclocal doesn't preexist. + Reported by Imacat. + * tests/listval.test, tests/suffix2.test: Remove pointless -I + argument to aclocal. + 2002-12-31 Alexandre Duret-Lutz <[EMAIL PROTECTED]> * automake.in (err): Rename as ... @@ -2929,7 +2938,7 @@ - -Copyright (C) 2002 Free Software Foundation, Inc. +Copyright (C) 2002, 2003 Free Software Foundation, Inc. This file is part of GNU Automake. Index: ChangeLog.2001 === RCS file: /cvs/automake/automake/ChangeLog.2001,v retrieving revision 1.1 diff -u -r1.1 ChangeLog.2001 --- ChangeLog.2001 10 Apr 2002 07:54:30 - 1.1 +++ ChangeLog.2001 5 Jan 2003 21:51:15 - @@ -832,12 +832,12 @@ 2001-10-21 Akim Demaille <[EMAIL PROTECTED]> - * tests/defs (ACLOCAL): Point to the installed aclocaldir is + * tests/defs (ACLOCAL): Point to the installed aclocaldir if libtool is required. * tests/lex.test: Run AC_INIT once. * tests/ldflags.test, tests/listval.test, tests/suffix2.test: Libtool is required. - * tests/header.test: Built a correct configure.in. + * tests/header.test: Build a correct configure.in. * tests/defun2.test (configure.in): Be a bit respectful with Autoconf, close the macro invocations. * tests/confdeps.test: Even when not using aclocal, aclocal.m4 @@ -4931,7 +4931,7 @@ - -Copyright 2001 Free Software Foundation, Inc. +Copyright (C) 2001, 2003 Free Software Foundation, Inc. This file is part of GNU Automake. Index: THANKS === RCS file: /cvs/automake/automake/THANKS,v retrieving revision 1.186.2.12 diff -u -r1.186.2.12 THANKS --- THANKS 31 Dec 2002 21:25:35 - 1.186.2.12 +++ THANKS 5 Jan 2003 21:51:16 - @@ -75,6 +75,7 @@ Harlan Stenn [EMAIL PROTECTED] Henrik Frystyk Nielsen [EMAIL PROTECTED] Ian Lance Taylor [EMAIL PROTECTED] +Imacat [EMAIL PROTECTED] Inoue [EMAIL PROTECTED] James Henstridge [EMAIL PROTECTED] James Youngman [EMAIL PROTECTED] Index: tests/defs.in === RCS file: /cvs/automake/automake/tests/defs.in,v retrieving revision 1.4.2.3 diff -u -r1.4.2.3 defs.in --- tests/defs.in 21 Nov 2002 13:27:43 - 1.4.2.3 +++ tests/defs.in 5 Jan 2003 21:51:42 - @@ -1,5 +1,5 @@ # -*- shell-script -*- -# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002 +# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003 # Free Software Foundation, Inc. # # This file is part of GNU Automake. @@ -200,10 +200,10 @@ # We might need extra macros, e.g., from Libtool or Gettext. # Find them on the system. -# Use `-I $srcdir/../m4' in addition to `--acdir', because the +# Use `-I $srcdir/../m4' in addition to `--acdir=$srcdir/../m4', because the # other `-I' directories added for libtool and gettext might contain # files from an old version of Automake that we don't want to use. -aclocaldir=`(aclocal --print-ac-dir) 2>/dev/null` +aclocaldir='@prefix@/share/aclocal' extra_includes="" if [ -f $aclocaldir/dirlist ] ; then extra_includes=`(tmp_inc="" Index: tests/listval.test === RCS file: /cvs/automake/automake/tests/listval.test,v retr
Re: Absolute directories for tests.
>>> "David" == David Kirkby <[EMAIL PROTECTED]> writes: [...] David> The problem is that if run from the 'tests' directory, this runs okay, David> as the paths given in the test '../tools/src/mycksum' and David> '../examples/cop1.bmp' are correct relative to that 'tests' directory. David> However, if 'make distcheck' is run from the top directory of the David> package, the tests fails as those paths are wrong. To account for VPATH-builds, you should consider that sources files lie in `$srcdir', not `.'. Only built files are in the current directory. The above two paths are probably better written `$srcdir/../tools/src/mycksum' and '$srcdir/../examples/cop1.bmp'. $(srcdir) is defined as a Make variable in each Makefile. It is also exported as an environment variable to each test run as part of an Automake-style testsuite. David> Am I doing something fundamentally flawed? If not, is there a way of David> referring to the top level directory, so that for example $TOP/tests David> and $TOP/examples always point to the same directory, no matter where David> they are run from? Makefiles define $(top_srcdir), but this isn't exported to tests. Probably because nobody needed that yet. To answer your subject, there is no garanty that either $(srcdir) or $(top_srcdir) are absolute or relative, they can be either. Autoconf has recently started to substitute @abs_srcdir@ and @abs_top_srcdir@ (they do not get defined as Makefile variables, but you could do this yourself), however generally it's better to avoid using absolute paths. -- Alexandre Duret-Lutz
Re: help in installing binaries in both /bin and /usr/bin
>>> "Aneesh" == Aneesh Kumar K V <[EMAIL PROTECTED]> writes:
Aneesh> Hello,
Aneesh> I want to write Makefile.am that need to install
Aneesh> binaries in both /bin and /usr/bin.
`bin_PROGRAMS = foo' installs foo in `${bindir}'.
`barexec_PROGRAMS = baz' installs baz in `${barexecdir}'.
If you need more directories you can invent them, just defines
as many *dir variables as you need (in Makefile.am or using
AC_SUBST in configure.ac).
[...]
Aneesh> As of now i have
Aneesh> bin_PROGRAMS=abc
Aneesh> bin_PROGRAMS=xyz ==> What do i assign this to in order to
Aneesh> install it in /usr/bin
One possibility among many variations:
bin_PROGRAMS = abc
usrbinexecdir = $(exec_prefix)/usr/bin
usrbinexec_PROGRAMS = xyz
This is assuming $(exec_prefix) gets empty in some way, so abc
installs in /bin as it seems you want.
Using $(exec_prefix) to defines $(usrbinexecdir) makes sure the
user still gets the expected result with `make prefix=/tmpdir
install'. Using `exec' in the name of the `usrbinexecdir' variable
ensures `xyz' will be installed by `install-exec', not `install-data'.
--
Alexandre Duret-Lutz
Re: Extending VPATH
>>> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes: Harlan> I find that automake-1.7* (at least) complains about lines like: Harlan> if COND_FOO Harlan> VPATH=$(srcdir):$(srcdir)/../foo Harlan> endif Harlan> in Makefile.am's (VPATH was already defined in Harlan> condition TRUE, which implies COND_FOO). Harlan> Bug or feature? Maybe both. http://mail.gnu.org/archive/html/automake/2002-09/msg00054.html http://mail.gnu.org/archive/html/automake/2002-10/msg00018.html Comments welcome! -- Alexandre Duret-Lutz
Re: Bug byte-compiling lisp, automake 1.7.2
Hi Ryan,
Thanks for your report and the patch.
>>> "Ryan" == Ryan T Sammartino <[EMAIL PROTECTED]> writes:
[...]
Ryan> doxymacs.el requires xml-parse.el. Unfortunately the
Ryan> rule that automake generates:
[...]
Ryan> byte compiles each file one at a time, whereas elisp-comp
Ryan> is expecting ALL .el files to be passed in. Thus I get
Ryan> While compiling toplevel forms in file
Ryan> /home/ryants/projects/doxymacs/lisp/elc.14611/doxymacs.el:
Ryan> !! File error (("Cannot open load file" "xml-parse"))
Ryan> Done
[...]
Ryan> +2003-01-05 Ryan T. Sammartino <[EMAIL PROTECTED]>
Ryan> +
Ryan> +* lib/elisp-comp: add .. to load-path.
Ryan> +
As far as I can tell the other sources files are not necessarily
in `..'. For instance during a VPATH-build we'd have to search
them in `../$srcdir' (in case `$srcdir' is a relative path) or
in `$srcdir' (if it's absolute). Elisp files could also comes
from subdirectories.
I see this issue was already reported in 2000, without answers.
http://sources.redhat.com/ml/automake/2000-05/msg00016.html
Wouldn't it be better to teach Automake to byte-compile all
files at once rather than one at a time? I'm willing to do this
if people agree. My impression is that the reason why Automake
byte-compile files one at a time is that it's easier to write
Makefile rules this way. (Make's semantics make it tricky to
write rules with multiple outputs.)
[...]
--
Alexandre Duret-Lutz
Re: Bug byte-compiling lisp, automake 1.7.2
>>> "Ryan" == Ryan T Sammartino <[EMAIL PROTECTED]> writes:
[...]
Ryan> I guess what I should have said was "this patch solves
Ryan> the problem in my particular instance" :)
Ryan> I see now a little more is needed.
>> Wouldn't it be better to teach Automake to byte-compile all
>> files at once rather than one at a time?
Ryan> Yes.
Here is a proposal. Could you check whether this solves the
problem in your particular instance ? :) The patch is against
CVS HEAD, I'll backport it to branch-1-7 if that's ok.
Aside from compiling all elisp sources at once, this also
updates elisp-comp to resist to ^C and propagate emacs's exit
code (this is needed so the elc-stamp rule doesn't create
elc-stamp on errors.)
I'd also appreciate if someone could review the elisp bits I've
written in the test case. This looks fine to me, but as I don't
really know emacs-lisp I can't tell for sure.
2003-01-08 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
Build elisp files all at once instead of one by one.
* automake.in (handle_emacs_lisp): Define am__ELFILES. Add
elc-stamp to all's dependencies.
* lib/am/lisp.am (elc-stamp): New rule.
(.el.elc): Rewrite to call elc-stamp.
(clean-lisp): Clean elc-stamp.
* lib/elisp-comp: Reindent. Erase the temporatry directory
from a trap. Propagate Emacs's exit status.
* tests/lisp3.test: New file.
* tests/Makefile.am (TESTS): Add lisp3.test.
Reported by Ryan T. Sammartino.
Index: NEWS
===
RCS file: /cvs/automake/automake/NEWS,v
retrieving revision 1.199
diff -u -r1.199 NEWS
--- NEWS5 Dec 2002 09:02:30 - 1.199
+++ NEWS8 Jan 2003 20:37:10 -
@@ -1,4 +1,6 @@
New in 1.7a:
+* elisp sources are compiled all at once, instead of one by one.
+ This allows interdependencies and speed up compilation.
* AM_PROG_CC_STDC is now empty. The content of this macro was
merged in AC_PROG_CC. If your code uses $am_cv_prog_cc_stdc,
you should adjust it to use $ac_cv_prog_cc_stdc instead.
@@ -288,8 +290,8 @@
-
-Copyright 1995, 1996, 1997, 1998, 1999, 2000, 2001 Free Software
-Foundation, Inc.
+Copyright 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003
+Free Software Foundation, Inc.
This file is part of GNU Automake.
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.1414
diff -u -r1.1414 automake.in
--- automake.in 5 Jan 2003 22:51:10 - 1.1414
+++ automake.in 8 Jan 2003 20:37:35 -
@@ -4969,8 +4969,14 @@
# Generate .elc files.
my @elcfiles = map { $_->[1] . 'c' } @elfiles;
define_pretty_variable ('ELCFILES', TRUE, INTERNAL, @elcfiles);
+ define_pretty_variable ('am__ELFILES', TRUE, INTERNAL,
+ map { $_->[1] } @elfiles);
- push (@all, '$(ELCFILES)');
+ # It's important that all depends on elc-stamp so that
+ # all .elc files get recompiled whenever a .el changes.
+ # It's important that all depends on $(ELCFILES) so that
+ # we can recover if any of them is deleted.
+ push (@all, 'elc-stamp', '$(ELCFILES)');
require_variables ($elfiles[0][0], "Emacs Lisp sources seen", TRUE,
'EMACS', 'lispdir');
Index: lib/elisp-comp
===
RCS file: /cvs/automake/automake/lib/elisp-comp,v
retrieving revision 1.5
diff -u -r1.5 elisp-comp
--- lib/elisp-comp 17 Jul 2001 06:00:37 - 1.5
+++ lib/elisp-comp 8 Jan 2003 20:37:36 -
@@ -1,5 +1,5 @@
#!/bin/sh
-# Copyright 1995 Free Software Foundation, Inc.
+# Copyright (C) 1995, 2000, 2003 Free Software Foundation, Inc.
# François Pinard <[EMAIL PROTECTED]>, 1995.
#
# This program is free software; you can redistribute it and/or modify
@@ -31,24 +31,30 @@
# they require or load-library one another.
if test $# = 0; then
- echo 1>&2 "No files given to $0"
- exit 1
-else
- if test -z "$EMACS" || test "$EMACS" = "t"; then
- # Value of "t" means we are running in a shell under Emacs.
- # Just assume Emacs is called "emacs".
- EMACS=emacs
- fi
-
- tempdir=elc.$$
- mkdir $tempdir
- cp $* $tempdir
- cd $tempdir
-
- echo "(setq load-path (cons nil load-path))" > script
- $EMACS -batch -q -l script -f batch-byte-compile *.el
- mv *.elc ..
+ echo 1>&2 "No files given to $0"
+ exit 1
+fi
- cd ..
- rm -fr $tempdir
+if test -z "$EMACS" || test "$EMACS" = "t"; then
+ # Value of "t" means we are runnin
Re: help needed "make check"
>>> "Harald" == Harald Mitterhofer <[EMAIL PROTECTED]> writes: [...] Harald> when I change test-progs or some corresponding, tested source-files, Harald> only some of the check_PROGRAMS are rebuild on "make check", which is Harald> what I expect; nevertheless ALL TESTS (also those, not rebuilt) are Harald> executed, which is a runtime-problem and slows down my "test first" Harald> development strategy; I only want to run rebuilt tests; Harald> I searched for another make-target than "check" in the generated Harald> Makefile, but could not find any; Harald> I have no idea how to define one myself; Something like this? check-new: $(TESTS) $(MAKE) $(AM_MAKEFLAGS) TESTS='$?' check-TESTS : > $@ CLEANFILES = check-new -- Alexandre Duret-Lutz
Re: CXXFLAGS and linking
>>> "William" == William S Fulton <[EMAIL PROTECTED]> writes: William> I see that CXXFLAGS and AM_CXXFLAGS gets passed to the linker William> ($CXXLINK). CXXLINK calls the compiler, so we ought to pass these flags as they may affect the way the compiler calls the linker in the end. For instance the compiler might pass on additional objects to link based on the presence of flags like `-g', `-pg' or `-pthread'. William> This doesn't seem correct as the C++ flags aren't William> necessarily appropriate for linking. The example you sent to Guido uses `AM_CXXFLAGS = -DSOMETHING'. I wouldn't expect this to cause any trouble during linking. Does it? (If so you should probably change it to `AM_CPPFLAGS = -DSOMETHING'.) Am I missing something? William> This isn't consistent with the per-program William> _CXXFLAGS which do not get passed to the William> linker. Is this all as intended? I agree this is a bug. We should honor per-target compiler flags at link time for consistency. -- Alexandre Duret-Lutz
Re: CXXFLAGS and linking
>>> "Braden" == Braden McDaniel <[EMAIL PROTECTED]> writes: Braden> GNU make doesn't agree. I hear you, but that no reason: Automake follows the GNU Coding Standards in this case. -- Alexandre Duret-Lutz
Re: CXXFLAGS and linking
>>> "Braden" == Braden McDaniel <[EMAIL PROTECTED]> writes: [...] Braden> I've reviewed 7.2 in the GNU Coding Standards, and it's Braden> not clear to me what you're referring to. Where exactly Braden> should I be looking? The following sentence in the `Variables for Specifying Commands' section (sorry I don't have section number in the info version). | `CFLAGS' should be used in every invocation of the C compiler, both | those which do compilation and those which do linking. -- Alexandre Duret-Lutz
Re: help! automake "sees" nonexistent C files
>>> "Markus" == Markus Werle <[EMAIL PROTECTED]> writes:
Markus> Markus Werle wrote:
>> Hi!
>>
>> After some very slight changes to my Makefile.am
Markus> ... which included a multline comment:
Markus> #euler_SOURCES = \
Markus> # ${COMMON_SOURCES} \
Markus> # src/pdes/EULER_2D_UNI/main.C \
Markus> # src/pdes/EULER_2D_UNI/ConservationOfMass.C \
Markus> # src/pdes/EULER_2D_UNI/ConservationOfMomentum.C \
Markus> # src/pdes/EULER_2D_UNI/ConservationOfEnergy.C \
Markus> # src/pdes/EULER_2D_UNI/BoundaryConditions.C
`euler_SOURCES' defaults to `euler.c' if you don't define it.
No wonder Automake asks for a compiler. Just define it as empty
to get rid of the error message.
[...]
--
Alexandre Duret-Lutz
Re: a question about automake
>>> "huangwei" == huangwei <[EMAIL PROTECTED]> writes: huangwei> Dear all, huangwei> I am a Newbie about automake. huangwei> I am confused in the makefile.in,because in it there huangwei> are many variables like as follows: huangwei> ... huangwei> LIBS = @LIBS@ huangwei> ... huangwei> When I type configure ,using LIBS=/home/yiyid/usr/lib huangwei> (non-standard lib directory),but int the makefile huangwei> generated automatically ,the value of LIBS will be huangwei> the system default path + the path which I have set. huangwei> Could tell me how to solve it then? Sorry I don't understand this part of your mail. Could you *show* what you did, what you got, and explain what you would have expected? huangwei> And another question, how to let the same variable in huangwei> makefile.in of subdirectors be set at the same time? Any variable defined with `AC_SUBST' in your `configure.ac' will be defined in all your `Makefile's. If you also want to defines rules or if you don't want to define variables in *all* `Makefile's, you can factor these definitions in a `Makefile' fragment that you will `include' in all the relevant `Makefile.am's. See the `Include' section of the manual for the syntax. huangwei> I have set the top directory makefile, but it seem huangwei> that the makefiles in the subdirectory can't be set. Indeed. There is no "variable inheritance" between `Makefile's. -- Alexandre Duret-Lutz
Re: making script executable?
>>> "mcmahill" == mcmahill <[EMAIL PROTECTED]> writes: mcmahill> I have a shell script which I want to run as part of mcmahill> a testsuite. However when I do a 'make distcheck' mcmahill> this script [...] ends up with execute permissions mcmahill> turned off. How does this happen? Automake uses many shell scripts in its test suite. They are all executable and they don't lose their permission bits during distcheck (AFAIK). Automake doesn't use `chmod +x' nor `$(SHELL)'. Anyway these would be just workarounds, the real problem is why your script lose its executable bit, not how to set it back. -- Alexandre Duret-Lutz
Re: making script executable?
>>> "Bob" == Bob Proulx <[EMAIL PROTECTED]> writes: Bob> Simon Richter wrote: >> >> $(SHELL) ? Bob> Does that mean that a SHELL=/bin/csh user will run the script with csh Bob> and a SHELL=/bin/zsh user will run the shell with zsh? Nope. The $(SHELL) Makefile variable is AC_SUBST'ed by ./configure, fortunately it doesn't come from the environment. (Still there are broken make implementations that will use the SHELL envvar when run as `make -e'. Details in the Autoconf manual.) -- Alexandre Duret-Lutz
Re: -rm -f core.$pid
>>> "Patrick" == Patrick Guio <[EMAIL PROTECTED]> writes: [...] Patrick> core files generated are called after process id with Patrick> the syntax core.$pid [...] Patrick> That might be nice to remove those as well? [...] Thanks for the suggestion. What do people thinks about Automake's removal of core dumps? I tend to think it's a misfeature. For one thing, this doesn't match the documentation. Quizz: which of the following targets do you think Automake is using to clear `core' files? | * If `make' built it, and it is commonly something that one would |want to rebuild (for instance, a `.o' file), then `mostlyclean' |should delete it. | | * Otherwise, if `make' built it, then `clean' should delete it. | | * If `configure' built it, then `distclean' should delete it | | * If the maintainer built it, then `maintainer-clean' should delete |it. Nhgbznxr pyrnaf pber svyrf qhevat va gur zbfgylpyrna gnetrg. Furthermore, if any core file is dumped during `make distcheck', then it's obviously a bug in the package and we should not hide it. What happens presently is that `distclean' will remove the core, so we'll not notice it when checking for spurious files in the build tree. Although the build will probably go wrong anyway, I'm not a supporter of things that may conceal bugs. -- Alexandre Duret-Lutz
Re: Sending header files to etags
>>> "Alan" == Alan Gutierrez <[EMAIL PROTECTED]> writes:
Alan> bin_PROGRAMS = foo
Alan> foo_SOURCES = \
Alan> src/foo/foo.hpp \
Alan> src/foo/foo.cpp
Alan> automake correctly determines the foo.hpp dependency for building foo,
Alan> but doesn't feed foo.hpp to etags.
% make tags
tags=; \
here=`pwd`; \
list='src/foo/foo.hpp src/foo/foo.cpp'; \
unique=`for i in $list; do \
if test -f "$i"; then echo $i; else echo ./$i; fi; \
done | \
gawk '{ files[$0] = 1; } \
END { for (i in files) print i; }'`; \
test -z "$tags$unique" \
|| etags\
$tags $unique
Looks like it works for me.
Which version of Automake are you complaining about?
--
Alexandre Duret-Lutz
Re: Java class files, again
>>> "Eric" == Eric Siegerman <[EMAIL PROTECTED]> writes: Eric> On Sat, Feb 01, 2003 at 02:59:00AM +0100, Simon Richter wrote: >> for a project of mine I need support for java .class files, and as I'd >> like to do this the right way I've thought I might as well try to hack >> automake's Java support. Eric> Cool! Seconded! (Although I can't make any technical comments regarding Java as eric did.) Simon, please, start here: http://sources.redhat.com/automake/contribute.html -- Alexandre Duret-Lutz
Re: Archives and/or Java
>>> "Simon" == Simon Richter <[EMAIL PROTECTED]> writes:
[...]
Simon> Hrm, what if an archive would be treated like a directory, i.e.
Simon> foo_jar_DATA = foo.properties
Sounds like a nice idea.
Simon> ... Hrm, that would go in the direction of generic archive target
Simon> support, and one would have to think about files in subdirectories of
Simon> archives as well ("propertiesdir = $(foo_jardir)/properties"? Ick.).
Ouch.
Simon> Any ideas how we could implement this cleanly? Actually, though it looks
Simon> icky, the idea of making archives "special" directories has its
Simon> advantages. I could think of
Simon> data_TGZS = images.tgz
Simon> images_tgz_DATA = penguin.png windows.bmp
Simon> or even
Simon> data_ARCHIVES = images.archive
[...]
Maybe we don't need several primaries (_TGZS, _JAR, _ZIP, ...).
How about
data_ARCHIVES = foo.tar.gz bar.zip baz.jar
Automake can match suffixes like it does in _SOURCES to
select a compiler.
BTW, an item on the TODO list is to merge _LIBRARIES and _LTLIBRARIES.
We can decide wether the user want to build a libtool library
or a plain static library by looking at the suffix.
Your $(propertiesdir) example apart, _ARCHIVES and _LIBRARIES do
not look very different, do they?
Simon> To do for archives: Files installed in archives need to
Simon> be installed at build time,
I guess this is required to support things like $(propertiesdir).
Is this still true if subdirectories are not used? (Like when
we build _LIBRARIES.)
Simon> but I don't think that's a major issue
Neither do I. AFAICT the major hindrance is the Automake guts.
(Hopefully that's an occasion to do some cleaning.)
[...skipping Java issues I can't comment on...]
--
Alexandre Duret-Lutz
FYI: Fix for _AC_AM_CONFIG_HEADER_HOOK (CONFIG_HEADER stamp filecreation) bug
>>> "Sander" == Sander Niemeijer <[EMAIL PROTECTED]> writes:
Sander> This replacement for the _AC_AM_CONFIG_HEADER_HOOK macro (located in
Sander> m4/init.m4) fixes an incorrect naming issue of stamp-h* files when
Sander> only specific headers are recreated through config.status.
Thanks a lot! I'm installing the following on HEAD and branch-1-7.
This also handles header.h:top.in:middle.in:bottom.in style arguments.
[...]
Sander> P.S. A better replacement would be to have the
Sander> $config_headers list passed along as variable to the
Sander> _AC_AM_HEADER_HOOK macro.
We can discuss this later when the Autoconf maintainer is back.
[...]
2003-02-04 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* m4/init.m4 (_AC_AM_CONFIG_HEADER_HOOK): Recompute
indexes of header files so we create stamp files with
the right numbers when config.status is run on some headers.
* tests/stamph2.test: Check for this.
Reported by Sander Niemeijer.
Index: THANKS
===
RCS file: /cvs/automake/automake/THANKS,v
retrieving revision 1.186.2.17
diff -u -r1.186.2.17 THANKS
--- THANKS 2 Feb 2003 10:45:41 - 1.186.2.17
+++ THANKS 4 Feb 2003 19:54:32 -
@@ -184,6 +184,7 @@
Rusty Ballinger[EMAIL PROTECTED]
Ryan T. Sammartino [EMAIL PROTECTED]
Sam Hocevar[EMAIL PROTECTED]
+Sander Niemeijer [EMAIL PROTECTED]
Sergey Vlasov [EMAIL PROTECTED]
Seth Alves [EMAIL PROTECTED]
Shuhei Amakawa [EMAIL PROTECTED]
Index: m4/init.m4
===
RCS file: /cvs/automake/automake/m4/init.m4,v
retrieving revision 1.50.2.2
diff -u -r1.50.2.2 init.m4
--- m4/init.m4 13 Jan 2003 14:06:04 - 1.50.2.2
+++ m4/init.m4 4 Feb 2003 19:54:32 -
@@ -118,5 +118,14 @@
# loop where config.status creates the headers, so we can generate
# our stamp files there.
AC_DEFUN([_AC_AM_CONFIG_HEADER_HOOK],
-[_am_stamp_count=`expr ${_am_stamp_count-0} + 1`
+[# Compute $1's index in $config_headers.
+_am_stamp_count=1
+for _am_header in $config_headers :; do
+ case $_am_header in
+$1 | $1:* )
+ break ;;
+* )
+ _am_stamp_count=`expr $_am_stamp_count + 1` ;;
+ esac
+done
echo "timestamp for $1" >`AS_DIRNAME([$1])`/stamp-h[]$_am_stamp_count])
Index: tests/stamph2.test
===
RCS file: /cvs/automake/automake/tests/stamph2.test,v
retrieving revision 1.7
diff -u -r1.7 stamph2.test
--- tests/stamph2.test 8 Sep 2002 13:07:56 - 1.7
+++ tests/stamph2.test 4 Feb 2003 19:54:32 -
@@ -1,5 +1,5 @@
#! /bin/sh
-# Copyright (C) 2001, 2002 Free Software Foundation, Inc.
+# Copyright (C) 2001, 2002, 2003 Free Software Foundation, Inc.
#
# This file is part of GNU Automake.
#
@@ -21,6 +21,8 @@
# Make sure stamp-h* files are created where we expect
. ./defs || exit 1
+set -e
+
cat >> configure.in << END
AM_CONFIG_HEADER(1.h
2.h:config.hin
@@ -42,17 +44,32 @@
: > sdir1/config1.hin
: > sdir2/config2.hin
-$ACLOCAL || exit 1
-$AUTOCONF || exit 1
-$AUTOMAKE || exit 1
-./configure || exit 1
-
-test -f stamp-h1 || exit 1
-test -f stamp-h2 || exit 1
-test -f stamp-h3 || exit 1
-test -f sdir1/stamp-h4 || exit 1
-test -f sdir1/stamp-h5 || exit 1
-test -f sdir1/stamp-h6 || exit 1
-test -f sdir1/stamp-h7 || exit 1
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE
+./configure
+
+test -f stamp-h1
+test -f stamp-h2
+test -f stamp-h3
+test -f sdir1/stamp-h4
+test -f sdir1/stamp-h5
+test -f sdir1/stamp-h6
+test -f sdir1/stamp-h7
+
+# Make sure `./config.status foo' creates the right stamp file.
+# Report from Sander Niemeijer.
+
+rm -f stamp-h*
+rm -f sdir1/stamp-h*
+
+./config.status sdir1/7.h 2.h sdir1/4.h
+test ! -f stamp-h1
+test -f stamp-h2
+test ! -f stamp-h3
+test -f sdir1/stamp-h4
+test ! -f sdir1/stamp-h5
+test ! -f sdir1/stamp-h6
+test -f sdir1/stamp-h7
exit 0
--
Alexandre Duret-Lutz
Re: Flex c++ bug
>>> "Aidan" == Aidan Delaney <[EMAIL PROTECTED]> writes: Aidan> balor@navi traditional $ make Aidan> flex traditional.ll && mv lex.yy.c traditional.cc Automake indeed does not support C++ scanners (i.e., flex -+), but will compile a C scanner as C++ source when asked so. [...] Aidan> AFAIK it should run the @BISON@ -d first [...] Automake 1.7.3 will have the following paragraphs in its manual. |When `yacc' is invoked, it is passed `YFLAGS' and `AM_YFLAGS'. The | former is a user variable and the latter is intended for the | `Makefile.am' author. | |`AM_YFLAGS' is usually used to pass the `-d' option to `yacc'. | Automake knows what this means and will automatically adjust its rules | to update and distribute the header file built by `yacc -d'. What | Automake cannot guess, though, is where this header will be used: it is | up to you to ensure the header gets built before it is first used. | Typically this is necessary in order for dependency tracking to work | when the header is included by another file. The common solution is | listing the header file in `BUILT_SOURCES' (*note Sources::) as follows. | | BUILT_SOURCES = parser.h | AM_YFLAGS = -d | bin_PROGRAMS = foo | foo_SOURCES = ... parser.y ... -- Alexandre Duret-Lutz
Re: Java class files, again
>>> "Simon" == Simon Richter <[EMAIL PROTECTED]> writes: Simon> This document says that the CVS tree is on sources.redhat.com, is that Simon> still the case (I got my working tree from subversions)? subversions mirrors sources.redhat.com. I don't know how often. -- Alexandre Duret-Lutz
RFC: FAQ chapter for the manual (LONG)
I people, Here is new chapter I would like to append to the Automake manual. As English is obviously not my mother tongue, and because I know some people have strong opinions about some of the issues discussed, I'd appreciate any comments. I've tried to stay neutral, but I'm pretty sure some people will think I'm unfair in some places. Let me know. Cheerio, Alexandre Duret-Lutz --- snip --- snip --- snip --- Frequently Asked Questions about Automake * This chapters covers some questions that often come up on the mailing lists. * Menu: * CVS:: CVS and generated files * maintainer-mode:: missing and AM_MAINTAINER_MODE * wildcards:: Why doesn't Automake support wildcards? * distcleancheck:: Files left in build directory after distclean File: automake.info, Node: CVS, Next: maintainer-mode, Prev: FAQ, Up: FAQ CVS and generated files === Background: distributed generated files --- Packages made with Autoconf and Automake ship with some generated files like `configure' or `Makefile.in'. These files were generated on the developer's host and are distributed so that end-users do not have to install the maintainer tools required to rebuild them. Other generated files like Lex scanners, Yacc parsers, or Info documentation, are usually distributed on similar grounds. Automake output rules in `Makefile's to rebuild these files. For instance `make' will run `autoconf' to rebuild `configure' whenever `configure.in' is changed. This makes development safer by ensuring a `configure' is never out-of-date with respect to `configure.in'. As generated files shipped in packages are up-to-date, and because `tar' preserves timestamps, these rebuild rules are not triggered when a user unpacks and builds a package. Background: CVS and timestamps -- CVS does not preserve timestamps. The modification time of a CVS-controlled file is its checkout date. Because CVS processes files in alphabetical order, `configure.in' will appear older than `configure' after a fresh checkout, even if `configure' was up-to-date when it was checked in. In other words, `make' relies on timestamps, CVS messes up timestamps, so these two tools do not work well together. Living with CVS in Autoconfiscated projects --- There are basically two clans amongst maintainers: those who keep all distributed files under CVS, including generated files, and those who keep generated files _out_ of CVS. All files in CVS * The CVS repository contains all distributed files so you know exactly what is distributed, and you can checkout any prior version entirely (except for timestamps). * Maintainers can see how generated files evolve (for instance you can see what happens to your `Makefile.in's when you upgrade Automake and make sure they look OK). * Users do not need the autotools to build a checkout of the project, it works almost like a released tarball. Timestamps are inaccurate, hence some rebuild rules will be triggered and attempt to run developer tools such as `autoconf' or `automake'. Actually, calls to such tools are all wrapped into a call to the `missing' script discussed later (*note maintainer-mode::). `missing' will take care of fixing the timestamps when these tools are not installed, so that the build can continue. * In distributed development, developers are likely to have different version of the maintainer tools installed. In this case rebuilds triggered by timestamp lossage will lead to spurious changes to generated files. There are several solutions to this: * All developers should use the same versions, so that the rebuilt files are identical to files in CVS. (This starts to be difficult when each project you work on uses different versions.) * Or people use a script to fix the timestamp after a checkout (the GCC folks have such a script). * Or `configure.in' uses `AM_MAINTAINER_MODE', which will disable all these rebuild rules by default. This is further discussed in *Note maintainer-mode::. * Although we focused on spurious rebuilds, the converse can also happen. CVS's timestamp handling can also let you think an out-of-date file is up-to-date. For instance, suppose a developer has modified `Makefile.am' and rebuilt `Makefile.in', and then decide to do a last-minute change to `Makefile.am' right before checking in both files (without rebuilding `Makefile.in' to account for th
Re: RFC: FAQ chapter for the manual (LONG)
>>> "Ronald" == Ronald Landheer-Cieslak <[EMAIL PROTECTED]> writes: [...] Ronald> I beg to differ: use the -d option with import keeps Ronald> the modification time, and The "commit" command retains Ronald> the timestamp of the file, if the act of checking it in Ronald> didn't change it (by expanding keywords). My impression was that CVS could preserve timestamp on checkin, but not on checkout. Looks like I was wrong. I just tried to make a fresh checkout of Automake, and timestamps are correct. However `cvs update' seems to always use the checkout time, loosing original timestamps. So although my description of this issue is admittedly wrong, there is still a problem. Do you know how to tell `cvs update' to preserve timestamps? Ronald> AFAICT, neither autoconf nor automake nor libtool adds Ronald> any CVS keyswords (like $Id$, for example) - but Ronald> correct me if I'm wrong :) They don't, but Autoconf and Automake will propagate keywords from input. [...] >> * The CVS repository contains all distributed files so you know >> exactly what is distributed, and you can checkout any prior >> version entirely (except for timestamps). Ronald> ^ Ronald> not true. Agreed. Ronald> [snip] >> * Although we focused on spurious rebuilds, the converse can also >> happen. CVS's timestamp handling can also let you think an >> out-of-date file is up-to-date. >> >> For instance, suppose a developer has modified `Makefile.am' and >> rebuilt `Makefile.in', and then decide to do a last-minute change >> to `Makefile.am' right before checking in both files (without >> rebuilding `Makefile.in' to account for the change). Ronald> .. and while having a CVS tag in the Makefile.am file Ronald> (which is quite common) Even without tag. We are talking about `cvs update' below. >> This last change to `Makefile.am' make the copy of `Makefile.in' >> out-of-date. Since CVS processes files alphabetically, when >> another developer update his or her tree, `Makefile.in' will >> happen to be newer than `Makefile.am'. This other developer will >> not see `Makefile.in' is out-of-date. [...] Ronald> AFAIK the problem with generated files in CVS is not a Ronald> problem of time stamps (file modification times) but Ronald> rather of CVS keyword expansion. We probably have two problems. I've never used CVS keywords (and I'm accustomed to type `cvs add -ko ...'), but I've always been beaten by this timestamp lossage. Thanks to you, I'm relieved to learn it doesn't happen with `cvs checkout'. Ronald> In any case, CVS is a versioning tool, not a Ronald> distribution tool. For me, that means that it makes Ronald> sense not to have generated files in the CVS Ronald> repository. I'll try to make your point in the relevant section. Thanks for your comments. pip-pip -- Alexandre Duret-Lutz
Re: RFC: FAQ chapter for the manual (LONG)
Here is a rewrite of this CVS/timestamp section. I hope it's more accurate. Background: CVS and timestamps -- Unless you use CVS keywords (in which case files are rewritten before commit), CVS preserves timestamp during `cvs commit' and `cvs import -d' operations. When you check out a file using `cvs checkout' its timestamp is set to that of the revision which is being checked out. However, during `cvs update', files will have the date of the update, not the original timestamp of this revision. This is meant to make sure that `make' notices sources files have been updated. This timestamp shift is troublesome when both sources and generated files are kept under CVS. Because CVS processes files in alphabetical order, `configure.in' will appear older than `configure' after a `cvs update' that updates both files, even if `configure' was newer than `configure.in' when it was checked in. Calling `make' will then trigger a spurious rebuild of `configure'. Living with CVS in Autoconfiscated projects --- There are basically two clans amongst maintainers: those who keep all distributed files under CVS, including generated files, and those who keep generated files _out_ of CVS. All files in CVS * The CVS repository contains all distributed files so you know exactly what is distributed, and you can checkout any prior version entirely. * Maintainers can see how generated files evolve (for instance you can see what happens to your `Makefile.in's when you upgrade Automake and make sure they look OK). * Users do not need the autotools to build a checkout of the project, it works just like a released tarball. * If users use `cvs update' to update their copy, instead of `cvs checkout' to fetch a fresh one, timestamps will be inaccurate. Some rebuild rules will be triggered and attempt to run developer tools such as `autoconf' or `automake'. Actually, calls to such tools are all wrapped into a call to the `missing' script discussed later (*note maintainer-mode::). `missing' will take care of fixing the timestamps when these tools are not installed, so that the build can continue. * In distributed development, developers are likely to have different version of the maintainer tools installed. In this case rebuilds triggered by timestamp lossage will lead to spurious changes to generated files. There are several solutions to this: * All developers should use the same versions, so that the rebuilt files are identical to files in CVS. (This starts to be difficult when each project you work on uses different versions.) * Or people use a script to fix the timestamp after a checkout (the GCC folks have such a script). * Or `configure.in' uses `AM_MAINTAINER_MODE', which will disable all these rebuild rules by default. This is further discussed in *Note maintainer-mode::. * Although we focused on spurious rebuilds, the converse can also happen. CVS's timestamp handling can also let you think an out-of-date file is up-to-date. For instance, suppose a developer has modified `Makefile.am' and rebuilt `Makefile.in', and then decide to do a last-minute change to `Makefile.am' right before checking in both files (without rebuilding `Makefile.in' to account for the change). This last change to `Makefile.am' make the copy of `Makefile.in' out-of-date. Since CVS processes files alphabetically, when another developer `cvs update' his or her tree, `Makefile.in' will happen to be newer than `Makefile.am'. This other developer will not see `Makefile.in' is out-of-date. Generated files out of CVS .. One way to get CVS and `make' working peacefully is to never store generated files in CVS, i.e., do not CVS-control files which are `Makefile' targets (or _derived_ files in Make terminology). This way developers are not annoyed by changes to generated files. It does not matter if they all have different versions (assuming they are compatible, of course). And finally, timestamps are not lost, changes to sources files can't be missed as in the `Makefile.am'/`Makefile.in' example discussed earlier. The drawback is that the CVS repository is not an exact copy of what is distributed and that users now need to install various development tools (maybe even specific versions) before they can build a checkout. But, after all, CVS's job is versioning, not distribution. Allowing developers to use different versions of their tools can also hide bugs during distributed development. Indeed, developers will be using (hence testing) their own generated files, instead of the generated files that will be released actually. The developer who prepares th
Re: Comment on: FAQ chapter for the manual
Hi Bruce! >>> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes: [...] Bruce> You left out an argument in favor: the add-on files are self Bruce> contained. I, in fact, intentionally make it very simple to Bruce> add expression files to AutoGen. :-) You add a file named Bruce> ``exprMumble.c'' to the agen5 directory and it is automatically Bruce> incorporated into autogen, but for the fact you also have to Bruce> edit Makefile.am to add it to the list. If they don't want to Bruce> distribute it, then omit it. It gets dropped automatically, Bruce> but for the fact it is now listed in Makefile.am. :-) Point taken. Bruce> There ought to be a way to say, "I understand all your Bruce> philosophical objections, but I don't care. Glob this expression Bruce> and insert the result into Makefile.in and please don't tell me you Bruce> know how to do my business better than me." I think we agree. The last sentence in this section was meant to imply such a patch would be considered, would someone mind enough to work it out. Bruce> We have philosophical differences. Fortunately this allows us to talk more often. [...] >> Suppose our package contains a program for >> which we want to build a man page using `help2man'. [...] Bruce> This example is too simplistic. There are a number of packages Bruce> that derive documentation from the sources. That's seems simplier to me: you can distribute the sources and the derived documentation without spurious rebuilds. I'm speaking of a simple one-step .c -> .html case here. If you meant .c -> .texi -> .info, you need to distribute the files at each step if you decide to distribute the latter. This is really what I wanted to imply with "If you distribute something generated, distribute its sources." Maybe I should elaborate on this. Or would it be clearer to just replace `sources' by `dependencies'? There are ugly stamp-file tricks to play if one doesn't want to ship intermediate files, but I'm not volunteering to document such an hairy topic. Not these days, at least. Bruce> Mine is "special" in that I distribute the piece that Bruce> does the extraction, but anyone deriving a .texi file Bruce> from javadoc comments will have essentially the same Bruce> difficulty. Honestly, I've used getdefs/autogen to build Texinfo documentation in three projects so far and never hit any difficulty. I don't think this is different from your javadoc example. I just ship the .info files so that users to not need Texinfo. And I ship the .texi files so that users do not need getdefs/autogen. I understand you can decide that my last sentence does not apply in your case, since your package builds getdefs and autogen. I think this precisely makes your project different from others. Bruce> Do you distribute trivially extracted text or not? I Bruce> say, "not" and if not you have this dilemma. Various Bruce> pieces of documentation will depend upon the extracted Bruce> .texi file, even if you distribute these docs. The Bruce> result is your clients will always have their builds Bruce> attempting to rebuild distributed docs and the distcheck Bruce> will choke. After years of arguing this, I did finally Bruce> win my point and it ought to be in the FAQ. :-) I confess I don't understand this paragraph at all. Are you speaking about not distributing some intermediate files? Also what are the dilemma and the point? You said your clients always rebuild distributed docs. Either you think this is ok and there is no point in distributing these docs, either you think this rebuilding is not ok and your dependencies need work. In all cases it seems distcheck is right in complaining. I don't yet see how this could be otherwise so I'm certainly missing your point. Bruce> BTW, the problem gets much worse if the product distributes with Bruce> no .texi files because the texi rules know that if there are no Bruce> texi files, then there can be no texi documentation. This is Bruce> a mistake. I've been told that the texi rules come from the texi Bruce> folks, so it's not Automake's job to fix it. It's still a problem. Fixing the rules for building .info files is cleary Automake's job. Could you fill a PR with an example of what you are trying to achieve? (I'm not sure I understand what you want.) -- Alexandre Duret-Lutz
Re: Comment on: FAQ chapter for the manual
>>> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes:
[...]
Bruce> There's now a relatively simple process by which one can
Bruce> delete reconstructed, but also distributed files. I do
Bruce> think it would be worthwhile to make that visible so that
Bruce> those that do construct and distribute .texi files won't
Bruce> have to necessarily tear their hair out. Here's the magic:
Bruce> distcleancheck_listfiles = \
Bruce> find -type f -exec 'test -f $(srcdir)/{} || echo {} ;'
This is already documented. I'm fine with adding an explicit
reference to this. "For desperate cases", I'd say, as I think
there is always better to do.
Bruce> That will cause to be removed any file you both build and
Bruce> redistribute. Period.
To be less confusing, it's not "delete" nor "removed", but
"ignore" and "ignored". (If you were meaning "removed from the
diagnostic" then we agree.)
[...]
>> I just ship the .info files so that users to not need
>> Texinfo. And I ship the .texi files so that users do not need
>> getdefs/autogen.
Bruce> and if you have the .texi derivation rule as well,
Of course I do. They rules need to be here in case the user
changes something in the .texi dependencies. This is a
requirement to achieve what François Pinard would call a
dependable build.
Bruce> then you need to either 1) be careful that "make
Bruce> distcheck" doesn't construct the distributed file,
I don't. It simply doesn't happen. There is no reason why it
should happen, expect if I, by error, had made these files
dependent on non-distributed built files like in the exemple I
present in the FAQ (or like you do in AutoGen), or if I forgot
to distribute a dependency. These are two errors I could fix
easily, so I have no reason to hide them with
bla^H^H^Hdistcleancheck_listfiles magic.
I believe you have such dependencies in AutoGen: .texi files
that explicitely depends on binaries such as autogen or getdefs,
and are therefore always rebuilt.
I believe that these dependencies unnecessarily trigger your
whole documentation pipe at make time, and that you then have to
play (too) many tricks in order not to suffer the consequences.
Have you tried getting rid of theses as in the help2man example?
foo.texi: built-build-tools sources
build-command
becomes
foo.texi: sources
$(MAKE) built-build-tools
build-command
I believe fixing the dependencies at the root should allow to
distribute .c files, generated .texi files, and generated .info
files, without sourious rebuilds of the documentation. With
clean rules and no pain.
Maybe I believe too much :). Anyway, this is assuming you also
ship all dependencies (including @included .texi files, to be
clearer -- two mails ago I was under the impression you didn't
want to distribute them, as they were "trivially extracted", but
now you say you do distribute .texi files, so I'm confused).
[...]
Bruce> It's ok to rebuild the .texi, not ok to choke because
Bruce> they dont have texinfo or texi2html or whatever to go on.
Bruce> In other words, I distribute the .texi and the .info and
Bruce> I distribute the means for getting from .c to .texi.
I still would like to understand why you distribute generated
(.texi) files when it's ok to rebuild them.
I think there is no reason to rebuild a file which is
distributed. That's what distcheckclean checks. So I'd really
want to understand why you think differently (appart from giving
us occasions to talk, that is :)). So far I've failed to get
your point.
BTW, autogen.info is not rebuilt the first time I run `make' in
Autogen (5.4.8), but it gets rebuilt if I run `make' a second
time. Looks weird. Is this intended? I'm sorry I don't
understand why this happens.
Ciao,
--
Alexandre Duret-Lutz
Re: Automatic dependency tracker vanished - why?
>>> "Markus" == Markus Werle <[EMAIL PROTECTED]> writes: [...] Markus> that the files in .deps only contain the line Markus> # dummy Markus> Why? You have run ./configure, but haven't run make yet. Dependencies are updated as a side-effect of the compilation. Markus> What went wrong? Nothing as far as I can tell. Please send more details if dependencies really aren't updated during build (don't forget to say which version of Automake you are and were using, especially if something "vanished"). [...] -- Alexandre Duret-Lutz
Re: CVS, bootstrapping and DJGPP
>>> "Richard" == Richard Dawe <[EMAIL PROTECTED]> writes:
[...]
Richard> I found the problem. It was due to $SHELL (in the
Richard> environment) not being set to bash.
Is this something we should set in Automake?
For instance
$ENV{'SHELL'} = '@SHELL@'
where @SHELL@ is the shell computed by ./configure
Or is this something DJGPP users should stick in their
environment?
The issue doesn't seem limited to automake. For instance
autoupdate will calls autoconf using arguments like
"--trace define:'AC:\$f:\$1'".
[...]
--
Alexandre Duret-Lutz
Re: CVS, bootstrapping and DJGPP
>>> "Richard" == Richard Dawe <[EMAIL PROTECTED]> writes:
[...]
Richard> I found the problem. It was due to $SHELL (in the
Richard> environment) not being set to bash.
>>
>> Is this something we should set in Automake?
>>
>> For instance
>> $ENV{'SHELL'} = '@SHELL@'
>> where @SHELL@ is the shell computed by ./configure
Richard> Yes, but I don't know whether you should do this for
Richard> all platforms or just DJGPP (by checking for
Richard> defined($ENV{'DJGPP'}) before defining $ENV{'SHELL'}
Richard> to be @SHELL@).
Thanks. I'm installing the following change on HEAD and branch-1-7.
2003-02-10 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* automake.in (BEGIN): Override $ENV{'SHELL'} with ./configure's
SHELL for DJGPP.
Suggested by Richard Dawe.
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.1365.2.30
diff -u -r1.1365.2.30 automake.in
--- automake.in 6 Feb 2003 16:52:51 - 1.1365.2.30
+++ automake.in 10 Feb 2003 14:02:35 -
@@ -33,6 +33,15 @@
{
my $perllibdir = $ENV{'perllibdir'} || '@datadir@/@PACKAGE@-@APIVERSION@';
unshift @INC, $perllibdir;
+
+ # Override SHELL. This is required on DJGPP so that system() uses
+ # bash, not COMMAND.COM which doesn't quote arguments properly.
+ # Other systems aren't expected to use $SHELL when Automake
+ # runs, but it should be safe to drop the `if DJGPP' gard if
+ # it turns up other systems need the same thing. After all,
+ # if SHELL is used, ./configure's SHELL is always better than
+ # the user's SHELL (which may be something like tcsh).
+ $ENV{'SHELL'} = '@SHELL@' if exists $ENV{'DJGPP'};
}
use Automake::Struct;
--
Alexandre Duret-Lutz
ANN: new mailing list: autotools-announce@gnu.org
[Please repost and forward wherever it is appropriate.] We have setup a new mailing list, [EMAIL PROTECTED], that will carry announcements for releases *and* beta-releases of Autoconf, Automake, Gettext, and Libtool. This is intended to be a read-only and low-traffic list, for people that cannot afford reading each tool's list, but still would like to hear about new releases, or are willing to test pre-releases. If you know such people, please tell them. You can subscribe here: http://mail.gnu.org/mailman/listinfo/autotools-announce Cheers, -- Alexandre Duret-Lutz
Re: _TEXINFOS question
>>> "Patrick" == Patrick Guio <[EMAIL PROTECTED]> writes: Patrick> Dear all, Patrick> I am using the _TEXINFOS variables in a Makefile.am to build the Patrick> documentation. I would like these to be built on request with a `doc' Patrick> target for example and not with the default 'all' or 'all-am'. Patrick> Is there a way to do that? No friendly way. -- Alexandre Duret-Lutz
Automake 1.7.2b uploaded (beta for 1.7.3)
Hi people! Here is a snapshot of the 1.7.x branch of Automake. ftp://alpha.gnu.org/gnu/automake/automake-1.7.2b.tar.gz ftp://alpha.gnu.org/gnu/automake/automake-1.7.2b.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.7.2b.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.7.2b.tar.bz2 This should be reasonably close to what 1.7.3 will be. Please test it and report any problem you have to <[EMAIL PROTECTED]>. I hope we can release 1.7.3 by the middle of next week. There is a known bug with VPATH handling of Texinfo and Lex rules which isn't fixed here. This affects all 1.7.x versions for Texinfo rules. I think older versions will also fails on Lex rules but I haven't verified. This is triggered during VPATH builds with (at least) Tru64 make, FreeBSD (current) make, and OpenBSD (3.2) make. In short, these make implementations will *not* perform a VPATH search for dependencies which appear as targets in Makefiles. As far as BSD make is concerned this seems to be a recent change in its behavior, as I believe it worked fine in the past. Fixing this requires too much changes for the 1.7.x branch. The following failures in the test suite can denote this bug: lex3.test, txinfo3.test, txinfo13.test, txinfo16.test, txinfo18.test Please report these failures anyway, with your system's version, so we know more precisely where this happens. Here is a list of changes since 1.7.1. Those that worry me the more are the changes to elisp compilation, and the changes to depcomp. If you can test these, by all means please do! Bugs fixed in 1.7.2b: * Fix stamp files numbering (when using multiple AC_CONFIG_HEADERS). * Query distutils for `pythondir' and `pythonexecdir', instead of using an hardcoded path. This should allow builds on 64-bit distributions that usually use lib64/ instead of lib/. * AM_PATH_PYTHON will also search for python2.3. * elisp files are now built all at once instead of one by one. Besides incurring a speed-up, this is required to support interdependent elisp files. * Support for DJGPP: - `make distcheck' will now work in `_inst/' and `_build' instead of `=inst/' and `=build/' - use `_dirstamp' when the file-system doesn't support `.dirstamp' - more changes that affect only the Automake package (not its output) * Fix some incompatibilities with upcoming perl-5.10. * Properly quote AC_PACKAGE_TARNAME and AC_PACKAGE_VERSION when defining PACKAGE and VERSION. * depcomp fixes: - dashmstdout and dashXmstdout modes: don't use `-o /dev/null', this is troublesome with gcc and Solaris compilers. (PR/385) - makedepend mode: work with Libtool. (PR/385 too) - support for ICC. * better support for unusual gettext setups, such as multiple po/ directories (PR/381): - Flag missing po/ and intl/ directories as warnings, not errors. - Disable these warnings if po/ does not exist. * Noteworthy manual updates: - New FAQ chapter. - Document how AC_CONFIG_AUX_DIR interacts with missing files. (Debian Bug #39542) - Document `AM_YFLAGS = -d'. (PR/382) -- Alexandre Duret-Lutz
Re: Automake 1.7.2b uploaded (beta for 1.7.3)
>>> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes:
Robert> Hello,
Robert> I have a problem with the beta, after bootstrapping a
Robert> fresh checkout of Libtool with Autoconf 2.57 and Automake
Robert> 1.7.2b, I get a make distcheck error. Apparently the
Robert> distcheck fails because files are left over in the
Robert> insallation directory after "make uninstall" is run.
I was luckier: CVS Libtool distchecks succesfully here.
I'm using Debian unstable, with Autoconf 2.57, Automake 1.7.2b,
Libtool 1.4e, Texinfo 4.3a, Make 3.80, Bash 2.05b.0(1)-release.
My install-info is that from Texinfo, not from Debian.
(Maybe Debian's install-info creates the ${infodir}/dir file?)
Robert> Below are the offending files
Robert> ${infodir}/dir
Robert> ${prefix}/share/libtool:
Robert> install-sh missing mkinstalldirs
Any idea when these files get installed?
Are they installed by `make install'? (i.e., outside distcheck')
--
Alexandre Duret-Lutz
Re: Multiple makefiles and rules for CONFIG_HEADER and CONFIG_FILEentries
>>> "Sander" == Sander Niemeijer <[EMAIL PROTECTED]> writes: [...] Sander> Now I recently discovered that automake places the Sander> rules to rebuild foo.h from foo.h.in (with the use of a Sander> stamp-h* file) in the Makefile of the directory where Sander> foo.h will appear if that directory has a Makefile and Sander> otherwise put it in the toplevel Makefile. But it won't Sander> put these rules in any of the other Makefiles. Of Sander> course this leaves me with a problem if I change Sander> foo.h.in and perform a make, since for targets in my Sander> subdirectories that depend on foo.h make won't try to Sander> rebuild foo.h and thus these targets won't be rebuild Sander> either. I've been bitten by this too. I added your email to the Cc: list for PR/355. Sander> I would like to know whether anybody knows a way to have the foo.h.in Sander> -> foo.h (with appropriate stamp-h* usage) dependencies included in Sander> all my makefiles that contain targets with dependencies on foo.h. No idea :( Except handwriting these rules, of course, but that means you must know how stamp files are numbered. Sander> I'm currently considering to let configure create a separate foo.h in Sander> each of the directories that need foo.h (through a Sander> AC_CONFIG_HEADERS([dir1/foo.h:inc/foo.h.in dir2/foo.h:inc/foo.h.in]), This looks safer. [...] -- Alexandre Duret-Lutz
Re: Automake 1.7.2b uploaded (beta for 1.7.3)
>>> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes: [...] Robert> these files are installed by "make install", Could you send the output of `make install', so we see exactly when these files are installed? Robert> which is run as a dependency of distcheck. Any ideas Robert> why this is happening? I began to look into this Robert> problem because another maintainer has not been able to Robert> run "make distcheck" since he abandoned a much older Robert> Automake. Which version worked last? [...] -- Alexandre Duret-Lutz
Re: Distcheck: cannot create regular file
>>> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes: Bruce> At the end of this log, you'll see lines like this: Bruce> cp: cannot create regular file \ Bruce> `blocksort-1.4.2/libopts/.deps/save.Plo': Permission denied Simply don't distribute these files. -- Alexandre Duret-Lutz
Re: Distcheck: cannot create regular file
>>> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes:
[...]
Bruce> Distributing files marked read-only or in read-only directories
Bruce> really ought not cause a distribution failure.
They really wouldn't cause distcheck failures if they weren't rebuilt.
(Does it ring a bell?)
[...]
Bruce> This is a really gnarly little twisty hassle, but I
Bruce> think I've simplified the issue as much as I know how.
I think we already discussed this, probably at the time the
"Conditional subdirectories" section was added to the manual.
I suggest you take a look at it, it's really much easier.
As long as LIBOPTS_DIRS is defined using a conditional, as you
do in libopts/MakeDefs.inc, then libopts/ will be distributed
correctly without any work from you.
The trouble, in blocksort, comes from the fact that LIBOPTS_DIR
is defined by an AC_SUBSTitution. A bogus AC_SUBST, by the
way, because LIBOPTS_DIR was set to either '' or 'true' (i.e.,
never to 'libopts' which is what we would expect in SUBDIRS)
blocksort-1.4.2 passes distcheck with the following patch.
--- blocksort-1.4.2/Makefile.am 2003-02-15 20:22:55.0 +0100
+++ blocksort-1.4.2/Makefile.am 2003-02-16 02:37:10.0 +0100
@@ -16,10 +16,11 @@
extra = $(TARG)-lsm.tpl $(TARG)-spec.tpl bsort-opt.def
specfiles = $(TARG).lsm $(TARG).spec
CFG_FILES = cfg/libopts.m4 cfg/bootstrap cfg/bootstrap.local
-EXTRA_DIST = $(specfiles) $(extra) $(TARG).1 $(CFG_FILES) libopts
+EXTRA_DIST = $(specfiles) $(extra) $(TARG).1 $(CFG_FILES)
man_MANS = blocksort.1
+include $(srcdir)/libopts/MakeDefs.inc
SUBDIRS= $(LIBOPTS_DIR)
blocksort_LDADD= $(LIBOPTS_LDADD)
blocksort_CFLAGS = $(LIBOPTS_CFLAGS)
--- blocksort-1.4.2/cfg/libopts.m4 2003-02-15 20:23:14.0 +0100
+++ blocksort-1.4.2/cfg/libopts.m4 2003-02-16 02:27:50.0 +0100
@@ -337,7 +337,6 @@
AM_CONDITIONAL([NEED_LIBOPTS], [test -n "${LIBOPTS_DIR}"])
AC_SUBST(LIBOPTS_LDADD)
AC_SUBST(LIBOPTS_CFLAGS)
- AC_SUBST(LIBOPTS_DIR)
AC_CONFIG_FILES([libopts/Makefile])
]) # end of AC_DEFUN of LIBOPTS_CHECK
--- blocksort-1.4.2/libopts/libopts.m4 2003-02-15 19:55:40.0 +0100
+++ blocksort-1.4.2/libopts/libopts.m4 2003-02-16 02:35:49.0 +0100
@@ -337,6 +337,5 @@
AM_CONDITIONAL([NEED_LIBOPTS], [test -n "${LIBOPTS_DIR}"])
AC_SUBST(LIBOPTS_LDADD)
AC_SUBST(LIBOPTS_CFLAGS)
- AC_SUBST(LIBOPTS_DIR)
AC_CONFIG_FILES([libopts/Makefile])
]) # end of AC_DEFUN of LIBOPTS_CHECK
--
Alexandre Duret-Lutz
Re: Automake 1.7.2b uploaded (beta for 1.7.3)
anged to AC_CONFIG_AUX_DIR([.]). I suppose some people will mind about the extra kilobytes, though. [*] To be fair, I guess it's harmless if you don't rerun automake in the libltdl directory embeded in a package. However I think it's quite common to do so, for instance `autoreconf' will work recursively. -- Alexandre Duret-Lutz
Re: yacc/lex dependency order
>>> "mcmahill" == mcmahill <[EMAIL PROTECTED]> writes: [...] mcmahill> The problem I'm having is that the lex source mcmahill> includes a header generated by yacc but the automake mcmahill> generated makefile doesn't capture that dependency. The 1.7.3 documentation has a paragraph about this, see http://sources.redhat.com/automake/automake.html#Yacc%20and%20Lex -- Alexandre Duret-Lutz
Re: tests under automake-1.7.2 fail (AFS @sys variable)
>>> "Martin" == Martin MOKREJ© <[EMAIL PROTECTED]> writes: [...] Martin> Unfortunately, I cannot find out where is the logfile of the test Martin> executions to inspect details. The documentation on this is very bad: Martin> http://www.gnu.org/manual/automake/html_mono/automake.html#SEC96 , so I 1.7.3 has a tests/README Martin> I found out I can run the test myself at least. There is nothing else to find out :) [...] Martin> + autoupdate Martin> Possible unintended interpolation of @sys in string at /software/@sys/usr/bin/autoupdate line 29. Martin> Can't locate Autom4te/General.pm in @INC (@INC contains: /software//usr/share/autoconf /software/@sys/usr/lib/perl5/5.8.0/alpha-dec_osf-thread-multi-ld /software/@sys/usr/lib/perl5/5.8.0 /software/@sys/usr/lib/perl5/site_perl/5.8.0/alpha-dec_osf-thread-multi-ld /software/@sys/usr/lib/perl5/site_perl/5.8.0 /software/@sys/usr/lib/perl5/site_perl .) at /software/@sys/usr/bin/autoupdate line 34. Martin> BEGIN failed--compilation aborted at /software/@sys/usr/bin/autoupdate line 34. autoupdate (= Autoconf) is failing here, so please report this to [EMAIL PROTECTED] -- Alexandre Duret-Lutz
Re: How to create static library with sources from multiple dirs?
>>> "Bob" == Bob Rossi <[EMAIL PROTECTED]> writes: [...] Bob> I would like to create 1 library even though the sources are spread out Bob> over 3 directories. I can only seem to come up with 2 undesirable solutions. Bob> 1. Put all the code in one directory and make 1 library. Bob> 2. Create 3 library's You haven't said which Automake version you were using. With recent versions (>= 1.5 I think), you can build programs or libraries from sources in subdirectories. AUTOMAKE_OPTIONS = subdir-objects # Optional, see the manual. noinst_LIBRARIES = liball.a liball_a_SOURCES = sub1/foo.c sub1/foo.h sub2/bar.c sub2/bar.h ... (It's good style to list headers files in _SOURCES instead of EXTRA_DIST, even if they aren't compiled.) -- Alexandre Duret-Lutz
Re: aclocal: adding user-home parts to aclocal(/automake) ?
Hi Guido! >>> "gd" == Guido Draheim <[EMAIL PROTECTED]> writes: [...] gd> there is no way that a path can be added - the aclocal 1.7 gd> does read $datadir/aclocal/dirlist but that one is a gd> sysadmin file as well, not a user-home related file. One workaround is to install aclocal in your account, among the many other packages you already have. This way you control your dirlist, and can even point to the system's aclocal directory. There is little interest in working on aclocal these days. First, the plan is to have aclocal replaced by an equivalant Autoconf feature. So the less features we put in aclocal, the easier the transition will be. Second, using aclocal to fetch macros outside the source tree is considered bad style (that's one reason for getting rid of aclocal). So I'd rather consider the inconvenience you mention as an invitation to use an m4/ directory in your project. [...] gd> It happens that there is no AUTOMAKE_OPTIONS environment gd> variable either to add default-options. Default options are better set in a Makefile. (I've got your point with -I, but I'm answering the general case here.) -- Alexandre Duret-Lutz
Re: Stupid problem: how to specify the directory for .h files?
>>> "JG" == Jean-Guillaume Paradis (LMC) <[EMAIL PROTECTED]> writes: [...] JG> dsiSecManager_SOURCES = file1.cpp $(PROJECT_ROOT_DIR)/include/file1.h BTW, Automake doesn't support variables as *part of* filenames. This break the dependency tracking code. So, I you ever want to do this, it should read dsiSecManager_SOURCES = file1.cpp ../../include/file1.h (Or whatever PROJECT_ROOT_DIR is.) -- Alexandre Duret-Lutz
Re: Building application on Mac OS X with automake
>>> "Paul" == Paul F Kunz <[EMAIL PROTECTED]> writes: Paul> I have an application based on Qt that I build with automake on Paul> Linux and other UNIX platforms. Now I'm attempting to build it on Paul> Mac OS X. After I upgrade to libtool 1.4.3, I can build the Paul> application, even with older version of autoconf and automake. Paul> However, the applicatons's main window doesn't become the active Paul> window and its menus don't show on the Mac Menu bar. I think it is Paul> because the applicaiton has be packaged in a certain way and producing Paul> just an execuatable is not sufficient. Looking at Qt's examples Paul> makefile shows that this seems to be true. Paul> My question is whether somebody has worked out what needs to be Paul> done using automake. I can probably do it myself, but if it has Paul> already been done so much the better. No idea. Have you asked the Qt people? Or did you finally worked it out? -- Alexandre Duret-Lutz
Re: Archives and/or Java
Sorry for the delay. >>> "Simon" == Simon Richter <[EMAIL PROTECTED]> writes: [...] Simon> The question is basically: Should jar files be treated Simon> as libraries, losing the ability to stuff application Simon> data into them, or should they be treated as Simon> to-be-implemented archives, which can contain anything. Simon> I'd vote for the latter choice, because it doesn't add Simon> to the complexity of _LIBRARIES (which will eventually Simon> be a good thing in light of the _LTLIBRARIES merge), Simon> gives us an important feature (additional members in the Simon> jar) without being an evil hack and also gives us the Simon> archive feature (which isn't too important standalone). Eiter ways, even both together, sound fine to me. The former seems a lot simpler to implement (*), but if you are volunteering to implement the second... (*) I'm assuming _LIBRARIES and _LTLIBRARIES have been merged first. This shouldn't be too hard to do, and actually I'd like to do it, but it's unclear whether I'll have enought time to commit to this before before mid-march. [...] -- Alexandre Duret-Lutz
Re: Archives and/or Java
>>> "Simon" == Simon Richter <[EMAIL PROTECTED]> writes: [...] >> (*) I'm assuming _LIBRARIES and _LTLIBRARIES have been merged >> first. Simon> ... since jars would be an exception then, since they Simon> are not built with libtool as all other libraries are. Sorry, the plan is *not* to always use Libtool! There will still be two kinds for libraries: `*.la' and `*.a'. The former should be built with libtool and the second without. The sole difference is that we decide what to do based on the suffix, rather than the _PRIMARY. This gives room for handling other suffixes. [...] -- Alexandre Duret-Lutz
Re: AM_PATH_PYTHON and Python C interface headers
>>> "Raphaël" == Raphaël Poss <[EMAIL PROTECTED]> writes: Raphaël> I suffer with Autoconf/Automake when Raphaël> looking for the correct include path to find Python C Raphaël> interface headers. Could something be done about this Raphaël> ? Hi Raph! See the end of http://article.gmane.org/gmane.comp.sysutils.automake.bugs/594 -- Alexandre Duret-Lutz
Automake 1.7.3 released
We're pleased to announce the release of Automake 1.7.3 This is a bug fix release. The list of bug fixes is appended. You can find the new release here: ftp://ftp.gnu.org/gnu/automake/automake-1.7.3.tar.bz2 ftp://ftp.gnu.org/gnu/automake/automake-1.7.3.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.7.3.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.7.3.tar.gz Soon it will also appear on the sources and GNU mirrors listed here: http://www.gnu.org/order/ftp.html http://sources.redhat.com/mirrors.html Here are the MD5 checksums: f088f86393ab21931513d91de95162a4 automake-1.7.3.tar.bz2 83145fcf00bb1105be1b0974e258b86c automake-1.7.3.tar.gz Please report bugs to <[EMAIL PROTECTED]>. - Akim, Alexandre, and Tom Bugs fixed in 1.7.3: * Fix stamp files numbering (when using multiple AC_CONFIG_HEADERS). * Query distutils for `pythondir' and `pythonexecdir', instead of using an hardcoded path. This should allow builds on 64-bit distributions that usually use lib64/ instead of lib/. * AM_PATH_PYTHON will also search for python2.3. * elisp files are now built all at once instead of one by one. Besides incurring a speed-up, this is required to support interdependent elisp files. * Support for DJGPP: - `make distcheck' will now work in `_inst/' and `_build' instead of `=inst/' and `=build/' - use `_dirstamp' when the file-system doesn't support `.dirstamp' - install/uninstall `*.i[0-9][0-9]'-style info files - more changes that affect only the Automake package (not its output) * Fix some incompatibilities with upcoming perl-5.10. * Properly quote AC_PACKAGE_TARNAME and AC_PACKAGE_VERSION when defining PACKAGE and VERSION. * depcomp fixes: - dashmstdout and dashXmstdout modes: don't use `-o /dev/null', this is troublesome with gcc and Solaris compilers. (PR/385) - makedepend mode: work with Libtool. (PR/385 too) - support for ICC. * better support for unusual gettext setups, such as multiple po/ directories (PR/381): - Flag missing po/ and intl/ directories as warnings, not errors. - Disable these warnings if po/ does not exist. * Noteworthy manual updates: - New FAQ chapter. - Document how AC_CONFIG_AUX_DIR interacts with missing files. (Debian Bug #39542) - Document `AM_YFLAGS = -d'. (PR/382)
Re: libtool integration question/issue
>>> "Pavel" == Pavel Hlavnicka <[EMAIL PROTECTED]> writes: Pavel> Hi all, Pavel> I have a small touble with libtool 1.4.2 and automake 1.6 on my RH 8.0 Pavel> box. Everything I use is installed from vanilla packages. Pavel> I noticed a couple of people complaining about ltmain.sh is not added Pavel> to required files (a warning is issued). Libtool files can be installed with libtoolize. Automake's --add-missing option will only add files that are shipped with Automake. autoreconf (from recent Autoconf versions) can call all of these tools for you. [...] Pavel> a) is it a result of non-perfect installation, e.g. should be here Pavel> some links from automake libdir to liboolt libdir? no, see above Pavel> b) what versions of config.guess and config.sub should be used? any, or the more recent if you really care (check ./config.guess -t). You can also fetch new versions from ftp://ftp.gnu.org/gnu/config/ Pavel> (particulary, is there something libtool specific in files delivered Pavel> with libtool?) no Pavel> c) shouldn't the handle_libtool procedure save the $libdir value and Pavel> store the libtool library path into it temporarily? Pavel> (yes, but where this value should come from... ?) nah, it's libtoolize's job -- Alexandre Duret-Lutz
Re: Newbie help regarding .so modules
Hi Michael, >>> "Michael" == Michael Reynolds <[EMAIL PROTECTED]> writes: Michael> I have 2 modules, each with their own _init and _fini functions. My Michael> Makefile.am file is as follows: [...] Michael> /services/services/src/modules/dns.c:40: multiple definition of `_init' Michael> /usr/lib/crti.o(.init+0x0): first defined here Michael> dns.lo: In function `_fini': Michael> /services/services/src/modules/dns.c(.text+0x88): multiple definition Michael> of `_fini' Michael> /usr/lib/crti.o(.fini+0x0): first defined here Michael> *** Error code 1 Michael> ** END ** Michael> What I need help with is compiling the so modules. This looks like a libtool question to me, so I just Googled for "libtool _init" and got this as the first answer: http://mail.gnu.org/archive/html/libtool/2001-02/msg00020.html Does it answer your question? Otherwise, I suggest you write to [EMAIL PROTECTED] -- Alexandre Duret-Lutz
Re: Corba IDL and automake
>>> "Thomas" == Thomas Richter <[EMAIL PROTECTED]> writes: [...] Thomas> 1) If I run "automake --foreign", I get the following warnings: Thomas> idl/Makefile.am:21: invalid variable `noinst_libidl_a_HEADERS' Thomas> idl/Makefile.am:8: invalid unused variable name: `IDL_SOURCES' Thomas> Why is "noinst_libidl_a_HEADERS" invalid? These are header files for Thomas> the idl static library that are not to be included in the distribution. Because foo_HEADERS means "please install these header in the $(foodir) directory during `make install'", and you haven't defined $(noinst_libidl_adir). These headers should be listed in libidl_a_SOURCES or nodist_libidla_a_SOURCES (whether you want to distribute them or not). Thomas> Why is IDL_SOURCES unused? It is very well used in all Thomas> the lines below. It's not used by Automake. Automake reserves *_SOURCES variables. IDL_SOURCES would be the sources for an undeclared IDL program, so Automake presumes you made a typo. Thomas> 2) I need to specify an explicit make rule how to form Thomas> an object from a .cpp file. If I don't, then the Thomas> automake generated makefile does not include any such Thomas> rule, and it won't compile any object code and would Thomas> rather fail to build the final library. Why is this so, Automake doesn't understand what you do because you are using many "GNUmakisms" such as "$(forall...)" or %-rules. By doing so you hide data, so Automake cannot help. Thomas> and what would be a more apropriate solution instead of Thomas> giving the rule manually (which is, as far as I Thomas> understand it, against the automake paradigm). I suggest you install Automake 1.7.3 (any version >= 1.7 will do), and run it with the -Wall option. This will flag various unportable constructs in your Makefile. If you fixes these (using `.idl.cpp:' instead of `%.cpp: %.idl', using `$(idlsources:.idl=.cpp)' instead of `$(forall...)'), then Automake should work better. At least it will see your sources, so it can output rules to build them. -- Alexandre Duret-Lutz
