bug#62791: BUILT_SOURCES not honoured in parallel build?

Patch attached. Looks just fine. Thanks Reuben. I installed it. Closing ... --all the best, karl.

bug#62791: BUILT_SOURCES not honoured in parallel build?

ATCH] doc: add advice to list Yacc/Lex generated sources in BUILT_SOURCES This fixes #62791: it seems to be necessary to list the generated C source file for a Yacc/Lex file, as well as the header file in BUILT_SOURCES. --- doc/automake.texi | 9 + 1 file changed, 5 insertions(+), 4

bug#62791: BUILT_SOURCES not honoured in parallel build?

asn't the question, but I > think the manual's statement about "any `SOURCES' variables" was simply > not meant to apply to BUILT_SOURCES (probably didn't think about it), > I did wonder that myself. but rather to the "normal" something_SOURCES variables. So my gut &

bug#62791: BUILT_SOURCES not honoured in parallel build?

ot;any `SOURCES' variables" was simply not meant to apply to BUILT_SOURCES (probably didn't think about it), but rather to the "normal" something_SOURCES variables. So my gut reaction is to add "(except @code{BUILT_SOURCES}, see below)". Later, it talks about adding the header

bug#62791: BUILT_SOURCES not honoured in parallel build?

On Wed, 6 Dec 2023 at 23:59, Karl Berry wrote: > Any chance that one of you could write a patch for the manual to explain > whatever needs to be explained (better)? --thanks, karl. > I'd happily do that if I could work out, or someone could explain, exactly what's going on here. The manual

bug#62791: BUILT_SOURCES not honoured in parallel build?

Any chance that one of you could write a patch for the manual to explain whatever needs to be explained (better)? --thanks, karl.

bug#62791: BUILT_SOURCES not honoured in parallel build?

On Sun, 3 Dec 2023 at 03:47, Mike Frysinger wrote: > > > > I think I've worked it out: I need to add the .c file that is generated > > from the .y file, not the .h file, to BUILT_SOURCES. Certainly, doing > that > > fixes the problem. > > we prob could add a .y/.

bug#62791: BUILT_SOURCES not honoured in parallel build?

ong, but I can't work out what! > > I think I've worked it out: I need to add the .c file that is generated > from the .y file, not the .h file, to BUILT_SOURCES. Certainly, doing that > fixes the problem. we prob could add a .y/.l example to the manual. i think i tripped over th

bug#62791: BUILT_SOURCES not honoured in parallel build?

s generated from the .y file, not the .h file, to BUILT_SOURCES. Certainly, doing that fixes the problem. -- https://rrt.sc3d.org

bug#62791: BUILT_SOURCES not honoured in parallel build?

On Wed, 12 Apr 2023 at 16:17, Reuben Thomas wrote: > I am bootstrapping GNU a2ps git master[1] with automake 1.16.5. When I do > a parallel build (in my case, MAKEFLAGS=-j4), I get build failures > sometimes: > In fact, I don't need to do a parallel build, just build serially from a fresh git

bug#62791: BUILT_SOURCES not honoured in parallel build?

ished jobs parsessh.output is unchanged updating parsessh.h make[1]: Leaving directory '/home/rrt/.local/var/repo/a2ps/src' make: *** [Makefile:1514: all] Error 2 But parsessh.h is listed in BUILT_SOURCES, so it should be built before any other target. [1] git clone https://git.savannah.gnu.org/gi

bug#49317: dist: depends on $(BUILT_SOURCES), but has no reason to

Hi Allison - Jim finished pushing your patch a day or two ago. Complications in testing. Thanks for the contribution! --karl

bug#49317: dist: depends on $(BUILT_SOURCES), but has no reason to

[PATCH] dist: add new "pure-dist" automake option Since v1.15.1-204-gac47c22e3, "make dist" has been depending on $(BUILT_SOURCES) to avoid problems when building some GNU packages which need to compile themselves as part of building their tarballs (for example, to generate

bug#49317: dist: depends on $(BUILT_SOURCES), but has no reason to

GNU Hello builds its manpage (which it dists) by building and running the binary and capturing its --help output. This is quite common (among GNU packages anyway). So it is not surprising Jim (hi Jim) committed a general solution. A blanket depend on $(BUILT_SOURCES) for all automake

bug#49317: dist: depends on $(BUILT_SOURCES), but has no reason to

BUILT_SOURCES solves a useful problem and we use it in our package for a few things. Its stated purpose (from the docs) is all about compilation and dependency tracking. It makes sense that $(BUILT_SOURCES) should then be built as a prerequisite before any targets that result in compilation: all

Re: bug#43683: make install-exec does not trigger make $(BUILT_SOURCES)

Thank you Karl! Il giorno mer 7 ott 2020 alle ore 02:18 Karl Berry ha scritto: > Hi madmurphy, > > install-exec: $(BUILT_SOURCES) > $(MAKE) $(AM_MAKEFLAGS) install-exec-am > > Thanks very much for the bug report, patch, and test case. I just > applied and

bug#43683: make install-exec does not trigger make $(BUILT_SOURCES)

Thank you Karl! Il giorno mer 7 ott 2020 alle ore 02:18 Karl Berry ha scritto: > Hi madmurphy, > > install-exec: $(BUILT_SOURCES) > $(MAKE) $(AM_MAKEFLAGS) install-exec-am > > Thanks very much for the bug report, patch, and test case. I just > applied and

Re: bug#43683: make install-exec does not trigger make $(BUILT_SOURCES)

Hi madmurphy, install-exec: $(BUILT_SOURCES) $(MAKE) $(AM_MAKEFLAGS) install-exec-am Thanks very much for the bug report, patch, and test case. I just applied and pushed it, with small modifications. Please report back if problems persist. Meanwhile, closing this bug. Thanks

bug#43683: make install-exec does not trigger make $(BUILT_SOURCES)

Hi madmurphy, install-exec: $(BUILT_SOURCES) $(MAKE) $(AM_MAKEFLAGS) install-exec-am Thanks very much for the bug report, patch, and test case. I just applied and pushed it, with small modifications. Please report back if problems persist. Meanwhile, closing this bug. Thanks

Re: Patch to trigger make $(BUILT_SOURCES) from make install-exec

Sure! Please find the test case attached. All you have to do is to launch these two commands **from the clean package** to see that they will not work: ./bootstrap make DESTDIR=~/libfoo-install-test install-exec If you replace install-exec with install everything will work well instead.

Re: Patch to trigger make $(BUILT_SOURCES) from make install-exec

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43683 Thanks much for the report and patch. Looks sensible. Can you provide a test case (example configure.ac + Makefile.am + tree) that exposes the problem (and thus verifies the patch)? Thanks again, Karl

Patch to trigger make $(BUILT_SOURCES) from make install-exec

Today I have reported a bug at bug-autom...@gnu.org (see bug #43683 – please use this link for a better rendering of the HTML). However I have written in the meanwhile a patch

bug#43683: make install-exec does not trigger make $(BUILT_SOURCES)

Please find attached a patch that solves the problem. --madmurphy Il giorno lun 28 set 2020 alle ore 23:34 madmurphy ha scritto: > I have a project that relies on automatically-built sources, therefore I > have created a BUILT_SOURCES variable in my src/Makefile.am file (see GNU >

bug#43683: make install-exec does not trigger make $(BUILT_SOURCES)

I have a project that relies on automatically-built sources, therefore I have created a BUILT_SOURCES variable in my src/Makefile.am file (see GNU Automake § 9.4 Built Sources <https://www.gnu.org/software/automake/manual/html_node/Built-Sources-Example.html>). Everything works perfectly, h

Re: BUILT_SOURCES called on `make dist` even if the built sources should not be included in the dist

the dist. > > `EXTRA_DIST` only goes so far.  In my own project I use `dist-hook` to > bundle up foreign subdirectories which I am too lazy to fully describe > or which are too fluid to bake into Makefile.am.  For example: I don't really have a problem with the distribution c

Re: BUILT_SOURCES called on `make dist` even if the built sources should not be included in the dist

On Wed, 18 Sep 2019, Jerry Lundström wrote: With v1.16 this step is executed during `make dist` and using `EXTRA_DIST` for that whole directory would also mean that _the built library_ would be included in the dist. `EXTRA_DIST` only goes so far. In my own project I use `dist-hook` to

Re: BUILT_SOURCES called on `make dist` even if the built sources should not be included in the dist

e I can start building my software, this library is included in the project and I run a simple `cd dir && make` in it. With v1.16 this step is executed during `make dist` and using `EXTRA_DIST` for that whole directory would also mean that _the built library_ would be included in the

Re: BUILT_SOURCES called on `make dist` even if the built sources should not be included in the dist

Hi Jerry, On 9/17/19, Jerry Lundström wrote: > This problem seems to have been introduced in v1.16 with: > > - "./configure && make dist" no longer fails when a distributed file > depends on one from BUILT_SOURCES. > > And what I can see in the Makefile output

Re: BUILT_SOURCES called on `make dist` even if the built sources should not be included in the dist

On Tue, 17 Sep 2019, Jerry Lundström wrote: I can't really see how this change got approved, isn't the point of BUILT_SOURCES to be sources built when building!? Including them into distributions seems wrong. I see considerable documentation regarding BUILT_SOURCES at "https://www.gn

BUILT_SOURCES called on `make dist` even if the built sources should not be included in the dist

Hi, This problem seems to have been introduced in v1.16 with: - "./configure && make dist" no longer fails when a distributed file depends on one from BUILT_SOURCES. And what I can see in the Makefile output is that $(BUILT_SOURCES) has been added to distdir. I can't really s

Re: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)

On Tue, Nov 28, 2017 at 8:35 PM, Nick Bowler <nbow...@draconx.ca> wrote: > On 2017-11-28 18:13 -0800, Jim Meyering wrote: >> On Tue, Nov 28, 2017 at 12:45 PM, Nick Bowler <nbow...@draconx.ca> wrote: >> > The Automake manual unequivocally states that BUILT_SOURCES file

Re: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)

On 2017-11-28 18:13 -0800, Jim Meyering wrote: > On Tue, Nov 28, 2017 at 12:45 PM, Nick Bowler <nbow...@draconx.ca> wrote: > > The Automake manual unequivocally states that BUILT_SOURCES files are > > generated only when running 'make all', 'make check' or 'make

Re: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)

On Tue, Nov 28, 2017 at 12:01 PM, Mathieu Lirzin wrote: > Hello Jim, ... >> >> Here's the patch I expect to push to master: ... > > OK to push. Thanks. Pushed. I have also removed the micro branch.

Re: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)

On Tue, Nov 28, 2017 at 12:45 PM, Nick Bowler <nbow...@draconx.ca> wrote: > Hi Jim, > > On 2017-11-28 11:21 -0800, Jim Meyering wrote: >> Date: Thu, 20 Mar 2014 12:31:32 -0700 >> Subject: [PATCH] "make dist" did not depend on $(BUILT_SOURCES) >&g

Re: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)

Hi Jim, On 2017-11-28 11:21 -0800, Jim Meyering wrote: > Date: Thu, 20 Mar 2014 12:31:32 -0700 > Subject: [PATCH] "make dist" did not depend on $(BUILT_SOURCES) > > * lib/am/distdir.am (distdir-am): New intermediate target. > Interpose this target between $(di

Re: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)

ter: > > From: Jim Meyering <meyer...@fb.com> > Date: Thu, 20 Mar 2014 12:31:32 -0700 > Subject: [PATCH] "make dist" did not depend on $(BUILT_SOURCES) > > * lib/am/distdir.am (distdir-am): New intermediate target. > Interpose this target between $(distdir) and

[PATCH] "make dist" did not depend on $(BUILT_SOURCES)

is: src/hello.c:27:10: fatal error: configmake.h: No such file or directory #include "configmake.h" ^~ Here's the patch I expect to push to master: From: Jim Meyering <meyer...@fb.com> Date: Thu, 20 Mar 2014 12:31:32 -0700 Subject: [PATCH] "make dist&

Shouldn’t TAGS depend upon and use BUILT_SOURCES?

Hi! Shouldn’t TAGS depend upon and use BUILT_SOURCES? For example, header files generated by yacc/bison may include things that one would want tagged.

Re: [Automake-NG] [FYI 2/2] built sources: avoid fork bomb in $(BUILT_SOURCES) handling

Le 19 sept. 2012 à 21:49, Stefano Lattarini a écrit : Well, if the user calls make all in the recipe for a $(BUILT_SOURCES), he will still experience a fork bomb, even after this patch -- but that is the case also for mainline Automake, so no regression here. On the other hand, before

Re: [Automake-NG] [FYI 2/2] built sources: avoid fork bomb in $(BUILT_SOURCES) handling

Le 16 sept. 2012 à 20:21, Stefano Lattarini a écrit : Hi Akim. On 09/16/2012 03:48 PM, Akim Demaille wrote: Le 11 sept. 2012 à 16:49, Stefano Lattarini a écrit : Due to how the handling of $(BUILT_SOURCES) was implemented in Automake-NG, a recursive make call in the recipe of any

Re: [Automake-NG] [FYI 2/2] built sources: avoid fork bomb in $(BUILT_SOURCES) handling

On 09/19/2012 03:19 PM, Akim Demaille wrote: Le 16 sept. 2012 à 20:21, Stefano Lattarini a écrit : Hi Akim. On 09/16/2012 03:48 PM, Akim Demaille wrote: Le 11 sept. 2012 à 16:49, Stefano Lattarini a écrit : Due to how the handling of $(BUILT_SOURCES) was implemented in Automake-NG

Re: [Automake-NG] [FYI 2/2] built sources: avoid fork bomb in $(BUILT_SOURCES) handling

Hi Akim. On 09/16/2012 03:48 PM, Akim Demaille wrote: Le 11 sept. 2012 à 16:49, Stefano Lattarini a écrit : Due to how the handling of $(BUILT_SOURCES) was implemented in Automake-NG, a recursive make call in the recipe of any $(BUILT_SOURCES) (or of any of its prerequisites) would have

[Automake-NG] [FYI 2/2] built sources: avoid fork bomb in $(BUILT_SOURCES) handling

Due to how the handling of $(BUILT_SOURCES) was implemented in Automake-NG, a recursive make call in the recipe of any $(BUILT_SOURCES) (or of any of its prerequisites) would have caused an infinite recursion (complete with fork bomb, yuck). Work around the issue. See: http://lists.gnu.org

[Automake-NG] [FYI 1/2] coverage: expose fork bomb in $(BUILT_SOURCES) handling

Due to how the handling of $(BUILT_SOURCES) is implemented in Automake-NG, a recursive make call in the recipe of any $(BUILT_SOURCES) (or of any of its prerequisites) will cause an infinite recursion (complete with fork bomb, yuck). Expose the issue in a test case (still failing, of course

[BUG] Possible hang of make with tricky use of BUILT_SOURCES (was: Re: [PATCH 0/5] build: refactoring and preparations for Automake-NG)

Automake-NG is used to bootstrap the Smalltalk build system. Why should it hang make all? Because of a limitation in how BUILT_SOURCES are handled in Automake-NG. This limitation is the price to pay to allow us avoid an extra recursive make invocation per each Makefile using BUILT_SOURCES

Re: How to use BUILT_SOURCES ?

On Thu, Jun 21, 2012 at 7:20 AM, Timothy Madden terminato...@gmail.com wrote: Hello I have automake 1.11.1 (on CentOS 6.2 x86_64), and a Makefile.am like this: AM_YFLAGS=-d BUILT_SOURCES=position.hh location.hh code-formatter-parser.hh stack.hh bin_PROGRAMS=code-formatter

How to use BUILT_SOURCES ?

Hello I have automake 1.11.1 (on CentOS 6.2 x86_64), and a Makefile.am like this: AM_YFLAGS=-d BUILT_SOURCES=position.hh location.hh code-formatter-parser.hh stack.hh bin_PROGRAMS=code-formatter code_formatter_SOURCES=code-formatter-parser.yy code-formatter-lexer.ll

problem with BUILT_SOURCES and make distcheck

cmap_cns.h $(some files) $(some files) are just a list of files needed to generate the header file 3) I compile mupdf stuff using cmap_cns.h. I do that in mylib/mupdf-0.9/Makefile.am (points 1 and 2 only): [code] noinst_PROGRAMS = cmapdump fontdump BUILT_SOURCES = cmapdump cmap_cns.h cmapdump_SOURCES

Re: on Windows, BUILT_SOURCES does not append .exe

* Vincent Torri wrote on Mon, Nov 22, 2010 at 10:44:31PM CET: On Mon, 22 Nov 2010, Ralf Wildenhues wrote: * Dave Hart wrote on Mon, Nov 22, 2010 at 12:34:47AM CET: In that case you may need to add cmap_tounicode.c to BUILT_SOURCES, leaving cmapdump out of same. That shouldn't be necessary

Re: on Windows, BUILT_SOURCES does not append .exe

don't use BUILT_SOURCES, cmapdump binary is not built before libcmaps, hence cmap_tounicode.c is not created, and compilation of libcmaps fails. Is there another solution ? Yes: just specify cmapdump$(EXEEXT) as prerequisite to cmap_tounicode.c. isn't what the line: cmap_tounicode.c: cmapdump

on Windows, BUILT_SOURCES does not append .exe

Hey, I use: noinst_PROGRAMS = cmapdump fontdump BUILT_SOURCES = cmapdump fontdump With MSYS, noinst_PROGRAMS is set to cmapdump$(EXEEXT) fontdump$(EXEEXT) but BUILT_SOURCES is set to cmapdump fontdump Is it normal that BUILT_SOURCES does not try to see if they are binaries in some

Re: on Windows, BUILT_SOURCES does not append .exe

Hello Vincent, * Vincent Torri wrote on Sun, Nov 21, 2010 at 10:51:53PM CET: noinst_PROGRAMS = cmapdump fontdump BUILT_SOURCES = cmapdump fontdump With MSYS, noinst_PROGRAMS is set to cmapdump$(EXEEXT) fontdump$(EXEEXT) but BUILT_SOURCES is set to cmapdump fontdump Is it normal

Re: on Windows, BUILT_SOURCES does not append .exe

On Sun, 21 Nov 2010, Ralf Wildenhues wrote: Hello Vincent, * Vincent Torri wrote on Sun, Nov 21, 2010 at 10:51:53PM CET: noinst_PROGRAMS = cmapdump fontdump BUILT_SOURCES = cmapdump fontdump With MSYS, noinst_PROGRAMS is set to cmapdump$(EXEEXT) fontdump$(EXEEXT) but BUILT_SOURCES is set

Re: on Windows, BUILT_SOURCES does not append .exe

\ [...] libcmaps_la_SOURCES = cmap_tounicode.c cmap_tounicode.c: cmapdump $(cmap_tounicode_files) ./cmapdump $@ $(cmap_tounicode_files) If I don't use BUILT_SOURCES, cmapdump binary is not built before libcmaps, hence cmap_tounicode.c is not created, and compilation of libcmaps fails

Re: on Windows, BUILT_SOURCES does not append .exe

-0.7/cmaps/Adobe-CNS1-UCS2 \ [...] libcmaps_la_SOURCES = cmap_tounicode.c cmap_tounicode.c: cmapdump $(cmap_tounicode_files) ./cmapdump $@ $(cmap_tounicode_files) If I don't use BUILT_SOURCES, cmapdump binary is not built before libcmaps, hence cmap_tounicode.c is not created

Re: on Windows, BUILT_SOURCES does not append .exe

On Sun, Nov 21, 2010 at 22:44 UTC, Vincent Torri vto...@univ-evry.fr wrote: On Sun, 21 Nov 2010, Ralf Wildenhues wrote: * Vincent Torri wrote on Sun, Nov 21, 2010 at 11:14:23PM CET: If I don't use BUILT_SOURCES, cmapdump binary is not built before libcmaps, hence cmap_tounicode.c

Re: on Windows, BUILT_SOURCES does not append .exe

* Dave Hart wrote on Mon, Nov 22, 2010 at 12:34:47AM CET: On Sun, Nov 21, 2010 at 22:44 UTC, Vincent Torri vto...@univ-evry.fr wrote: On Sun, 21 Nov 2010, Ralf Wildenhues wrote: * Vincent Torri wrote on Sun, Nov 21, 2010 at 11:14:23PM CET: If I don't use BUILT_SOURCES, cmapdump binary

RE: No rule to make target in a BUILT_SOURCES, non-recursive, multi-directory project

Weird. I cannot reproduce your issue with that make version on GNU/Linux. Which file system does this happen on, maybe a case-insensitive one and there is another file in the source or the build tree matching the name (or parts of the dirname) case-insensitively? Great tip! I forgot this

No rule to make target in a BUILT_SOURCES, non-recursive, multi-directory project

I have almost the same situation as a post many years ago. The solution didn't seem to apply, however, http://www.opensubscriber.com/message/automake@gnu.org/3498366.html I am using subdir-objects and I have a single, top-level Makefile.am: #*snip* BUILT_SOURCES = lib_LTLIBRARIES = libfoo.la

Re: No rule to make target in a BUILT_SOURCES, non-recursive, multi-directory project

Hi Jeff, * Daily, Jeff A wrote on Tue, Aug 10, 2010 at 08:54:53PM CEST: I am using subdir-objects and I have a single, top-level Makefile.am: #*snip* BUILT_SOURCES = lib_LTLIBRARIES = libfoo.la libfoo_la_SOURCES = #*snip* If HAVE_PYTHON BUILT_SOURCES += foo/bar/wapi.c foo/bar/wapi.c

RE: No rule to make target in a BUILT_SOURCES, non-recursive, multi-directory project

#*snip* BUILT_SOURCES = lib_LTLIBRARIES = libfoo.la libfoo_la_SOURCES = #*snip* If HAVE_PYTHON BUILT_SOURCES += foo/bar/wapi.c foo/bar/wapi.c: foo/bar/papi.h $(top_srcdir)/build-aux/wapi.py -rm -f foo/bar/wapi.c \ $(PYTHON) $(top_srcdir)/build-aux/wapi.py

Re: No rule to make target in a BUILT_SOURCES, non-recursive, multi-directory project

* Daily, Jeff A wrote on Tue, Aug 10, 2010 at 09:45:43PM CEST: Which make version and implementation, Please answer this one as well.

RE: No rule to make target in a BUILT_SOURCES, non-recursive, multi-directory project

Which make version and implementation, Please answer this one as well. Sorry for missing that. GNU Make 3.81 built for i386-apple-darwin9.0.

appending to BUILT_SOURCES, if appropriate

Hi For one of the projects I work on we need to add something like the following to each Makefile.am to ensure that vcs information is current: vcsID: cd $(top_builddir)/src/lalapps $(MAKE) liblalapps.la BUILT_SOURCES = vcsID As this is going to be the same in each Makefile.am, I would like

Re: appending to BUILT_SOURCES, if appropriate

On 03/11/2010 01:39 PM, Adam Mercer wrote: include path/to/Makefile.common The problem is that some Makefile.am's already define BUILT_SOURCES, whilst some do not. Is there a way that I can append to BUILT_SOURCES, if it already exists, or define it if it doesn't? How about modifying

Re: appending to BUILT_SOURCES, if appropriate

On Thu, Mar 11, 2010 at 14:42, Eric Blake ebl...@redhat.com wrote: How about modifying the makefiles that don't append to BUILT_SOURCES to just add the line BUILT_SOURCES= prior to the include, then use BUILT_SOURCES+= in the included file. Of course, great idea! Thanks! Cheers Adam

Re: BUILT_SOURCES

Hi Russell, beside the typo you already found, * Russell Shaw wrote on Thu, Dec 17, 2009 at 02:07:40PM CET: bin_PROGRAMS = appmain appmain_SOURCES = appmain.c nodist_appmain_SOURCES = gran.proc.tab.c BUILT_SOURCES = gran.proc.tab.c gran.proc.tab.c: gran.spec eerat $ -o gran

BUILT_SOURCES

Hi, BUILT_SOURCES has no effect. gran.proc.tab.c should be built first, but it doesn't happen. eerat isn't even run: bin_PROGRAMS = appmain appmain_SOURCES = appmain.c nodist_appmain_SOURCES = gran.proc.tab.c BUILT_SOURCES: gran.proc.tab.c gran.proc.tab.c: gran.spec eerat $ -o gran

Re: BUILT_SOURCES

Simon Richter wrote: Hi, On Fri, Dec 18, 2009 at 12:07:40AM +1100, Russell Shaw wrote: BUILT_SOURCES: gran.proc.tab.c BUILT_SOURCES is a variable, not a target. Ok Thanks Simon. Should be '=' instead of ':'. I knew that, but i didn't type what i mean ;)

Re: QT Plugins, target build order AND BUILT_SOURCES

Hello Andre, Your example is pretty complex, and doesn't make the problem obvious. Merely adding libCustomPlugin.la to BUILT_SOURCES doesn't seem to introduce a cycle in the build dependencies, at least from a 'make -n' in an example package that has this Makefile.am but no other files. It may

Re: QT Plugins, target build order AND BUILT_SOURCES

with BUILT_SOURCES, but I can't resolve the cycles... Any hints? Best regards Andre System: SuSE 10.2 autoconf-2.60-21 automake-1.9.6-35 Makefile.am - AUTOMAKE_OPTIONS = foreign 1.4 gnu INCLUDES = -I

QT Plugins, target build order AND BUILT_SOURCES

, because there some file with .hpp and some with .h. So I must add some extra suffix rules... When I call make libCustomPlugin.la make qplugin all things works correctly. make all can't build the project... I had gamble a little with BUILT_SOURCES, but I can't resolve the cycles... Any hints

Re: BUILT_SOURCES doesn't seem to work

Hello Bobby, a few comments: On Sat, May 03, 2008 at 11:38:08PM -0700, Bobby Dill wrote: When I try to compile my app, I get a message stating that sigcreatedlg.h does not exist, so the files in BUILT_SOURCES are not generated before the rest of my app is compiled. What's the right way to do

BUILT_SOURCES doesn't seem to work

) BUILT_SOURCES = $(pkgmaker_UI) # set the include path found by configure INCLUDES= $(all_includes) # the library search path. pkgmaker_LDFLAGS = $(all_libraries) pkgmaker_LDADD = ../dirlist/libdirlist.la CLEANFILES = $(BUILT_SOURCES) I get several warning when I run automake. pkgmaker

Re: BUILT_SOURCES doesn't seem to work

Bobby Dill [EMAIL PROTECTED] writes: pkgmaker_UI = sigcreatedlg.h sigcreatedlg.cpp One obvious error is here: the first two lines should end in \. -- [Modern] war is waged by each ruling group against its own subjects, and the object of the war is not to make or prevent conquests of

Re: BUILT_SOURCES automagically made MAINTAINERCLEANFILES

Hello Benoit, * Benoit Sigoure wrote on Fri, Mar 30, 2007 at 10:30:43PM CEST: I've searched in the manual but the following behavior is not documented: [...] # Built sources are automatically removed by maintainer-clean. $clean_files{'$(BUILT_SOURCES)'} = MAINTAINER_CLEAN if var

BUILT_SOURCES automagically made MAINTAINERCLEANFILES

Hello I've searched in the manual but the following behavior is not documented: # handle_clean ($MAKEFILE) # # Handle all 'clean' targets. sub handle_clean ($) { ... # Built sources are automatically removed by maintainer-clean. $clean_files{'$(BUILT_SOURCES

Re: BUILT_SOURCES: dependencies not copied to build_dir

Hi Michael, Tom, * tom fogal wrote on Mon, Mar 27, 2006 at 10:38:27PM CEST: [EMAIL PROTECTED]Michael Biebl writes: snip ngcs_marshal.c: ngcs_marshal.ngci idef.py $(srcdir)/idef.py ngcs_marshal ngcs_marshal.h: ngcs_marshal.ngci idef.py $(srcdir)/idef.py ngcs_marshal Not

Re: BUILT_SOURCES: dependencies not copied to build_dir

Ralf Wildenhues wrote: Hi Michael, Tom, Hi, thanks for you help so far. * tom fogal wrote on Mon, Mar 27, 2006 at 10:38:27PM CEST: [EMAIL PROTECTED]Michael Biebl writes: snip ngcs_marshal.c: ngcs_marshal.ngci idef.py $(srcdir)/idef.py ngcs_marshal ngcs_marshal.h:

Re: BUILT_SOURCES: dependencies not copied to build_dir

Hi Michael, * Michael Biebl wrote on Tue, Mar 28, 2006 at 12:16:18PM CEST: This is the solution I came up with: EXTRA_DIST = ngcs_marshal.ngci idef.py ngcs.py CLEANFILES = ngcs_marshal.h ngcs_marshal.c ngcs_marshal.c: ngcs_marshal.ngci idef.py $(srcdir)/idef.py

Re: BUILT_SOURCES: dependencies not copied to build_dir

Ralf Wildenhues wrote: Hi Michael, * Michael Biebl wrote on Tue, Mar 28, 2006 at 12:16:18PM CEST: This is the solution I came up with: EXTRA_DIST = ngcs_marshal.ngci idef.py ngcs.py CLEANFILES = ngcs_marshal.h ngcs_marshal.c ngcs_marshal.c: ngcs_marshal.ngci idef.py

Re: BUILT_SOURCES: dependencies not copied to build_dir

Hello, On Tue, Mar 28, 2006 at 12:16:18PM +0200, Michael Biebl meant to write: EXTRA_DIST = ngcs_marshal.ngci idef.py ngcs.py CLEANFILES = ngcs_marshal.h ngcs_marshal.c ngcs_marshal.c: ngcs_marshal.ngci idef.py $(srcdir)/idef.py $(srcdir)/ngcs_marshal $@ ngcs_marshal.h:

Re: BUILT_SOURCES: dependencies not copied to build_dir

I forgot to add that I'm not subscribed to the list so please CC on replies. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature

Re: BUILT_SOURCES: dependencies not copied to build_dir

[EMAIL PROTECTED]Michael Biebl writes: snip ngcs_marshal.c: ngcs_marshal.ngci idef.py $(srcdir)/idef.py ngcs_marshal ngcs_marshal.h: ngcs_marshal.ngci idef.py $(srcdir)/idef.py ngcs_marshal Not sure if it will work, but perhaps you could just use the .ngci file without copying

Re: How to use BUILT_SOURCES in non-recursive, multi-directory project?

I wrote: .fl.h: d=`dirname [EMAIL PROTECTED] ; \ f=`basename $@ .h`.fl ; \ cp $ $(top_builddir)/$$d/$$f ; \ cd $(top_builddir)/$$d ; \ fluid -c $$f BUILT_SOURCES += src/foo.h Ralf replied: dirname and basename

Re: How to use BUILT_SOURCES in non-recursive, multi-directory project?

$ $(top_builddir)/$$d/$$f ; \ cd $(top_builddir)/$$d ; \ fluid -c $$f BUILT_SOURCES += src/foo.h nodist_src_libfoo_a_SOURCES = src/foo.cxx src_foo_test_LDADD = src/libfoo.a $(FLTK_LIBRARYS) src_foo_test_LDFLAGS = $(FLTK_LDSFLAGS

Re: How to use BUILT_SOURCES in non-recursive, multi-directory project?

On Thu, 9 Mar 2006, Ralf Wildenhues wrote: dirname and basename are not portable to ancient hosts. In practice they will work fine, though. I'd write I know that dirname is not, but what platform did not support basename? -- Thomas E. Dickey http://invisible-island.net

Re: How to use BUILT_SOURCES in non-recursive, multi-directory project?

* Thomas Dickey wrote on Thu, Mar 09, 2006 at 08:13:07PM CET: On Thu, 9 Mar 2006, Ralf Wildenhues wrote: dirname and basename are not portable to ancient hosts. In practice they will work fine, though. I'd write I know that dirname is not, but what platform did not support basename? No

Re: How to use BUILT_SOURCES in non-recursive, multi-directory project?

On Thu, 9 Mar 2006, Ralf Wildenhues wrote: * Thomas Dickey wrote on Thu, Mar 09, 2006 at 08:13:07PM CET: On Thu, 9 Mar 2006, Ralf Wildenhues wrote: dirname and basename are not portable to ancient hosts. In practice they will work fine, though. I'd write I know that dirname is not, but

Re: How to use BUILT_SOURCES in non-recursive, multi-directory project?

On Mar 9, 2006, at 11:51 AM, Thomas Dickey wrote: On Thu, 9 Mar 2006, Ralf Wildenhues wrote: * Thomas Dickey wrote on Thu, Mar 09, 2006 at 08:13:07PM CET: On Thu, 9 Mar 2006, Ralf Wildenhues wrote: dirname and basename are not portable to ancient hosts. In practice they will work fine,

Re: How to use BUILT_SOURCES in non-recursive, multi-directory project?

On Thu, 9 Mar 2006, Thomas 'Tom' R. Treadway III wrote: On Mar 9, 2006, at 11:51 AM, Thomas Dickey wrote: hmm - I can remember when it was a problem (around 1990), but can't recall whether it was Apollo SR9, SunOS 3 or HPUX. You did say ancient... The dirname utility originated in System III.

Re: How to use BUILT_SOURCES in non-recursive, multi-directory project?

On Mar 9, 2006, at 12:57 PM, Thomas Dickey wrote: On Thu, 9 Mar 2006, Thomas 'Tom' R. Treadway III wrote: On Mar 9, 2006, at 11:51 AM, Thomas Dickey wrote: hmm - I can remember when it was a problem (around 1990), but can't recall whether it was Apollo SR9, SunOS 3 or HPUX. You did say

Re: Adding BUILT_SOURCES to a multi-directory, non-recursive project

Alexandre Duret-Lutz [EMAIL PROTECTED] wrote: lots of helpful things... Thanks. I will look into your suggestions this evening. No doubt you have noticed that I reposted a more up to date version of src/Makefile.am that does handle some of these problems better, and I have made even further

Re: Adding BUILT_SOURCES to a multi-directory, non-recursive project

BUILT_SOURCES += src/foo.h DG src_libfoo_a_SOURCES = src/foo.fl DG src_foo_test_LDADD = src/libfoo.a $(FLTK_LIBRARYS) DG src_foo_test_LDFLAGS = $(FLTK_LDSFLAGS) DG src_foo_test_SOURCES = src/foo_test.cxx DG My problem is that if I create a separate build directory, and run DG sh ../configure and make

How to use BUILT_SOURCES in non-recursive, multi-directory project?

) However, it's taken me several evenings of experimentation, not to mention frustration, to try to marry the BUILT_SOURCES needed for the two stage build with the non-recursive auto{conf,make} configuration, and also be able to run 'configure' and 'make' in a new directory outside the source tree. What I

Adding BUILT_SOURCES to a multi-directory, non-recursive project

I was given help two weeks ago in the thread Autoconfisticating a multi-directory, non-recursive, GNU-make specific project (see http://lists.gnu.org/archive/html/automake/2006-02/msg00036.html) Three years ago on this list, I was helped with BUILT_SOURCES in the thread How to specify 2 stage

document .ypp and .lpp (Was: Re: Automake doesn't invoke bison even with BUILT_SOURCES)

RW == Ralf Wildenhues [EMAIL PROTECTED] writes: [...] RW I noted that .ypp is not documented. The patch below (against RW CVS Automake) fixes this. Thanks. RW * doc/automake.texi (Yacc and Lex): Document that `.ypp' and RW `.lpp' file extensions are recognized. RW Index:

Re: Automake doesn't invoke bison even with BUILT_SOURCES

Could you modify it so that it fails for you? I updated my automake 1.6 to automake 1.9 and I autoreconfigured all. It works well now. Thanks for your help.

Re: BUILT_SOURCES too clumsy

In the meantime I have patched automake, e.g. diff -ur automake-1.9.5/lib/am/library.am automake-1.9.5.new/lib/am/library.am --- automake-1.9.5/lib/am/library.am2003-06-02 09:08:40.0 +0200 +++ automake-1.9.5.new/lib/am/library.am 2005-05-22 20:22:51.0 +0200 @@ -15,6 +15,7 @@

Re: BUILT_SOURCES too clumsy

Hi, On Sun, May 22, 2005 at 05:02:09PM +0200, Harald Dunkel wrote: The targets in BUILT_SOURCES are unconditionally built for 'make all' and 'make install' and 'make check'. Very clumsy. yes, it is. Yet it can be useful in certain situations. I would like to generate some code

  1   2   >