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
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
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
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
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
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
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
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.