builddir vs. srcdir
Hi. I'm currently massaging my `Makefile.am's to allow building in a separate directory. However, I have a problem which I cannot find how to solve. I have a few source (`.c' and `.h') files which are generated at build time from another source using a custom utility. When the build directory is the same as the source directory, everything is fine. However, with separate build directory things go hairy, because the generated sources are placed into the build directory, while `make' looks for them in the source directory. Automake pseudo-code looks like this: noinst_LIBRARIES = libfoo.a BUILT_SOURCES = \ foo.c \ \ foo.h PARSE_LIST = ./parse-list$(EXEEXT) foo.c foo.h : $(srcdir)/foo.list $(PARSE_LIST) $(PARSE_LIST) $(srcdir)/foo.list foo.h foo.c\ || (rm -f foo.c foo.h ; exit 1) libfoo_a_SOURCES = ... nodist_libfoo_a_SOURCES = $(BUILT_SOURCES) plus the lines to build the parser utility and other non-important stuff. Paul
Automake feature request
I approached the Libtool maintainers with this request, who convinced me that Automake was the right place to implement this. I would like Automake-generated Makefiles to pass --quiet to libtool when make is invoked with -s. At present, even when compiling with make -s, libtool echoes the commands it is compiling/linking with. Libtool can know how make is invoked, by MAKEFLAGS, but it really ought not to be doing this, as libtool might not be invoked via make. Automake's generated Makefiles sit in between and I believe this is the right place to glue in the logic. Comments? Ben signature.asc Description: OpenPGP digital signature
Re: builddir vs. srcdir
Hello, On Tue, Mar 08, 2005 at 11:56:56PM +0200, Paul Pogonyshev wrote: > because the generated sources are placed into the build directory, > while `make' looks for them in the source directory. generally, make should look for them in both places. Let me point out several problems: > BUILT_SOURCES = \ > foo.c \ > foo.h You probably need only the foo.h file here. > foo.c foo.h : $(srcdir)/foo.list $(PARSE_LIST) > $(PARSE_LIST) $(srcdir)/foo.list foo.h foo.c\ > || (rm -f foo.c foo.h ; exit 1) This rule can break with parallel make. For details about these two issues, see http://sources.redhat.com/automake/automake.html#Built-sources-example You can solve the second issue by adding the dependency: foo.c: foo.h Yet it might be more readable if you change your generator so that it would generate .c and .h in separate runs. And I'd like to suggest that you use SUFFIXES to handle the .list source. Please look at the following example: noinst_LTLIBRARIES = libgoffice-utils.la libgoffice_utils_la_SOURCES = \ go-marshalers.list \ go-font.c CLEANFILES =\ go-marshalers.h \ go-marshalers.c # A hint is needed to build the header first: BUILT_SOURCES = go-marshalers.h GENMARSHAL_COMMAND = $(GLIB_GENMARSHAL) --prefix=go_ SUFFIXES = .list .list.h: $(GLIB_GENMARSHAL) $(GENMARSHAL_COMMAND) --header $< >$@ .list.c: $(GLIB_GENMARSHAL) (echo '/* This file has been automatically generated. Do not edit. */' && \ echo '#include "$*.h"' && \ $(GENMARSHAL_COMMAND) --body $< ) >$@ This works with current Automake 1.9.5 (which I recommend), as well as an ancient 1.7.x version. HTH, Stepan Kasal
Re: adding subdirectories
On Mon, Mar 07, 2005 at 04:49:11PM +0100, Stepan Kasal wrote: > for each AC_SUBSTed variable, automake adds a line like > > ZZZ_LIBS = @ZZZ_LIBS@ > > so there is generally no need to use the @...@ notation in Makefile.am. Yes, thanks for the info! I've replaced all @...@ references with $(...). With kind regards, Baurzhan.
Re: adding subdirectories
On Mon, Mar 07, 2005 at 02:27:25PM +0100, Nicolas Joly wrote: > > 2. More importantly, I can't build the project any more: make > >immediately dives into testsuite/, files under which require > >libzzz.la, which is going to be built later. If I "make libzzz.la > >all", everything works fine. > > Use `SUBDIRS = . testsuite' in your Makefile.am, this will force the > directory processing order. An interesting trick, thanks for the suggestion! I quickly tested it yesterday, and it worked. However, today I've tried make -j3, and it failed, since make builds libzzz.la and the test1 in parallel, and building the library takes longer than building the test program. So, what I actually want is that automake generates dependencies for libraries in LDADD. I've tried adding "test1_DEPENDENCIES = $(top_builddir)/libzzz.la" to Makefile.am, but this didn't work (make said "*** No rule to make target `../../libzzz.la', needed by `test1'. Stop."), which is normal, since that makefile doesn't know anything about the library. So, this has to be solved from the top-level makefile. How can I specify e.g. that all targets in testsuite depend on libzzz.la? With kind regards, Baurzhan.
Re: adding subdirectories
On Mon, Mar 07, 2005 at 02:27:25PM +0100, Nicolas Joly wrote: > > AUTOMAKE_OPTIONS = dejagnu > > bin_PROGRAMS = zzz > > noinst_PROGRAMS = test1 test2 test3 > > noinst_LTLIBRARIES = libzzz.la > > zzz_SOURCES = zzz.c > > libzzz_la_SOURCES = a/a.c b/b.c > > AM_CFLAGS = -g -Wall -std=c99 -I$(top_srcdir)/include @ZZZ_CFLAGS@ > > -DSYSCONFDIR=\"@[EMAIL PROTECTED]" > > zzz_LDADD = @ZZZ_LIBS@ $(top_builddir)/libzzz.la > > test1_LDADD = @ZZZ_LIBS@ $(top_builddir)/libzzz.la > > test2_LDADD = @ZZZ_LIBS@ $(top_builddir)/libzzz.la > > test3_LDADD = @ZZZ_LIBS@ $(top_builddir)/libzzz.la I haven't found a way of specifying dependencies between different makefiles. I've reverted to a single Makefile.am and specified the dependencies manually, like this: zzz_DEPENDENCIES = libzzz.la test1_DEPENDENCIES = libzzz.la test2_DEPENDENCIES = libzzz.la test3_DEPENDENCIES = libzzz.la This works, but clutters Makefile.am (I'm planning to have at least hundreds of tests). Is there a way to specify that binaries should depend on the libraries they are linked with (i.e., that a general LDADD implies general DEPENDENCIES or generates the respective dependencies automatically)? The goal is to be able to build unit tests via specifying them in noinst_PROGRAMS only (AM_CFLAGS and LDADD are AC_SUBST'ed). Thanks in advance, Baurzhan.
AC_DEFINE_DIR in autoconf (was: Re: SYSCONFDIR: config.h vs. AM_CFLAGS)
[Taking the discussion to the autoconf list.] On Mon, Mar 07, 2005 at 09:57:31AM -0400, Leonardo Boiko wrote: > Isn't config.h created at configure time? AFAIK directory installation > variables should only be defined at make time. See > ``info Autoconf "Installation Directory Variables"''. I had read these sections before posting, but I understand them only now :) . What I don't understand is why the manual states that AC_DEFINE_DIR does not conform with GNU codings standards. If I define DATADIR in CPPFLAGS, it is hard-coded into the binary, and the user can override the prefix during make install. This behaviour is not declared non-conforming. If I define DATADIR in config.h, it is hard-coded into the binary, and the user can override the prefix during make install. The section 7.2.4 of GCS states that prefix should be redefinable by installers via make or configure. I couldn't find a place where it requires that "make prefix=xxx" should cause hard-coding of the new prefix, so I fail to see why AC_DEFINE_DIR is declared non-compliant. I would really like that AC_DEFINE_DIR is included in automake, thus making config.h the single compilation configuration file. Comments? > Maybe you could use instead a dedicated header, created through the > Makefile. See ``info Autoconf "Defining Directories"''.[2] I would ideally prefer to have a single configuration file, namely, config.h. From my (naive autoconf user's) perspective, there is no difference between PACKAGE_VERSION and DATADIR. With kind regards, Baurzhan.
Re: builddir vs. srcdir
Stepan Kasal wrote: > Hello, > > On Tue, Mar 08, 2005 at 11:56:56PM +0200, Paul Pogonyshev wrote: > > because the generated sources are placed into the build directory, > > while `make' looks for them in the source directory. > > generally, make should look for them in both places. Yes, and it does look in both places, but the dependencies make `foo.o' depend on `$(srcdir)/foo.c', so `make' tells it has no rule to build the latter. How do I make dependencies tell `foo.o' depends on `$(builddir)/foo.c' instead? > Let me point out several problems: > > BUILT_SOURCES = \ > > foo.c \ > > foo.h > > You probably need only the foo.h file here. Right. > > foo.c foo.h : $(srcdir)/foo.list $(PARSE_LIST) > > $(PARSE_LIST) $(srcdir)/foo.list foo.h foo.c\ > > > > || (rm -f foo.c foo.h ; exit 1) > > This rule can break with parallel make. > > For details about these two issues, see > http://sources.redhat.com/automake/automake.html#Built-sources-example > > You can solve the second issue by adding the dependency: > foo.c: foo.h > > Yet it might be more readable if you change your generator so that it > would generate .c and .h in separate runs. I'd hate to hack the generator for such a goal. I'll better stick with the `foo.c: foo.h' solution. Maybe generating two files at once is non- standard, but it seems natural, since they are so closely related and are built from one source file, and that's the way it works already. > And I'd like to suggest that you use SUFFIXES to handle the .list > source. Please look at the following example: Well, my generator is even more non-standard, since I need to pass an additional command-line parameter sometimes. So, `SUFFIXES' are not an option, although I agree it would have been nicer to use them. Paul
Re: AC_DEFINE_DIR in autoconf
Baurjan Ismagulov wrote: I would ideally prefer to have a single configuration file, namely, config.h. I don't want to talk about the GNU conformance because I have the same doubts as you :) but as for having a single file, I often have to do lots of tests of things defined in config.h, so I usually need another header anyway. If config.h has a "#define HAVE_FOO", I'll need to do "#ifndef HAVE_FOO ". I put all these tests in a "system.h" file. In your case, I'd make "system.h" include "" and "datadir.h". -- Leonardo Boiko signature.asc Description: OpenPGP digital signature
Re: AC_DEFINE_DIR in autoconf
On Wed, Mar 09, 2005 at 05:55:48PM -0400, Leonardo Boiko wrote: > I don't want to talk about the GNU conformance because I have the same > doubts as you :) but as for having a single file, I often have to > do lots of tests of things defined in config.h, so I usually need > another header anyway. If config.h has a "#define HAVE_FOO", I'll need > to do "#ifndef HAVE_FOO ". I put > all these tests in a "system.h" file. In your case, I'd make "system.h" > include "" and "datadir.h". Ok, I'll look if it's worth the trouble... Thanks for all suggestions! With kind regards, Baurzhan.
Re: adding subdirectories
>>> "Baurjan" == Baurjan Ismagulov <[EMAIL PROTECTED]> writes: Baurjan> On Mon, Mar 07, 2005 at 02:27:25PM +0100, Nicolas Joly wrote: >> > AUTOMAKE_OPTIONS = dejagnu >> > bin_PROGRAMS = zzz >> > noinst_PROGRAMS = test1 test2 test3 >> > noinst_LTLIBRARIES = libzzz.la >> > zzz_SOURCES = zzz.c >> > libzzz_la_SOURCES = a/a.c b/b.c >> > AM_CFLAGS = -g -Wall -std=c99 -I$(top_srcdir)/include @ZZZ_CFLAGS@ >> > -DSYSCONFDIR=\"@[EMAIL PROTECTED]" >> > zzz_LDADD = @ZZZ_LIBS@ $(top_builddir)/libzzz.la >> > test1_LDADD = @ZZZ_LIBS@ $(top_builddir)/libzzz.la >> > test2_LDADD = @ZZZ_LIBS@ $(top_builddir)/libzzz.la >> > test3_LDADD = @ZZZ_LIBS@ $(top_builddir)/libzzz.la 1) since libzzz.la is referenced as `libzzz.la' in noinst_LTLIBRARIES, a) it is built built is the current directory b) you should reference it as `libzzz.la' anywhere else in the same Makefile (BSD Make is not able to guess that ./libzzz.la is the same file as libzzz.la, for instance). So all these $(top_builddir)/libzzz.la really should be libzzz.la. 2) the `LDADD' variable contains the default definition for all *_LDADD variables. So linking all you programs against the same libraries requires only one line (LDADD = $(ZZZ_LIBS) libzzz.la) Baurjan> I haven't found a way of specifying dependencies between different Baurjan> makefiles. I've reverted to a single Makefile.am and specified the Baurjan> dependencies manually, like this: Baurjan> zzz_DEPENDENCIES = libzzz.la Baurjan> test1_DEPENDENCIES = libzzz.la Baurjan> test2_DEPENDENCIES = libzzz.la Baurjan> test3_DEPENDENCIES = libzzz.la When you write zzz_LDADD = $(ZZZ_LIBS) libzzz.la automake generates zzz_DEPENDENCIES = libzzz.la automatically. Baurjan> Is there a way to specify that binaries should depend Baurjan> on the libraries they are linked with (i.e., that a Baurjan> general LDADD implies general DEPENDENCIES or Baurjan> generates the respective dependencies automatically)? This is what happens. -- Alexandre Duret-Lutz
Re: builddir vs. srcdir
>>> "Paul" == Paul Pogonyshev <[EMAIL PROTECTED]> writes: Paul> Stepan Kasal wrote: >> Hello, >> >> On Tue, Mar 08, 2005 at 11:56:56PM +0200, Paul Pogonyshev wrote: >> > because the generated sources are placed into the build directory, >> > while `make' looks for them in the source directory. >> >> generally, make should look for them in both places. Paul> Yes, and it does look in both places, but the dependencies make `foo.o' Paul> depend on `$(srcdir)/foo.c', This could happen if this location was the right one in the past, and building foo.c in the build directory is a recent change. In that case the dependency file still have the old info. The way to erase dependency info is distclean: make -k distclean; ./configure; make -- Alexandre Duret-Lutz
