Re: builddir vs. srcdir
Hello, On Thu, Mar 10, 2005 at 10:05:51PM +0200, Paul Pogonyshev wrote: I'm not sure which one comes first. [...] I can just do foo.c : foo.h foo.c foo.h : ... if $(BUILD_THEM_FILES) foo.list foo.h foo.c; then \ touch foo.c; \ else\ (rm -f foo.c foo.h; exit 1) \ fi right? Correct, of course. About the side topic of suffixes: Well, I also need something like `echo $* | sed 's/\.h$/.c/'` No, $* is the base without the suffix. in one directory I have two `.list' files, one of which is processed by my parser, while the other---by `glib-genmarshal' (I chose my suffix before I even started with GTK+ GUI.) One option is to change the suffix for your parser, of course. Or you could do something like: LIST_H_CMDS = if $(BUILD_THEM_FILES) $*.list $*.h $*.c; then\ touch $*.c; \ else\ (rm -f $*.c $*.h; exit 1) \ fi BUILD_THEM_FILES = case $* in \ *marshal*) $(GENMARSHAL_CMD) $*.list ... ;; \ *) $(PARSE) $*.list ... ;; \ esac .list.h: $(LIST_H_CMDS) .list.c: $(LIST_H_CMDS) All the variables in the commands, are expanded just before execution, so the usage of $* ``outside of a rule'' is correct here. But when I recall that all this is done just to be able to do xx_SOURCES = foo.list ... intead of xx_SOURCES = ... nodist_xx_SOURCES = foo.c EXTRA_DIST = foo.list then I agree it's not worth it. (Setting CLEANFILES = foo.c foo.h; BUILT_SOURCES = foo.h is necessary in both cases.) Have a nice day, Stepan
Re: adding subdirectories
On Thu, Mar 10, 2005 at 12:26:36AM +0100, Alexandre Duret-Lutz wrote: 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. Indeed. After playing a little with the actual project, I found out the difference: I had LDADD = $(ZZZ_DEFAULT_LIBS), where the latter was AC_SUBST'ed, so automake didn't detect the dependencies. I've tried that, it works great. Thanks much! One more question: how do I define that make alone should build zzz, and test1..testn should be built only when I do make check? With kind regards, Baurjan.
Re: adding subdirectories
* Baurjan Ismagulov wrote on Fri, Mar 11, 2005 at 11:39:58AM CET: One more question: how do I define that make alone should build zzz, and test1..testn should be built only when I do make check? Put them in check_PROGRAMS. Regards, Ralf
Re: adding subdirectories
On Fri, Mar 11, 2005 at 12:31:06PM +0100, Ralf Wildenhues wrote: One more question: how do I define that make alone should build zzz, and test1..testn should be built only when I do make check? Put them in check_PROGRAMS. Wow, now I have Makefile.am exactly as I want it! Thanks much for all answers! With kind regards, Baurzhan.
Re: AC_DEFINE_DIR in autoconf (was: Re: SYSCONFDIR: config.h vs. AM_CFLAGS)
On Wed, Mar 09, 2005 at 08:06:18PM +0100, Baurjan Ismagulov wrote: 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 you set CPPFLAGS=$CPPFLAGS -DDATADIR='\$(datadir)' or CPPFLAGS=$CPPFLAGS '-DDATADIR=$(datadir)' in your configure.ac, then the $(datadir) part is expanded by make. So you can do ./configure --prefix=oneprefix make prefix=anotherprefix make prefix=yetanother install Your config.h approach doesn't allow the user to redifine prefix for make all, even though it allows them to redefine it for make install. (Not that I know what is this requirment good for. I don't advocate the standard, I just explain what conforms to it and what doesn't.) Have a nice day, Stepan
macro search path
Hello, node Macro search path describes several ways how one can tell aclocal where to search for macro files. Please consider the following scenario: /opt/gnome28 contains Gnome 2.8 /opt/gnome210 contains Gnome 2.10 Then I sometimes want to search /opt/gnome28/share/aclocal sometimes /opt/gnome210/share/aclocal but never both. So I cannot use /usr/share/aclocal/dirlist for both types of builds. I could use '-I /opt/gnome28/share/aclocal', but I had to do some tricks to make sure that this option is propagated to the makefile rule for aclocal.m4. Besides this, the manual rightly says that -I should be used for relative paths, not for absolute ones. Similar problem arises when I don't have write access to /usr and have some packages with prefix $HOME/usr, yet I don't want to reinstall Automake under $HOME/usr and want to use the system's Automake. In both cases, a colon separated env. variable ACLOCAL_PATH would solve the problem neatly. Could you accept such a change? Have a nice day, Stepan Kasal
Re: macro search path
On Fri, 2005-03-11 at 17:44 +0100, Stepan Kasal wrote: Hello, node Macro search path describes several ways how one can tell aclocal where to search for macro files. Please consider the following scenario: /opt/gnome28 contains Gnome 2.8 /opt/gnome210 contains Gnome 2.10 Then I sometimes want to search /opt/gnome28/share/aclocal sometimes /opt/gnome210/share/aclocal but never both. In both cases, a colon separated env. variable ACLOCAL_PATH would solve the problem neatly. I doubt it would solve your problem. Imagine a macro file is only present in one of the directories. You'd end up with the risk of mixing macros from both directories. To work around this issue, you'd have to switch ACLOCAL_PATH depending on which directory you'd want to use. As a work-around to this problem, I once had been using wrapper scripts to aclocal, located in corresponding */bin directories and to switch PATH. [Meanwhile I found it easier and less error-prone to install appropriate autotool-toolchains several times using different prefixes.] Ralf
Re: macro search path
Hello, On Fri, Mar 11, 2005 at 06:38:39PM +0100, Ralf Corsepius wrote: In both cases, a colon separated env. variable ACLOCAL_PATH would solve the problem neatly. To work around this issue, you'd have to switch ACLOCAL_PATH depending on which directory you'd want to use. this is what I meant. It's very similar the current Gnome approach: they set ACLOCAL_FLAGS in the environment, and gnome-autogen.sh uses it. I think ACLOCAL_PATH is better then switching two copies of dirlist or then creating two wrappers or two installations of Automake. Have a nice weekend, Stepan
Re: macro search path
On Fri, 2005-03-11 at 18:44 +0100, Stepan Kasal wrote: Hello, On Fri, Mar 11, 2005 at 06:38:39PM +0100, Ralf Corsepius wrote: In both cases, a colon separated env. variable ACLOCAL_PATH would solve the problem neatly. To work around this issue, you'd have to switch ACLOCAL_PATH depending on which directory you'd want to use. this is what I meant. It's very similar the current Gnome approach: they set ACLOCAL_FLAGS in the environment, and gnome-autogen.sh uses it. I think ACLOCAL_PATH is better then switching two copies of dirlist or then creating two wrappers or two installations of Automake. I don't agree - IMO, both are essentially equivalent. i.e. I consider adding ACLOCAL_FLAGS as shifting around problems. Ralf
