bug#54390: YACC rules don't check DESTDIR existence for VPATH builds

> On 13 Jan 2023, at 08:43, Mike Frysinger wrote: > > On 13 Jan 2023 07:07, Sam James wrote: >> $ /tmp/libaacs/configure YACC=bison LEX=flex > > the problem is you're forcing `YACC=bison`. Automake defaults to `bison -y` > which tells bison to operate in POSIX-yacc-compatible mode because

bug#54390: YACC rules don't check DESTDIR existence for VPATH builds

On 13 Jan 2023 07:07, Sam James wrote: > $ /tmp/libaacs/configure YACC=bison LEX=flex the problem is you're forcing `YACC=bison`. Automake defaults to `bison -y` which tells bison to operate in POSIX-yacc-compatible mode because Automake's rules target POSIX. the end result is that you've

bug#54390: YACC rules don't check DESTDIR existence for VPATH builds

cs_la_SOURCES=\ >>>> src/libaacs/aacs.h \ >>>> [...] >>>> src/file/dirs.h \ >>>> src/file/file.h \ >>>> src/file/file.c \ >>>> src/file/filesystem.h \ >>>> src/file/filesystem.c \ >>>> src/file/keydbcfg.c \ >&g

bug#54390: YACC rules don't check DESTDIR existence for VPATH builds

e.c \ > >> src/file/filesystem.h \ > >> src/file/filesystem.c \ > >> src/file/keydbcfg.c \ > >> src/file/keydbcfg.h \ > >> src/file/keydb.h \ > >> src/file/keydbcfg-parser.y \ > >> src/file/keydbcfg-lexer.l \ > >> src/file/mmc_device.h

bug#54390: YACC rules don't check DESTDIR existence for VPATH builds

/keydbcfg-lexer.l \ >> src/file/mmc_device.h \ >> [...] >> ``` >> >> While src/libaacs exists within the build dir, src/file/ doesn't exist at >> all, hence the failure. >> >> automake yacc rules should mkdir -p the needed directories within the bu

bug#54390: YACC rules don't check DESTDIR existence for VPATH builds

/keydbcfg-lexer.l \ >> src/file/mmc_device.h \ >> [...] >> ``` >> >> While src/libaacs exists within the build dir, src/file/ doesn't exist at >> all, hence the failure. >> >> automake yacc rules should mkdir -p the needed directories within the bu

bug#54390: YACC rules don't check DESTDIR existence for VPATH builds

/keydbcfg.c \ > src/file/keydbcfg.h \ > src/file/keydb.h \ > src/file/keydbcfg-parser.y \ > src/file/keydbcfg-lexer.l \ > src/file/mmc_device.h \ > [...] > ``` > > While src/libaacs exists within the build dir, src/file/ doesn't exist at > al

bug#54390: YACC rules don't check DESTDIR existence for VPATH builds

\ [...] ``` While src/libaacs exists within the build dir, src/file/ doesn't exist at all, hence the failure. automake yacc rules should mkdir -p the needed directories within the build dir for VPATH builds before running ylwrap/yacc. Best, sam signature.asc Description: Message signed with OpenPGP

bug#39666: distcheck for VPATH build: #line directives of generated YACC and LEX c-files in tarballs

Hi Jannick - (sorry for the delayed reply) So my question is under the premise of a VPATH build: Is there a remedy for the incorrect paths in these #line directives (OTHER THAN running configure and make in the top src dir)? My gut reaction is that make distcheck is not intended

bug#7884: [PATCH] yacc: fix VPATH builds with FreeBSD make

It seems something more needs to be done with this bug, but I don't know what. I hope someone with more energy, expertise, and/or time can look into it and find a resolution. Marking it as severity normal (seems like it can't be crucially important after languishing for N years) and with the

bug#10852: VPATH builds cannot recover from missing parser header

Back on this bug from 2012, https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10852 ak> Also, why two "if"? sl> For the sake of "make -n": * doc/automake.texi (Multiple Outputs): Split commands than reinvoke $(MAKE) to avoid file removals during dry runs. I pushed Akim's patch.

bug#39666: distcheck for VPATH build: #line directives of generated YACC and LEX c-files in tarballs

next to their corresponding source YACC or LEX file; it appears that their #line directives are the same as in the build process. This causes an issue when 'make distcheck' is run in a (strict) VPATH build: In the distribution tarball the relative #line directives pointing to the source YACC or LEX

bug#33085: using myprog_CXXFLAGS with VPATH prevents Makefile from finding sources

Hello Nick, Nick Bowler writes: > On 10/18/18, Julien COURTAT wrote: >> Here's my bug report, I'm building my software out of the source tree, this >> is called parallel build (very nice feature). >> The way to reproduce the issue is very simple, set myprog_CXXFLAGS = -DAN

bug#33085: using myprog_CXXFLAGS with VPATH prevents Makefile from finding sources

Hello, On 10/18/18, Julien COURTAT wrote: > Here's my bug report, I'm building my software out of the source tree, this > is called parallel build (very nice feature). > The way to reproduce the issue is very simple, set myprog_CXXFLAGS = -DANY > and VPATH=@MYDIR@ and the correspond

bug#33085: using myprog_CXXFLAGS with VPATH prevents Makefile from finding sources

Hello, Here's my bug report, I'm building my software out of the source tree, this is called parallel build (very nice feature). The way to reproduce the issue is very simple, set myprog_CXXFLAGS = -DANY and VPATH=@MYDIR@ and the corresponding Makefile won't find my source file. Replace

Difficulty handling specific case with subdir-objects in VPATH build

way, under a VPATH build, this first target would ensure compilation of the specified paths in their matching locations (i.e. $(top_srcdir)/src/base/paramx.f90 would lead to $(top_builddir)/src/base/paramx.lo), and the rest of the libraries could then be compiled normally. Adding "subdir

Re: Problem with VPATH builds and SCRIPTS primary

On 11/02/2016 08:06 PM, Raphaël Halimi wrote: Hi Peter, Thanks for your answer. Just to make sure I understand: CLEANFILES += data/.dirstamp data/.dirstamp: @$(MKDIR_P) data @: > $@ This creates a directory "data", and then a file ".dirstamp" in this directory by redirecting

Re: Problem with VPATH builds and SCRIPTS primary

Hi Peter, Thanks for your answer. Just to make sure I understand: > CLEANFILES += data/.dirstamp > > data/.dirstamp: > @$(MKDIR_P) data > @: > $@ This creates a directory "data", and then a file ".dirstamp" in this directory by redirecting the (empty) result of the "true" command to

Re: Problem with VPATH builds and SCRIPTS primary

Hi Raphael, I have the following in my Makefile.am CLEANFILES += data/.dirstamp data/.dirstamp: @$(MKDIR_P) data @: > $@ data/foo.txt: data/.dirstamp Cheers, Peter On 10/28/2016 05:46 AM, Raphaël Halimi wrote: Hi, I have a problem with parallel build trees (a.k.a. VP

Re: Problem with VPATH builds and SCRIPTS primary

Le 27/10/2016 à 23:06, Russ Allbery a écrit : > Raphaël Halimi writes: > >> According to section 2.2.6 of GNU automake documentation: > >> "The build tree usually has the same subdirectory layout as the source >> tree; its subdirectories are created automatically by

Re: Problem with VPATH builds and SCRIPTS primary

Raphaël Halimi writes: > According to section 2.2.6 of GNU automake documentation: > "The build tree usually has the same subdirectory layout as the source > tree; its subdirectories are created automatically by the build system." > Unfortunately, it doesn't seem to

Problem with VPATH builds and SCRIPTS primary

Hi, I have a problem with parallel build trees (a.k.a. VPATH Builds). I'm trying to use GNU autotools to distribute a shell script that need to be installed with some other files (sample configuration, man pages, data, etc etc). Nothing in this project needs to be compiled, but the script

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

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

[FYI] {maint} maint: port check-minimal-autoconf to VPATH builds

* maintainer/maint.mk (check-minimal-autoconf): Here. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- maintainer/maint.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/maintainer/maint.mk b/maintainer/maint.mk index e46b6db..d180b09 100644 ---

bug#13928: VPATH issues with subdir-objects

...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Sat, 8 Jun 2013 22:00:32 +0200 Subject: [PATCH] tests: expose automake bug#13928 * t/subobj-indir-pr13928.sh: New test, still xfailing. * t/subobj-vpath-pr13928.sh: Likewise. * t/list-of-tests.mk (XFAIL_TESTS, handwritten_TESTS

Re: bug#13928: VPATH issues with subdir-objects

...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Sat, 8 Jun 2013 22:00:32 +0200 Subject: [PATCH] tests: expose automake bug#13928 * t/subobj-indir-pr13928.sh: New test, still xfailing. * t/subobj-vpath-pr13928.sh: Likewise. * t/list-of-tests.mk (XFAIL_TESTS, handwritten_TESTS

[FYI] {maint} build: fixup for building in a VPATH setup

* bin/Makefile.inc (%D%/automake, %D%/aclocal): Make sure that the directory where the targets scripts are going to be built exists, before trying to create said scripts. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- bin/Makefile.inc | 1 + 1 file changed, 1 insertion(+) diff

bug#13928: VPATH issues with subdir-objects

On 2013-03-11 23:27 +0100, Stefano Lattarini wrote: On 03/11/2013 10:33 PM, Nick Bowler wrote: On 2013-03-11 21:55 +0100, Stefano Lattarini wrote: [...] - from Automake 2.0 onward, only enable the automatic dependency tracking if GNU make is used; we can thus assume the presence

bug#13928: VPATH issues with subdir-objects

Regarding the actual bug: without knowing much (yet!) about the relevant Automake internals, I'm a bit surprised that src = src foo_SOURCES = $(src)/foo.c fails with subdir-objects, but on the other hand src = src/foo.c foo_SOURCES = $(src) seems to work just fine... That's

bug#13928: VPATH issues with subdir-objects (was: [PATCH 1/2] preproc: add support for relative names in included fragments)

first prefixed it with '$(srcdir)/', test_SOURCES = $(srcdir)/test.c just to see the generated make rule: $(srcdir)/test-test.o: $(srcdir)/test.c which would completely circumvent VPATH builds, would it? Yes. The answer is: don't use $(srcdir) in your source files -- they will be picked

bug#13928: VPATH issues with subdir-objects (was: [PATCH 1/2] preproc: add support for relative names in included fragments)

On 2013-03-11 21:55 +0100, Stefano Lattarini wrote: [...] - from Automake 2.0 onward, only enable the automatic dependency tracking if GNU make is used; we can thus assume the presence of the -include directive (which ignore non-existing files, rather than punting), and its use

bug#13928: VPATH issues with subdir-objects

On 03/11/2013 10:33 PM, Nick Bowler wrote: On 2013-03-11 21:55 +0100, Stefano Lattarini wrote: [...] - from Automake 2.0 onward, only enable the automatic dependency tracking if GNU make is used; we can thus assume the presence of the -include directive Actually, to be more

[FYI 0/2] {maint} tests: fix a spurious failure when run in a VPATH build

This failure was breaking make distcheck. Not a big deal, but I want to release 1.12.5 soon enough, so better fix it now. Stefano Lattarini (2): tests: rename $am_testauxdir - $am_testaux_srcdir tests: new variable $am_testaux_builddir t/ax/tap-summary-aux.sh| 2 +-

vpath and make dist newbie problem

I don't understand automake's make dist support, and could use a clue. I've boiled my problem down to the following tiny test case, in which ./configure; make works, but make dist fails. It seems that make dist is unable to follow vpath. Is this a known problem? To reproduce the problem, do

Re: vpath and make dist newbie problem

or move the guts of it to pathprob/foobar/blah/Makefile.am Yes, removing the vpath and moving george.c up one level works around the problem in the test case. Should I file a bug for the fact that vpath and dist don't work together, or is that already documented somewhere? It doesn't quite solve

Re: vpath and make dist newbie problem

On Mon, Oct 22, 2012 at 3:12 PM, Paul Davis paul.joseph.da...@gmail.com wrote: It doesn't quite solve the problem in my real world situation; make dist didn't copy #included files, and I needed to add something like EXTRA_DIST = foobar to pathprob/Makefile.am. This is to be expected, you

Re: vpath and make dist newbie problem

to follow vpath. Is this a known problem? To reproduce the problem, do wget http://kegel.com/pathprob.tgz tar -xzvf pathprob.tgz cd pathprob touch NEWS README AUTHORS ChangeLog aclocal autoconf automake --add-missing ./configure make dist This outputs { test ! -d foo-0.1

Re: vpath and make dist newbie problem

/george.c and if that works, either put sources next to this Makefile.am or move the guts of it to pathprob/foobar/blah/Makefile.am Yes, removing the vpath and moving george.c up one level works around the problem in the test case. Should I file a bug for the fact that vpath and dist don't work

Re: vpath and make dist newbie problem

List the .c and .h files in FOO_SOURCES. H

Fix build failure in VPATH setup (was: Re: [Automake-NG] [FYI] [ng] vars: names of iterating vars in $(foreach) loops shorter simpler)

] Error 1 Compilation FAILED: /Users/akim/src/gnu/automake-ng: build-for-darwin V=1 exit 2 I don't have any t/ax in my builddir. Oops, VPATH-only issues, shared by mainline Automake in maint. The attached patch will fix it. Soon to be merged in 'master' and 'ng/master' as well. Thanks

[FYI] {maint} test runner: work correctly in VPATH setups

, this substitution is wrong; for example, the final 't/ax/test-runner' build in a VPATH builds where the source directory is .. contains the line: : ${srcdir='../../../t/ax'} instead of the expected (and correct): : ${srcdir='../t/ax'} We solve the issue by making 't/ax/test-runner

Re: [FYI] {maint} test runner: work correctly in VPATH setups

'. Because our build system operates in a non-recursive setup, this substitution is wrong; for example, the final 't/ax/test-runner' build in a VPATH builds where the source directory is .. contains the line: : ${srcdir='../../../t/ax'} instead of the expected (and correct

Re: [FYI] {maint} test runner: work correctly in VPATH setups

Hi Dave. On 07/06/2012 10:33 PM, Dave Hart wrote: We solve the issue by building 't/ax/test-runner' with a Makefile recipe instead of config.status substitutions; ... Thanks, fixed! Regards, Stefano

[FYI] {maint} tests: work in VPATH setup again

* defs: Drop overly paranoid sanity checks that was causing all the tests to fail spuriously when run in a VPATH setup, with a message like: ../t/nodef.sh: ./t/ax/test-init.sh: not found in current directory. Those checks looked for invariants that, even if broken, would still cause the test

[FYI] {maint} tests: fix some spurious failures in VPATH setup

* t/self-check-cleanup.tap: No need to copy the 'ax/t/test-init.sh' file over in our temporary directory. * t/self-check-reexec.tap: Likewise. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- t/self-check-cleanup.tap |6 ++ t/self-check-reexec.tap |9 - 2

bug#10852: VPATH builds cannot recover from missing parser header

Le 20 févr. 2012 à 14:58, Stefano Lattarini a écrit : Also, why two if? For the sake of make -n: at least GNU make and Solaris make execute recipes containing the $(MAKE) string even when they are running in dry mode; so if we didn't break the recipe above in two invocations, the file

bug#10852: VPATH builds cannot recover from missing parser header

Hi Akim. On 02/24/2012 01:55 PM, Akim Demaille wrote: Le 20 févr. 2012 à 14:58, Stefano Lattarini a écrit : Also, why two if? For the sake of make -n: at least GNU make and Solaris make execute recipes containing the $(MAKE) string even when they are running in dry mode; so if we didn't

bug#10852: VPATH builds cannot recover from missing parser header

On 02/22/2012 03:54 PM, Akim Demaille wrote: hi Stefano, Hello World!\n On 02/20/2012 02:24 PM, Akim Demaille wrote: src/parse-gram.h: src/parse-gram.c @if test ! -f $@; then rm -f src/parse-gram.c; else :; fi @if test ! -f $@; then $(MAKE) $(AM_MAKEFLAGS) src/parse-gram.c; else :;

bug#10852: VPATH builds cannot recover from missing parser header

Le 23 févr. 2012 à 10:43, Stefano Lattarini a écrit : src/parse-gram.h: src/parse-gram.c test -f $@ || rm -f src/parse-gram.c test -f $@ || $(MAKE) $(AM_MAKEFLAGS) src/parse-gram.c This seems nicer. Care to write a patch to implement this simplification (here and for other

bug#10852: VPATH builds cannot recover from missing parser header

different from the user-source-tree. It's easy to imagine situations where the user, in a vpath-build, would have one parser.c in srcdir and another in builddir. Then, who knows what will happen... As I showed in my previous message, it can even behave extremely weirdly because of pretty much

bug#10852: VPATH builds cannot recover from missing parser header

wrong to me that the maintainer-source-tree is so different from the user-source-tree. It's easy to imagine situations where the user, in a vpath-build, would have one parser.c in srcdir and another in builddir. Then, who knows what will happen... The one in builddir should take precedence

bug#10852: VPATH builds cannot recover from missing parser header

that my brains decided to quickly forget :). Also, why two if? In case some concurrent execution of Make would already have provided $@ in the meanwhile? The following patch extends a test which is aimed at checking this, but does it in a non-vpath build :) I have a question though. I don't

[FYI] {master} tests: avoid FreeBSD make VPATH issues in more tests (see bug#7884)

. * tests/lex-noyywrap.test: Likewise. * tests/lex-libobj.test: Likewise. * tests/man6.test: This test suffers from the same FreeBSD make incompatibility in VPATH handling that is the source of automake bug#7884. Since this is caused by rules that are defined in the Makefile.am by the test itself

Re: [PATCH] {master} cscope: is only expected to work with GNU make in VPATH setup

On 02/15/2012 10:28 AM, Stefano Lattarini wrote: The 'cscope' functionality does not properly handle VPATH rewrites; so we explicitly document that, for now, it is only ensured to work with GNU make when doing a VPATH build, and we adjust testsuite requirements accordingly. Issue revealed

bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make remake

tags 10434 + patch close 10434 thanks On 02/08/2012 12:29 AM, Peter Rosin wrote: Stefano Lattarini skrev 2012-02-08 00:01: Hi Peter, thanks for the invaluable feedback. Thanks for the appreciation, but invaluable is perhaps a bit over the top... Not for what concerns this patch IMHO.

bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make remake

Stefano Lattarini skrev 2012-02-05 14:16: On 02/02/2012 11:41 PM, Peter Rosin wrote: Stefano Lattarini skrev 2012-02-02 22:45: Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10434 OK, the attached patch fixes the two spurious failures of GCC forced into Tru64 mode. About time

bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make remake

right depmode selected \ +grep ^checking dependency style .*\.\.\. $displayed_depmode$ stdout + command_ok_ $pfx simple make make_ok # Some bugs in VPATH builds only kick in during a rebuild. command_ok_ $pfx clean rebuild eval '$MAKE clean make_ok' Remember to also

Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make remake

breakage in the basic compilation rules, checking that it was *also* good enough not to break remake rules in VPATH builds. This seemed a good approach when this test was first introduced, as it apparently increased coverage for the less used and less tested dependency-tracking modes. But in the log

Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make remake

Stefano Lattarini skrev 2012-02-05 14:16: On 02/02/2012 11:41 PM, Peter Rosin wrote: Stefano Lattarini skrev 2012-02-02 22:45: Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10434 OK, the attached patch fixes the two spurious failures of GCC forced into Tru64 mode. About time

Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make remake

+ command_ok_ $pfx simple make make_ok # Some bugs in VPATH builds only kick in during a rebuild. command_ok_ $pfx clean rebuild eval '$MAKE clean make_ok' I will push the patch by tomorrow, barring objections. Thanks, Stefano

Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make remake

right depmode selected \ +grep ^checking dependency style .*\.\.\. $displayed_depmode$ stdout + command_ok_ $pfx simple make make_ok # Some bugs in VPATH builds only kick in during a rebuild. command_ok_ $pfx clean rebuild eval '$MAKE clean make_ok' Remember to also

bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make remake

, and, for each such forced mode that was compatible enough with said compiler not to cause breakage in the basic compilation rules, checking that it was *also* good enough not to break remake rules in VPATH builds. This seemed a good approach when this test was first introduced, as it apparently

bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make remake

Hi Jim, thanks for the feedback. On 02/06/2012 03:27 PM, Jim Meyering wrote: Stefano Lattarini wrote: [SNIP] This seemed a good approach when this test was first introduced, as it apparently increased coverage for the less used and less tested dependency-tracking modes. But in the log

bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make remake

Stefano Lattarini wrote: Hi Jim, thanks for the feedback. On 02/06/2012 03:27 PM, Jim Meyering wrote: Stefano Lattarini wrote: [SNIP] This seemed a good approach when this test was first introduced, as it apparently increased coverage for the less used and less tested

Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make remake

Hi Jim, thanks for the feedback. On 02/06/2012 03:27 PM, Jim Meyering wrote: Stefano Lattarini wrote: [SNIP] This seemed a good approach when this test was first introduced, as it apparently increased coverage for the less used and less tested dependency-tracking modes. But in the log

Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make remake

compiler not to cause breakage in the basic compilation rules, checking that it was *also* good enough not to break remake rules in VPATH builds. This seemed a good approach when this test was first introduced, as it apparently increased coverage for the less used and less tested dependency-tracking

bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make remake

Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10434 OK, the attached patch fixes the two spurious failures of GCC forced into Tru64 mode. About time I'd say. But I'm not sure whether we should apply this without first testing it on a real Tru64 compiler, lest we cause a real

bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make remake

Stefano Lattarini skrev 2012-02-02 22:45: Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10434 OK, the attached patch fixes the two spurious failures of GCC forced into Tru64 mode. About time I'd say. But I'm not sure whether we should apply this without first testing it on a

Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make remake

Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10434 OK, the attached patch fixes the two spurious failures of GCC forced into Tru64 mode. About time I'd say. But I'm not sure whether we should apply this without first testing it on a real Tru64 compiler, lest we cause a real

Re: bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make remake

Stefano Lattarini skrev 2012-02-02 22:45: Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10434 OK, the attached patch fixes the two spurious failures of GCC forced into Tru64 mode. About time I'd say. But I'm not sure whether we should apply this without first testing it on a

[PATCH 5/5] {Automake-NG} tests: GNU make doesn't perform VPATH rewrites

* tests/parallel-tests8.test: Remove extra hacks that accounted for the possibility of VPATH rewrites, since GNU make performs none. * tests/suffix10.tap: Likewise. * tests/suffix11.tap: Likewise. * tests/suffix12.test: Likewise. * tests/suffix13.test: Likewise. * tests/suffix3.tap: Likewise

bug#10111: remake rules can fail in a weird corner case (VPATH into $distdir).

interested in trying out a VPATH build. +mkdir build +cd build +../configure +# He wants to verify that the rules he's written to rebuild a file +# included by configure.in works also in VPATH builds. +rm -f ../foobar.am +$MAKE +grep '# foobar was here #' ../Makefile.in +$MAKE distcheck + +: diff --git

[PATCH] {maint} tests: fix spurious failure with FreeBSD make and Yacc in VPATH

and installed properly when ylwrap is in a default auxdir found in a parent package ... * tests/subpkg-yacc.test: ... into this new test, which carefully avoids to trigger the known bug#7884 (combo FreeBSD make plus Yacc plus VPATH build). * tests/Makefile.am (TESTS): Update. --- ChangeLog

bug#9506: makeinfo in VPATH builds fails

tags 9506 wontfix close 9506 thanks Hi Sebastian, thanks for the bug report. On Wednesday 14 September 2011, Sebastian Freundt wrote: Package: automake Version: 1.11a VPATH build of a project using makeinfo fails if $(srcdir) isn't writable. Yes, this is a consequence of the fact

bug#9512: TEXINFOS primary and nodist_ (was: Re: makeinfo in VPATH builds fails)

Submitter: Sebastian Freundt de...@fresse.org thanks Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9506 On Thursday 15 September 2011, Sebastian Freundt wrote: Stefano Lattarini stefano.lattar...@gmail.com writes: The main point is that if you're distributing you `.info' files,

bug#9506: makeinfo in VPATH builds fails

Package: automake Version: 1.11a VPATH build of a project using makeinfo fails if $(srcdir) isn't writable. freundt@plutos:~/devel_freundt/datetools/=build make /home/freundt/devel/datetools/git-version-gen .version /dev/null make all-recursive make[1]: Entering directory `/home/guest

[FYI] {test-protocols} test harness: more minor VPATH-rewrite issues

* tests/am/check.am (am__set_TESTS_bases, $(TEST_SUITE_LOGS), am--redo-logs, recheck, recheck-html): Cosmetic fixlets to minimize the risk of unwanted VPATH rewrites. (check-TESTS): Likewise, and normalize trailing whitespace since we are at it. Bugs exposed by test cases `check6-p.test

[FYI] {test-protocols} test harness: work around a VPATH rewrite issue

* lib/am/check.am (am__TEST_BASES): Removed, it's role taken over by ... (am__set_TESTS_bases): ... these new variable. ($(TEST_SUITE_LOG): Use it, to avoid VPATH rewrite issues. * automake.in (handle_tests): Update the code for the cleanup of the `.trs' file to use `$(TEST_LOGS)' instead

Re: documentation about AM_CPPFLAGS and VPATH builds

: 5d4dc886c0863ed2a4fdec933a1bded31402094b.1312376796.git.stefano.lattar...@gmail.com From: Bruno Haible br...@clisp.org Date: Wed, 3 Aug 2011 15:05:22 +0200 Subject: [PATCH] docs: how to use '-I' option in AM_CPPFLAGS for best VPATH support * doc/automake.texi (Program Variables): Recommend -I

Re: documentation about AM_CPPFLAGS and VPATH builds

(@pxref{VPATH Builds}). Therefore we recommend to use a pair of +@option{-I} options: @samp{-Isome/subdir -I$(srcdir)/some/subdir} +or @samp{-I$(top_builddir)/some/subdir -I$(top_srcdir)/some/subdir}. I'm not sure this sentence is truly warrented: it is redundant for someone who has

Re: documentation about AM_CPPFLAGS and VPATH builds

On Sunday 31 July 2011, Bruno Haible wrote: Hi, Hi Bruno. Thanks for the patch, and sorry for the delay. Paul and Jim approved the idea to give a recommendation about how to set up the -I options in AM_CPPFLAGS for dealing with VPATH builds. Originally I wanted to document

Re: documentation about AM_CPPFLAGS and VPATH builds

Hi Stefano, +When a file to be included is generated during the build and not part +of a distribution tarball, its location is under @code{$(builddir)}, +not under @code{$(srcdir)}. This matters for builds outside the source +tree (@pxref{VPATH Builds}). Therefore we recommend to use

documentation about AM_CPPFLAGS and VPATH builds

Hi, Paul and Jim approved the idea to give a recommendation about how to set up the -I options in AM_CPPFLAGS for dealing with VPATH builds. Originally I wanted to document this in the Autoconf manual, but I didn't find the appropriate place: The Autoconf manual talks more about the CPPFLAGS

Re: [PATCH] {master} tests: extend tests on dependency tracking with VPATH

.html On Tuesday 19 April 2011, Stefano Lattarini wrote: Hello Ralf. On Monday 11 April 2011, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Mon, Apr 11, 2011 at 07:13:00AM CEST: Fix hp depmode for VPATH builds with GNU make. * lib/depcomp: Be sure to remove

Re: [FYI] {testsuite-work} tests: extend tests on dependency tracking with VPATH

April 2011, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Mon, Apr 11, 2011 at 07:13:00AM CEST: Fix hp depmode for VPATH builds with GNU make. * lib/depcomp: Be sure to remove VPATH-prefixed object from dependency output when creating stub rule. * tests

Re: [PATCH] {master} tests: extend tests on dependency tracking with VPATH

wrote on Mon, Apr 11, 2011 at 07:13:00AM CEST: Fix hp depmode for VPATH builds with GNU make. * lib/depcomp: Be sure to remove VPATH-prefixed object from dependency output when creating stub rule. * tests/depcomp10.test: New test. * tests/Makefile.am (TESTS

[FYI] {testsuite-work} tests: extend tests on dependency tracking with VPATH

Reference: http://lists.gnu.org/archive/html/automake-patches/2011-04/msg0014 On Tuesday 19 April 2011, Stefano Lattarini wrote: Hello Ralf. On Monday 11 April 2011, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Mon, Apr 11, 2011 at 07:13:00AM CEST: Fix hp depmode for VPATH

[PATCH] {maint} tests: fix spurious failure in a test on TESTS (VPATH-related)

Another spurious failure in one of my testcases fixed (this failure was triggered only by make implementations that perform VPATH-rewriting, such as Solaris or Heirloom make). Patch applied to a temporary branch based off of the offending commit, merged to maint and master, and pushed. Sorry

Re: bug#8473: depcomp bug with HP-UX cc and VPATH build

Hello Ralf and Bruno. I've spotted a couple of harmful typos in the patch, and I also have a very minor nit. On Monday 11 April 2011, Ralf Wildenhues wrote: Fix hp depmode for VPATH builds with GNU make. * lib/depcomp: Be sure to remove VPATH-prefixed object from dependency

Re: bug#8473: depcomp bug with HP-UX cc and VPATH build

Hi Stefano, I've spotted a couple of harmful typos in the patch, and I also have a very minor nit. You'd do me a big favor if you fixed them right away (if you have time) and merge to active branches. I don't have my ssh keys available until tonight. Thanks, and sorry for the messup, Ralf

Re: bug#8473: depcomp bug with HP-UX cc and VPATH build

to the relevant bug report. Add a comment which + explains why the test result 'skipped' if the first make call + fails. Add other useful comments. + * tests/depcomp9.test: Slightly improve comments. + 2011-04-11 Ralf Wildenhues ralf.wildenh...@gmx.de Fix hp depmode for VPATH builds with GNU make

Re: bug#8473: depcomp bug with HP-UX cc and VPATH build

On Monday 11 April 2011, Stefano Lattarini wrote: On Monday 11 April 2011, Ralf Wildenhues wrote: Hi Stefano, I've spotted a couple of harmful typos in the patch, and I also have a very minor nit. You'd do me a big favor if you fixed them right away (if you have time) and merge

Re: bug#8473: depcomp bug with HP-UX cc and VPATH build

Hi Stefano, * Stefano Lattarini wrote on Mon, Apr 11, 2011 at 12:29:51PM CEST: On Monday 11 April 2011, Ralf Wildenhues wrote: I've spotted a couple of harmful typos in the patch, and I also have a very minor nit. You'd do me a big favor if you fixed them right away (if you have time)

bug#8473: depcomp bug with HP-UX cc and VPATH build

Hi, The dependencies mechanism of Automake leads to a compilation failure when used in a VPATH build (with GNU make, of course) and HP-UX cc. The failure occurs during the third command of this command sequence: $ gmake $ gmake clean $ gmake ... gmake[4]: Entering directory `/tmp

bug#8473: depcomp bug with HP-UX cc and VPATH build

Hi Bruno, * Bruno Haible wrote on Mon, Apr 11, 2011 at 02:44:48AM CEST: The dependencies mechanism of Automake leads to a compilation failure when used in a VPATH build (with GNU make, of course) Actually, in this case you could have avoided this particular bug by using HP make. :-p Automake

Re: bug#8473: depcomp bug with HP-UX cc and VPATH build

Hi Bruno, * Bruno Haible wrote on Mon, Apr 11, 2011 at 02:44:48AM CEST: The dependencies mechanism of Automake leads to a compilation failure when used in a VPATH build (with GNU make, of course) Actually, in this case you could have avoided this particular bug by using HP make. :-p Automake

Re: bug#8473: depcomp bug with HP-UX cc and VPATH build

* Ralf Wildenhues wrote on Mon, Apr 11, 2011 at 07:13:00AM CEST: Fix hp depmode for VPATH builds with GNU make. * lib/depcomp: Be sure to remove VPATH-prefixed object from dependency output when creating stub rule. * tests/depcomp10.test: New test. * tests

Re: Fix makedepend depmode to cope with VPATH builds

2011, Ralf Wildenhues wrote: Ugh, a looong-standing depmode=makedepend bug that silently breaks rebuilds in VPATH trees. It has now hit me in the wild. :-( Just out of curiosity: with which compiler? IBM XL on BlueGene. --- a/lib/depcomp +++ b/lib/depcomp @@ -557,7 +557,9

Re: Fix makedepend depmode to cope with VPATH builds

Hi Stefano, * Stefano Lattarini wrote on Sat, Apr 09, 2011 at 11:38:47AM CEST: On Friday 08 April 2011, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Fri, Apr 08, 2011 at 01:05:53PM CEST: On Wednesday 06 April 2011, Ralf Wildenhues wrote: + # makedepend may prepend the VPATH

  1   2   3   >