libfoo.la is already going to be installed in lib.
This appears to be aproblem with libtool+automake; if I use a static library (no libtool) I don't see this problem. Is there a workaround/bugfix? This problem means that autoreconf bails with an error... (Yes, I've tried a couple of other choices, like using a variable in the conditionals and setting lib_LTLIBRARIES = $(foo).) --Makefile.am: AUTOMAKE_OPTIONS = foreign if FOO_A lib_LTLIBRARIES=libfoo.la endif if FOO_B lib_LTLIBRARIES=libfoo.la endif libfoo_la_SOURCES = foo.c --configure.ac: AC_INIT AC_CONFIG_SRCDIR([Makefile.am]) AM_INIT_AUTOMAKE(foo, 1.0) AC_PROG_CC AC_PROG_LIBTOOL FOO=a AM_CONDITIONAL(FOO_A, test x$FOO = xa) AM_CONDITIONAL(FOO_B, test x$FOO = xb) AC_CONFIG_FILES(Makefile) AC_OUTPUT
CVS automake, -Wwarnings, and AM_PROG_LIBTOOL
If I enable warnings with CVS automake and run autoreconf, AM_PROG_LIBTOOL generates a warning: configure.in:64: warning: The macro `AC_FD_CC' is obsolete. You should run autoupdate. Line 64 is AM_PROG_LIBTOOL. Or am I missing something? H
Should ylwap get installed by autoreconf -i?
I'm not sure if this is a bug or a feature. The documentation says: The `ylwrap' program is distributed with Automake. It should appear in the directory specified by `AC_CONFIG_AUX_DIR' (*note Finding `configure' Input: (autoconf)Input.), or the current directory if that macro is not used in `configure.in'. What does should mean in that sentence? I'm asking because we have discovered that (since automake/1.5, at least) ylwrap is not being installed by either automake --add-missing or autoreconf --install. In case it matters, we are using AC_CONFIG_AUX_DIR(config) . H
Subdirectory problem
Hi, I decided to switch a project I'm working on to use a single top level Makefile, instead of using recursive make. One thing I noticed was that if you have this in your Makefile.am: bin_PROGRAMS = a/a a_a_SOURCES = a/a.c Then a.o gets built in $(top_builddir), not $(top_builddir)/a as I would have expected, and as it would be using recursive make. Is this a bug, or am I misunderstanding something? Peter Gavin
Re: How build C++ header with m4 and install them - no program
Marc == Marc Waeckerlin [EMAIL PROTECTED] writes: Marc I have a little C++ signal-slot library, that consists of only Marc two C++ header files. The automake script should do the Marc following: Marc [ ... ] Marc How do I write the makefile.am? nobase_include_HEADERS = sig/functor.hxx sig/sigslot.hxx SUFFIXES = .m4 sig/functor.hxx: sig/functor.hxx.m4 m4 $(srcdir)/sig/functor.hxx.m4 sig/functor.m4 [ also for sigslot.hxx ] This isn't perfect since you must arrange for mkdir sig somehow. Automake doesn't do this automatically in this situation. Marc- How to tell that the *.hxx are targets that must be cleared? CLEANFILES = $(nobase_include_HEADERS) Marc- How to tell that the *.hxx are derieved from the *.m4? As above. Suffix rules don't work if the files are in subdirs. Suffix rule support in automake could use some enhancements. Marc Is there a check or macros for invoking m4 in autoconf, automake? Not that I know of. Tom
Re: strange error message
Nicholas == Nicholas Kidd [EMAIL PROTECTED] writes: Nicholas I was wondering if someone knew what these error message meant: Nicholas Makefile:483: warning: overriding commands for target Nicholas `engine/cpp/engine.o' Nicholas Makefile:362: warning: ignoring old commands for target Nicholas `engine/cpp/engine.o' This means that this file has two different rules to generate it in the Makefile. We can't tell exactly why without more information. What version of automake are you using? What is your Makefile.am? Tom
Re: Subdirectory problem
On Sat, Sep 21, 2002 at 06:36:10PM -0400, Peter Gavin wrote: Hi, I decided to switch a project I'm working on to use a single top level Makefile, instead of using recursive make. One thing I noticed was that if you have this in your Makefile.am: bin_PROGRAMS = a/a a_a_SOURCES = a/a.c Then a.o gets built in $(top_builddir), not $(top_builddir)/a as I would have expected, and as it would be using recursive make. Is this a bug, or am I misunderstanding something? Peter Gavin Oh, btw, I'm using automake-1.6.3. And one other problem... My project has a library and an executable that links to that library. So, e.g. my project's Makefile.am is something like this: lib_LTLIBRARIES = liba/liba.la liba_liba_la_SOURCES = liba/liba.c bin_PROGRAMS = a/a a_a_SOURCES = a a_a_LDADD = $(top_builddir)/liba/liba.la So, liba/liba.c and a/a.c get compiled to liba.o and a.o respectively. liba.la gets created as liba/liba.la, and the real .so and .a files are put in liba/.libs, as expected. But, make distclean fails to remove liba/.libs or any of the files within, apparently because make distclean does rm -f liba/liba.la instead of using libtool to remove it. Pete
Re: How build C++ header with m4 and install them - no program
Marc Waeckerlin [EMAIL PROTECTED] writes: Is there a check or macros for invoking m4 in autoconf, automake? We use a couple in GMP, just searching for an m4 with enough features (eval, $#), and checking for a gremlin in m4wrap that afflicts a few systems.
