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
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
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:
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
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
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
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
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
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
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
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
* 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 +
-## 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
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
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
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.
Hi,
is a builddir other than . possible ?
mfg
aotto1968
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
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
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
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
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,
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; \
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
* 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)
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
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
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
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
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
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:
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
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,
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
"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
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,
36 matches
Mail list logo
