Re: AM_CONDITIONAL + AM_COND_IF does not work
Hi,
I had a similar issue and solved it as follows:
use AC_CONFIG_FILES with and AC_SUBST-ed variable:
AC_SUBST([VARIABLE_CONTAINING_MY_MAKEFILES])
AC_CONFIG_FILES([${VARIABLE_CONTAINING_MY_MAKEFILES}])
Snippet from our solution (little bit adjusted to match your issue):
_EXCENTIS_PROTOBUF_MAKEFILES=
AC_MSG_CHECKING([Excentis PROTOBUF ${srcdir}/src/Makefile.am exists])
AM_CONDITIONAL([EXCENTIS_PROTOBUF__BUILD_FROM_SOURCE], [test -f
${srcdir}/src/Makefile.am])
dnl
dnl AC_CONFIG_FILES within AS_IF does not work here because automake
dnl does not check it when processing `Makefile.am` in
`AC_CONFIG_FILES`!
dnl
dnl See also
[http://www.gnu.org/software/automake/manual/html_node/Requirements.html] for
more information
dnl
dnl See
[http://www.gnu.org/software/automake/manual/html_node/Usage-of-Conditionals.html#Usage-of-Conditionals]
dnl for the fix.
dnl
dnl = Defining _EXCENTIS_PROTOBUF_MAKEFILES variable
dnl
AM_COND_IF([EXCENTIS_PROTOBUF__BUILD_FROM_SOURCE],
[AC_MSG_RESULT([yes])
_EXCENTIS_PROTOBUF_MAKEFILES=src/Makefile],
[AC_MSG_RESULT([no])])
dnl
dnl @note
dnl Automake processing `AC_CONFIG_FILES` with variable subtitution
dnl only works when the variable is `AC_SUBST`ed
dnl
dnl See also
[http://www.gnu.org/software/automake/manual/html_node/Requirements.html]
dnl
AC_SUBST([_EXCENTIS_PROTOBUF_MAKEFILES])
AC_CONFIG_FILES([${_EXCENTIS_PROTOBUF_MAKEFILES}])
I hope this helps!
With best regards,
Tom.
On di, 2015-03-10 at 10:02 +0100, Marc Wäckerlin wrote:
Hi Gavin
Thank you, that helps up to the next step ...
Am 09.03.2015 18:45, schrieb Gavin Smith:
automake doesn't know or care that one of these uses of
AC_CONFIG_FILES was conditional. It is looking for the input files to
automake (like Makefile.am), which it will derive from the arguments
to AC_CONFIG_FILES. It wouldn't be possible for these input files to
be defined conditionally in the configure script, because logically
automake runs before the configure script.
That's what I thought, so AM_COND_IF + AC_CONFIG_FILES only works for
existing files, but not in my case. A limitation, that should be better
documented ...
In my eyes, this behaviour is a bug, automake should not test, read or
evaluate conditional files, if the condition does not match.
Now, is there a way to workaround that?
Your idea is a good approach:
The automake manual says that automake won't recognize an argument to
AC_CONFIG_FILES if its value is given indirectly through a shell
variable (see Requirements node), so maybe you could try that.
It works, e.g. I always generate RPM spec files by filling in configure
information:
--
AC_CONFIG_FILES([${PACKAGE_NAME}.spec])
--
That works great. But here, automake is not involved. Unfortunately,
variables seem not to work, if automake is required. The code:
--
makefile=makefile
AM_CONDITIONAL([HAVE_SRC_DIR], [test -f src/${makefile}.am])
AM_COND_IF([HAVE_SRC_DIR], [AC_CONFIG_FILES([src/${makefile}])])
--
does not generate src/makefile.in by automake, as it should.
So, the meaning od the above mentioned manual text is: variables don't
work with automake ... :(
Other ideas? Other solutions?
Am I the only one with dozens of similar projects who wants to save some
typing ...? ;)
On 9 March 2015 at 15:06, Marc Wäckerlin m...@waeckerlin.org wrote:
I try to generically find out, whether examples/makefile.am exists in
a
project and to automatically use it, if it exists:
--
AM_CONDITIONAL([HAVE_EXAMPLES_DIR], [test -f examples/makefile.am])
AM_COND_IF([HAVE_EXAMPLES_DIR],
[AC_CONFIG_FILES([examples/makefile])])
--
A note for those who did not understand the intention:
If and only if file examples/makefile.am exists, then it should be
added to AC_CONFIG_FILES. That means, it is possible and wanted
behavior that examples/makefile.am does not exists, then it should
simply not be added. So if examples/makefile.am does not exists, also
examples/makefile.in will not exist.
The idea behind: I have a standard project setup, where examples, tests
and other subdirectories are optional and I want to write a generic
M4-file that scans for the existing makefiles and automatically adds
those that exist.
So, yes the file does not exits, but no, it does not have to, since
that's exactly the idea of the test: Find out if it exists and use it in
case it exists.
Thank you
Regards
Marc
Re: AM_CONDITIONAL + AM_COND_IF does not work
Hi Gavin
Thank you, that helps up to the next step ...
Am 09.03.2015 18:45, schrieb Gavin Smith:
automake doesn't know or care that one of these uses of
AC_CONFIG_FILES was conditional. It is looking for the input files to
automake (like Makefile.am), which it will derive from the arguments
to AC_CONFIG_FILES. It wouldn't be possible for these input files to
be defined conditionally in the configure script, because logically
automake runs before the configure script.
That's what I thought, so AM_COND_IF + AC_CONFIG_FILES only works for
existing files, but not in my case. A limitation, that should be better
documented ...
In my eyes, this behaviour is a bug, automake should not test, read or
evaluate conditional files, if the condition does not match.
Now, is there a way to workaround that?
Your idea is a good approach:
The automake manual says that automake won't recognize an argument to
AC_CONFIG_FILES if its value is given indirectly through a shell
variable (see Requirements node), so maybe you could try that.
It works, e.g. I always generate RPM spec files by filling in configure
information:
--
AC_CONFIG_FILES([${PACKAGE_NAME}.spec])
--
That works great. But here, automake is not involved. Unfortunately,
variables seem not to work, if automake is required. The code:
--
makefile=makefile
AM_CONDITIONAL([HAVE_SRC_DIR], [test -f src/${makefile}.am])
AM_COND_IF([HAVE_SRC_DIR], [AC_CONFIG_FILES([src/${makefile}])])
--
does not generate src/makefile.in by automake, as it should.
So, the meaning od the above mentioned manual text is: variables don't
work with automake ... :(
Other ideas? Other solutions?
Am I the only one with dozens of similar projects who wants to save some
typing ...? ;)
On 9 March 2015 at 15:06, Marc Wäckerlin m...@waeckerlin.org wrote:
I try to generically find out, whether examples/makefile.am exists in
a
project and to automatically use it, if it exists:
--
AM_CONDITIONAL([HAVE_EXAMPLES_DIR], [test -f examples/makefile.am])
AM_COND_IF([HAVE_EXAMPLES_DIR],
[AC_CONFIG_FILES([examples/makefile])])
--
A note for those who did not understand the intention:
If and only if file examples/makefile.am exists, then it should be
added to AC_CONFIG_FILES. That means, it is possible and wanted
behavior that examples/makefile.am does not exists, then it should
simply not be added. So if examples/makefile.am does not exists, also
examples/makefile.in will not exist.
The idea behind: I have a standard project setup, where examples, tests
and other subdirectories are optional and I want to write a generic
M4-file that scans for the existing makefiles and automatically adds
those that exist.
So, yes the file does not exits, but no, it does not have to, since
that's exactly the idea of the test: Find out if it exists and use it in
case it exists.
Thank you
Regards
Marc
--
Marc Wäckerlin
http://marc.wäckerlin.ch
AM_CONDITIONAL + AM_COND_IF does not work
According to the official documentation(*): -- Here is an example of how to define a conditional config file: AM_CONDITIONAL([SHELL_WRAPPER], [test x$with_wrapper = xtrue]) AM_COND_IF([SHELL_WRAPPER], [AC_CONFIG_FILES([wrapper:wrapper.in])]) -- I try to generically find out, whether examples/makefile.am exists in a project and to automatically use it, if it exists: -- AM_CONDITIONAL([HAVE_EXAMPLES_DIR], [test -f examples/makefile.am]) AM_COND_IF([HAVE_EXAMPLES_DIR], [AC_CONFIG_FILES([examples/makefile])]) -- But automake fails: -- configure.ac:27: error: required file 'examples/makefile.in' not found -- So, what's the problem? It's nearly the same code as in the example ... (*) see http://www.gnu.org/software/automake/manual/html_node/Usage-of-Conditionals.html Thank you Regards Marc -- Marc Wäckerlin
Re: AM_CONDITIONAL + AM_COND_IF does not work
Hey, On 3/9/2015 11:06 AM, Marc Wäckerlin wrote: According to the official documentation(*): -- Here is an example of how to define a conditional config file: AM_CONDITIONAL([SHELL_WRAPPER], [test x$with_wrapper = xtrue]) AM_COND_IF([SHELL_WRAPPER], [AC_CONFIG_FILES([wrapper:wrapper.in])]) -- I try to generically find out, whether examples/makefile.am exists in a project and to automatically use it, if it exists: -- AM_CONDITIONAL([HAVE_EXAMPLES_DIR], [test -f examples/makefile.am]) AM_COND_IF([HAVE_EXAMPLES_DIR], [AC_CONFIG_FILES([examples/makefile])]) -- But automake fails: -- configure.ac:27: error: required file 'examples/makefile.in' not found -- AC_CONFIG_FILES([examples/makefile]) presumes you have examples/makefile.in from which to generate makefile when configure is run. The error is clear, examples/makefile.in isn't found. Did you forget generate makefile.in from makefile.am with automake? I'd try that first. Tyler
Re: AM_CONDITIONAL + AM_COND_IF does not work
Hi Marc, On ma, 2015-03-09 at 16:06 +0100, Marc Wäckerlin wrote: I try to generically find out, whether examples/makefile.am exists in a project and to automatically use it, if it exists: -- AM_CONDITIONAL([HAVE_EXAMPLES_DIR], [test -f examples/makefile.am]) AM_COND_IF([HAVE_EXAMPLES_DIR], [AC_CONFIG_FILES([examples/makefile])]) -- Don't you mean to have AM_CONDITIONAL([HAVE_EXAMPLES_DIR], [test -f examples/Makefile.am]) AM_COND_IF([HAVE_EXAMPLES_DIR], [AC_CONFIG_FILES([examples/Makefile])]) (Titlecase Makefile) With best regards, Tom. -- | tom.ghyseli...@excentis.com | | Tom Ghyselinck | Senior Engineer | Excentis N.V. | Gildestraat 8 B-9000 Ghent, Belgium | Tel: +32 9 269 22 91 - Fax: +32 9 329 31 74
Re: AM_CONDITIONAL + AM_COND_IF does not work
On 9 March 2015 at 15:06, Marc Wäckerlin m...@waeckerlin.org wrote:
According to the official documentation(*):
--
Here is an example of how to define a conditional config file:
AM_CONDITIONAL([SHELL_WRAPPER], [test x$with_wrapper = xtrue])
AM_COND_IF([SHELL_WRAPPER],
[AC_CONFIG_FILES([wrapper:wrapper.in])])
--
I try to generically find out, whether examples/makefile.am exists in a
project and to automatically use it, if it exists:
--
AM_CONDITIONAL([HAVE_EXAMPLES_DIR], [test -f examples/makefile.am])
AM_COND_IF([HAVE_EXAMPLES_DIR], [AC_CONFIG_FILES([examples/makefile])])
--
But automake fails:
--
configure.ac:27: error: required file 'examples/makefile.in' not found
--
So, what's the problem?
It's nearly the same code as in the example ...
As you found automake gets information from configure.ac. It does this
using a macro tracing feature of autoconf. If you run automake
--verbose you will see the macros it is tracing, including
AC_CONFIG_FILES. With a setup like yours,
$autoconf --trace=AC_CONFIG_FILES:\$f:\$l::\$d::\$n::\${::}%
gives the output
configure.ac:6::1::AC_CONFIG_FILES::examples/makefile:examples/makefile.in
configure.ac:12::1::AC_CONFIG_FILES::Makefile
automake doesn't know or care that one of these uses of
AC_CONFIG_FILES was conditional. It is looking for the input files to
automake (like Makefile.am), which it will derive from the arguments
to AC_CONFIG_FILES. It wouldn't be possible for these input files to
be defined conditionally in the configure script, because logically
automake runs before the configure script.
The automake manual says that automake won't recognize an argument to
AC_CONFIG_FILES if its value is given indirectly through a shell
variable (see Requirements node), so maybe you could try that.
Re: AM_CONDITIONAL fails with line break at the end of $2
On 07/17/2014 12:44 PM, Dimitrios Apostolou wrote: Hi Erik, thank you for forwarding to the appropriate list! On Thu, 17 Jul 2014, Eric Blake wrote: I don't know if automake should work around your bad syntax, or if you should just fix your configure.ac to use correct syntax to begin with. I Is my syntax illegal? Can't I put line-breaks there? If I knew I wouldn't bother with this patch, it's just that I consumed some time to figure out this failure, so I thought it would be helpful to others. Not illegal (there's no law prohibiting it), but not typical; and the fact that it is causing a syntax error is a sign that fixing your code is more likely to bring it in line with other packages, than waiting for the tools to be taught to work with your usage as a new pattern, and then waiting for that fix to percolate to the distros you care about. More typical usage looks like one of these: AM_CONDITIONAL([HAVE_LIBXML2], [test x$with_libxml2 != xno test x$ac_cv_lib_xml2_xmlFirstElementChild = xyes]) or AM_CONDITIONAL([HAVE_LIBXML2], [ test x$with_libxml2 != xno test x$ac_cv_lib_xml2_xmlFirstElementChild = xyes]dnl ) (that is, you'll usually see the close ) flush against the close ], or you will see a use of 'dnl' to eat any newlines that were used to visually spot that the closing ) on the start of the next line matches an earlier line above) also wonder if automake could use AS_IF instead of open-coding the if to try and take advantage of autoconf's smarts for trying to sanitize conditions. However, even autoconf's AS_IF current implementation prefers the 'if cond; then' rather than 'if cond $newline then', so it is likewise not robust to conditions ending in a spurious newline. If changing AS_IF to use newline separator does not increase configure size, I could see making that change in autoconf. I'll play with the idea. Thanks, please keep me posted! Sure. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: AM_CONDITIONAL fails with line break at the end of $2
Hi Erik, thank you for forwarding to the appropriate list! On Thu, 17 Jul 2014, Eric Blake wrote: I don't know if automake should work around your bad syntax, or if you should just fix your configure.ac to use correct syntax to begin with. I Is my syntax illegal? Can't I put line-breaks there? If I knew I wouldn't bother with this patch, it's just that I consumed some time to figure out this failure, so I thought it would be helpful to others. also wonder if automake could use AS_IF instead of open-coding the if to try and take advantage of autoconf's smarts for trying to sanitize conditions. However, even autoconf's AS_IF current implementation prefers the 'if cond; then' rather than 'if cond $newline then', so it is likewise not robust to conditions ending in a spurious newline. If changing AS_IF to use newline separator does not increase configure size, I could see making that change in autoconf. I'll play with the idea. Thanks, please keep me posted! Dimitris
Re: AM_CONDITIONAL fails with line break at the end of $2
dropping autoconf
On 07/17/2014 10:24 AM, Eric Blake wrote:
[adding automake]
On 07/17/2014 10:00 AM, Dimitrios Apostolou wrote:
--- cond.m4 2014-07-17 17:46:37.741723897 +0200
+++ cond.2.m42014-07-17 17:50:43.456076469 +0200
@@ -13,17 +13,18 @@
[AC_PREREQ([2.52])dnl
m4_if([$1], [TRUE], [AC_FATAL([$0: invalid condition: $1])],
[$1], [FALSE], [AC_FATAL([$0: invalid condition: $1])])dnl
AC_SUBST([$1_TRUE])dnl
AC_SUBST([$1_FALSE])dnl
_AM_SUBST_NOTMAKE([$1_TRUE])dnl
_AM_SUBST_NOTMAKE([$1_FALSE])dnl
m4_define([_AM_COND_VALUE_$1], [$2])dnl
-if $2; then
+if $2
+then
$1_TRUE=
$1_FALSE='#'
else
$1_TRUE='#'
$1_FALSE=
fi
AC_CONFIG_COMMANDS_PRE(
[if test -z ${$1_TRUE} test -z ${$1_FALSE}; then
This patch looks correct for automake, especially given that I just
pushed a similar patch to autoconf's AS_IF. Alas, I don't trust myself
to push it to all the correct automake branches, so I'm hoping a
maintainer will step in here.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Using AM_CONDITIONAL in m4 macros
I have come across a package where autoreconf doesn't work out of the box. The reason is that it calls a m4 macro that contains an AM_CONDITIONAL which is later tested in Makefile.am. This seemingly works when running the autogen.sh script included in the package that calls the autotools. Calling autoreconf only works if the macro file is explicitly included (via m4_include). So my question is, if there is a way to have this working without the explicit inclusion. This is with automake 1.12.3 and autoconf 2.69. Philipp
Re: Using AM_CONDITIONAL in m4 macros
On 2013-01-18 16:49 +0100, Philipp Thomas wrote: I have come across a package where autoreconf doesn't work out of the box. The reason is that it calls a m4 macro that contains an AM_CONDITIONAL which is later tested in Makefile.am. This seemingly works when running the autogen.sh script included in the package that calls the autotools. Calling autoreconf only works if the macro file is explicitly included (via m4_include). So my question is, if there is a way to have this working without the explicit inclusion. If the package author(s) provided a script to bootstrap the build system, then you should use that script. Someone made the effort to write that script, and they presumably did not do so for no reason. You say that the provided script works, so that implies that a plain autoreconf is not the correct way to bootstrap this package. If you think this is a bug or limitation in autoreconf, could you provide a small example package which demonstrates the problem? I am not aware of any problems like this related to AM_CONDITIONAL inside m4 macros. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Re: Using AM_CONDITIONAL in m4 macros
* Nick Bowler (nbow...@elliptictech.com) [20130118 17:17]: If the package author(s) provided a script to bootstrap the build system, then you should use that script. Someone made the effort to write that script, and they presumably did not do so for no reason. I have no idea why they originally wrote that script. Fact is it failed to update the libtool configury correctly so that builing failed because of libtool version mismatches. I had (wrongly) assumed that running autoreconf instead would get me quicker to a building package. You say that the provided script works, so that implies that a plain autoreconf is not the correct way to bootstrap this package. That wasn't quite correct as I wrote above. If you think this is a bug or limitation in autoreconf, could you provide a small example package which demonstrates the problem? ATM I have no time for dol an example package but the scenario I encounterd goes something like this: In file swig.m4: AC_DEFUN([MLX_PROG_SWIG],[ if test ! -z $has_swig; then SWIG_LIB=`$SWIG -swiglib` AM_CONDITIONAL(HAS_SWIG,[test 1]) else AM_CONDITIONAL(HAS_SWIG,[test 0]) fi ]) configure.in calls MLX_PROG_SWIG and Makefile.am contains if HAS_SWIG [...] endif And autoreconf complains that there is no AM_CONDITIONAL for HAS_SWIG unless I directly m4_include swig.m4. Is that a suffient description? Philipp
Re: Using AM_CONDITIONAL in m4 macros
On 01/18/2013 07:45 PM, Philipp Thomas wrote: * Nick Bowler (nbow...@elliptictech.com) [20130118 17:17]: If the package author(s) provided a script to bootstrap the build system, then you should use that script. Someone made the effort to write that script, and they presumably did not do so for no reason. I have no idea why they originally wrote that script. Fact is it failed to update the libtool configury correctly so that builing failed because of libtool version mismatches. I had (wrongly) assumed that running autoreconf instead would get me quicker to a building package. You say that the provided script works, so that implies that a plain autoreconf is not the correct way to bootstrap this package. That wasn't quite correct as I wrote above. If you think this is a bug or limitation in autoreconf, could you provide a small example package which demonstrates the problem? ATM I have no time for dol an example package but the scenario I encounterd goes something like this: In file swig.m4: AC_DEFUN([MLX_PROG_SWIG],[ if test ! -z $has_swig; then SWIG_LIB=`$SWIG -swiglib` AM_CONDITIONAL(HAS_SWIG,[test 1]) else AM_CONDITIONAL(HAS_SWIG,[test 0]) fi ]) This is a user error; according to the POSIX standard, test N evaluates to true for every N = 0: $ bash -c 'test 1' echo TRUE TRUE $ bash -c 'test 0' echo TRUE TRUE $ dash -c 'test 1' echo TRUE TRUE $ dash -c 'test 0' echo TRUE TRUE A correct usage would probably be something like (untested): AM_CONDITIONAL([HAS_SWIG], [test x$has_swig != x]) test x$has_swig != x SWIG_LIB=`$SWIG -swiglib` And autoreconf complains that there is no AM_CONDITIONAL for HAS_SWIG unless I directly m4_include swig.m4. Is that a suffient description? As for this, it might be a bug or a limitation, since it doesn't seem related to the user error above. Could you try to send a minimal and correct reproducer for it? Thanks, Stefano
AM_CONDITIONAL to choose between building library or linking directly
Is that supposed not to work? (“LIBRARY_BUILD” AM_CONDITIONAL set accordingly on configre.ac) Makefile.am: if LIBRARY_BUILD lib_LTLIBRARIRES = libprog.la libprog_la_SOURCES = a.c b.c d.c else !LIBRARY_BUILD bin_PROGRAMS = driver driver_SOURCES = a.c b.c d.c driver.c endif !LIBRARY_BUILD if LIBRARY_BUILD a.lo: a.c b.lo b.lo: b.c d.lo: d.c a.lo b.lo else !LIBRARY_BUILD a.o: a.c b.o b.o: b.c d.o: d.c a.o b.o driver.o: driver.c a.o b.o d.o endif !LIBRARY_BUILD ### With a setup like this I get errors like Makefile.am: object ‘a.$(OBJEXT)’ created both with libtool and without for a, b and d source files. Removing ‘a.c’ from one of the libprog_la_SOURCES -or- driver_SOURCES takes out the error message but also renders either the library or driver unbuildable... thank ya. p.s.: I am using fortran, so I -must- build rules manually. anyway, the problem part is at the ‘*_SOURCES =’ definition.
Re: AM_CONDITIONAL to choose between building library or linking directly
On 2012-09-11 15:41 -0300, Fabrício Zimmerer Murta wrote: Is that supposed not to work? (“LIBRARY_BUILD” AM_CONDITIONAL set accordingly on configre.ac) Makefile.am: if LIBRARY_BUILD lib_LTLIBRARIRES = libprog.la libprog_la_SOURCES = a.c b.c d.c else !LIBRARY_BUILD bin_PROGRAMS = driver driver_SOURCES = a.c b.c d.c driver.c endif !LIBRARY_BUILD Instead of the pattern above, what will probably work is to use the conditional to select between an installable libtool library or a libtool convenience library, so that libtool is used in both cases. For example (untested): if LIBRARY_BUILD lib_LTLIBRARIES = libprog.la else noinst_LTLIBRARIES = libprog.la bin_PROGRAMS = driver endif libprog_la_SOURCES = a.c b.c d.c driver_SOURCES = driver.c driver_LDADD = libprog.la if LIBRARY_BUILD a.lo: a.c b.lo b.lo: b.c d.lo: d.c a.lo b.lo else !LIBRARY_BUILD a.o: a.c b.o b.o: b.c d.o: d.c a.o b.o driver.o: driver.c a.o b.o d.o endif !LIBRARY_BUILD Then with the above change, the else case of this conditional is now not required. Note that regardless of what you do, these prerequisites look very odd as they say that object files depend on other object files (which would imply that b.o is somehow required to update a.o: very unusual in a C program). Moreover, Automake already provides prerequisites from object files to their C source files, so listing the .c files here is redundant. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Re: AM_CONDITIONAL to choose between building library or linking directly
these prerequisites look very odd as they say that object files depend on other object files Blame fortran for that. Is 'b' is a module, I have to assure 'a' is compiled only when 'b' is compiled (so the .mod file is created). With this rule, I can assure make -jN would not result in error. I think your noinst_ suggestion really does the trick, although I thought it was an incosistent error. If I am not building any library, it shouldn't think I am building one (as long as I sepparated it correctly with conditionals). :/ But thank you, I was really wondering if that noinst_ approach would fit, it turns that it's the only solution. -Original Message- From: Nick Bowler Sent: Tuesday, September 11, 2012 4:42 PM To: FabrícioZimmerer Murta Cc: Automake Mailing List Subject: Re: AM_CONDITIONAL to choose between building library or linking directly On 2012-09-11 15:41 -0300, Fabrício Zimmerer Murta wrote: Is that supposed not to work? (“LIBRARY_BUILD” AM_CONDITIONAL set accordingly on configre.ac) Makefile.am: if LIBRARY_BUILD lib_LTLIBRARIRES = libprog.la libprog_la_SOURCES = a.c b.c d.c else !LIBRARY_BUILD bin_PROGRAMS = driver driver_SOURCES = a.c b.c d.c driver.c endif !LIBRARY_BUILD Instead of the pattern above, what will probably work is to use the conditional to select between an installable libtool library or a libtool convenience library, so that libtool is used in both cases. For example (untested): if LIBRARY_BUILD lib_LTLIBRARIES = libprog.la else noinst_LTLIBRARIES = libprog.la bin_PROGRAMS = driver endif libprog_la_SOURCES = a.c b.c d.c driver_SOURCES = driver.c driver_LDADD = libprog.la if LIBRARY_BUILD a.lo: a.c b.lo b.lo: b.c d.lo: d.c a.lo b.lo else !LIBRARY_BUILD a.o: a.c b.o b.o: b.c d.o: d.c a.o b.o driver.o: driver.c a.o b.o d.o endif !LIBRARY_BUILD Then with the above change, the else case of this conditional is now not required. Note that regardless of what you do, these prerequisites look very odd as they say that object files depend on other object files (which would imply that b.o is somehow required to update a.o: very unusual in a C program). Moreover, Automake already provides prerequisites from object files to their C source files, so listing the .c files here is redundant. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
building conditionnaly without using AM_CONDITIONAL
Hey I want to build conditionnaly a program. Usually, I do that with autoconf and AM_CONDITIONAL. Unfortunately, the author of the lib wants me to build a part of the library with just a make rule. Note that autoconf is used, but the author does not want to use a configure option for that. So: make : does not build that part make bench : build that part (it's a benchmark prog) So i tried to set the 'all' rule to nothing in Makefile.am, it has no effect. Is there a way to do what I want ? thank you Vincent Torri
Re: building conditionnaly without using AM_CONDITIONAL
On 09/09/2012 04:05, Vincent Torri wrote: So i tried to set the 'all' rule to nothing in Makefile.am, it has no effect. Is there a way to do what I want ? EXTRA_PROGRAMS = benchmark This way the program is not built during make all. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: Weird behaviour of AM_CONDITIONAL
Hi Eric, It was in fact my mistake, I'm really sorry for posting for such a trivial issue, but I'm a real beginner to autotools and I guess that after spending hours understanding all the complex principles, I didn't take care enough to basic stuff. Anyway thank you very much for your fast answer, I'm really happy to have my first autotools project working now! Have a great week-end! On Fri, Sep 2, 2011 at 6:48 PM, Eric Blake ebl...@redhat.com wrote: On 09/02/2011 08:24 AM, Thibaut Le Guilly wrote: I am using AM_CONDITIONAL to enable a user to choose between one kind of library and another one with : AM_CONDITIONAL([ENABLE_A], [test x$condition=xyes]) Am I doing something wrong? Do you know how to solve this problem? Wrong syntax. You meant: test x$condition = xyes the quoting around $condition, and the spacing around =, are essential in shell syntax. Otherwise, if $condition has no whitespace to cause IFS word splitting, you end up testing whether the single word x$condition=xyes is non-empty, which it is, so the test is always true. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- Thibaut Le Guilly Research Assistant at Aalborg University Embedded System Engineer (ECE Paris) Software System Engineer (Aalborg University)
Weird behaviour of AM_CONDITIONAL
Hello everybody, I first hope that I choose the right mailing list to expose my issue, and if I didn't please excuse my mistake. I've spent some days working with autotools in order to build a shared library, and everything went fine except a really weird issue that I have using AM_CONDITIONAL and the if else statement. I am using AM_CONDITIONAL to enable a user to choose between one kind of library and another one with : AM_CONDITIONAL([ENABLE_A], [test x$condition=xyes]) In my Makefile.am file, I'm using : if ENABLE_A lib_la_SOURCES += \ fileA.c\ fileA.h else lib_la_SOURCES += \ fileB.c\ fileB.h endif My problem is that it always enter in the if statement even when $condition is equal to 'no'. In fact, I used AC_MSG_RESULT in order to check its value, but in the generated Makefile, I always find the fileA.c/.h whatever the value of condition is. I really tried a lot of stuff, like using two AM_CONDITIONAL like : AM_CONDITIONAL([ENABLE_A], [test x$condition=xyes]) AM_CONDITIONAL([DISABLE_A], [test x$condition=xno]) with two different if statement (if ENABLE_A and if DISBALE_A), but then both fileA.c/.h and fileB.c/.h were included in the sources. Am I doing something wrong? Do you know how to solve this problem? Thanks in advance to anybody who could help me! -- Thibaut Le Guilly
Re: Weird behaviour of AM_CONDITIONAL
On 09/02/2011 08:24 AM, Thibaut Le Guilly wrote: I am using AM_CONDITIONAL to enable a user to choose between one kind of library and another one with : AM_CONDITIONAL([ENABLE_A], [test x$condition=xyes]) Am I doing something wrong? Do you know how to solve this problem? Wrong syntax. You meant: test x$condition = xyes the quoting around $condition, and the spacing around =, are essential in shell syntax. Otherwise, if $condition has no whitespace to cause IFS word splitting, you end up testing whether the single word x$condition=xyes is non-empty, which it is, so the test is always true. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Problem with AM_CONDITIONAL
Hi, I have been studying deeply the GNU automake manual in order to use AM_CONDITIONAL and I have found that is is not useful for me in the following sense: I define the AM_CONDITIONAL in 'configure.ac': CONF_HAVE_RTK=yes AM_CONDITIONAL( [COMPILE_WITH_RTK], [ test $CONF_HAVE_RTK == yes ]) and in the makefile.am: if COMPILE_WITH_RTK RTK_SUBDIR = gestiong-rtk endif SUBDIRS = gestiong-lib gestiong-gui-qt3 $(RTK_SUBDIR) gestiong-system \ gestiong-contactos gestiong-contable gestiong-socias gestiong Everything works fine, but the problem is that in the generated Makefile, there is a line almost at the bottom that says: RTK_SUBDIR = gestiong-rtk but this line is BELOW the line that says SUBDIRS = gestiong-lib gestiong-gui-qt3 $(RTK_SUBDIR) gestiong-system \ gestiong-contactos gestiong-contable gestiong-socias gestiong in the same Makefile, so there is no substitution at all and my RTK_SUBDIR is never compiled. To the best of my knoledge, the line RTK_SUBDIR = gestiong should have been generated at the beginning of the Makefile. Is that an issue? Is there any workaround? Thanks in advance, -- santilin
Re: Problem with AM_CONDITIONAL
On Monday 21 January 2008, Santiago Capel Torres wrote: I define the AM_CONDITIONAL in 'configure.ac': CONF_HAVE_RTK=yes AM_CONDITIONAL( [COMPILE_WITH_RTK], [ test $CONF_HAVE_RTK == yes ]) test uses one =, not two and in the makefile.am: if COMPILE_WITH_RTK RTK_SUBDIR = gestiong-rtk endif SUBDIRS = gestiong-lib gestiong-gui-qt3 $(RTK_SUBDIR) gestiong-system \ gestiong-contactos gestiong-contable gestiong-socias gestiong your indentation is what's causing problems. do not indent RTK_SUBDIR. Everything works fine, but the problem is that in the generated Makefile, there is a line almost at the bottom that says: RTK_SUBDIR = gestiong-rtk but this line is BELOW the line that says SUBDIRS = gestiong-lib gestiong-gui-qt3 $(RTK_SUBDIR) gestiong-system \ gestiong-contactos gestiong-contable gestiong-socias gestiong in the same Makefile, so there is no substitution at all and my RTK_SUBDIR is never compiled. To the best of my knoledge, the line RTK_SUBDIR = gestiong should have been generated at the beginning of the Makefile. the order with make does not matter so long as you use = for assignments as this means delayed processing. so if you do: FOO = $(A) $(B) A = a B = $(C) b C = c then when you use $(FOO), it would just work which means you'd end up with: FOO = a c b -mike signature.asc Description: This is a digitally signed message part.
Re: What is meant by, XXX does not appear in AM_CONDITIONAL?
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes: [...] Ralf A semi-classic example of such a situation is this one: [...] Ralf AS_IF([test $enable_cxx = yes], Ralf [AC_PROG_CXX]) [...] Ralf = Not even automake and autoconf are to treat this situation properly. No. But if someone know how to do this better, ideas would be welcome. Producing an error at configure time was an improvement over what we had in the past (make failing to parse Makefile.in). Currently the motto is « don't check conditionally; check unconditionally and only perform conditional actions ». I know that unfortunately AC_PROG_CXX does not allow conditional actions (since it abort if no compiler is found), but calling it conditionally as above is just what causes AM_CONDITIONAL to be called conditionally (and thus, fail at configure time). -- Alexandre Duret-Lutz
Re: What is meant by, XXX does not appear in AM_CONDITIONAL?
Hi Bruce, On Mon, Jan 10, 2005 at 08:35:27AM -0800, Bruce Korb wrote: if [some-shell-script-test] then ... AM_CONDITIONAL([XXX], [true]) else ... AM_CONDITIONAL([XXX], [false]) fi reading the docs some more, they explicitly state to not do this. I re-read the node ``Conditionals'' of automake manual (CVS version) just now. I don't see any problem: ``you must arrange for _every_ `AM_CONDITIONAL' to be invoked every time `configure' is run'' and you are doing this. But Ralf said that this practice is not reliable, and I'd believe his experience. If I can add a bit of my experience, then I witness that using commands `true' or `false' as the second part of AM_CONDITIONAL is often sign of bad style. This might apply to your ``set_XXX'' too. Let me explain: You said: This is more-or-less exactly what is going on, except that the some-shell-script-test includes (but is not exactly limited to) some compile-and-link macros. Oh, then the following if should not probably test for `$?', but for a variable value, or something else which represents the result of the previous tests. In most cases, you can follow this pattern: AC_CHECK_FOR_ELEPHANTS(...) if test x$ELEPHANTS_FOUND = xyes; then ... else ... fi AM_CONDITIONAL([XXX], [test x$ELEPHANTS_FOUND = xyes]) or perhaps this pattern: AC_CHECK_FOR_ELEPHANTS(...) HAVE_ELEPHANTS=yes case $ELEPHANT_TYPE in indian) ...;; african) ...;; *) HAVE_ELEPHANTS=no;; esac AM_CONDITIONAL([HAVE_ELEPHANTS], [test $HAVE_ELEPHANTS = yes]) AM_CONDITIONAL([INDIAN_ELEPHANTS], [test x$ELEPHANT_TYPE = xindian]) A side note: yes, you could set HAVE_ELEPHANTS to `true' or `false' here and call ``AM_CONDITIONAL([HAVE_ELEPHANTS], [$HAVE_ELEPHANTS])''. It's a matter of taste. Another side note: this example probably explains the Ralf's recommendation to have AM_CONDITIONALa out of any if is right: you could easily imagine that one forgets to set INDIAN_ELEPHANTS when no elephants are available. Have a nice day, Stepan
Re: What is meant by, XXX does not appear in AM_CONDITIONAL?
On Tue, 2005-01-11 at 11:09 +0100, Stepan Kasal wrote: Hi Bruce, On Mon, Jan 10, 2005 at 08:35:27AM -0800, Bruce Korb wrote: if [some-shell-script-test] then ... AM_CONDITIONAL([XXX], [true]) else ... AM_CONDITIONAL([XXX], [false]) fi reading the docs some more, they explicitly state to not do this. I re-read the node ``Conditionals'' of automake manual (CVS version) just now. I don't see any problem: ``you must arrange for _every_ `AM_CONDITIONAL' to be invoked every time `configure' is run'' and you are doing this. But Ralf said that this practice is not reliable, and I'd believe his experience. The _every_ is the crucial word in your sentence. In practice this _every_ is very easy to miss, esp. if packing conditionals into macros, splitting setting up conditionals/using conditionals into different macro files and trying to AC_REQUIRE the these macros: A semi-classic example of such a situation is this one: # cat configure.ac: AC_PREREQ(2.59) AC_INIT(autobug, 20040111, [EMAIL PROTECTED]) AM_INIT_AUTOMAKE([foreign 1.9.4]) AC_ARG_ENABLE(cxx) AS_IF([test $enable_cxx = yes], [AC_PROG_CXX]) AM_CONDITIONAL(USECXX,[test enable_cxx = yes]) AC_CONFIG_FILES([Makefile]) AC_OUTPUT # cat Makefile.am if USECXX noinst_PROGRAMS = foo foo_SOURCES = foo.cc endif automake will not complain, but configure will yell at runtime: # ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes configure: error: conditional AMDEP was never defined. Usually this means the macro was only invoked conditionally. = Not even automake and autoconf are to treat this situation properly. Even more bizarre situations can be constructed when adding AC_PROG_CC to the configure.ac above. Depending on where you insert it either this happens: # ./configure ... hecking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 configure: error: conditional am__fastdepCXX was never defined. Usually this means the macro was only invoked conditionally. or this # ./configure ... checking whether we are using the GNU C compiler... no checking whether gcc accepts -g... no checking for gcc option to accept ANSI C... none needed checking dependency style of gcc... none configure: error: conditional AMDEP was never defined. Usually this means the macro was only invoked conditionally. [Note: this is the same system, same environment!] In a real-world example, I once encountered a case were such breakdown occurred conditionally, depending on the --enable/--disable arguments being passed to a configure script ;( Ralf
Re: What is meant by, XXX does not appear in AM_CONDITIONAL?
Hi On Sat, Jan 08, 2005 at 03:21:44PM -0800, Bruce Korb wrote: [`some-shell-script-test` if test $? -eq 0 then] AM_CONDITIONAL([XXX], [true]) [else] AM_CONDITIONAL([XXX],[false]) [fi] one usually relies that `else', `fi', etc. are not m4 macros. So it's usually enough to write [some-shell-script-test] if test $? -eq 0 then AM_CONDITIONAL([XXX], [true]) else AM_CONDITIONAL([XXX], [false]) fi Well, I'd use if [some-shell-script-test] then ... AM_CONDITIONAL([XXX], [true]) else ... AM_CONDITIONAL([XXX], [false]) fi in cases when at least one of the alternatives requires additional code to bve put insted of the `...' If you have no such code, I see no reason why not to use the simple AM_CONDITIONAL([XXX], [[some-shell-script-test]]) note the double quote: the inner pair prevents expanding of macros in the test code, if you need it. HTH, Stepan Kasal
Re: What is meant by, XXX does not appear in AM_CONDITIONAL?
Hi Stepan,
On Monday 10 January 2005 06:00 am, Stepan Kasal wrote:
So it's usually enough to write
Well, I'd use
if [some-shell-script-test]
then
...
AM_CONDITIONAL([XXX], [true])
else
...
AM_CONDITIONAL([XXX], [false])
fi
This is more-or-less exactly what is going on, except that
the some-shell-script-test includes (but is not exactly
limited to) some compile-and-link macros. However, upon
reading the docs some more, they explicitly state to not do
this. Is that overcaution in the docs? Should one actually
do the following?
if [some-shell-script-test]
then
...
set_XXX=true
else
...
set_XXX=false
fi
AM_CONDITIONAL([XXX], [${set_XXX}])
Re: What is meant by, XXX does not appear in AM_CONDITIONAL?
Bruce == Bruce Korb [EMAIL PROTECTED] writes: Bruce The problem is is that XXX *DOES* actually appear in an AM_CONDITIONAL. But these macros are not evaluated because of your quoting, so effectively XXX is not defined at all. [...] Bruce [`some-shell-script-test` Bruce if test $? -eq 0 Bruce then Bruce AM_CONDITIONAL([XXX], [true]) Bruce else Bruce AM_CONDITIONAL([XXX],[false]) Bruce fi] [...] -- Alexandre Duret-Lutz
Re: What is meant by, XXX does not appear in AM_CONDITIONAL?
On Saturday 08 January 2005 01:53 pm, Alexandre Duret-Lutz wrote: Bruce == Bruce Korb [EMAIL PROTECTED] writes: Bruce The problem is is that XXX *DOES* actually appear in an AM_CONDITIONAL. But these macros are not evaluated because of your quoting, so effectively XXX is not defined at all. Then it needs to be spelled thus?? Bruce [`some-shell-script-test` Bruce if test $? -eq 0 Bruce then] Bruce AM_CONDITIONAL([XXX], [true]) Bruce [else] Bruce AM_CONDITIONAL([XXX],[false]) Bruce [fi] (putting the AM_CONDITIONALs outside of quotes). I didn't guess that. Thank you! - Bruce
Error: am__fastdepCC does not appear in AM_CONDITIONAL
I'm getting the following error on Fedora Core 2 (it used to work but no longer). /usr/share/automake-1.8/am/depend2.am: am__fastdepCC does not appear in AM_CONDITIONAL I see many posting on the google with the same error message.Can you describe the actual reason why?The most of the goole reply was to update the version.I'd like to know the reason. Here are the versions on this Fedora Core2 PC: autoconf (GNU Autoconf) 2.59 automake (GNU automake) 1.8.3 ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) Thank you. Tosa -- Yasunari Tosa, Ph.D. Email: [EMAIL PROTECTED] NMR Ctr, Mass. General HospitalTEL: 617-726-4050 Building 149, 13th Street Charlestown, MA 02129 USA
Re: Error: am__fastdepCC does not appear in AM_CONDITIONAL
Yasunari == Yasunari Tosa [EMAIL PROTECTED] writes: Yasunari I'm getting the following error on Fedora Core 2 (it used to work but Yasunari no longer). What is it? What changed? Yasunari /usr/share/automake-1.8/am/depend2.am: am__fastdepCC does not appear Yasunari in AM_CONDITIONAL Is this the only output? Usually the explanation for that one comes right afterwards. Yasunari I see many posting on the google with the same error message.Can Yasunari you describe the actual reason Yasunari why?The most of the goole reply was to update the version. Updating won't fix this. (The answer you found was not for users of Automake 1.8). Yasunari I'd like to know the reason. For this you should post the input (configure.ac, Makefile.am...), the set of commands you typed, and their full output. http://www.chiark.greenend.org.uk/~sgtatham/bugs.html -- Alexandre Duret-Lutz
Re: AM_CONDITIONAL error
Volker == Volker Boerchers [EMAIL PROTECTED] writes:
Volker Hi,
Volker i experienced an error in witch AM_CONDITIONAL is involved. My
Volker configure.in contains the following lines
[...]
Volker AM_CONDITIONAL([SWIG_PYTHON], [test x$enable_swig_python = xyes])
Volker After updating my swig installation (www.swig.org) the
Volker following error occured (I'm using automake 1.5 and
Volker 1.7.6, autoconf 2.52 and 2.57):
[...]
Volker ./configure: line 2901: syntax error near unexpected token `(c'
Volker ./configure: line 2901: ` echo $ECHO_N (cached) $ECHO_C 6'
[...]
Volker It took a long time until I realized what went wrong: swig installs a
Volker m4 file that defines a macro 'SWIG_PYTHON' too. So actually the
Volker problem is not really an automake problem...
Thanks for the detailed report. I'm installing the following
fix on HEAD and branch-1-8.
2004-05-17 Alexandre Duret-Lutz [EMAIL PROTECTED]
* m4/cond.m4 (AM_CONDITIONAL): Double-quote diagnostic.
* tests/condd.test: Define a macro with the same name as a
conditional.
* tests/pr220.test: Modernize, and make sure the diagnostics
contains the macro name.
Report from Volker Boerchers.
Index: THANKS
===
RCS file: /cvs/automake/automake/THANKS,v
retrieving revision 1.252
diff -u -r1.252 THANKS
--- THANKS 15 May 2004 21:01:03 - 1.252
+++ THANKS 17 May 2004 20:16:12 -
@@ -252,6 +252,7 @@
Ulrich Drepper [EMAIL PROTECTED]
Václav Haisman [EMAIL PROTECTED]
Vadim Zeitlin [EMAIL PROTECTED]
+Volker Boerchers [EMAIL PROTECTED]
Werner John[EMAIL PROTECTED]
Werner Koch[EMAIL PROTECTED]
William S Fulton [EMAIL PROTECTED]
Index: m4/cond.m4
===
RCS file: /cvs/automake/automake/m4/cond.m4,v
retrieving revision 1.11
diff -u -r1.11 cond.m4
--- m4/cond.m4 24 Aug 2003 19:56:07 - 1.11
+++ m4/cond.m4 17 May 2004 20:16:19 -
@@ -1,6 +1,6 @@
# AM_CONDITIONAL -*- Autoconf -*-
-# Copyright (C) 1997, 2000, 2001, 2003 Free Software Foundation, Inc.
+# Copyright (C) 1997, 2000, 2001, 2003, 2004 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -37,6 +37,6 @@
fi
AC_CONFIG_COMMANDS_PRE(
[if test -z ${$1_TRUE} test -z ${$1_FALSE}; then
- AC_MSG_ERROR([conditional $1 was never defined.
-Usually this means the macro was only invoked conditionally.])
+ AC_MSG_ERROR([[conditional $1 was never defined.
+Usually this means the macro was only invoked conditionally.]])
fi])])
Index: tests/condd.test
===
RCS file: /cvs/automake/automake/tests/condd.test,v
retrieving revision 1.5
diff -u -r1.5 condd.test
--- tests/condd.test14 Nov 2003 21:25:58 - 1.5
+++ tests/condd.test17 May 2004 20:16:19 -
@@ -1,5 +1,5 @@
#! /bin/sh
-# Copyright (C) 2001, 2002 Free Software Foundation, Inc.
+# Copyright (C) 2001, 2002, 2004 Free Software Foundation, Inc.
#
# This file is part of GNU Automake.
#
@@ -26,7 +26,10 @@
cat configure.in 'END'
AC_PROG_CC
-AM_CONDITIONAL(COND1, false)
+dnl Define a macro with the same name as the conditional to exhibit
+dnl any underquotted bug.
+AC_DEFUN([COND1], [some'meaningless;characters`])
+AM_CONDITIONAL([COND1], false)
AC_CONFIG_FILES([foo/Makefile])
AC_CONFIG_FILES([bar/Makefile])
AC_OUTPUT
@@ -65,6 +68,7 @@
$ACLOCAL
$AUTOCONF
+grep meaningless;characters configure exit 1
$AUTOMAKE
./configure
$MAKE test
Index: tests/pr220.test
===
RCS file: /cvs/automake/automake/tests/pr220.test,v
retrieving revision 1.6
diff -u -r1.6 pr220.test
--- tests/pr220.test14 Nov 2003 21:25:59 - 1.6
+++ tests/pr220.test17 May 2004 20:16:19 -
@@ -1,5 +1,5 @@
#! /bin/sh
-# Copyright (C) 2001, 2002 Free Software Foundation, Inc.
+# Copyright (C) 2001, 2002, 2004 Free Software Foundation, Inc.
#
# This file is part of GNU Automake.
#
@@ -23,6 +23,8 @@
required=gcc
. ./defs || exit 1
+set -e
+
cat main.c EOF
int main() { return 0; }
EOF
@@ -36,9 +38,7 @@
main_SOURCES = main.c $(NEVER_DEFINED)
EOF
-cat configure.in 'EOF'
-AC_INIT(main.c)
-AM_INIT_AUTOMAKE(test_am, 1.0)
+cat configure.in 'EOF'
AC_PROG_CC
AC_ARG_ENABLE(foo,
[ --enable-foo Enable foo],
@@ -48,18 +48,17 @@
AM_CONDITIONAL(NEVER_TRUE, false)
fi
])
-AC_OUTPUT(Makefile)
+AC_OUTPUT
EOF
-touch README NEWS AUTHORS ChangeLog
-
mkdir build
-$ACLOCAL \
-$AUTOCONF \
-$AUTOMAKE -a || exit 1
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE -a
cd build
# configure should fail since we've done something invalid.
-../configure exit 1
-exit 0
Re: AM_CONDITIONAL not working properly, or I just don't understand :-(
Gary V. Vaughan wrote: Yeah, that is pretty sucky. What about installing the modules to a bogus directory (in the build tree?) and then removing that directory? if !INSTALL_LIBS pkglibdir = $(top_builddir)/_noinst install-exec-hook: @echo pruning statically linked modules rm -rf $(pkglibdir) endif This didn't work, because pkglibdir is a relative path when you are building in a separate object directory, and then libtool can't accept that path for an --rpath option. Or, if you give the modules their own Makefile.am, you might be able to redefine INSTALL and mkinstalldirs to neuter the install rules: if !INSTALL_LIBS INSTALL=: mkinstalldirs=: endif This may have worked, but automake complained about the double target definition, and I'm not sure I could guarantee that they would always be defined in the proper order. In the end, coupled with a small patch to ltmain.sh (posted to the libtool list) to allow --silent to _actually_ be --silent, I put this in the top-level Makefile.am: install-data-hook: rm -rf $(includedir) install-exec-hook: rm -rf $(pkglibdir) rm -rf $(libdir)/[lib-name] It works, and I can live with the extra install/remove activity. Most people that build this statically likely aren't going to use make install anyway, they'll just copy the static binary out of the build directory and put it wherever they want. Thanks for all your help, Gary, I appreciate the assistance. Hopefully you'll get some time to review the patches I posted to the libtool list to see if those make sense for the main distribution.
Re: AM_CONDITIONAL not working properly, or I just don't understand :-(
Kevin P. Fleming wrote: Gary V. Vaughan wrote: The only way I can think of doing this is with an install-exec-hook that removes installed libraries if INSTALL_LIBS was not set: if !INSTALL_LIBS install-exec-hook: $(MAKE) $(AM_MAKEFLAGS) uninstall-pkglibLTLIBRARIES endif But this depends on an undocumented target. Better to put the modules in a separate dir with their own Makefile.am, and call that Makefile's uninstall rule in the same way. Yuck... that means my users will see the libtool --mode=install messages and ldconfig runs for all 30+ modules, then they'll all get removed. For now I think I can live with the files getting installed and the users just knowing that they're not necessary for the application to be used. Yeah, that is pretty sucky. What about installing the modules to a bogus directory (in the build tree?) and then removing that directory? if !INSTALL_LIBS pkglibdir = $(top_builddir)/_noinst install-exec-hook: @echo pruning statically linked modules rm -rf $(pkglibdir) endif Or, if you give the modules their own Makefile.am, you might be able to redefine INSTALL and mkinstalldirs to neuter the install rules: if !INSTALL_LIBS INSTALL=: mkinstalldirs=: endif Cheers, Gary. -- ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/
Re: AM_CONDITIONAL not working properly, or I just don't understand :-(
Gary V. Vaughan wrote: Or, if you give the modules their own Makefile.am, you might be able to redefine INSTALL and mkinstalldirs to neuter the install rules: if !INSTALL_LIBS INSTALL=: mkinstalldirs=: endif That looks a lot more promising, I'll give it a try.
Re: AM_CONDITIONAL not working properly, or I just don't understand :-(
Kevin P. Fleming wrote: Gary V. Vaughan wrote: Actually, you *do* need to install the libraries even if they are linked into the program statically because libltdl looks up the pseudolibrary (.la) in the module directory to get metadata about (even preloaded) modules. Fixing this is on the TODO list, but it is quite a big job and probably won't be fixed soon. Well, now that you've seen my messages on the libtool list you know that I'm not lt_dlopen-ing the .la files at all (unless they were built shared), but rather scanning the lt_preloaded_symbols list directly and using the names I find there. So in my case I don't need the .la files when the libraries were built statically, unless there's something else that I'm missing. I'd really like my users to be able to create a static binary and be able to copy it around without needing any support files for it to function properly. Is there a way to get this AM_CONDITIONAL logic to do what I'm asking? Completely untested, but have you tried: pkglib_LTLIBRARIES = noinst_LTLIBRARIES = if INSTALL_LIBS pkglib_LTLIBRARIES += $(LIBLIST) else noinst_LTLIBRARIES += $(LIBLIST) endif ? HTH, Gary. -- ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/
Re: AM_CONDITIONAL not working properly, or I just don't understand :-(
Gary V. Vaughan wrote: Completely untested, but have you tried: pkglib_LTLIBRARIES = noinst_LTLIBRARIES = if INSTALL_LIBS pkglib_LTLIBRARIES += $(LIBLIST) else noinst_LTLIBRARIES += $(LIBLIST) endif Just tried it, same results, automake reports each module in LIBLIST as already going to be installed in 'noinst'. In fact, I even tried changing noinst_ to lib_, and now it reports already going to be installed in 'lib'.
Re: AM_CONDITIONAL not working properly, or I just don't understand :-(
Kevin P. Fleming wrote: Gary V. Vaughan wrote: Completely untested, but have you tried: pkglib_LTLIBRARIES = noinst_LTLIBRARIES = if INSTALL_LIBS pkglib_LTLIBRARIES += $(LIBLIST) else noinst_LTLIBRARIES += $(LIBLIST) endif Just tried it, same results, automake reports each module in LIBLIST as already going to be installed in 'noinst'. In fact, I even tried changing noinst_ to lib_, and now it reports already going to be installed in 'lib'. Argh! No wait, I am a dufus. A noinst_LTLIBRARY is always a convenience library, whereas a pkglib_LTLIBRARY is affected by configure --disable-shared etc. Even if you somehow got past the syntax problems, the semantics are all wrong anyhow. The only way I can think of doing this is with an install-exec-hook that removes installed libraries if INSTALL_LIBS was not set: if !INSTALL_LIBS install-exec-hook: $(MAKE) $(AM_MAKEFLAGS) uninstall-pkglibLTLIBRARIES endif But this depends on an undocumented target. Better to put the modules in a separate dir with their own Makefile.am, and call that Makefile's uninstall rule in the same way. Cheers, Gary. -- ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/
Re: AM_CONDITIONAL not working properly, or I just don't understand :-(
Gary V. Vaughan wrote: Argh! No wait, I am a dufus. A noinst_LTLIBRARY is always a convenience library, whereas a pkglib_LTLIBRARY is affected by configure --disable-shared etc. Even if you somehow got past the syntax problems, the semantics are all wrong anyhow. I'm not sure I follow all of that, but OK. The only way I can think of doing this is with an install-exec-hook that removes installed libraries if INSTALL_LIBS was not set: if !INSTALL_LIBS install-exec-hook: $(MAKE) $(AM_MAKEFLAGS) uninstall-pkglibLTLIBRARIES endif But this depends on an undocumented target. Better to put the modules in a separate dir with their own Makefile.am, and call that Makefile's uninstall rule in the same way. Yuck... that means my users will see the libtool --mode=install messages and ldconfig runs for all 30+ modules, then they'll all get removed. For now I think I can live with the files getting installed and the users just knowing that they're not necessary for the application to be used.
Re: AM_CONDITIONAL not working properly, or I just don't understand :-(
Kevin P. Fleming wrote: automake-1.7.8/autoconf-2.57/libtool-1.5 in configure.ac (after all the libtool-related macros but before AC_OUTPUT): AM_CONDITIONAL(INSTALL_LIBS, test x$enable_shared = xyes) in Makefile.am: ... LIBLIST = src/lib/libnALFS.la LIBLIST += src/handlers/alfs.la LIBLIST += src/handlers/build.la LIBLIST += src/handlers/chroot.la LIBLIST += src/handlers/configure.la LIBLIST += src/handlers/copy.la LIBLIST += src/handlers/execute.la ... (more of the same) if INSTALL_LIBS INSTALL_LIBLIST = $(LIBLIST) else INSTALL_LIBLIST = endif if !INSTALL_LIBS NOINST_LIBLIST = $(LIBLIST) else NOINST_LIBLIST = endif pkglib_LTLIBRARIES = $(INSTALL_LIBLIST) noinst_LTLIBRARIES = $(NOINST_LIBLIST) With this construction, automake complains src/handlers/alfs.la is already going to be installed in 'noinst' (for each library). All _SOURCES/_LDFLAGS/etc. variables for these libraries appear after this set of lines (I have tried them before and after, no difference). I have tried setting pkglib_LTLIBRARIES and noinst_LTLIBRARIES _directly_ inside the conditional (instead of using intermediate variables), but that didn't help. This is about the fourth attempt at constructing this logic; I need to _always_ build these libraries, but only install them if the user asked them to be built shared (for a static build, they will be subsumed into the main binary and don't need to be installed). Am I missing something? This seems to be a valid thing to try, but I can't get automake to accept it. Actually, you *do* need to install the libraries even if they are linked into the program statically because libltdl looks up the pseudolibrary (.la) in the module directory to get metadata about (even preloaded) modules. Fixing this is on the TODO list, but it is quite a big job and probably won't be fixed soon. Cheers, Gary. -- ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/
Re: AM_CONDITIONAL not working properly, or I just don't understand :-(
Gary V. Vaughan wrote: Actually, you *do* need to install the libraries even if they are linked into the program statically because libltdl looks up the pseudolibrary (.la) in the module directory to get metadata about (even preloaded) modules. Fixing this is on the TODO list, but it is quite a big job and probably won't be fixed soon. Well, now that you've seen my messages on the libtool list you know that I'm not lt_dlopen-ing the .la files at all (unless they were built shared), but rather scanning the lt_preloaded_symbols list directly and using the names I find there. So in my case I don't need the .la files when the libraries were built statically, unless there's something else that I'm missing. I'd really like my users to be able to create a static binary and be able to copy it around without needing any support files for it to function properly. Is there a way to get this AM_CONDITIONAL logic to do what I'm asking?
AM_CONDITIONAL not working properly, or I just don't understand :-(
automake-1.7.8/autoconf-2.57/libtool-1.5 in configure.ac (after all the libtool-related macros but before AC_OUTPUT): AM_CONDITIONAL(INSTALL_LIBS, test x$enable_shared = xyes) in Makefile.am: ... LIBLIST = src/lib/libnALFS.la LIBLIST += src/handlers/alfs.la LIBLIST += src/handlers/build.la LIBLIST += src/handlers/chroot.la LIBLIST += src/handlers/configure.la LIBLIST += src/handlers/copy.la LIBLIST += src/handlers/execute.la ... (more of the same) if INSTALL_LIBS INSTALL_LIBLIST = $(LIBLIST) else INSTALL_LIBLIST = endif if !INSTALL_LIBS NOINST_LIBLIST = $(LIBLIST) else NOINST_LIBLIST = endif pkglib_LTLIBRARIES = $(INSTALL_LIBLIST) noinst_LTLIBRARIES = $(NOINST_LIBLIST) With this construction, automake complains src/handlers/alfs.la is already going to be installed in 'noinst' (for each library). All _SOURCES/_LDFLAGS/etc. variables for these libraries appear after this set of lines (I have tried them before and after, no difference). I have tried setting pkglib_LTLIBRARIES and noinst_LTLIBRARIES _directly_ inside the conditional (instead of using intermediate variables), but that didn't help. This is about the fourth attempt at constructing this logic; I need to _always_ build these libraries, but only install them if the user asked them to be built shared (for a static build, they will be subsumed into the main binary and don't need to be installed). Am I missing something? This seems to be a valid thing to try, but I can't get automake to accept it.
Re: AMDEP does not appear in AM_CONDITIONAL
== Olefirenko Alexander [EMAIL PROTECTED] writes: Subj: what am i doing wrong ? executing automake i getting alot of messages: /usr/share/automake/am/lang-compile.am: AMDEP does not appear in AM_CONDITIONAL and /usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL My first guess is that you didn't run aclocal. If it isn't that then I'd need more information. For instance, what versions of auto* are you using? Tom
AMDEP does not appear in AM_CONDITIONAL
Subj: what am i doing wrong ? executing automake i getting alot of messages: /usr/share/automake/am/lang-compile.am: AMDEP does not appear in AM_CONDITIONAL and /usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
Re: Pathalogical behavior with more AM_CONDITIONAL()s?
Harlan == Harlan Stenn [EMAIL PROTECTED] writes: Harlan Again, I'm not sure why automake cares about SUBDIRS. Automake computes DIST_SUBDIRS from SUBDIRS, unless you define DIST_SUBDIRS yourself. In this case it might try to compute a value. With a large number of conditionals affecting the value of SUBDIRS, this can be expensive :-( Try setting DIST_SUBDIRS yourself and see if that solves the problem. Tom
Re: Pathalogical behavior with more AM_CONDITIONAL()s?
I've done a bit more testing.
The slowdown happens if I only modify 1 Makefile.am, and it seems to be
related to using SUBDIRS inside an AM_CONDITIONAL.
If I change the Makefile.am to use a non-SUBDIRS variable inside the
conditional autmake zips right along.
In fact, if I specify an as-yet non-existent directory to SUBDIRS I get a
warning message out of automake.
This surprised me - I thought I read that automake did not pay attention to
SUBDIRS and got its information from configure.{ac,in}.
Any ideas (while I go back to digging)?
H
Re: Pathalogical behavior with more AM_CONDITIONAL()s?
On Sat, 2002-08-03 at 09:50, Harlan Stenn wrote: I've done a bit more testing. The slowdown happens if I only modify 1 Makefile.am, and it seems to be related to using SUBDIRS inside an AM_CONDITIONAL. If I change the Makefile.am to use a non-SUBDIRS variable inside the conditional autmake zips right along. Can you post your example? The usual approach to SUBDIRS is something like: DIST_SUBDIRS = every subdir you may or may not want SUBDIRS = every compulsory subdir optionalsubdirlist1 optionalsubdirlist2 Are you doing something different? Rob
Re: Pathalogical behavior with more AM_CONDITIONAL()s?
I'll work on posting an example.
We do not use x to expand subdir lists; that forces too much info into
configure.XX.
We write either:
if FOO
SUBDIRS = a b c
endif
or
if FOO
X_DIRS = a b
endif
SUBDIRS = $(X_DIRS) d e
Again, I'm not sure why automake cares about SUBDIRS. From the .texi:
Although the code{SUBDIRS} macro can contain configure substitutions
(e.g. samp{DIRS}); Automake itself does not actually examine the
contents of this variable.
H
--
On Sat, 2002-08-03 at 09:50, Harlan Stenn wrote:
I've done a bit more testing.
The slowdown happens if I only modify 1 Makefile.am, and it seems to be
related to using SUBDIRS inside an AM_CONDITIONAL.
If I change the Makefile.am to use a non-SUBDIRS variable inside the
conditional autmake zips right along.
Can you post your example?
The usual approach to SUBDIRS is something like:
DIST_SUBDIRS = every subdir you may or may not want
SUBDIRS = every compulsory subdir optionalsubdirlist1
optionalsubdirlist2
Are you doing something different?
Rob
Re: Pathalogical behavior with more AM_CONDITIONAL()s?
On Thu, 2002-08-01 at 12:55, Harlan Stenn wrote: Here are the results of my testing: someconditionals/: automake-1.5:249.480u 2.660s 4:42.35 89.3% 0+0k 0+0io 341pf+0w automake-1.6.3: 341.810u 2.840s 6:07.24 93.8% 0+0k 0+0io 356pf+0w moreconditionals/: automake-1.5: 1134.130u 6.730s 21:27.70 88.5% 0+0k 0+0io 615pf+0w automake-1.6.3: 1199.000u 5.520s 21:45.32 92.2% 0+0k 0+0io 578pf+0w someconditionals uses 24 conditionals and has 632 Makefile.am's. moreconditionals uses 24 conditionals and has 635 Makefile.am's. It sure looks like I ran these on the same machine, and I doubt the difference is due to 3 more Makefile.am's... I should have provided more information: Automake 1.6 will run slower, but produce -much- smaller Makefile.in files. 1.5 generates (2^conditionalcount)*rules with any conditional lines. 1.6 eliminates non-impacting permutations. One example: an automake 1.5 generated Makefile.in from a 8K Makefile.am for squid (www.squid-cache.org) was 1.6 Megabytes in size. The same file generated via automake 1.6 is 40K in size. So... automake is slower to run, but generates faster makefiles. Also, you should only need to run automake infrequently over the whole project. Finally, to address your 800 second increase - you don't say whether the someconditionals results are from a subset of the moreconditionals run - assuming they are then it appears you only have 3 Makefile.am's to investigate to identify the problem file - and I'm sure that it's likely worth generating a problem report (PR) for if we can pin down the Makefile layout that causes such a large increase. I.e. what is the timing of: project root$ automake (your options) path/to/one/slow/Makefile.am. Is that still ~1000 seconds? Or is it ~200-400 seconds? Rob signature.asc Description: This is a digitally signed message part
Pathalogical behavior with more AM_CONDITIONAL()s?
I have a report that indicates that as the number of AM_CONDITIONAL()s increases, the time it takes to run automake increases Significantly. This is with automake-1.5. I'm about to dive in and look at what's going on to be sure, but just in case, does anybody have any information on what might be going on here? H
Re: Pathalogical behavior with more AM_CONDITIONAL()s?
On Thu, 2002-08-01 at 09:34, Harlan Stenn wrote: I have a report that indicates that as the number of AM_CONDITIONAL()s increases, the time it takes to run automake increases Significantly. This is with automake-1.5. I'm about to dive in and look at what's going on to be sure, but just in case, does anybody have any information on what might be going on here? It's a bug in 1.5, use 1.6. Rob signature.asc Description: This is a digitally signed message part
Re: Pathalogical behavior with more AM_CONDITIONAL()s?
THanks! H
Re: Pathalogical behavior with more AM_CONDITIONAL()s?
Here are the results of my testing: someconditionals/: automake-1.5:249.480u 2.660s 4:42.35 89.3% 0+0k 0+0io 341pf+0w automake-1.6.3: 341.810u 2.840s 6:07.24 93.8% 0+0k 0+0io 356pf+0w moreconditionals/: automake-1.5: 1134.130u 6.730s 21:27.70 88.5% 0+0k 0+0io 615pf+0w automake-1.6.3: 1199.000u 5.520s 21:45.32 92.2% 0+0k 0+0io 578pf+0w someconditionals uses 24 conditionals and has 632 Makefile.am's. moreconditionals uses 24 conditionals and has 635 Makefile.am's. It sure looks like I ran these on the same machine, and I doubt the difference is due to 3 more Makefile.am's... H
Re: AM_CONDITIONAL and += macros
[Jean-Bernard Delva] |Why is it that using '+=' inside an 'if' with automake causes errors? |Here is an example makefile.am illustrating the offending behavior: | |DUMMY = a | |if SOME_CONDITION |DUMMY += b |endif [...] |Can anyone point to me what I am doing wrong or provide a workaround? This is a known problem in Automake. You can use the following instead: if SOME_CONDITION MUMBLE = b endif DUMMY = a $(MUMBLE) -- Alexandre Duret-Lutz
AM_CONDITIONAL and += macros
Why is it that using '+=' inside an 'if' with automake causes errors?
Here is an example makefile.am illustrating the offending behavior:
DUMMY = a
if SOME_CONDITION
DUMMY += b
endif
---
This prompts automake to produce the following error:
Makefile.am:1: DUMMY was already defined in condition TRUE, which implies
condition SOME_CONDITION
DUMMY (User, where = 1) +=
{
TRUE = a
}
Since 'DUMMY' is previously unconditionally defined, I don't see a way that
it could cause an error later. Automake should allow the definition.
I know that Automake likes to collect all definitions of a particular macro
into a single definition. Couldn't Automake make an exception with '+=' in
conditionals?
Can anyone point to me what I am doing wrong or provide a workaround?
Thank you,
Jean-Bernard Delva
Re: AM_CONDITIONAL and config.status
Roger == Roger Leigh [EMAIL PROTECTED] writes: Roger in Makefile.in, is it safe to use this format in my own .in files (e.g. Roger po/POTFILES.in), or will the format used for the conditionals in .in Roger files change at a future date? What I need to do is have lines Roger conditionally included, as some are conditionally distributed. Conditionals don't work they way you seem to think they do. The @FOO_TRUE@ is rewritten to either `' (empty string) or `#' (make comment) by configure. No line is omitted from the generated Makefile. My recommendation is not to rely on the implementation of conditionals. It isn't something we have ever documented. We might actually change it at some point; for instance we might be able to get better performance from config.status if we change how conditionals are implemented. Roger if COND Roger FOO Roger BAR Roger BAZ Roger else Roger BAD Roger endif I read this example but I don't understand how it differs from what we already do. Right now you can enclose all kinds of stuff in a single conditional. What you can't do is have a conditional that starts or ends in the middle of a rule or macro definition. Roger Being able to use 'ifndef' would also be another nice addition, Roger or has this already been done (I possibly remember this being Roger mentioned). You can use `if !FOO'. Tom
Re: AM_CONDITIONAL and config.status
On Sat, Feb 02, 2002 at 11:07:15AM -0700, Tom Tromey wrote: Roger == Roger Leigh [EMAIL PROTECTED] writes: Roger in Makefile.in, is it safe to use this format in my own .in files (e.g. Roger po/POTFILES.in), or will the format used for the conditionals in .in Roger files change at a future date? What I need to do is have lines Roger conditionally included, as some are conditionally distributed. Conditionals don't work they way you seem to think they do. The @FOO_TRUE@ is rewritten to either `' (empty string) or `#' (make comment) by configure. No line is omitted from the generated Makefile. My recommendation is not to rely on the implementation of conditionals. It isn't something we have ever documented. We might actually change it at some point; for instance we might be able to get better performance from config.status if we change how conditionals are implemented. OK. Back to the drawing board ;-) I did actually get this working: @GIMP_SOURCE_FALSE@# CUPS sources @GIMP_SOURCE_FALSE@src/cups/genppd.c @GIMP_SOURCE_FALSE@# Foomatic-related sources @GIMP_SOURCE_FALSE@src/foomatic/printer_options.c == # CUPS sources src/cups/genppd.c # Foomatic-related sources src/foomatic/printer_options.c When GIMP_SOURCE is true, the lines are nicely commented out with '#'. I won't use this though ;-) Roger if COND Roger FOO Roger BAR Roger BAZ Roger else Roger BAD Roger endif I read this example but I don't understand how it differs from what we already do. Right now you can enclose all kinds of stuff in a single conditional. What you can't do is have a conditional that starts or ends in the middle of a rule or macro definition. OK. I though that in the past I could only have one line between if-endif or if-else or else-endif. That was quite some time ago though. automake.info only gives examples which use a single line. Roger Being able to use 'ifndef' would also be another nice addition, Roger or has this already been done (I possibly remember this being Roger mentioned). You can use `if !FOO'. Great. Many thanks, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: AM_CONDITIONAL and config.status
Roger == Roger Leigh [EMAIL PROTECTED] writes: Roger OK. I though that in the past I could only have one line between Roger if-endif or if-else or else-endif. It has always worked to put a lot of stuff inside the condition. Tom
Re: AM_CONDITIONAL
On Thu, 2001-12-06 at 22:02, Francis Michel wrote:
Hi all,
I am trying to use the AM_CONDITIONAL macro in order to use that Macro in
the makefile.am as follow in the configure.in
AC_MSG_CHECKING(Dummy file selection)
AC_ARG_ENABLE(dummyfile,
[ --enable-dummyfile Use debug file],
[case ${enableval} in
yes) debug=true ;;
no) debug=false ;;
*) AC_MSG_ERROR(bad value ${enableval} for --enable-debug) ;;
esac],[debug=false])
AM_CONDITIONAL(DEBUGSTRING test x$debug = xtrue)
You need a comma to separate the arguments:
AM_CONDITIONAL(DEBUGSTRING, test x$debug = xtrue)
and in the makefile.am:
if DEBUGSTRING
libfoo_a_SOURCES = dummy.c file.h
endif
but the problem is that AUTOMAKE is generating empty codes like that in the
makefile.in
if DEBUGSTRING
endif
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:
I was expecting something like that:
@DEBUGSTRING @
Can you help me out there? Is that one of the best way to select different
source code files depending on the input from the confifure script?
This is the correct approach.
--
Richard
AM_CONDITIONAL
Hi all,
I am trying to use the AM_CONDITIONAL macro in order to use that Macro in
the makefile.am as follow in the configure.in
AC_MSG_CHECKING(Dummy file selection)
AC_ARG_ENABLE(dummyfile,
[ --enable-dummyfile Use debug file],
[case ${enableval} in
yes) debug=true ;;
no) debug=false ;;
*) AC_MSG_ERROR(bad value ${enableval} for --enable-debug) ;;
esac],[debug=false])
AM_CONDITIONAL(DEBUGSTRING test x$debug = xtrue)
and in the makefile.am:
if DEBUGSTRING
libfoo_a_SOURCES = dummy.c file.h
endif
but the problem is that AUTOMAKE is generating empty codes like that in the
makefile.in
if DEBUGSTRING
endif
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:
I was expecting something like that:
@DEBUGSTRING @
Can you help me out there? Is that one of the best way to select different
source code files depending on the input from the confifure script?
Thanks a lot
Francis Michel
Re: Problems with AMDEP does not appear in AM_CONDITIONAL
On Friday 12 Oct 2001 12:41 pm, you wrote: Adam == Adam Tee [EMAIL PROTECTED] writes: Adam Hi all, Adam I've just upgraded my machine to use automake 1.5 and autoconf 2.5 Adam and am having problems with the automake and autoconf process. Adam I get the following messages: Adam /usr/share/automake/am/depend2.am: AMDEP does not appear Adam in AM_CONDITIONAL Did you run 'aclocal' before running 'automake'? You should :) Yes, I did and no joy I still get the same errors. When I do autoconf I don't get any errors but with autoreconf I do. When I run make I get the following error: make[1]: Entering directory `/home/eenajt/Simulation' Making all in src make[2]: Entering directory `/home/eenajt/Simulation/src' Makefile:207: *** missing separator. Stop. make[2]: Leaving directory `/home/eenajt/Simulation/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/eenajt/Simulation' make: *** [all] Error 2 In the Makefile the lines are .. @AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/cleanlexer.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/cleanparser.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/kbar.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/kbeat.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/knote.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/kscore.Po@am__quote@ etc ... Adam
Re: Problems with AMDEP does not appear in AM_CONDITIONAL
On Monday 15 Oct 2001 1:03 pm, you wrote: On Friday 12 Oct 2001 12:41 pm, you wrote: Adam == Adam Tee [EMAIL PROTECTED] writes: Adam Hi all, Adam I've just upgraded my machine to use automake 1.5 and autoconf 2.5 Adam and am having problems with the automake and autoconf process. Adam I get the following messages: Adam /usr/share/automake/am/depend2.am: AMDEP does not appear Adam in AM_CONDITIONAL Did you run 'aclocal' before running 'automake'? You should :) Yes, I did and no joy I still get the same errors. When I do autoconf I don't get any errors but with autoreconf I do. Apologies, I've solved the problem by deleting the stale Makefile and Makefile.in, running aclocal and autoreconf. Adam
Re: Problems with AMDEP does not appear in AM_CONDITIONAL
Have you run aclocal ? Rob - Original Message - From: Adam Tee [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 12, 2001 6:47 PM Subject: Problems with AMDEP does not appear in AM_CONDITIONAL Hi all, I've just upgraded my machine to use automake 1.5 and autoconf 2.5 and am having problems with the automake and autoconf process. I get the following messages: /usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake/am/lang-compile.am: AMDEP does not appear in AM_CONDITIONAL The toplevel makefile.am is as follows: SUBDIRS = src macros TestCode and the configure.in is dnl Process this file with autoconf to produce a configure script. AC_INIT(src/kscore.cc) AM_CONFIG_HEADER(config.h) AC_CANONICAL_SYSTEM AM_INIT_AUTOMAKE(Simulation, 0.2.6) dnl Checks for programs. #AM_ACLOCAL_INCLUDE(macros) AC_PROG_CC AC_PROG_CPP AC_PROG_CXX AM_PROG_LEX AC_PROG_YACC dnl Checks for libraries. #AM_PATH_GTK(1.2.0, [LIBS=$LIBS $GTK_LIBS # CFLAGS=$CFLAGS $GTK_CFLAGS # LDFLAGS=$LDFLAGS $GTK_LDFLAGS], # AC_MSG_ERROR(Cannot find GTK: Is gtk-config in path?)) #AM_PATH_SIGC(1.0.0,, #AC_MSG_ERROR(Cannot find libsigc++ = 1.0.0)) #AM_PATH_GTKMM(1.2.0,, # AC_MSG_ERROR(Cannot find GTK-- = 1.2.0)) #AM_PATH_GTKEXTRA(0.99.13, [LIBS=$LIBS $GTK_EXTRA_LIBS # CFLAGS=$CFLAGS $GTK_EXTRA_CFLAGS], # AC_MSG_ERROR(Cannot find GTK+Extra: Is #gtkextra-config in path?)) CXXFLAGS=$CFLAGS -g -Wall -O2 dnl Checks for header files. dnl Checks for typedefs, structures, and compiler characteristics. AC_C_CONST dnl Checks for library functions. AC_SUBST(CFLAGS) AC_SUBST(CPPFLAGS) AC_SUBST(LDFLAGS) AC_OUTPUT([Makefile src/Makefile macros/Makefile TestCode/Makefile]) Other projects that I have do not have this problem. Adam
Re: Problems with AMDEP does not appear in AM_CONDITIONAL
On Friday 12 Oct 2001 11:40 am, you wrote: Have you run aclocal ? yes, but still the error messages occur. Adam
Re: AM_CONDITIONAL
Hi, Jens Krüger [EMAIL PROTECTED] writes: Am Montag, 24. September 2001 17:08 schrieben Sie: [snip] You'll have to rewrite your configure script to generate all directories _even_ if not all the features are used. Automake tries to ensure that 'make dist' enters all directories and copies all the files. The generated package can later be configured with different settings, after all. So, all the directories and Makefiles should exist, even if they're never invoked during some builds. I had a look at the tar.gz file and I found all files needed for the distribution. I took this tarball, untar it, run configure with all possible options and packages and it works fine. That tarball is the result of the first (outer) 'make dist', which likely was run in your development tree. It was likely generated from a tree which had many/most/all of the options selected, so that all directories existed in the build tree. No wonder it has everything needed. (Even if the latest configure didn't have some options selected, your tree may have had slightly stale makefiles left over from earlier 'configure's with different options, essentially leaving you with a complete tree nonetheless.) My problem was and is that the make distcheck doesn't work. I have no possibility to run the configure script during make distcheck with any option. In my opinion the reason is based on the 'make dist' call during make distcheck. Obviously. We know one 'make dist' succeeded, since it wouldn't have created the '=build' directory otherwise. It is the inner 'make dist', the one inside the '=build' directory, that is failing. For me is there no reason to 'make dist' during 'make distcheck' or may you give me one? Well, one reason is it's automake philosophy (or cussedness, if you want it that way ;-). Basically, you want the user of the generated tarball to have all the privileges of a developer -- including the expectation that a 'make dist' in a default configured build directory will generate a complete tarball with all features. Another reason is that it is a great debugging feature. It helps you root out mistakes that you may have made w.r.t builddir, srcdir, dist, nodist, BUILT_SOURCES and other issues. It all boils down to this: the tarball generated by 'make dist' should NOT depend on what flags you passed to 'configure' in the build tree where you ran 'make dist' or 'make distcheck'. - Hari -- Raja R Harinath -- [EMAIL PROTECTED] When all else fails, read the instructions. -- Cahn's Axiom Our policy is, when in doubt, do the right thing. -- Roy L Ash
Re: AM_CONDITIONAL
Hi, Hari Am Montag, 24. September 2001 17:08 schrieben Sie: [snip] You'll have to rewrite your configure script to generate all directories _even_ if not all the features are used. Automake tries to ensure that 'make dist' enters all directories and copies all the files. The generated package can later be configured with different settings, after all. So, all the directories and Makefiles should exist, even if they're never invoked during some builds. I had a look at the tar.gz file and I found all files needed for the distribution. I took this tarball, untar it, run configure with all possible options and packages and it works fine. My problem was and is that the make distcheck doesn't work. I have no possibility to run the configure script during make distcheck with any option. In my opinion the reason is based on the 'make dist' call during make distcheck. distcheck: dist -chmod -R a+w $(distdir) /dev/null 21; rm -rf $(distdir) GZIP=$(GZIP_ENV) gunzip -c $(distdir).tar.gz | $(AMTAR) xf - chmod -R a-w $(distdir); chmod a+w $(distdir) mkdir $(distdir)/=build mkdir $(distdir)/=inst chmod a-w $(distdir) dc_install_base=`CDPATH=: cd $(distdir)/=inst pwd` \ $(MAKE) $(AM_MAKEFLAGS) distcheck-hook \ cd $(distdir)/=build \ ../configure --srcdir=.. --prefix=$$dc_install_base \ $(MAKE) $(AM_MAKEFLAGS) \ $(MAKE) $(AM_MAKEFLAGS) dvi \ $(MAKE) $(AM_MAKEFLAGS) check \ $(MAKE) $(AM_MAKEFLAGS) install \ $(MAKE) $(AM_MAKEFLAGS) installcheck \ $(MAKE) $(AM_MAKEFLAGS) uninstall \ (test `find $$dc_install_base -type f -print | wc -l` -le 1 \ || (echo Error: files left after uninstall 12; \ exit 1) ) \ $(MAKE) $(AM_MAKEFLAGS) dist \ $(MAKE) $(AM_MAKEFLAGS) distclean \ rm -f $(distdir).tar.gz \ (test `find . -type f -print | wc -l` -eq 0 \ || (echo Error: files left after distclean 12; \ exit 1) ) -chmod -R a+w $(distdir) /dev/null 21; rm -rf $(distdir) @echo $(distdir).tar.gz is ready for distribution | \ sed 'h;s/./=/g;p;x;p;x' check-am: all-am check: check-recursive For me is there no reason to 'make dist' during 'make distcheck' or may you give me one? - Hari Regards Jens -- Jens Krüger Technische Universität München ZBE FRM-II Lichtenberg-Str. 1 D-85747 Garching Tel: + 49 89 289 14 716 Fax: + 49 89 289 14 666 mailto:[EMAIL PROTECTED] http://www.frm2.tu-muenchen.de
Re: AM_CONDITIONAL
[snip] /bin/sh: cd: SoNXLakeShore: Datei oder Verzeichnis nicht gefunden Can you translate the message to English? I'm guessing that the directory doesn't exist (since that's pretty much the main reason 'cd' would complain in a build tree). Sorry, for the missing translation: /bin/sh: cd: SoNXLakeShore: File or directory not found You're right: The directory is missing, but only in the =build tree. I found it in at the following places in the tree ./src/Modules/SoNXLakeShore ./=build/openDaVE-0.1.4/src/Modules/SoNXLakeShore the first contains the source to be distribute. I think, that's is correct. the second appearance seems to be a copy of the source distribution tree and it is empty. The reason may be the missing directory in the =build/src tree. (Having a look on the Makefile I saw in the 'distcheck' target, that this target will run a 'make dist' again ???) [snip] The next step I've done was to call make manually in the =build dir and it works. I think the reason for the break of distcheck is based on the DIST_SUBDIRS macro. My question is: Is this behaviour a bug or a feature. 'make distcheck' is based on DIST_SUBDIRS since you want to test as much of your package as possible. It is a feature. The next question, is there a workaround to solve my problem? Given my guess, you should ensure that all directories and all Makefiles are created by the 'configure' scripts, even if the build will not enter those directories. The problem is, the default configure script doesn't generate all features of the package. The normal build works fine, with and without the additional feature. But in 'make distcheck' I haven't any way to say the configure script, built all. (Or is there a way to say it?) - Hari Thanks Jens
Re: AM_CONDITIONAL
On Fri, Sep 21, 2001 at 12:49:00PM -0500, Raja R Harinath wrote: Jens Krüger [EMAIL PROTECTED] writes: /bin/sh: cd: SoNXLakeShore: Datei oder Verzeichnis nicht gefunden Can you translate the message to English? /bin/sh: cd: SoNXLakeShore: File or directory not found Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/
AM_CONDITIONAL
Hi, in one of our projects I want to use the AM_CONDITIONAL macro to configure the software package. Here is the code fragment form the configure.in: my_add_modules= AC_MSG_CHECKING([for generating LakeShore Source Module]) my_build_lakeshore=no AC_ARG_WITH(lakeshore, AC_HELP_STRING([--with-lakeshore], [create LakeShore module, please read src/Modules/SoNXLakeShore/README]), [ if test $withval = yes; then my_build_lakeshore=yes AC_MSG_RESULT(yes) my_add_modules=$my_add_modules src/Modules/SoNXLakeShore else AC_MSG_RESULT(no) fi ], [AC_MSG_RESULT(no)] ) AM_CONDITIONAL(BUILD_LAKESHORE_MODULE, test $my_build_lakeshore = yes) the contents of the corresponding Makefile looks like: if BUILD_LAKESHORE_MODULE SUBDIRS= . MySource MySink MyFilter SoNXFileReader SoNXLakeShore SoNXDataGenerator \ FiNXDataSelector FiNXDimensionCutter \ SiNXTableBrowser SiNXFileWriter GL3DPlot SiNX2DPlot else SUBDIRS= . MySource MySink MyFilter SoNXFileReader SoNXDataGenerator \ FiNXDataSelector FiNXDimensionCutter \ SiNXTableBrowser SiNXFileWriter GL3DPlot SiNX2DPlot endif This code works fine if I make a normal build. Also the 'make dist' works, but the 'make distcheck' doesn't work. It breaks with these messages: /bin/sh: cd: SoNXLakeShore: Datei oder Verzeichnis nicht gefunden make[3]: *** [distdir] Error 1 make[3]: Leaving directory `/home/jkrueger/tmp/taco/frmII/nexus/openDaVE-0.1.4/=build/src/Modules' make[2]: *** [distdir] Error 1 make[2]: Leaving directory `/home/jkrueger/tmp/taco/frmII/nexus/openDaVE-0.1.4/=build/src' make[1]: *** [distdir] Error 1 make[1]: Leaving directory `/home/jkrueger/tmp/taco/frmII/nexus/openDaVE-0.1.4/=build' make: *** [distcheck] Error 2 I had a look at the Makefile and I found the following pieces of code .. .. SUBDIRS = . MySource MySink MyFilter SoNXFileReader SoNXLakeShore SoNXDataGenerator \ FiNXDataSelector FiNXDimensionCutter \ SiNXTableBrowser SiNXFileWriter GL3DPlot SiNX2DPlot #SUBDIRS = . MySource MySink MyFilter SoNXFileReader SoNXDataGenerator \ #FiNXDataSelector FiNXDimensionCutter \ #SiNXTableBrowser SiNXFileWriter GL3DPlot SiNX2DPlot .. .. DIST_SUBDIRS = . MySource MySink MyFilter SoNXFileReader SoNXLakeShore \ SoNXDataGenerator FiNXDataSelector FiNXDimensionCutter \ SiNXTableBrowser SiNXFileWriter GL3DPlot SiNX2DPlot The next step I've done was to call make manually in the =build dir and it works. I think the reason for the break of distcheck is based on the DIST_SUBDIRS macro. My question is: Is this behaviour a bug or a feature. The next question, is there a workaround to solve my problem? Thanks Jens -- Jens Krüger Technische Universität München ZBE FRM-II Lichtenberg-Str. 1 D-85747 Garching Tel: + 49 89 289 14 716 Fax: + 49 89 289 14 666 mailto:[EMAIL PROTECTED] http://www.frm2.tu-muenchen.de
Re: AM_CONDITIONAL
Jens Krüger [EMAIL PROTECTED] writes: [snip] AM_CONDITIONAL(BUILD_LAKESHORE_MODULE, test $my_build_lakeshore = yes) the contents of the corresponding Makefile looks like: if BUILD_LAKESHORE_MODULE SUBDIRS= . MySource MySink MyFilter SoNXFileReader SoNXLakeShore SoNXDataGenerator \ FiNXDataSelector FiNXDimensionCutter \ SiNXTableBrowser SiNXFileWriter GL3DPlot SiNX2DPlot else SUBDIRS= . MySource MySink MyFilter SoNXFileReader SoNXDataGenerator \ FiNXDataSelector FiNXDimensionCutter \ SiNXTableBrowser SiNXFileWriter GL3DPlot SiNX2DPlot endif This code works fine if I make a normal build. Also the 'make dist' works, but the 'make distcheck' doesn't work. It breaks with these messages: /bin/sh: cd: SoNXLakeShore: Datei oder Verzeichnis nicht gefunden Can you translate the message to English? I'm guessing that the directory doesn't exist (since that's pretty much the main reason 'cd' would complain in a build tree). [snip] The next step I've done was to call make manually in the =build dir and it works. I think the reason for the break of distcheck is based on the DIST_SUBDIRS macro. My question is: Is this behaviour a bug or a feature. 'make distcheck' is based on DIST_SUBDIRS since you want to test as much of your package as possible. It is a feature. The next question, is there a workaround to solve my problem? Given my guess, you should ensure that all directories and all Makefiles are created by the 'configure' scripts, even if the build will not enter those directories. - Hari -- Raja R Harinath -- [EMAIL PROTECTED] When all else fails, read the instructions. -- Cahn's Axiom Our policy is, when in doubt, do the right thing. -- Roy L Ash
AM_CONDITIONAL
Hello,
I'm new to this list and to automake. I followed the instructions in
the manual on how to do conditionals, but I'm having a problem.
In the Makefile.am I have:
if ARCI
EXTRA_LTLIBRARIES= libsensorTB16.la libsensorTB23.la
libsensorTB29.la
lib_LTLIBRARIES = libsensorARCI.la
else if APB
lib_LTLIBRARIES=libsensorTB16.la libsensorTB23.la
libsensorTB29.la
EXTRA_LTLIBRARIES = libsensorARCI.la
else
lib_LTLIBRARIES=libsensorTB16.la libsensorTB23.la
libsensorTB29.la libsensorARCI.la
endif
In configure.in I have:
AC_MSG_CHECKING(for build type)
AC_ARG_WITH(build,
[ --with-build=type specify build type: apb or arci],
[
AC_MSG_RESULT($withval)
if test "$withval" = 'apb' ; then
BLD="apb"
else
if test "$withval" = 'arci' ; then
BLD="arci"
else
AC_MSG_ERROR("Build type unrecognized")
fi
fi
], [
AC_MSG_RESULT(no)
AC_MSG_ERROR("Must specify build type: apb or arci")
])
AM_CONDITIONAL(ARCI,[test x"$BLD" = xarci])
AM_CONDITIONAL(APB,[test x"$BLD" = xapb])
from automake I get:
Makefile.am:5: ARCI does not appear in AM_CONDITIONAL
Makefile.am:9: lib_LTLIBRARIES multiply defined in condition
Makefile.am:10: EXTRA_LTLIBRARIES multiply defined in condition
When I try to add AM_CONDITIONAL to configure.in I get:
configure: syntax error at line 3497: `AM_CONDITIONAL' unexpected
Any suggestions?
Thanks,
Anna Niemtschk
begin:vcard
n:;
tel;work:(512)835-3142
x-mozilla-html:FALSE
org:The University of Texas at Austin;Applied Research Labs
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
note;quoted-printable:May God stand between you =0D=0Aand harm in all the empty places=0D=0Awhere you must walk. =0D=0A--Old Egyptian Blessing
fn:Anna Niemtschk
end:vcard
Re: AM_CONDITIONAL
Hello, Anna! AM_CONDITIONAL(ARCI,[test x"$BLD" = xarci]) AM_CONDITIONAL(APB,[test x"$BLD" = xapb]) from automake I get: Makefile.am:5: ARCI does not appear in AM_CONDITIONAL That's weird. Could you please send me (not to the list!) your configure.in? Regards, Pavel Roskin
