How to generate version.texi in builddir?
Hi all, I'm trying to change automake's behaviour to generate version.texi inside the builddir instead of srcdir. Based on https://www.gnu.org/software/automake/manual/html_node/Texinfo.html I've tried info-in-builddir , but that seems to affect only the final .info file and not the version.texi one. Which is not that suprising given the name (`info-'). But there is not texi-in-builddir option as far as I can tell. Is this currently possible at all or is version.texi being in srcdir hard-coded behavior? Thank you for your help, W. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Produce symlink into builddir on VPATH?
Other than resorting to the shell in a target, is there a way to cause Automake to produce a symlink from the source tree into the build tree if-and-only-if the build is VPATH? I've some non-generated Python code (srcdir) relying on generated Python code (builddir) and I'd like to be able to just use it from the builddir (hence the symlink from srcdir) without monkeying with PYTHONPATH. Thanks, Rhys
Re: Produce symlink into builddir on VPATH?
On 06/11/2014 04:18 PM, Rhys Ulerich wrote: Other than resorting to the shell in a target, is there a way to cause Automake to produce a symlink from the source tree into the build tree if-and-only-if the build is VPATH? Yes, for new enough autotools. See how gnulib does it for GNUmakefile: http://git.savannah.gnu.org/cgit/gnulib.git/tree/modules/gnumakefile -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH] texi: info files can be generated in the builddir
On 01/02/2013 01:06 PM, Stefano Lattarini wrote: And here is the patch deprecating the CLEANFILES hack. This too is for maint, and scheduled to appear in Automake 1.13.2. I will push it with together with the patch introducing the new 'info-in-builddir' option, tomorrow. Regards, Stefano 8 8 8 8 8 8 8 8 8 From c1a8f56295d9c1621c65de28400cd1d93f037063 Mon Sep 17 00:00:00 2001 Message-Id: c1a8f56295d9c1621c65de28400cd1d93f037063.1357128164.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Wed, 2 Jan 2013 00:33:42 +0100 Subject: [PATCH] texi: deprecate hack about info files in CLEANFILES variables For quite a long time, Automake has been implementing an undocumented hack which ensured that '.info' files which appeared to be cleaned (by e.g. being listed in the CLEANFILES or DISTCLEANFILES variables) were built in the builddir rather than in the srcdir; this hack was introduced to ensure better backward-compatibility with packages such as Texinfo, which did things like: info_TEXINFOS = texinfo.txi info-stnd.texi info.texi DISTCLEANFILES = texinfo texinfo-* info*.info* # Do not create info files for distribution. dist-info: @: in order not to distribute .info files. Now that we have the 'info-in-builddir' option that explicitly causes generated '.info' files to be placed in the builddir, this hack should be longer necessary, so we deprecate it with runtime warnings. It is scheduled to be removed altogether in Automake 1.14. * automake.in (handle_texinfo_helper): Raise proper runtime warnings if the hack is triggered. * NEWS: Update. * t/txinfo28.sh: Adjust. * t/txinfo23.sh: Likewise. * t/txinfo25.sh: Adjust and extend. * t/txinfo24.sh: Likewise. Merged into maint. This change will appear in Automake 1.13.2. Regards, Stefano
Re: [PATCH] texi: info files can be generated in the builddir
And here is the patch deprecating the CLEANFILES hack. This too is
for maint, and scheduled to appear in Automake 1.13.2. I will push
it with together with the patch introducing the new 'info-in-builddir'
option, tomorrow.
Regards,
Stefano
8 8 8 8 8 8 8 8 8
From c1a8f56295d9c1621c65de28400cd1d93f037063 Mon Sep 17 00:00:00 2001
Message-Id:
c1a8f56295d9c1621c65de28400cd1d93f037063.1357128164.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Wed, 2 Jan 2013 00:33:42 +0100
Subject: [PATCH] texi: deprecate hack about info files in CLEANFILES variables
For quite a long time, Automake has been implementing an undocumented
hack which ensured that '.info' files which appeared to be cleaned (by
e.g. being listed in the CLEANFILES or DISTCLEANFILES variables) were
built in the builddir rather than in the srcdir; this hack was introduced
to ensure better backward-compatibility with packages such as Texinfo,
which did things like:
info_TEXINFOS = texinfo.txi info-stnd.texi info.texi
DISTCLEANFILES = texinfo texinfo-* info*.info*
# Do not create info files for distribution.
dist-info:
@:
in order not to distribute .info files.
Now that we have the 'info-in-builddir' option that explicitly causes
generated '.info' files to be placed in the builddir, this hack should
be longer necessary, so we deprecate it with runtime warnings. It is
scheduled to be removed altogether in Automake 1.14.
* automake.in (handle_texinfo_helper): Raise proper runtime warnings
if the hack is triggered.
* NEWS: Update.
* t/txinfo28.sh: Adjust.
* t/txinfo23.sh: Likewise.
* t/txinfo25.sh: Adjust and extend.
* t/txinfo24.sh: Likewise.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
NEWS | 20
automake.in | 15 +++
t/txinfo23.sh | 5 -
t/txinfo24.sh | 2 +-
t/txinfo25.sh | 7 ++-
t/txinfo28.sh | 2 +-
6 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/NEWS b/NEWS
index 804805e..6fd1c75 100644
--- a/NEWS
+++ b/NEWS
@@ -58,6 +58,26 @@ New in 1.13.2:
bfd library. See the extensive discussion about automake bug#11034
for more details.
+ - For quite a long time, Automake has been implementing an undocumented
+hack which ensured that '.info' files which appeared to be cleaned
+(by e.g. being listed in the CLEANFILES or DISTCLEANFILES variables)
+were built in the builddir rather than in the srcdir; this hack was
+introduced to ensure better backward-compatibility with packages such
+as Texinfo, which did things like:
+
+info_TEXINFOS = texinfo.txi info-stnd.texi info.texi
+DISTCLEANFILES = texinfo texinfo-* info*.info*
+# Do not create info files for distribution.
+dist-info:
+@:
+
+in order not to distribute generated '.info' files.
+
+Now that we have the 'info-in-builddir' option that explicitly causes
+generated '.info' files to be placed in the builddir, this hack should
+be longer necessary, so we deprecate it with runtime warnings. It will
+likely be removed altogether in Automake 1.14.
+
New in 1.13.1:
diff --git a/automake.in b/automake.in
index e56ea65..fe7f459 100644
--- a/automake.in
+++ b/automake.in
@@ -3140,6 +3140,21 @@ sub handle_texinfo_helper ($)
my @f = ();
push @f, $d-value_as_list_recursive (inner_expand = 1) if $d;
push @f, $c-value_as_list_recursive (inner_expand = 1) if $c;
+ if (@f !option 'info-in-builddir')
+ {
+msg 'obsolete', $am_file.am, EOF;
+Oops!
+It appears this file (or files included by it) are triggering
+an undocumented, soon-to-be-removed automake hack.
+Future automake versions will no longer place in the builddir
+(rather than in the srcdir) the generated '.info' files that
+appear to be cleaned, by e.g. being listed in CLEANFILES or
+DISTCLEANFILES.
+If you want your '.info' files to be placed in the builddir
+rather than in the srcdir, you have to use the shiny new
+'info-in-builddir' automake option.
+EOF
+ }
@f = map { s|[^A-Za-z_0-9*\[\]\-]|\\$|g; s|\*|[^/]*|g; $_; } @f;
my $user_cleaned_files = '^(?:' . join ('|', @f) . ')$';
diff --git a/t/txinfo23.sh b/t/txinfo23.sh
index c2b2797..6c2d9ce 100755
--- a/t/txinfo23.sh
+++ b/t/txinfo23.sh
@@ -53,9 +53,12 @@ I'm included.
END
$ACLOCAL
-$AUTOMAKE --add-missing
$AUTOCONF
+AUTOMAKE_run --add-missing -Wno-error
+grep Makefile\.am:.*undocumented.* automake hack stderr
+grep Makefile\.am:.*'info-in-builddir' automake option stderr
+
mkdir build
cd build
../configure
diff --git a/t/txinfo24.sh b/t/txinfo24.sh
index bfad312..9daa82e 100755
--- a/t/txinfo24.sh
+++ b/t/txinfo24.sh
@@ -41,7 +41,7 @@ Hello walls.
END
$ACLOCAL
-$AUTOMAKE --add-missing
+$AUTOMAKE --add-missing -Wno-obsolete
$AUTOCONF
mkdir build
[PATCH] texi: info files can be generated in the builddir (was: Re: [PATCH 0/3] Texinfo: allow '.info' placed in $(builddir), remove cruft)
References: http://lists.gnu.org/archive/html/automake-patches/2012-12/msg00107.html http://lists.gnu.org/archive/html/automake-patches/2012-12/msg00125.html On 12/31/2012 07:45 PM, Stefano Lattarini wrote: On 12/31/2012 11:02 AM, Stefano Lattarini wrote: See the commit messages of the individual patches for rationales and background. I plan to push this series to master in 72 hours. Stefano Lattarini (3): texinfo: info files can be generated in the builddir docs: document the new 'info-in-builddir' option texinfo: remove hack about info files in CLEANFILES variables Actually, I think it might make sense to apply the first two patches to maint (after the 1.13.1 bug-fixing release is out). This should be OK, since the change itself is very unobtrusive and no possible source of bugs (Murphy spare me for having said so :-). In addition, having this new option earlier will allow a proper deprecation of the old CLEANFILES hack, so that its final removal in Automake 1.14 won't be too abrupt. Opinions, objections? OK, so here is the first patch for maint, that I hope to get into Automake 1.13.2. I will push it in a couple of days if there is no review by then. The deprecation of the obsolescent CLEANFILES hack (that too for maint) and its removal (that for master only, to appear as part of 1.14) will follow at leisure. Thanks, Stefano 8 8 8 8 8 8 8 8 8 From 36ee783a1000b5a1e52b81e5564de19ffb99fd37 Mon Sep 17 00:00:00 2001 Message-Id: 36ee783a1000b5a1e52b81e5564de19ffb99fd37.1357081425.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Tue, 3 Apr 2012 22:02:55 +0200 Subject: [PATCH] texi: info files can be generated in the builddir User can now ask info files to be built in the $(builddir), rather than the $(srcdir), by specifying the Automake option 'info-in-builddir'. This feature was requested by the developers of GCC, GDB, GNU binutils and the GNU bfd library. See the extensive discussion about automake bug#11034 for more details. OK, to be honest, having '.info' files built in the builddir was *already* possible, but only using ugly and undocumented hacks involving definition of the CLEANFILES and/or DISTCLEANFILES. For example, the binutils project did something like this in the relevant 'Makefile.am': # Automake 1.9 will only build info files in the objdir if they are # mentioned in DISTCLEANFILES. It doesn't have to be unconditional, # though, so we use a bogus condition. if GENINSRC_NEVER DISTCLEANFILES = binutils.info endif See also the extensive discussion about automake bug#11034; in particular, the following messages: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11034#65 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11034#80 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11034#86 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11034#101 * lib/Automake/Options.pm (_is_valid_easy_option): Recognize the new 'info-in-builddir' option. * automake.in (handle_texinfo_helper): If that option is set, initialize '$insrc' to '0', so that info files will be generated in the builddir. Adjust comments to match. * t/txinfo-builddir.sh: New test. * t/list-of-tests.mk: Add it. * NEWS: Update. * doc/automake.texi: Document the new options. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- NEWS| 9 automake.in | 38 +-- doc/automake.texi | 13 + lib/Automake/Options.pm | 1 + t/list-of-tests.mk | 1 + t/txinfo-builddir.sh| 127 6 files changed, 174 insertions(+), 15 deletions(-) create mode 100755 t/txinfo-builddir.sh diff --git a/NEWS b/NEWS index c5b6514..804805e 100644 --- a/NEWS +++ b/NEWS @@ -49,6 +49,15 @@ New in 1.13.2: should take precedence over the same-named automake-provided macro (defined in '/usr/local/share/aclocal-1.14/vala.m4'). +* Texinfo support: + + - Automake can now be instructed to place '.info' files generated from +Texinfo input in the builddir rather than in the srcdir; this is done +specifying the new automake option 'info-in-builddir'. This feature +was requested by the developers of GCC, GDB, GNU binutils and the GNU +bfd library. See the extensive discussion about automake bug#11034 +for more details. + New in 1.13.1: diff --git a/automake.in b/automake.in index 0764258..e56ea65 100644 --- a/automake.in +++ b/automake.in @@ -3269,23 +3269,31 @@ sub handle_texinfo_helper ($) # have a single variable ($INSRC) that controls whether # the current .info file must be built in the source tree # or in the build tree. Actually this variable is switched - # off for .info files that appear to be cleaned; this is - # for backward compatibility with package
[PATCH 0/3] Texinfo: allow '.info' placed in $(builddir), remove cruft
See the commit messages of the individual patches for rationales and
background. I plan to push this series to master in 72 hours.
Stefano Lattarini (3):
texinfo: info files can be generated in the builddir
texinfo: remove hack about info files in CLEANFILES variables
docs: document the new 'info-in-builddir' option
NEWS | 26 +++
automake.in | 30 ++--
doc/automake.texi | 11 +++
lib/Automake/Options.pm | 1 +
t/list-of-tests.mk| 5 +-
t/mdate5.sh | 51 --
t/{txinfo25.sh = txinfo-builddir.sh} | 126 +++---
t/txinfo23.sh | 66 --
t/txinfo24.sh | 83 --
t/txinfo28.sh | 89
t/txinfo33.sh | 1 -
11 files changed, 146 insertions(+), 343 deletions(-)
rename t/{txinfo25.sh = txinfo-builddir.sh} (50%)
delete mode 100755 t/txinfo23.sh
delete mode 100755 t/txinfo24.sh
delete mode 100755 t/txinfo28.sh
--
1.8.1.rc3.27.g3b73c7d
Re: [PATCH 0/3] Texinfo: allow '.info' placed in $(builddir), remove cruft
On 12/31/2012 11:02 AM, Stefano Lattarini wrote: See the commit messages of the individual patches for rationales and background. I plan to push this series to master in 72 hours. Stefano Lattarini (3): texinfo: info files can be generated in the builddir docs: document the new 'info-in-builddir' option texinfo: remove hack about info files in CLEANFILES variables Actually, I think it might make sense to apply the first two patches to maint (after the 1.13.1 bug-fixing release is out). This should be OK, since the change itself is very unobtrusive and no possible source of bugs (Murphy spare me for having said so :-). In addition, having this new option earlier will allow a proper deprecation of the old CLEANFILES hack, so that its final removal in Automake 1.14 won't be too abrupt. Opinions, objections? Regards, Stefano
[PATCH 2/8] docs: build the web manuals for CVS in the builddir, not in the srcdir
We can do so using the '-I' option of the gendocs.sh script.
Inspired by the 'web-manual' rule in the 'top/maint.mk' file provided
by gnulib (as of commit v0.0-7741-g4a8c422) as customized by Bison in
its 'cfg.mk' file (as of commit v2.6.5-1007-gf5fceda).
* Makefile.am (web-manuals): Modify and simplify to take advantage
of gendocs.sh's '-I' option.
(upload-we-manuals): Accordingly adjust sanity checks and the rsync
invocation in the recipe.
(clean_texinfo_clutter_cmd): Delete this variable, it's no longer
required.
(clean-texinfo-clutter): Delete this phony target, it's no longer
required.
(clean-local): Don't depend on it.
* configure.ac: Invoke AC_PROG_LN_S, since we want to use $(LN_S)
in the new 'web-manuals' recipe.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
Makefile.am | 39 +++
configure.ac | 2 ++
2 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index a573ff2..8bcb6ed 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -997,33 +997,32 @@ fetch:
## Generate and upload manuals in several formats, for the GNU website. ##
## -- ##
-# The gendocs.sh script sadly leaves TeX and Texinfo auxiliary files
-# in the directory where it's invoked.
-clean_texinfo_clutter_cmd = \
- $(am__cd) doc rm -f *.ac *.aux *.cm *.cp *.cps *.fn *.fns *.ky \
- *.log *.op *.pg *.toc *.tp *.tr *.vr *.vrs
-
clean-web-manuals:
$(AM_V_at)rm -rf doc/web-manuals
-clean-texinfo-clutter:
- $(AM_V_at)$(clean_texinfo_clutter_cmd)
-clean-local: clean-web-manuals clean-texinfo-clutter
-.PHONY: clean-web-manuals clean-texinfo-clutter
+.PHONY: clean-web-manuals
+clean-local: clean-web-manuals
web-manuals:
$(AM_V_at)rm -rf doc/web-manuals
- $(AM_V_GEN): \
-## The gendocs.sh script only works from the srcdir, sadly.
- $(am__cd) $(srcdir)/doc \
- GENDOCS_TEMPLATE_DIR=../lib \
+ $(AM_V_GEN)tmp=$@.dir \
+ rm -rf $$tmp \
+ mkdir $$tmp \
+ $(am__cd) $$tmp \
+ GENDOCS_TEMPLATE_DIR='$(abs_srcdir)/lib' \
export GENDOCS_TEMPLATE_DIR \
+## Needed to pacify extra checks from gendocs.sh.
+ $(LN_S) '$(abs_srcdir)/doc/$(PACKAGE).texi' . \
## Try to respect silent rules.
if $(AM_V_P); then :; else exec /dev/null 21; fi \
## Finally generate the manual in several formats.
- $(SHELL) ../lib/gendocs.sh -o web-manuals \
---email $(PACKAGE_BUGREPORT) $(PACKAGE) '$(PACKAGE_NAME)'
- $(AM_V_at)$(clean_texinfo_clutter_cmd)
- $(AM_V_at)if $(AM_V_P); then ls -l doc/web-manuals; else :; fi
+ $(SHELL) '$(abs_srcdir)/lib/gendocs.sh' \
+-I '$(abs_srcdir)/doc' --email $(PACKAGE_BUGREPORT) \
+$(PACKAGE) '$(PACKAGE_NAME)'
+ $(AM_V_at)tmp=$@.dir \
+ mkdir doc/web-manuals \
+ mv -f $$tmp/manual/* doc/web-manuals \
+ rm -rf $$tmp \
+ { ! $(AM_V_P) || ls -l doc/web-manuals; }
.PHONY: web-manuals
RSYNC = rsync
@@ -1040,7 +1039,7 @@ upload-web-manuals:
*) echo Cannot upload manuals from a \$$release_type\ 2; \
exit 1;; \
esac
- $(AM_V_at)test -f $(srcdir)/doc/web-manuals/$(PACKAGE).html || { \
+ $(AM_V_at)test -f doc/web-manuals/$(PACKAGE).html || { \
echo 'You have to run $(MAKE) web-manuals before' \
'invoking $(MAKE) $@' 2; \
exit 1; \
@@ -1054,7 +1053,7 @@ upload-web-manuals:
$(CVS) -z3 -d :ext:$(CVS_USER)@$(WEBCVS_ROOT)/$(PACKAGE) \
co $(PACKAGE) \
cd .. \
- $(RSYNC) -avP $(srcdir)/doc/web-manuals/ $$tmp/$(PACKAGE)/manual \
+ $(RSYNC) -avP doc/web-manuals/ $$tmp/$(PACKAGE)/manual \
( \
cd $$tmp/$(PACKAGE)/manual \
new_files=`$(CVSU) --types='?'` \
diff --git a/configure.ac b/configure.ac
index 7f126c4..5582a51 100644
--- a/configure.ac
+++ b/configure.ac
@@ -70,6 +70,8 @@ AC_SUBST([system_acdir], [\${datadir}/aclocal])
ACLOCAL=\`pwd`/t/wrap/aclocal-$APIVERSION\
AUTOMAKE=\`pwd`/t/wrap/automake-$APIVERSION\
+AC_PROG_LN_S
+
AC_PATH_PROG([PERL], [perl])
if test -z $PERL; then
AC_MSG_ERROR([perl not found])
--
1.8.0.1.347.gf94c325
[PATCH 2/7] coverage: elisp path contains $(srcdir) and $(builddir)
* t/lisp-loadpath.sh: Check that. Also check that, in true VPATH spirit, elisp files in the build directory are preferred to those in the source directory. This test currently fails. * t/list-of-tests.mk (handwritten_TESTS): Add the new test. (XFAIL_TESTS): Likewise. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- t/lisp-loadpath.sh | 67 t/list-of-tests.mk |2 ++ 2 files changed, 69 insertions(+) create mode 100755 t/lisp-loadpath.sh diff --git a/t/lisp-loadpath.sh b/t/lisp-loadpath.sh new file mode 100755 index 000..50748ce --- /dev/null +++ b/t/lisp-loadpath.sh @@ -0,0 +1,67 @@ +#! /bin/sh +# Copyright (C) 2012 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2, or (at your option) +# any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see http://www.gnu.org/licenses/. + +# Emacs lisp files in both $(srcdir) and $(builddir) are found if +# required by other files. Related to automake bug#11806. + +required=emacs +. ./defs || exit 1 + +cat configure.ac 'END' +AM_PATH_LISPDIR +AC_OUTPUT +END + +cat Makefile.am 'END' +noinst_LISP = requirer.el +lisp_LISP = foo.el +lisp_DATA = bar.el +END + +echo (require 'foo) (require 'bar) requirer.el +echo (provide 'foo) foo.el +echo (provide 'bar) bar.el + +$ACLOCAL +$AUTOCONF +$AUTOMAKE -a + +mkdir build +cd build +../configure +$MAKE +test -f requirer.elc +test -f foo.elc +test ! -e bar.elc + +$MAKE clean +test ! -e requirer.elc +test ! -e foo.elc + +# In the spirit of VPATH, stuff in the builddir is preferred to +# stuff in the srcdir. +echo (provide ../foo.el # Break it. +echo defun) ../bar.el# Likewise. +$MAKE Exit 1 +$sleep +echo (provide 'foo) foo.el +echo (provide 'bar) bar.el +$MAKE +test -f requirer.elc +test -f foo.elc +test ! -e bar.elc + +: diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk index 40665c1..0f7bae0 100644 --- a/t/list-of-tests.mk +++ b/t/list-of-tests.mk @@ -38,6 +38,7 @@ t/override-conditional-2.sh \ t/dist-pr109765.sh \ t/instdir-cond2.sh \ t/java-nobase.sh \ +t/lisp-loadpath.sh \ t/lisp-subdir.sh \ t/lisp-subdir2.sh \ t/objext-pr10128.sh \ @@ -632,6 +633,7 @@ t/lisp5.sh \ t/lisp6.sh \ t/lisp7.sh \ t/lisp8.sh \ +t/lisp-loadpath.sh \ t/lisp-subdir.sh \ t/lisp-subdir2.sh \ t/lispdry.sh \ -- 1.7.9.5
[PATCH 5/7] elisp: no need to absolutize $(srcdir) and $(builddir) ...
* lib/am/lisp.am (.el.elc): ... here: we don't chdir around anyway, nor move or copy around our source '.el' files. Update comments, and re-wrap them while we are at it. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- lib/am/lisp.am | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/lib/am/lisp.am b/lib/am/lisp.am index ce87fb0..7326cb5 100644 --- a/lib/am/lisp.am +++ b/lib/am/lisp.am @@ -23,16 +23,17 @@ endif %?INSTALL% ## -- ## .el.elc: -## We add $(abs_builddir) and $(abs_srcdir) to load-path, so that any -## .el files that $ depends upon can be found (including generated -## ones). Prefer files from the build directory to those from the source -## directory, in true VPATH spirit. The destination file is normally -## determined by appending c to the input (which would erronously put -## it in $(srcdir) in VPATH builds), so we override that, too. +## We add $(builddir) and $(srcdir) to load-path, so that any '.el' files +## that $ depends upon can be found (including generated ones). +## We Prefer files from the build directory to those from the source +## directory, in true VPATH spirit. +## The destination file is normally determined by appending c to the +## input (which would erronously put it in $(srcdir) in VPATH builds), so +## we override that, too. if test $(EMACS) != no; then \ $(EMACS) -q --batch \ - --eval (setq load-path (cons \$(abs_srcdir)\ load-path)) \ - --eval (setq load-path (cons \$(abs_builddir)\ load-path)) \ + --eval (setq load-path (cons \$(srcdir)\ load-path)) \ + --eval (setq load-path (cons \$(builddir)\ load-path)) \ --eval (defun byte-compile-dest-file (f) \$@\) \ --eval (unless (byte-compile-file \$\) (kill-emacs 1)); \ else :; fi -- 1.7.9.5
[PATCH 4/7] elisp: prefer $(builddir) files over $(srcdir) ones
* lib/am/lisp.am (.el.elc): Here. This better respects VPATH spirit. Adjust and extends comments. * t/list-of-tests.mk (XFAIL_TESTS): Remove 't/lisp-loadpath.sh', which now passes. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- lib/am/lisp.am |9 + t/list-of-tests.mk |1 - 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/lib/am/lisp.am b/lib/am/lisp.am index 0d355f5..ce87fb0 100644 --- a/lib/am/lisp.am +++ b/lib/am/lisp.am @@ -25,13 +25,14 @@ endif %?INSTALL% .el.elc: ## We add $(abs_builddir) and $(abs_srcdir) to load-path, so that any ## .el files that $ depends upon can be found (including generated -## ones). The destination file is normally determined by appending c -## to the input (which would put it in $(srcdir)), so we override -## that, too. +## ones). Prefer files from the build directory to those from the source +## directory, in true VPATH spirit. The destination file is normally +## determined by appending c to the input (which would erronously put +## it in $(srcdir) in VPATH builds), so we override that, too. if test $(EMACS) != no; then \ $(EMACS) -q --batch \ - --eval (setq load-path (cons \$(abs_builddir)\ load-path)) \ --eval (setq load-path (cons \$(abs_srcdir)\ load-path)) \ + --eval (setq load-path (cons \$(abs_builddir)\ load-path)) \ --eval (defun byte-compile-dest-file (f) \$@\) \ --eval (unless (byte-compile-file \$\) (kill-emacs 1)); \ else :; fi diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk index 0f7bae0..c7d0fad 100644 --- a/t/list-of-tests.mk +++ b/t/list-of-tests.mk @@ -38,7 +38,6 @@ t/override-conditional-2.sh \ t/dist-pr109765.sh \ t/instdir-cond2.sh \ t/java-nobase.sh \ -t/lisp-loadpath.sh \ t/lisp-subdir.sh \ t/lisp-subdir2.sh \ t/objext-pr10128.sh \ -- 1.7.9.5
Re: [PATCH 5/7] elisp: no need to absolutize $(srcdir) and $(builddir) ...
On Sun, Jul 15, 2012 at 7:51 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: * lib/am/lisp.am (.el.elc): ... here: we don't chdir around anyway, nor move or copy around our source '.el' files. Update comments, and re-wrap them while we are at it. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- lib/am/lisp.am | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/lib/am/lisp.am b/lib/am/lisp.am index ce87fb0..7326cb5 100644 --- a/lib/am/lisp.am +++ b/lib/am/lisp.am @@ -23,16 +23,17 @@ endif %?INSTALL% ## -- ## .el.elc: -## We add $(abs_builddir) and $(abs_srcdir) to load-path, so that any -## .el files that $ depends upon can be found (including generated -## ones). Prefer files from the build directory to those from the source -## directory, in true VPATH spirit. The destination file is normally -## determined by appending c to the input (which would erronously put -## it in $(srcdir) in VPATH builds), so we override that, too. +## We add $(builddir) and $(srcdir) to load-path, so that any '.el' files +## that $ depends upon can be found (including generated ones). +## We Prefer files from the build directory to those from the source Nit: Capital on `Prefer'. +## directory, in true VPATH spirit. +## The destination file is normally determined by appending c to the +## input (which would erronously put it in $(srcdir) in VPATH builds), so +## we override that, too. if test $(EMACS) != no; then \ $(EMACS) -q --batch \ - --eval (setq load-path (cons \$(abs_srcdir)\ load-path)) \ - --eval (setq load-path (cons \$(abs_builddir)\ load-path)) \ + --eval (setq load-path (cons \$(srcdir)\ load-path)) \ + --eval (setq load-path (cons \$(builddir)\ load-path)) \ --eval (defun byte-compile-dest-file (f) \$@\) \ --eval (unless (byte-compile-file \$\) (kill-emacs 1)); \ else :; fi -- 1.7.9.5
Re: builddir
Hello Russell, * Russell Shaw wrote on Sun, Nov 14, 2010 at 02:49:07AM CET: In a Makefile.in generated by automake 1.9.6, it defines top_builddir ok, but builddir is used but not defined in there. This causes problems, because the automake manual says: — Variable: builddir Rigorously equal to ‘.’. Added for symmetry only. Automake 1.9.6 is very old. Presumably you're using an ancient version of Autoconf too, please state which. Normally I'd say upgrade and retry, but I might look at this if you post a small reproducer. Thanks, Ralf
Re: builddir
On 15/11/10 01:10, Ralf Wildenhues wrote: Hello Russell, * Russell Shaw wrote on Sun, Nov 14, 2010 at 02:49:07AM CET: In a Makefile.in generated by automake 1.9.6, it defines top_builddir ok, but builddir is used but not defined in there. This causes problems, because the automake manual says: — Variable: builddir Rigorously equal to ‘.’. Added for symmetry only. Automake 1.9.6 is very old. Presumably you're using an ancient version of Autoconf too, please state which. Normally I'd say upgrade and retry, but I might look at this if you post a small reproducer. Hi, I had a closer look at my system and found the debian alternatives system was pointing at an old version. I set it right now thanks.
builddir
Hi, In a Makefile.in generated by automake 1.9.6, it defines top_builddir ok, but builddir is used but not defined in there. This causes problems, because the automake manual says: — Variable: builddir Rigorously equal to ‘.’. Added for symmetry only.
builddir question
Hi, is a builddir other than . possible ? mfg aotto1968
Re: builddir question
Andreas Otto wrote: is a builddir other than . possible ? No http://www.gnu.org/software/autoconf/manual/autoconf.html#Preset-Output-Variables -- Peter Johansson svndigest maintainer, http://dev.thep.lu.se/svndigest yat maintainer, http://dev.thep.lu.se/yat
Re: builddir vs. srcdir
Hello, On Fri, Mar 18, 2005 at 09:34:15PM +0200, Paul Pogonyshev wrote: Sorry, but I'll stick with my setup. My parser depends on my lowest- level library (`libutils') and almost the whole build-tree depends on the generated files. So, when I touched my `libutils' in any way, I would get a full-blown rebuild of the project. That's why I used `cmp' and only replaced the `.[ch]' files with the newly generated if they differed. And so I need timestamps to avoid unecessary commands run yes, this indeed sounds as a good reason for usiong stamps. Anyway, even if I don't accept your advice this time, thank you for the help. :) You are welcome. It was a nice excercise for me, too. Stepan
Re: builddir vs. srcdir
Hello, On Sat, Mar 12, 2005 at 06:56:20PM +0200, Paul Pogonyshev wrote: Everything seems to work just fine and as expected, your code, which is in whole cited below, doesn't actually know about the dependency foo.c foo.h: foo.list So if you change the .list file, the other files won't be rebuilt. This might be a dangerous bug. It doesn't know about the dependency, but the files will be rebuilt as a ``side-effect'' of the timestamp rule. I actually just tried this out. In general, stamps are always dangerous, so it's good to avoid them if possible. I'd try something like this: [file `aux/list.make'] SUFFIXES = .list .list.c: Makefile $(PARSE_LIST_COMMAND) $(PARSE_LIST_BUILD_RULE) .list.h: Makefile $(PARSE_LIST_COMMAND) $(PARSE_LIST_BUILD_RULE) PARSE_LIST_BUILD_RULE = \ $(PARSE_LIST_COMMAND) $(PARSE_LIST_FLAGS) \ `test -f '$' || echo '$(srcdir)/'`$ $*.h $*.c \ touch $*.h [usage] LIST_FILES = foo.list bar.list # Prevent problems with parallel make: foo.h: foo.c bar.h: bar.c PARSE_LIST_COMMAND = ... PARSE_LIST_FLAGS = ... noinst_LIBRARIES = libfoo.a libfoo_a_SOURCES = ... $(LIST_FILES) # This hint is needed only for included files; *.c files # are handled by normal target dependencies: BUILT_SOURCES = $(LIST_FILES:.list=.h) MOSTLYCLEANFILES = $(LIST_FILES:.list=.h) $(LIST_FILES:.list=.c) include $(top_srcdir)/aux/list.make Sorry, but I'll stick with my setup. My parser depends on my lowest- level library (`libutils') and almost the whole build-tree depends on the generated files. So, when I touched my `libutils' in any way, I would get a full-blown rebuild of the project. That's why I used `cmp' and only replaced the `.[ch]' files with the newly generated if they differed. And so I need timestamps to avoid unecessary commands run all the time (I want to see ``nothing to be done...'' when it is the case.) Let me add some comments: 1) The maintainer of Automake said that $(LIST_FILES:.list=.h) is safe, and I trust him. Oh, great, that is what I was looking for! 2) nodist_libfoo_a_SOURCES was redundant, especially the .c files. Automake knows how to transform .list to .o, and listing the intermediate files again could cause problems. With your setup, yes. Not with mine, unfortunately. 3) I try to have the BUILT_SOURCES hist as small as possible, so when the .c file is a prerequisite of the corresponding .o, there is no need to pre-build it using BUILT_SOURCES. 4) With parallel make, the PARSE_LIST_COMMAND cnnot be run twice in parallel, because of the foo.c: foo.h dependency. So we are safe. I need to add this rule in my setup too. Anyway, even if I don't accept your advice this time, thank you for the help. :) Paul
Re: builddir vs. srcdir
Hello, On Sat, Mar 12, 2005 at 06:56:20PM +0200, Paul Pogonyshev wrote: Everything seems to work just fine and as expected, your code, which is in whole cited below, doesn't actually know about the dependency foo.c foo.h: foo.list So if you change the .list file, the other files won't be rebuilt. This might be a dangerous bug. In general, stamps are always dangerous, so it's good to avoid them if possible. I'd try something like this: [file `aux/list.make'] SUFFIXES = .list .list.c: Makefile $(PARSE_LIST_COMMAND) $(PARSE_LIST_BUILD_RULE) .list.h: Makefile $(PARSE_LIST_COMMAND) $(PARSE_LIST_BUILD_RULE) PARSE_LIST_BUILD_RULE = \ $(PARSE_LIST_COMMAND) $(PARSE_LIST_FLAGS) \ `test -f '$' || echo '$(srcdir)/'`$ $*.h $*.c \ touch $*.h [usage] LIST_FILES = foo.list bar.list # Prevent problems with parallel make: foo.h: foo.c bar.h: bar.c PARSE_LIST_COMMAND = ... PARSE_LIST_FLAGS = ... noinst_LIBRARIES = libfoo.a libfoo_a_SOURCES = ... $(LIST_FILES) # This hint is needed only for included files; *.c files # are handled by normal target dependencies: BUILT_SOURCES = $(LIST_FILES:.list=.h) MOSTLYCLEANFILES = $(LIST_FILES:.list=.h) $(LIST_FILES:.list=.c) include $(top_srcdir)/aux/list.make Let me add some comments: 1) The maintainer of Automake said that $(LIST_FILES:.list=.h) is safe, and I trust him. 2) nodist_libfoo_a_SOURCES was redundant, especially the .c files. Automake knows how to transform .list to .o, and listing the intermediate files again could cause problems. 3) I try to have the BUILT_SOURCES hist as small as possible, so when the .c file is a prerequisite of the corresponding .o, there is no need to pre-build it using BUILT_SOURCES. 4) With parallel make, the PARSE_LIST_COMMAND cnnot be run twice in parallel, because of the foo.c: foo.h dependency. So we are safe. One more comment: 5) It looks that the PARSE_LIST_COMMAND will be executed twice: forst to create foo.c and then again to create foo.h. But this is actually not the case with GNU make: when command is to be called for the second time, make discovers, that the file foo.h has somehow appeared there, and that it's newer then its prerequisities, foo.list and foo.c (see the touch command in PARSE_LIST_BUILD_RULE), so there is no longer any need to rebuild it. Even if some inferior implementations of make were not that clever, the only problem would be that each pair of the files would be created twice. I think we can live with that. What if we used such an inferior make implementation for parallel build? Well, in general, this could bring problems. But I think this combination simply won't happen. Happy making, Stepan --- your code: [file `aux/list.make'] SUFFIXES = .list $(LIST_STAMP_FILES) : Makefile $(PARSE_LIST_COMMAND) # `PARSE_LIST_COMMAND' and `PARSE_LIST_FLAGS' should be set by the # includer. # PARSE_LIST = $(PARSE_LIST_COMMAND) $(PARSE_LIST_FLAGS) # We use `cmp' here to avoid unneeded recompilations of files that # depend on generated ones (only really useful for `.h' files.) # PARSE_LIST_BUILD_RULE = \ if $(PARSE_LIST) `test -f '$' || echo '$(srcdir)/'`$ \ $*.h.new $*.c.new; then\ if cmp -s $*.c.new $*.c; \ then rm -f $*.c.new; else mv -f $*.c.new $*.c; \ fi; \ if cmp -s $*.h.new $*.h; \ then rm -f $*.h.new; else mv -f $*.h.new $*.h; \ fi; \ echo timestamp $@; \ else\ (rm -f $*.c $*.c.new $*.h $*.h.new ; exit 1) \ fi .list.stamp: $(PARSE_LIST_BUILD_RULE) # Since $(LIST_GENERATED_FILES) defined by the includer don't (at # least shouldn't) have any dependencies, if this rule is being # executed, it probably means that one of the files was removed. # Then all we can do is to force rebuilding of corresponding stamp # file, which builds the required sources ``by side-effect.'' # $(LIST_GENERATED_FILES): rm -f $*.stamp; $(MAKE) $(AM_MAKEFLAGS) $*.stamp [usage] noinst_LIBRARIES = libfoo.a LIST_FILES = foo.list bar.list LIST_STAMP_FILES = foo.stamp bar.stamp LIST_GENERATED_FILES = foo.c bar.c foo.h bar.h PARSE_LIST_COMMAND = ... PARSE_LIST_FLAGS = ... include $(top_srcdir)/aux/list.make libfoo_a_SOURCES = ... $(LIST_FILES) nodist_libfoo_a_SOURCES = $(LIST_GENERATED_FILES) BUILT_SOURCES = $(LIST_STAMP_FILES) MOSTLYCLEANFILES = $(LIST_STAMP_FILES) $(LIST_GENERATED_FILES)
Re: builddir vs. srcdir
Stepan Kasal wrote: About the side topic of suffixes: [...] I finally decided that suffixes are good and ``are worth it'', mostly because I use generated files in 4 different directories (with two files in one of them), so rewriting the rule 5 times is kinda nasty. Based on your suggestions, study of GTK+ `Makefile.am' and own thoughts, I came up with this: [file `aux/list.make'] SUFFIXES = .list $(LIST_STAMP_FILES) : Makefile $(PARSE_LIST_COMMAND) # `PARSE_LIST_COMMAND' and `PARSE_LIST_FLAGS' should be set by the # includer. # PARSE_LIST = $(PARSE_LIST_COMMAND) $(PARSE_LIST_FLAGS) # We use `cmp' here to avoid unneeded recompilations of files that # depend on generated ones (only really useful for `.h' files.) # PARSE_LIST_BUILD_RULE = \ if $(PARSE_LIST) `test -f '$' || echo '$(srcdir)/'`$ \ $*.h.new $*.c.new; then\ if cmp -s $*.c.new $*.c; \ then rm -f $*.c.new; else mv -f $*.c.new $*.c; \ fi; \ if cmp -s $*.h.new $*.h; \ then rm -f $*.h.new; else mv -f $*.h.new $*.h; \ fi; \ echo timestamp $@; \ else\ (rm -f $*.c $*.c.new $*.h $*.h.new ; exit 1) \ fi .list.stamp: $(PARSE_LIST_BUILD_RULE) # Since $(LIST_GENERATED_FILES) defined by the includer don't (at # least shouldn't) have any dependencies, if this rule is being # executed, it probably means that one of the files was removed. # Then all we can do is to force rebuilding of corresponding stamp # file, which builds the required sources ``by side-effect.'' # $(LIST_GENERATED_FILES): rm -f $*.stamp; $(MAKE) $(AM_MAKEFLAGS) $*.stamp [usage] noinst_LIBRARIES = libfoo.a LIST_FILES = foo.list bar.list LIST_STAMP_FILES = foo.stamp bar.stamp LIST_GENERATED_FILES = foo.c bar.c foo.h bar.h PARSE_LIST_COMMAND = ... PARSE_LIST_FLAGS = ... include $(top_srcdir)/aux/list.make libfoo_a_SOURCES = ... $(LIST_FILES) nodist_libfoo_a_SOURCES = $(LIST_GENERATED_FILES) BUILT_SOURCES = $(LIST_STAMP_FILES) MOSTLYCLEANFILES = $(LIST_STAMP_FILES) $(LIST_GENERATED_FILES) Everything seems to work just fine and as expected, however I suspect that the ``rm -f $*.stamp; $(MAKE) $(AM_MAKEFLAGS) $*.stamp'' command will cause the problem with parallel make you mentioned. Is it so? Also, is there a way to automatically set `LIST_STAMP_FILES' and `LIST_GENERATED_FILES' from `LIST_FILES'? (I'm aware of GNU make's text manipulation functions, but they are GNU make specific...) Paul
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: builddir vs. srcdir
Stepan Kasal wrote: Hello, On Tue, Mar 08, 2005 at 11:56:56PM +0200, Paul Pogonyshev wrote: 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. You can solve the second issue by adding the dependency: foo.c: foo.h Whats about a more general case SOMEFILES=a b c d e $(SOMEFILES): srcfile buildsomehow srcfile $(SOMEFILES) || (rm -f $(SOMEFILES); false) ??? Regards Harri
Re: builddir vs. srcdir
* Harald Dunkel wrote on Thu, Mar 10, 2005 at 09:27:34AM CET: Stepan Kasal wrote: On Tue, Mar 08, 2005 at 11:56:56PM +0200, Paul Pogonyshev wrote: 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. You can solve the second issue by adding the dependency: foo.c: foo.h Whats about a more general case SOMEFILES=a b c d e $(SOMEFILES): srcfile buildsomehow srcfile $(SOMEFILES) || (rm -f $(SOMEFILES); false) Please read info '(automake.info)Multiple Outputs' which comes with a recent Automake and documents the whole issue very thoroughly. Regards, Ralf
Re: builddir vs. srcdir
Hi, On Wed, Mar 09, 2005 at 11:21:35PM +0200, Paul Pogonyshev wrote: 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. well, in the example I cited, I had several .list sources, but only one in each directory. Thus I was able to have different rules in different directories. This is not usable for you, but you can make the .list.h rule general: $(PARSE) `case $* in *this.list) echo this options;; \ *that.list) echo that opt;; *) echo default opt;;esac` $ ($* is substituted by make) Or you can place the options at the first line of the .list source and grep for them. And if your generator creates *.c file after *.h file, you should define the dependency: foo.c: foo.h and vice versa if the generator creates .h after .c. That will make make happy and you won't observe repeated re-generation of the .c file. HTH, Stepan Kasal
Re: builddir vs. srcdir
Harald == Harald Dunkel [EMAIL PROTECTED] writes: Harald Whats about a more general case http://sources.redhat.com/automake/automake.html#Multiple-Outputs -- Alexandre Duret-Lutz
Re: builddir vs. srcdir
Alexandre Duret-Lutz wrote: 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 Yup, you are right, thanks. Should have guessed myself... :[ Paul
Re: builddir vs. srcdir
Hi, On Wed, Mar 09, 2005 at 11:21:35PM +0200, Paul Pogonyshev wrote: 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. well, in the example I cited, I had several .list sources, but only one in each directory. Thus I was able to have different rules in different directories. This is not usable for you, but you can make the .list.h rule general: $(PARSE) `case $* in *this.list) echo this options;; \ *that.list) echo that opt;; *) echo default opt;;esac` $ ($* is substituted by make) Well, I also need something like `echo $* | sed 's/\.h$/.c/'` (not tested), so using suffix rules seems like too much trouble. Besides, 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.) Or you can place the options at the first line of the .list source and grep for them. Then I could just make the parser read them as well. That might be a good idea, actually, since these options are more like modes that are absolutely necessary to be set correctly to parse anything. And if your generator creates *.c file after *.h file, you should define the dependency: foo.c: foo.h and vice versa if the generator creates .h after .c. That will make make happy and you won't observe repeated re-generation of the .c file. I'm not sure which one comes first. They are generated on-the-fly in parallel (i.e. fprintf's to both files are mixed.) I assume in this case 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? BTW, I have just built everything in a separate directory for the first time :) I need to sort out that parallel building stuff, but otherwise all works perfectly. Thanks for your help. Paul
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
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: 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: 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
Re: `make dist' with srcdir != builddir
adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes: adl Some weeks ago Bruno Haible reported (in private mail) that adl running `make dist' with srcdir != builddir could produce adl distributions which are not up-to-date, especially if you have adl generated files like bison parsers adl This can be easily fixed by changing the distdir code to look for adl files in the builddir first and failling back to look in the adl srcdir if needed. FYI, I looked at this the other day and came to the same conclusion. I made this change. Tom
Re: tags and config.in when srcdir!=builddir
"Kevin" == Kevin Ryde [EMAIL PROTECTED] writes: Kevin Using a recent cvs automake, I tried "make TAGS" in a separate Kevin object directory, but the etags command got config.in without a Kevin $(srcdir) path. Perhaps the @CONFIG@ in tags.am should be in Kevin the list that gets uniquified and checked for needing Kevin $(srcdir). The same might apply to $(LISP) there too, but I Kevin haven't tried that. Yeah, you're probably right. That seems like an easy change to make in tags.am. Kevin Actually, etags by default doesn't match anything in a Kevin config.in containing only #undefs, so this isn't important, Kevin it's just to get the target to go through. Maybe tags on the Kevin generated config.h would be more use. I think so too. Tom
tags and config.in when srcdir!=builddir
Using a recent cvs automake, I tried "make TAGS" in a separate object directory, but the etags command got config.in without a $(srcdir) path. Perhaps the @CONFIG@ in tags.am should be in the list that gets uniquified and checked for needing $(srcdir). The same might apply to $(LISP) there too, but I haven't tried that. Actually, etags by default doesn't match anything in a config.in containing only #undefs, so this isn't important, it's just to get the target to go through. Maybe tags on the generated config.h would be more use. Or maybe not.
