Re: mostlyclean and texinfo outputs (was: Installing gnulib from git)
Hi Ralf,
Thanks for pursuing this.
For the {dvi,ps} formats this is (arguably) a bug in automake,
I agree; automake should remove {html,dvi,ps,pdf} only upon 'clean', but
not upon 'mostlyclean'. Only the latex by-products should be removed
upon 'mostlyclean'.
OK, this is issue #1.
$ make -n mostlyclean
rm -rf gettext.am gettext.ams gettext.aux gettext.cp gettext.cps gettext.ef
\
gettext.em gettext.ems gettext.ev gettext.fn gettext.kw \
gettext.ky gettext.kys gettext.log gettext.op gettext.ops \
gettext.pg gettext.pgs gettext.tmp gettext.toc gettext.tp \
gettext.tps gettext.vr gettext.vrs gettext.dvi gettext.pdf \
gettext.ps gettext.html
So, it removes the temporary files and also the {html,dvi,ps,pdf} formatted
documentation but keeps the info formatted documentation. Why does it treat
the various formats differently?
One part is easily explained: info is not removed with 'mostlyclean' nor
with 'clean', but only with 'maintainer-clean', because info files are
distributed.
Issue #2: If I decide to distribute PDF formatted documentation, how to I tell
automake to not remove these files during make clean or make mostlyclean?
Testcase: The doc/ directory in GNU hello. Neither a definition
EXTRA_DIST = hello.pdf
nor a dependency
install : install-pdf
did have the desired effect.
Likewise for {html,dvi,ps} formatted documentation.
Bruno
Re: automake (GNU automake) 1.10.2 failed test
Hello Rainer, * Rainer Tammer wrote on Fri, Apr 03, 2009 at 04:03:41PM CEST: the test automake 1.10.2 check10.t fails on AIX 5.3: Yep. After I have applied * tests/check10.test: When a rule fails, Solaris make will output the complete command that failed; in this case the test suite driver. Adjust the test to not bogusly match lines from the driver, rather than its output. [...] I get the same results. Yep. Maybe you have a quick idea why the test fails. Yes I do. There was another patch applied to this test that should fix the issue. For reference I paste it below. Please note there is a new Automake test release, 1.10b, available on alpha.gnu.org. It would be very helpful if you could download and try it, and report failures. Thanks! Cheers, Ralf commit f51165dd1a6ca52d64ba73697e9ba4a24715b0ec Testsuite fixes for ksh. * tests/check10.test: Add ':' as last command in subshell, for zero exit status of the subshell. * tests/parallel-am.test: Do not let failing 'unset' of nonexistent variable exit the test. * tests/parallel-am2.test: Likewise. * tests/parallel-am3.test: Likewise. diff --git a/tests/check10.test b/tests/check10.test index c817dcb..138331c 100755 --- a/tests/check10.test +++ b/tests/check10.test @@ -72,6 +72,7 @@ unset TESTS || : env TESTS=xpass xpass2 $MAKE -e check env TESTS='pass skip xfail' $MAKE -e check $MAKE check + : ) stdout cat stdout
Using GNU Make
Is there a standard way to make an autotoolised build system require GNU Make? I'm getting a bit fed up having to express everything in POSIX make when most systems now seem to have GNU Make, even where it's not installed as the default make. -- http://rrt.sc3d.org/ | fiction, n. fact without citations
Re: Using GNU Make
On Friday 03 April 2009 20:01:15 Reuben Thomas wrote: Is there a standard way to make an autotoolised build system require GNU Make? I'm getting a bit fed up having to express everything in POSIX make when most systems now seem to have GNU Make, even where it's not installed as the default make. you dont want warnings or you want automake to generate code specific to GNU make ? the former is `automake --warnings=no-portability`. -mike
problem to create a noinst_LTLIBRARIES shared libraray
Hi,
I currently writing a java JNI extension used only for local check and
this library should *not* be installed.
The problem is that I need a shared library for dlopen using java
file: TestMain.java
===
public abstract class TestMain extends MqS.Main {
static {
System.loadLibrary(javatestmsgque);
}
...
===
but automake/libtool only create a *static* library even if the _LDFLAGS
-module is used
file: Makefile.am
===
noinst_LTLIBRARIES = libjavatestmsgque.la
libjavatestmsgque_la_SOURCES = test_java.c TestMain.h
libjavatestmsgque_la_CFLAGS = -I$(top_srcdir)/src $(AM_CFLAGS)
libjavatestmsgque_la_LIBADD = ../src/libmsgque.la
libjavatestmsgque_la_LDFLAGS = -module
===
this are the static libraries created using the noinst_ prefix
buildsubdirectory: .libs
===
-rw-r--r-- libjavatestmsgque.a
lrwxrwxrwx libjavatestmsgque.la - ../libjavatestmsgque.la
-rw-r--r-- libjavatestmsgque_la-test_java.o
===
using the pkglib_ or the lib_ prefix I get the shared libraries
subdirectory: .libs
==
lrwxrwxrwx libjavatestmsgque.la - ../libjavatestmsgque.la
-rw-r--r-- 1libjavatestmsgque.lai
-rw-r--r-- 1libjavatestmsgque_la-test_java.o
lrwxrwxrwx libjavatestmsgque.so - libjavatestmsgque.so.0.0.0
lrwxrwxrwx libjavatestmsgque.so.0 - libjavatestmsgque.so.0.0.0
-rwxr-xr-x 1libjavatestmsgque.so.0.0.0
===
Question: what can I do to get a shared LTLIBRARIES using the noinst
prefix ?
every answer is welcome ...
Re: Finding library procedures in /usr/local/lib/
On Thursday 02 April 2009 5:56:52 pm Peter Johansson wrote: Hello Gerald, Gerald I. Evenden wrote: After trying so many options related to libraries I am exhausted. I have a simple program that needs to link with a shared library installed in /usr/local/lib. When using my own simple Makefile and simply adding -lproject -lm everything works fine (libproject is the shared library). LDADD = -lm -lproject in your `Makefile.am' should do it. Cheers, Peter Of the suggestions offered, this one worked in the following literal entry into src/Makefile.am: geodesic_LDADD = -lproject -lm Ordering may not make any difference but I am too tired of the problem to check. :-( Many thanks. PS: I always seem to have trouble with the *_CHECK_* and *_SEARCH_* of configure.ac. Again, many thanks. -- The whole religious complexion of the modern world is due to the absence from Jerusalem of a lunatic asylum. -- Havelock Ellis (1859-1939) British psychologist
Re: Finding library procedures in /usr/local/lib/
On 4/3/2009 8:49 AM, Gerald I. Evenden wrote: On Thursday 02 April 2009 5:56:52 pm Peter Johansson wrote: Hello Gerald, Gerald I. Evenden wrote: After trying so many options related to libraries I am exhausted. I have a simple program that needs to link with a shared library installed in /usr/local/lib. When using my own simple Makefile and simply adding -lproject -lm everything works fine (libproject is the shared library). LDADD = -lm -lproject in your `Makefile.am' should do it. Cheers, Peter Of the suggestions offered, this one worked in the following literal entry into src/Makefile.am: geodesic_LDADD = -lproject -lm No offense intended to Peter, but this solution works because it simply assumes the library exists on the end-user's system. On systems where it doesn't exist in the default library paths, the build will fail with a linker error. The entire purpose of Autoconf checks is to ensure that the environment is actually able to build the project. If this solution is acceptable to you, then why even bother with configure? Why not simply write a makefile to build your project? Regards, John
Re: problem to create a noinst_LTLIBRARIES shared libraray
Andreas, On 4/3/2009 3:26 AM, Andreas Otto wrote: I currently writing a java JNI extension used only for local check and this library should *not* be installed. ... Question: what can I do to get a shared LTLIBRARIES using the noinst prefix ? Use check_LTLIBRARIES instead of noinst_LTLIBRARIES. Check libraries and programs are not installed either. Regards, John
Re: Finding library procedures in /usr/local/lib/
On Thursday 2009-04-02 23:45, Gerald I. Evenden wrote: After trying so many options related to libraries I am exhausted. I have a simple program that needs to link with a shared library installed in /usr/local/lib. When using my own simple Makefile and simply adding -lproject -lm everything works fine (libproject is the shared library). But regardless of how many tests, etc., I do in the .ac and .am files I cannot get the final Makefile to link with project. Perhaps you need ./configure LDFLAGS=-L/usr/local/lib? I remember having to do that on MSYS and some BSDs (along with -I/usr/local/include in CFLAGS).
Re: Finding library procedures in /usr/local/lib/
On Friday 03 April 2009 12:17:14 pm John Calcote wrote: On 4/3/2009 8:49 AM, Gerald I. Evenden wrote: On Thursday 02 April 2009 5:56:52 pm Peter Johansson wrote: Hello Gerald, Gerald I. Evenden wrote: After trying so many options related to libraries I am exhausted. I have a simple program that needs to link with a shared library installed in /usr/local/lib. When using my own simple Makefile and simply adding -lproject -lm everything works fine (libproject is the shared library). LDADD = -lm -lproject in your `Makefile.am' should do it. Cheers, Peter Of the suggestions offered, this one worked in the following literal entry into src/Makefile.am: geodesic_LDADD = -lproject -lm No offense intended to Peter, but this solution works because it simply assumes the library exists on the end-user's system. On systems where it doesn't exist in the default library paths, the build will fail with a linker error. The entire purpose of Autoconf checks is to ensure that the environment is actually able to build the project. If this solution is acceptable to you, then why even bother with configure? Why not simply write a makefile to build your project? Regards, John I suspect you have a point but my experience has been very frustrating in trying to employ the autoconf options. I tried the AC_SEARCH_LIBS option suggested earlier but then the math library failed to be included and all the trig functions disappeared. I have tried other options in configure.ac as well but either -lm or -lproject contents disappear. Obviously, my inexperience quite probably contributes to those failures. I often take a fetal position, thumb sucking pose when trying to decypher some of the options. As to whether final linking fails or not, if the damn procedures in libproject are not there then the installation fails regardless---there is no alternative. -- The whole religious complexion of the modern world is due to the absence from Jerusalem of a lunatic asylum. -- Havelock Ellis (1859-1939) British psychologist
Re: Finding library procedures in /usr/local/lib/
On Friday 03 April 2009 12:17:14 pm John Calcote wrote: On 4/3/2009 8:49 AM, Gerald I. Evenden wrote: On Thursday 02 April 2009 5:56:52 pm Peter Johansson wrote: Hello Gerald, Gerald I. Evenden wrote: After trying so many options related to libraries I am exhausted. I have a simple program that needs to link with a shared library installed in /usr/local/lib. When using my own simple Makefile and simply adding -lproject -lm everything works fine (libproject is the shared library). LDADD = -lm -lproject in your `Makefile.am' should do it. Cheers, Peter Of the suggestions offered, this one worked in the following literal entry into src/Makefile.am: geodesic_LDADD = -lproject -lm No offense intended to Peter, but this solution works because it simply assumes the library exists on the end-user's system. On systems where it doesn't exist in the default library paths, the build will fail with a linker error. The entire purpose of Autoconf checks is to ensure that the environment is actually able to build the project. If this solution is acceptable to you, then why even bother with configure? Why not simply write a makefile to build your project? Regards, John One added note, that bothers me a little. If the system checks for an entry being present in a particular iibrary by compiling/linking a test program using the function *and* linking to the specified library, what if the library under test heavily references another library such as -lm?? IF -lm is not in the test run would the test not fail??? Thus the entry under test fails also. Just a thought. -- The whole religious complexion of the modern world is due to the absence from Jerusalem of a lunatic asylum. -- Havelock Ellis (1859-1939) British psychologist
Re: mostlyclean and texinfo outputs
[ let's drop bug-gnulib ]
Hello Bruno, Karl, all,
* Bruno Haible wrote on Fri, Apr 03, 2009 at 12:58:26PM CEST:
For the {dvi,ps} formats this is (arguably) a bug in automake,
I agree; automake should remove {html,dvi,ps,pdf} only upon 'clean', but
not upon 'mostlyclean'. Only the latex by-products should be removed
upon 'mostlyclean'.
OK, this is issue #1.
Yes.
Issue #2: If I decide to distribute PDF formatted documentation, how to I tell
automake to not remove these files during make clean or make mostlyclean?
Yes, this is an issue, too. Hmm, but if you distribute this, then it
should be built in the source tree, too.
Testcase: The doc/ directory in GNU hello. Neither a definition
EXTRA_DIST = hello.pdf
This could probably be a key. Although testing EXTRA_DIST could be
expensive (but that is a minor implementation issue).
nor a dependency
install : install-pdf
BTW, hat would better be
install-data-local: install-pdf
However, whether something is installed or not should not decide about
whether something is distributed or not.
did have the desired effect.
There is an undocumented compatibility hack inside automake that
decides whether to build info files in the build tree or in the source
tree: the latter is the default, but if info files appear to be cleaned,
i.e., the info files are listed in CLEANFILES or DISTCLEANFILES, then
the former is done. There is a very long comment in automake, in the
handle_texinfo_helper function explaining the stuff. The comment ends
in:
[...]
# Consequently, starting with Automake 1.8, .info files are
# built in the source tree again. Because we still plan to
# support non-distributed .info files at some point, we
# have a single variable ($INSRC) that controls whether
# the current .info file must be built in the source tree
# or in the build tree. Actually this variable is switched
# off for .info files that appear to be cleaned; this is
# for backward compatibility with package such as Texinfo,
# which do things like
# info_TEXINFOS = texinfo.txi info-stnd.texi info.texi
# DISTCLEANFILES = texinfo texinfo-* info*.info*
# # Do not create info files for distribution.
# dist-info:
# in order not to distribute .info files.
Now, I'm not advocating we do alike for the other document output
formats, but it's worth a thought having a unified way ...
Likewise for {html,dvi,ps} formatted documentation.
Yes.
I would appreciate input on this, esp. in case there are plans to
standardize any of these semantics at some later point.
Thanks,
Ralf
Re: problem to create a noinst_LTLIBRARIES shared libraray
Hello, * John Calcote wrote on Fri, Apr 03, 2009 at 06:25:07PM CEST: On 4/3/2009 3:26 AM, Andreas Otto wrote: I currently writing a java JNI extension used only for local check and this library should *not* be installed. ... Question: what can I do to get a shared LTLIBRARIES using the noinst prefix ? Use check_LTLIBRARIES instead of noinst_LTLIBRARIES. Check libraries and programs are not installed either. I replied on the libtool list: http://lists.gnu.org/archive/html/libtool/2009-04/msg9.html Cheers, Ralf
Re: Finding library procedures in /usr/local/lib/
Hello Gerald, * Gerald I. Evenden wrote on Fri, Apr 03, 2009 at 08:11:22PM CEST: One added note, that bothers me a little. If the system checks for an entry being present in a particular iibrary by compiling/linking a test program using the function *and* linking to the specified library, what if the library under test heavily references another library such as -lm?? IF -lm is not in the test run would the test not fail??? Thus the entry under test fails also. I haven't read the thread in full, but this is probably the issue bothering you: AC_CHECK_LIB and AC_SEARCH_LIBS both have an optional 5th argument where one can supply additional needed libraries. So of libfoo needs libm, then a check for libfoo could look like AC_SEARCH_LIBS([function_from_libfoo], [foo], [], [], [-lm]) and after this macro, $LIBS would contain -lfoo if the test was successful. Of course, you can check for both in sequence, AC_SEARCH_LIBS([cos], [m]) AC_SEARCH_LIBS([function_from_libfoo], [foo]) and in this case you don't need to specify -lm in the second macro, because the first macro will have added that to $LIBS (and $LIBS is used for linking). And yes, library linking order *always* matters. The bugs are just more obscure with GNU/Linux and shared linking than they are under other circumstances. Cheers, Ralf
Re: silent build rules
* Jan Engelhardt wrote on Thu, Apr 02, 2009 at 09:53:21AM CEST: On Thursday 2009-04-02 04:01, Eric Blake wrote: One of Ralf's concerns is that you can't do AC_SUBST([V], [1]), because it interacts badly with various make implementations. That is, the Makefile must not pre-define V as the only means of setting the package's default, if it cannot be overridden by the user. Oh? CFLAGS is also contained in Makefiles, as a result of automake expanding Makefile.am-.in, and usually filled with the default of -O2 -g, and yet can be overriden at make-time. At least, that is, for GNU make, which I happen to use.. Yes. Try some other make implementation like BSD make for starters, or read info Autoconf 'Macros and Submakes'. The point is not to have to use V=1 make -e because 'make -e' can be quite problematic as it pulls in all kinds of junk from your environment. Cheers, Ralf
Re: silent build rules
* Bob Friesenhahn wrote on Wed, Apr 01, 2009 at 11:04:14PM CEST:
On Wed, 1 Apr 2009, Ralf Wildenhues wrote:
* Bob Friesenhahn wrote on Wed, Apr 01, 2009 at 09:32:54PM CEST:
My opinion is that if this mode is optional that it should default to
off
It defaults to off.
It is enabled if the *developer* (Makefile.am author) chooses so.
I take it you suggest that it default to on only if *both* the developer
and the user choose so? I take it that, if we introduced an
Yes, of course. The user should be in charge of building the package.
Developers produce packages for users. Why should the developer care to
restrict what the user sees? The developer should be more concerned
about what the developer sees. The developer typically has different
requirements than the package user.
There are two reasons the developer needs to have a word on this matter:
- To allow to override the silencing at 'make' run time, we use of a
makefile construct with recursive variable expansion $(var1$(var2)).
This is not specified by POSIX, and so might not be portable to all
kinds of 'make' implementations. That means, if your package has the
option 'silent-rules' enabled, then even with V=1, a strict POSIX 'make'
may barf on this construct.
Now, before anyone screams: all 'make' implementations that I could get
hold of *do* accept this construct correctly; that includes IRIX 6.5,
AIX 4.3.3, Tru64 4.0D, Solaris 2.6, HP-UX 10.20, NetBSD, FreeBSD,
OpenBSD, and of course GNU; Also, we tried an alternative implementation
that uses only constructs specified in POSIX, but that turned out to be
*a* *lot* *less* portable in practice.
To cut a long story short, if a developer or maintainer absolutely must
ensure that any remote 'make' implementation can build her package, then
she should not enable the 'silent-rules' option. I assume in practice
the only package that would care ought to be the GNU make package
itself.
- If a developer or maintainer wants to ensure that her users never post
bug reports with the silent-rules style output, then she should be able
to say: my packages are always built verbosely, as always.
I assume this to be a much more relevant issue in practice.
--enable-silent-rules switch to enable silent rules, and the developer
then went ahead and added
: ${enable_silent_rules=yes}
to the configure.ac file, effectively defaulting to silent rather than
verbose, then you will still ask *Automake* to override this somehow?
If it is supported by Automake, then it seems like the capability should
be available all the time (in all packages), defaulted to off. This
way all packages (going forward) will offer similar build options. This
should not be treated differently than the standard configure options
described by the default INSTALL document.
Well, see the reasons above for why I would not like to make
'silent-rules' the default setting.
OTOH you are probably right that the default for the user should be the
verbose mode.
I see two possible ways out, A and B. Suggestions, comments, flames
welcome.
A)
1) The developer can choose to enable the silent-rules option in
configure.ac (as argument to AM_INIT_AUTOMAKE) or Makefile.am (adding
the option to the AUTOMAKE_OPTIONS variable). Without this option,
there will never be less verbose output.
2) The developer or the maintainer can achieve the same effect as in (1)
by adding the command line argument --silent-rules when running
automake.
3) If (1) or (2) were done, then the user can enable less verbose output
with ./configure --enable-silent-rules (the default is verbose).
4) If (3) as well as either (1) or (2) were done, then, at 'make' run
time, less verbose output can be disabled with
make V=1
Is that a compromise everybody can live with?
Another note: even with (3), I would not like to drop (4), because
re-configuring a package just to get more verbose output seems like
a bad move. That is, after all, a nifty feature.
Alternatively:
B)
1) The developer can choose to enable the silent-rules option in
configure.ac (as argument to AM_INIT_AUTOMAKE) or Makefile.am (adding
the option to the AUTOMAKE_OPTIONS variable). Without this option,
there will never be less verbose output.
2) The developer or the maintainer can achieve the same effect as in (1)
by adding the command line argument --silent-rules when running
automake.
3) If (1) or (2) were done, then the silencing machinery is put into
place, but the *default* mode is still verbose. The user explicitly has
to
make V=0
in order to get less verbose output. There is no configure switch to
default to less verbose output.
(B) has the drawback that developers will add a configure switch anyway,
and start AC_SUBST'ing V which is a bad idea for portability reasons,
but we could not educate them anyway.
Thanks,
Ralf
Re: Finding library procedures in /usr/local/lib/
On 4/3/2009 12:29 PM, Ralf Wildenhues wrote: Hello Gerald, * Gerald I. Evenden wrote on Fri, Apr 03, 2009 at 08:11:22PM CEST: One added note, that bothers me a little. If the system checks for an entry being present in a particular iibrary by compiling/linking a test program using the function *and* linking to the specified library, what if the library under test heavily references another library such as -lm?? IF -lm is not in the test run would the test not fail??? Thus the entry under test fails also. I haven't read the thread in full, but this is probably the issue bothering you: AC_CHECK_LIB and AC_SEARCH_LIBS both have an optional 5th argument where one can supply additional needed libraries. So of libfoo needs libm, then a check for libfoo could look like AC_SEARCH_LIBS([function_from_libfoo], [foo], [], [], [-lm]) I sure don't know what's happening to my email messages lately. This is the third time this month that some response of mine has apparently been completely lost by Google mail. I sent this response to this thread last night (via Mozilla Thunderbird client), which goes hand-in-hand with Ralf's response above, but provides more details: - - - - - - I presume that the reason you link with both libproject and the math library is because libproject requires libm. This could explain why your configure.ac tests are failing to find libproject. Try adding this test to configure.ac: AC_SEARCH_LIBS([any_visible_function_in_libproject],[project],[AC_DEFINE([HAVE_LIBPROJECT])],,[-lm]) Tests in configure.ac look for libraries by actually building programs that attempt to link the specified symbol from the specified list of libraries. If the program links, then the test succeeds. The default action in successful cases for AC_SEARCH_LIBS is to add -lprojects to the LIBS variable, which is automatically added to your compiler command line (at least by Automake-generated makefiles). If the library that AC_SEARCH_LIBS attempts to link to requires other non-default libraries (like libm, for instance), then you have to add this list of linker commands to the other-libraries argument, or the test will fail, even if the function is found in the desired library. The documentation for AC_SEARCH_LIBS indicates that, on successfully testing for the desired library, this macro prepends -lproject to LIBS, and then executes the shell code in the action-if-found parameter, thus, you don't need to add -lproject to LIBS, because this is done by the macro before any additional shell code you specify is executed. You can also use the following macro, which generates shell code that is a little less complex. But it's a bit harder to use correctly, as you have to write the entire action-if-found functionality yourself. The carriage returns are fairly important here: AC_CHECK_LIB([project],[any_visible_function_in_libproject], [LIBS=-lproject $LIBS AC_DEFINE([HAVE_LIBPROJECT])],,[-lm]) AC_CHECK_LIB has no success functionality that executes even if you supply the action-if-found argument. All of it's success functionality is given by the default value of the argument. Thus, if you supply the argument, you have to supply all of the appropriate functionality for a successful check. In this case, the macro is supposed to prepend -lproject to LIBS, and then define HAVE_LIBPROJECT. You might also check the config.log file for failed tests that you believe should work. Each failed test is listed in full in config.log, along with the output of the compiler and linker, so you can probably easily see why the test failed. Regards, John
Re: silent build rules
On Fri, 3 Apr 2009, Ralf Wildenhues wrote: A) 1) The developer can choose to enable the silent-rules option in configure.ac (as argument to AM_INIT_AUTOMAKE) or Makefile.am (adding the option to the AUTOMAKE_OPTIONS variable). Without this option, there will never be less verbose output. 2) The developer or the maintainer can achieve the same effect as in (1) by adding the command line argument --silent-rules when running automake. 3) If (1) or (2) were done, then the user can enable less verbose output with ./configure --enable-silent-rules (the default is verbose). 4) If (3) as well as either (1) or (2) were done, then, at 'make' run time, less verbose output can be disabled with make V=1 Is that a compromise everybody can live with? This is an approach that I am happy with. I would not want to deny anyone access to silent rules if they want it (and I will am likely use it for my own developer builds), but feel that traditional verbose should continue to be the default. Without traditional verbose being the default then GNU packages suddenly start to build differently, and the user is much less likely to be able to diagnose a problem by themselves without consuming time from the package maintainer. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Finding library procedures in /usr/local/lib/
John Calcote wrote: I sure don't know what's happening to my email messages lately. This is the third time this month that some response of mine has apparently been completely lost by Google mail. I sent this response to this thread last night (via Mozilla Thunderbird client), which goes hand-in-hand with Ralf's response above, but provides more details: Hi John, I got your first email http://lists.gnu.org/archive/html/automake/2009-04/msg00027.html Cheers, Peter
aclocal problems
Automake maintainers, On page 158, paragraph 3 of the 2.63 Autoconf manual, it states: If a macro doesn’t use AC_REQUIRE, is expected to never be the object of an AC_REQUIRE directive, and macros required by other macros inside arguments do not need to be expanded before this macro, then use m4_define. So the Autoconf manual is encouraging users to use m4_define, however, when I define a macro using m4_define in a .m4 file in the m4 directory of my project, aclocal ignores it by not m4_including it in the generated aclocal.m4 file. It appears to require the use of AC_DEFUN, rather than m4_define in stand-alone .m4 files. Is this a bug in aclocal? I'm using the latest beta version of Automake - 1.10b. Thanks in advance, John
Re: aclocal problems
Hi John, * John Calcote wrote on Fri, Apr 03, 2009 at 09:33:40PM CEST: On page 158, paragraph 3 of the 2.63 Autoconf manual, it states: If a macro doesn’t use AC_REQUIRE, is expected to never be the object of an AC_REQUIRE directive, and macros required by other macros inside arguments do not need to be expanded before this macro, then use m4_define. So the Autoconf manual is encouraging users to use m4_define, however, when I define a macro using m4_define in a .m4 file in the m4 directory of my project, aclocal ignores it by not m4_including it in the generated aclocal.m4 file. It appears to require the use of AC_DEFUN, rather than m4_define in stand-alone .m4 files. Yep. Is this a bug in aclocal? I don't think so. Do you think the quote is an encouragement not to use AC_REQUIRE? For public macros, I'd even venture to say that they should be written so they can be AC_REQUIREd (if they don't take arguments), or at least, that other macros which are expanded inside their contents or their arguments, may themselves AC_REQUIRE yet other macros which are then expanded outside of all this mess. Does the above make sense in any way? Cheers, Ralf
Re: aclocal problems
On 4/3/2009 5:31 PM, Ralf Wildenhues wrote: Hi John, * John Calcote wrote on Fri, Apr 03, 2009 at 09:33:40PM CEST: On page 158, paragraph 3 of the 2.63 Autoconf manual, it states: If a macro doesn’t use AC_REQUIRE, is expected to never be the object of an AC_REQUIRE directive, and macros required by other macros inside arguments do not need to be expanded before this macro, then use m4_define. ... Is this a bug in aclocal? I don't think so. Do you think the quote is an encouragement not to use AC_REQUIRE? For public macros, I'd even venture to say that they should be written so they can be AC_REQUIREd (if they don't take arguments), or at least, that other macros which are expanded inside their contents or their arguments, may themselves AC_REQUIRE yet other macros which are then expanded outside of all this mess. Hmmm. No, I don't think it's an encouragement not to use AC_REQUIRE. It simply states that if you don't use the prerequisite framework, there's no reason to use AC_DEFUN. I supposed that from a certain point of view (a rather sarcastic one), it could be saying something like, if ever you could conceive of a situation in which you wouldn't need to use AC_REQUIRE, then go ahead and use m4_define. I agree completely with your assessment, but I think the manual should make it clear that the only proper way to write a macro is with AC_DEFUN, don't you? I mean, if the only way I can write a macro outside of adding it directly to configure.ac (which is pointless in all but the strangest cases) is to use AC_DEFUN, then *when* would I ever be able to successfully use m4_define? I suppose it might work in acsite.m4, as that's not included by aclocal.m4. My only point is that the manual is a bit unclear on this point - almost misleading, in fact. I'd call it a documentation bug at this point. (Eric - comments?) Regards, John
