Re: Feature request
Le 23 sept. 08 à 23:08, Ralf Wildenhues a écrit : Hi Akim, Hi Ralf! * Akim Demaille wrote on Tue, Sep 23, 2008 at 04:35:50PM CEST: I'm slowly getting rid of my recursive Makefiles. Instead I have one local.mk per directory, and a few Makefile.ams that include them. Of course I have to prefix all my file names with the name of the directory, and I find that this explicit name is actually clutter. I don't think automake can be educated to guess by itself where to prepend the directory name, I agree that that would be too much magic, and probably too fragile. Yet that would be wonderful to have a means to tell Automake to make a single large Makefile instead of several ones. It can't do it all by itself, but if the Makefile.ams are sufficiently complete, it might be doable. Then the magic from Automake would be mostly to give a local and magic value to $(srcdir) $(builddir) etc. Which is basically what I'm suggesting here. yet it would be quite easier to have some variable that would expand to the prefix of the included file. Sounds like a reasonable wish. Let's look at an example. Probably you want a set of these: - one for the full relative path to the Makefile.am (%AMSUB%=foo/bar) (this one would be '.' if in the same directory) - likewise, including final slash (%AMPREFIX%=foo/bar/) (needed if the prefix can also be empty, to avoid './') - likewise, but flattened (%AMFLAT%=foo_bar_) - reverse of the full relative path (%AMREV%=../..) - maybe a set of these for only the path to the next included snippet? - would that be enough for all use cases? Yes, I think it would. Another option would be to provide local variables, scoped to the current local.mk and the one it includes, with traditional scoping. Automake itself could rely on this to define these magic variables. Example: --- Makefile.am --- include foo/local1.mk --- foo/local1.mk --- # Yes, it is very ugly and IMNSHO an automake misfeature that # the next line requires an %AMPREFIX%. Unfortunately, fixing # it would break user's scripts. include %AMPREFIX%bar/local2.mk Bummer :( --- foo/bar/local2.mk --- FOO_FLAGS = -I%AMREV%/include I would not promote too much AMREV. In my experience it's always clearer and safer to start from top_src/builddir rather than trying to play these tricks. bin_PROGRAMS = %AMPREFIX%bar %AMFLAT%bar_SOURCES = %AMPREFIX%bar.c %AMPREFIX%baz.c Yuck. That's already quite ugly, nothing I'd want to edit regularly. We could use even shorter abbreviations. Suggestions? For a start, if you really do not want to use the $() syntax, maybe we can move to something like %()? Or $[]? Provided we give a means to the user to write '$[' when she means it, I'm not sure that would be really such a problem to infringe on the Make name space. %FOO% is hard to read when there are many, braces are much easier to read. Also, we can stick to $(), but within Automake's namespace. Say $ (AMPREFIX) instead of %AMPREFIX%. And yes, if the resulting snippets are to be usable also from the same directory, then most usages need AMPREFIX and not AMSUB, if non-GNU make should work well, too. This is probably not easy on users. Agreed. Thanks for the good work! Thanks for the feedback, and the suggestion. [1] whatever the name, but not too long. Maybe a symbol, $/ for instance. I'd really hate to invade make's namespace. They may come up with this really cool new makefile variable, and we can't use it then. :-/ Unless we can spell it (read escape) differently.
Re: Kdevelop + automake problems
On Wednesday 24 September 2008 06:54:50 Ralf Wildenhues wrote: * Bryan Bennetts wrote on Tue, Sep 23, 2008 at 05:01:21PM CEST: If I do include the aclocal.m4, the configure *still* kicks off automake because of a subdirs file that is created by configure being newer than the configure.in, which the Makefile.in is dependant on. What exactly do you mean by a subdirs file? Hmm, seems it *might* be a KDE-ism. From the Makefile.am : snip $(top_srcdir)/configure.in: configure.in.in $(top_srcdir)/subdirs cd $(top_srcdir) $(MAKE) -f admin/Makefile.common configure.in ; $(top_srcdir)/subdirs: cd $(top_srcdir) $(MAKE) -f admin/Makefile.common subdirs $(top_srcdir)/acinclude.m4: $(top_srcdir)/admin/acinclude.m4.in $(top_srcdir)/admin/libtool.m4.in @cd $(top_srcdir) cat admin/acinclude.m4.in admin/libtool.m4.in acinclude.m4 /snip If that subdirs file really is updated by configure, then it's time to file a bug report against whoever wrote those lines. Input files to configure should not be modified by configure. Hmm, running configure without subdirs existing does create it - but I haven't managed to work out *where* it does this, yet. It makes me think that both the aclocal.m4 and subdirs should be included in the distribution by KDevelop as default. Further, as already stated, all files necessary to rebuild configure (in this case at least: the subdirs file, configure.in.in, admin/Makefile.common (why does configure.in not depend on it BTW?), admin/*.m4 (same question)). Not a clue, this is all new to me. Is a fairly impenetrable make target which uses cvs.sh to create a file 'subdirs' which lists the (you gonna love this) sub-directories in the project - dunno why. Probably to avoid having to write AC_CONFIG_FILES([subdir/Makefile]) for each subdir. I've attached the tarball of the project so you can peruse at you leisure - it'll be quicker than me quoting bits and pieces randomly. That attachment got lost on the way, so if there are further important bits, it may help to put the package online somewhere and post a link (use a pastebin if you don't have web space). I've put the tarballs here : http://www.bbennetts.pwp.blueyonder.co.uk/ The first is the make dist version that works and the second the evil KDevelop version, there's also links to the missing aclocal.m4 and subdirs files. I've posted on the KDevelop forums but there's been little interest, I'm thinking I'll just use make dist from now on, and be damned. Thanks for you help, Bryan.
Re: Feature request
Ralf Wildenhues [EMAIL PROTECTED] writes: * Akim Demaille wrote on Tue, Sep 23, 2008 at 04:35:50PM CEST: I'm slowly getting rid of my recursive Makefiles. Instead I have one local.mk per directory, and a few Makefile.ams that include them. Of course I have to prefix all my file names with the name of the directory, and I find that this explicit name is actually clutter. I don't think automake can be educated to guess by itself where to prepend the directory name, I would also find a feature to reduce this clutter useful. GNU PSPP in particular does not use recursive makefiles and has lots of directories. (Although PSPP uses the file name automake.mk instead of local.mk.) I don't have better syntax suggestions than yours or Akim's (unfortunately). Except: I'd really hate to invade make's namespace. They may come up with this really cool new makefile variable, and we can't use it then. :-/ I wonder whether this is a real issue, because Automake cannot really use new GNU make extensions anyhow (right?) because it writes out portable Makefiles. And it seems unlikely that POSIX would start inventing new Makefile syntax either. -- Unix... is not so much a product as it is a painstakingly compiled oral history of the hacker subculture. --Neal Stephenson
multiple targets, different build options
(I'm an autotools newbie.)
What is the automake sanctioned way of providing different top-level
make targets, that build my application with different options?
For example, say I want to build foo_nondebug, and foo_debug, and
(luckily) all of my application code resides in the subdirectories of
the top level directory containing the top-level Makefile.
Obviously, if I invoke make from one of these targets, I can use the
traditional trick of passing a sub-make arguments (like FOO_DEBUG=-g
or FOO_DEBUG=empty).
Indeed, this is the only way I know how to switching parameters to a
submake at build time. But it would seem inappropriate, and tricky,
to intercept invoking make, in every place it is used by automake,
unless that is something that is officially supported (I gather not
based on earlier commentary). Is there any other way to achieve this
(changing various command line tool options passed to submakes as a
function of the chosen build target)?
I only have two ideas about how to achieve this that seem as if they
could work acceptably.
Option 1 is to have the top level make targets reinvoke top-level
make, with the desired options. For some reason, this doesn't seem
to work (seems to be something to do with the targets: either I'm
messing up something automake is doing, because I have my ancillary
self-calling make targets, or the make target provided to the second
recursive make is wrong (seems like I must use all to get anything to
work, but that doesn't seem to work, generally concluding that there
is nothing that needs to be built).
Outline of scheme:
foo_nondebug:
${MAKE} ${AM_MAKEFLAGS} all FOO_DEBUG=
foo_debug:
${MAKE} ${AM_MAKEFLAGS} all FOO_DEBUG=-g
The second option is to simply have independent top-level
Makefile.ams (with different names, probably) that build the
different executables (all beneficially named differently) after
setting up the desired options straightforwardly. For example:
FooMakefile.am:
FOO_DEBUG=
FooDebugMakefile.am:
FOO_DEBUG=-g
Some sub-Makefile.am:
foo_CFLAGS = ${FOO_DEBUG}
foo_LDFLAGS = ${FOO_DEBUG}
I fear either approach will potentially be problematic WRT correctly
rebuilding when options that affect source compilation change (unless
I can find a way to ensure all build intermediates (.o files) are
stored in a location tied to the top-level make target). The second
approach seems more likely to work (in some basic sense) but is a bit
clumsier for the maintainer. But I am sure automake must provide
some way of achieving functionality equivalent to this essential make
capability - no?
Ideas and input greatly appreciated. If I missed relevant material
in the docs, please point me to it, and I'll read some more. Thanks,
-jar
Re: multiple targets, different build options
Peter, On Sep 24, 2008, at 10:24 AM, Peter Johansson wrote: John Richetta wrote: (I'm an autotools newbie.) What is the automake sanctioned way of providing different top- level make targets, that build my application with different options? For example, say I want to build foo_nondebug, and foo_debug, and (luckily) all of my application code resides in the subdirectories of the top level directory containing the top-level Makefile. Obviously, if I invoke make from one of these targets, I can use the traditional trick of passing a sub-make arguments (like FOO_DEBUG=-g or FOO_DEBUG=empty). I use the following snippet in one my projects: AC_ARG_ENABLE(debug, [AS_HELP_STRING([--enable-debug],[turn on debug options and code])], [SD_CXXFLAGS=$SD_CXXFLAGS -g -O], [SD_CPPFLAGS=-DNDEBUG SD_CXXFLAGS=$SD_CXXFLAGS -O3]) # Export flags AC_SUBST([SVNDIGEST_CPPFLAGS], $SD_CPPFLAGS) AC_SUBST([SVNDIGEST_CXXFLAGS], $SD_CXXFLAGS) and then in each Makefile.am: AM_CPPFLAGS = $(SVNDIGEST_CPPFLAGS) AM_CXXFLAGS = $(SVNDIGEST_CXXFLAGS) This is definitely better than no solution. I was aware that something like this was possible, but I appreciate seeing the details. This will add a switch to configure so we can call ./configure -- enable-debug when we wanna build in debug mode, and else ignore the option. Their is no dependency, so if I switch between the modes in the same builddir I need to issue make clean. This is certainly workable, but I would prefer to avoid using the (lengthy) configure process to change simple things like compile options for this application. If it's not possible, I guess we'll have to live with that. Obviously, side-stepping any issues arising from stale .o files is a good thing, to put it mildly. It would be best if somehow I could ensure that make clean was always run after a reconfigure. I'm guessing I can probably figure out how to do that - build in some dependency on config.status's timestamp, perhaps? Hope this helps. Cheers, Thanks for your helpful reply. -jar
Re: multiple targets, different build options
John Richetta wrote: (I'm an autotools newbie.) What is the automake sanctioned way of providing different top-level make targets, that build my application with different options? For example, say I want to build foo_nondebug, and foo_debug, and (luckily) all of my application code resides in the subdirectories of the top level directory containing the top-level Makefile. Obviously, if I invoke make from one of these targets, I can use the traditional trick of passing a sub-make arguments (like FOO_DEBUG=-g or FOO_DEBUG=empty). I use the following snippet in one my projects: AC_ARG_ENABLE(debug, [AS_HELP_STRING([--enable-debug],[turn on debug options and code])], [SD_CXXFLAGS=$SD_CXXFLAGS -g -O], [SD_CPPFLAGS=-DNDEBUG SD_CXXFLAGS=$SD_CXXFLAGS -O3]) # Export flags AC_SUBST([SVNDIGEST_CPPFLAGS], $SD_CPPFLAGS) AC_SUBST([SVNDIGEST_CXXFLAGS], $SD_CXXFLAGS) and then in each Makefile.am: AM_CPPFLAGS = $(SVNDIGEST_CPPFLAGS) AM_CXXFLAGS = $(SVNDIGEST_CXXFLAGS) This will add a switch to configure so we can call ./configure --enable-debug when we wanna build in debug mode, and else ignore the option. Their is no dependency, so if I switch between the modes in the same builddir I need to issue make clean. Hope this helps. Cheers, Peter
Re: Feature request
Hi Ben, * Ben Pfaff wrote on Wed, Sep 24, 2008 at 06:51:14PM CEST: Ralf Wildenhues [EMAIL PROTECTED] writes: I'd really hate to invade make's namespace. They may come up with this really cool new makefile variable, and we can't use it then. :-/ I wonder whether this is a real issue, because Automake cannot really use new GNU make extensions anyhow (right?) Right. because it writes out portable Makefiles. And it seems unlikely that POSIX would start inventing new Makefile syntax either. What I meant was: while automake itself cannot use new extensions, users can (and will) use them, as long as they don't directly conflict with automake's work. It would be sad if automake would prevent such usage. Cheers, Ralf
