bug#62791: BUILT_SOURCES not honoured in parallel build?

[Karl Berry]

Patch attached.

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

bug#62791: BUILT_SOURCES not honoured in parallel build?

[Reuben Thomas via Bug reports for Automake]

On Sat, 9 Dec 2023 at 15:16, Reuben Thomas  wrote:

>
> If you're happy with that, I'll write a patch.
>

Patch attached.

-- 
https://rrt.sc3d.org
From 06f6765b7d10132d0dcefde1265b4d5f01df76b4 Mon Sep 17 00:00:00 2001
From: Reuben Thomas 
Date: Sat, 9 Dec 2023 15:20:44 +0200
Subject: [PATCH] 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 deletions(-)

diff --git a/doc/automake.texi b/doc/automake.texi
index e53a44332..77292288d 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -6329,7 +6329,8 @@ extensions @file{.l}, @file{.ll}, @file{.l++}, @file{.lxx}, and
 @file{.lpp} are recognized.
 
 You should never explicitly mention the intermediate (C or C++) file
-in any @code{SOURCES} variable; only list the source file.
+in any @code{SOURCES} variable (except @code{BUILT_SOURCES}, see below);
+only list the source file.
 
 The intermediate files generated by @command{yacc} (or @command{lex})
 will be included in any distribution that is made.  That way the user
@@ -6359,11 +6360,11 @@ What Automake cannot guess, though, is where this header will be used:
 it is up to you to ensure the header gets built before it is first
 used.  Typically this is necessary in order for dependency tracking to
 work when the header is included by another file.  The common solution
-is listing the header file in @code{BUILT_SOURCES} (@pxref{Sources})
-as follows.
+is listing the header file, and the corresponding C file, in
+@code{BUILT_SOURCES} (@pxref{Sources}) as follows.
 
 @example
-BUILT_SOURCES = parser.h
+BUILT_SOURCES = parser.h parser.c
 AM_YFLAGS = -d
 bin_PROGRAMS = foo
 foo_SOURCES = @dots{} parser.y @dots{}
-- 
2.34.1

bug#62791: BUILT_SOURCES not honoured in parallel build?

[Reuben Thomas via Bug reports for Automake]

On Sat, 9 Dec 2023 at 00:03, Karl Berry  wrote:

> The manual currently says: "You should never explicitly mention the
> intermediate (C or C++) file in any `SOURCES' variable; only list
> the source file."
>
> I don't know the code here, and this probably wasn'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
> reaction is to add "(except @code{BUILT_SOURCES}, see below)".
>
> Later, it talks about adding the header file to
> "BUIILT_SOURCES". This seems at odds with what Mike said and I found
> empirically.
>
> I suggest that we could just say to add both files, although if you want
> to try to understand what's actually going on, more power to you :).
>

In terms of solving the problem, that would seem the safer option.

If you're happy with that, I'll write a patch.

-- 
https://rrt.sc3d.org

bug#62791: BUILT_SOURCES not honoured in parallel build?

[Karl Berry]

The manual currently says: "You should never explicitly mention the
intermediate (C or C++) file in any `SOURCES' variable; only list
the source file."  

I don't know the code here, and this probably wasn'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),
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 file to
"BUIILT_SOURCES". This seems at odds with what Mike said and I found
empirically.

I suggest that we could just say to add both files, although if you want
to try to understand what's actually going on, more power to you :).

Best,
Karl

bug#62791: BUILT_SOURCES not honoured in parallel build?

[Reuben Thomas via Bug reports for Automake]

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 currently says: "You should never explicitly mention the
intermediate (C or C++) file in any ‘SOURCES’ variable; only list the
source file." Later, it talks about adding the header file to
"BUIILT_SOURCES". This seems at odds with what Mike said and I found
empirically.

-- 
https://rrt.sc3d.org

bug#62791: BUILT_SOURCES not honoured in parallel build?

[Karl Berry]

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?

[Reuben Thomas via Bug reports for Automake]

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/.l example to the manual.  i think i tripped over
> this
> error myself in a project in the past.  i think you want to list both
> files.
>

Thanks for the tip; on a belt-and-braces basis, it seems it can't hurt
anyway, so I've added the .h file back as well.

-- 
https://rrt.sc3d.org

bug#62791: BUILT_SOURCES not honoured in parallel build?

[Mike Frysinger]

On 12 Apr 2023 18:14, Reuben Thomas via Bug reports for Automake wrote:
> On Wed, 12 Apr 2023 at 17:59, Reuben Thomas  wrote:
> > 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 checkout, to reproduce this problem. It seems that I must be
> > doing something wrong, 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 this
error myself in a project in the past.  i think you want to list both files.
-mike


signature.asc
Description: PGP signature

bug#62791: BUILT_SOURCES not honoured in parallel build?

[Reuben Thomas via Bug reports for Automake]

On Wed, 12 Apr 2023 at 17:59, Reuben Thomas  wrote:

> 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 checkout, to reproduce this problem. It seems that I must be
> doing something wrong, 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.

-- 
https://rrt.sc3d.org

bug#62791: BUILT_SOURCES not honoured in parallel build?

[Reuben Thomas via Bug reports for Automake]

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 checkout, to reproduce this problem. It seems that I must be
doing something wrong, but I can't work out what!

-- 
https://rrt.sc3d.org

bug#62791: BUILT_SOURCES not honoured in parallel build?

[Reuben Thomas via Bug reports for Automake]

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:

$ make all
make  all-am
make[1]: Entering directory '/home/rrt/.local/var/repo/a2ps/src'
  YACC parsessh.c
  CC   libparse_a-lexssh.o
/home/rrt/repo/a2ps/src/ylwrap1077905
lexssh.c:38:11: fatal error: parsessh.h: No such file or directory
   38 |  #include "parsessh.h"
  |   ^~~~
compilation terminated.
make[1]: *** [Makefile:1710: libparse_a-lexssh.o] Error 1
make[1]: *** Waiting for unfinished 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/git/a2ps.git

-- 
https://rrt.sc3d.org

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

[Karl Berry]

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

[Allison Karlitskaya]

[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 manpage content from --help output).  This default
behaviour might be "too much" for other projects, though, so add a new
option "pure-dist" to disable it.

* NEWS:
* bin/automake.in:
* doc/automake.texi: Add a new option "pure-dist" to disable the
dependency of distdir: on $(BUILT_SOURCES).
* t/pure-dist.sh:
* t/impure-dist.sh: Add a pair of tests for a similar scenario with and
  without the option.

Fixes automake bug https://debbugs.gnu.org/49317
---
 NEWS|  3 ++
 bin/automake.in |  3 +-
 doc/automake.texi   |  7 +
 lib/Automake/Options.pm |  1 +
 lib/am/distdir.am   |  5 
 t/impure-dist.sh|  1 +
 t/pure-dist.sh  | 66 +
 7 files changed, 85 insertions(+), 1 deletion(-)
 create mode 12 t/impure-dist.sh
 create mode 100644 t/pure-dist.sh
From 1f46cc63475b8af1a52e84ae329bb4c00ce291e3 Mon Sep 17 00:00:00 2001
From: Allison Karlitskaya 
Date: Fri, 2 Jul 2021 14:37:06 +0200
Subject: [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 manpage content from --help output).  This default
behaviour might be "too much" for other projects, though, so add a new
option "pure-dist" to disable it.

* NEWS:
* bin/automake.in:
* doc/automake.texi: Add a new option "pure-dist" to disable the
dependency of distdir: on $(BUILT_SOURCES).
* t/pure-dist.sh:
* t/impure-dist.sh: Add a pair of tests for a similar scenario with and
  without the option.

Fixes automake bug https://debbugs.gnu.org/49317
---
 NEWS|  3 ++
 bin/automake.in |  3 +-
 doc/automake.texi   |  7 +
 lib/Automake/Options.pm |  1 +
 lib/am/distdir.am   |  5 
 t/impure-dist.sh|  1 +
 t/pure-dist.sh  | 66 +
 7 files changed, 85 insertions(+), 1 deletion(-)
 create mode 12 t/impure-dist.sh
 create mode 100644 t/pure-dist.sh

diff --git a/NEWS b/NEWS
index 5e92387e2..71602e768 100644
--- a/NEWS
+++ b/NEWS
@@ -14,6 +14,9 @@ New in ?.?.?:
   --with-python_prefix and --with-python_exec_prefix supported,
   to specify explicitly.
 
+  - the new option "pure-dist" skips generating $(BUILT_SOURCES) before
+  building the tarball as part of "make dist"
+
 * Bugs fixed
 
   - automake output reproducible.
diff --git a/bin/automake.in b/bin/automake.in
index 19ea9538f..bb18790a0 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -3900,7 +3900,8 @@ sub handle_dist ()
   $output_rules .= file_contents ('distdir',
   new Automake::Location,
   %transform,
-  FILENAME_FILTER => $filename_filter);
+  FILENAME_FILTER => $filename_filter,
+  PURE_DIST => !! option 'pure-dist');
 }
 
 
diff --git a/doc/automake.texi b/doc/automake.texi
index 351b0a1bb..c043e864d 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -10403,6 +10403,13 @@ disable automatic dependency tracking.
 Don't emit any code related to @code{dist} target.  This is useful
 when a package has its own method for making distributions.
 
+@item @option{pure-dist}
+@cindex Option, @option{pure-dist}
+@opindex pure-dist
+Don't build @code{BUILT_SOURCES} as part of @code{dist}.  This option
+can be set if building the distribution only requires the source files,
+and doesn't compile anything as a side-effect.
+
 @item @option{no-dist-gzip}
 @cindex Option, @option{no-dist-gzip}
 @opindex no-dist-gzip
diff --git a/lib/Automake/Options.pm b/lib/Automake/Options.pm
index b846fee87..37e2bb14b 100644
--- a/lib/Automake/Options.pm
+++ b/lib/Automake/Options.pm
@@ -289,6 +289,7 @@ sub _is_valid_easy_option ($)
 no-installman
 no-texinfo.tex
 nostdinc
+pure-dist
 readme-alpha
 serial-tests
 parallel-tests
diff --git a/lib/am/distdir.am b/lib/am/distdir.am
index 774d08b91..a18892d9d 100644
--- a/lib/am/distdir.am
+++ b/lib/am/distdir.am
@@ -75,8 +75,13 @@ if %?SUBDIRS%
 AM_RECURSIVE_TARGETS += distdir distdir-am
 endif %?SUBDIRS%
 
+if %?PURE_DIST%
+distdir:
+	$(MAKE) $(AM_MAKEFLAGS) distdir-am
+else !%?PURE_DIST%
 distdir: $(BUILT_SOURCES)
 	$(MAKE) $(AM_MAKEFLAGS) distdir-am
+endif !%?PURE_DIST%
 
 distdir-am: $(DISTFILES)
 ##
diff --git a/t/impure-dist.sh b/t/impure-dist.sh
new file mode 12
index 0..0f8c349cd
--- /dev/null
+++ b/t/impure-dist.sh
@@ -0,0 +1 @@
+pure-dist.sh
\ No newline at end of file
diff --git a/t/pure-dist.sh

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

[Karl Berry]

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-using projects
seems to be much too large of a hammer to solve that specific problem.

I tend to agree, but at this point I would not want to create an
incompatibility by undoing it. Instead, I guess a new option (for
AUTOMAKE_OPTIONS) would be needed. A patch would be welcome.

Jim, maybe you have other/more ideas ... --thanks, karl.

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

[Allison Karlitskaya]

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, check, install-exec, ...

`make dist` doesn't compile the program, though: it distributes the
sources.  And usually generated files are not distributed.  If they
were to be disted, they could be listed explicitly for being disted
(for example in a _SOURCES variable or so).  We go out of the way to
put our compiled sources in nodist_ variables, and indeed, they're not
disted.

But because of the above dependency `make dist` still builds them (and
then ignores them).

Of course, there might be a edgecase where the disted tarball should
contain content that is output by a C program which needs to be
compiled and contains, itself, some generated sources.  Indeed, this
change was introduced in 2017, in this commit:

commit ac47c22e3c0c8b055cdd47ccd18621c56f807b37
Author: Jim Meyering 
AuthorDate: Thu Mar 20 12:31:32 2014 -0700
Commit: Jim Meyering 
CommitDate: Tue Nov 28 19:05:59 2017 -0800

"make dist" did not depend on $(BUILT_SOURCES)

in response to this report:

https://lists.gnu.org/r/bug-hello/2014-03/msg00016.html

GNU Hello builds its manpage (which it dists) by building and running
the binary and capturing its --help output.

A blanket depend on $(BUILT_SOURCES) for all automake-using projects
seems to be much too large of a hammer to solve that specific problem.

Thanks very much,

Allison Karlitskaya

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

[madmurphy]

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 pushed it, with small modifications. Please report back if
> problems persist. Meanwhile, closing this bug. Thanks again! --karl
>

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

[madmurphy]

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 pushed it, with small modifications. Please report back if
> problems persist. Meanwhile, closing this bug. Thanks again! --karl
>

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

[Karl Berry]

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 again! --karl

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

[Karl Berry]

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 again! --karl

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

[madmurphy]

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.

--madmurphy


libfoo.tar.xz
Description: Binary data

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

[Karl Berry]

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

[madmurphy]

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 that solves the problem, and I guess this is the place where to
submit it. Please find it attached.

--madmurphy


patch.tar.xz
Description: application/xz

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

[madmurphy]

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
> Automake § 9.4 Built Sources
> <https://www.gnu.org/software/automake/manual/html_node/Built-Sources-Example.html>).
> Everything works perfectly, however I have noticed that if I launch make
> install before launching make all the sources are correctly built, but
> the same does not happen if I launch make install-exec before launching make
> all. So I have examined the generated src/Makefile, and I have found the
> reason.
>
> Currently src/Makefile.am generates the following code in src/Makefile:
>
> install: $(BUILT_SOURCES)
> $(MAKE) $(AM_MAKEFLAGS) install-am
>
> install-exec: install-exec-am
>
> Evidently install and install-exec are treated differently, and the
> second one does not build any source. I believe that the correct generated
> code for src/Makefile should be instead:
>
> install: $(BUILT_SOURCES)
>     $(MAKE) $(AM_MAKEFLAGS) install-am
>
> install-exec: $(BUILT_SOURCES)
> $(MAKE) $(AM_MAKEFLAGS) install-exec-am
>
> Cheers and thanks, GNU folks, for your incredible work.
>
> --madmurphy
>


patch.tar.xz
Description: application/xz

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

[madmurphy]

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, however I have noticed that if I launch make
install before launching make all the sources are correctly built, but the
same does not happen if I launch make install-exec before launching make all.
So I have examined the generated src/Makefile, and I have found the reason.

Currently src/Makefile.am generates the following code in src/Makefile:

install: $(BUILT_SOURCES)
$(MAKE) $(AM_MAKEFLAGS) install-am

install-exec: install-exec-am

Evidently install and install-exec are treated differently, and the second
one does not build any source. I believe that the correct generated code
for src/Makefile should be instead:

install: $(BUILT_SOURCES)
$(MAKE) $(AM_MAKEFLAGS) install-am

install-exec: $(BUILT_SOURCES)
$(MAKE) $(AM_MAKEFLAGS) install-exec-am

Cheers and thanks, GNU folks, for your incredible work.

--madmurphy

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

[Jerry Lundström]

Hi Bob,

On 9/18/19 3:22 PM, Bob Friesenhahn wrote:
> 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
> 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 created, the issue
is why `BUILT_SOURCES` are called on `make dist`.

That could have been solved with the same `dist-hook` you use, and no
change to the existing logic would have been needed.

Cheers,
Jerry

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

[Bob Friesenhahn]

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 
bundle up foreign subdirectories which I am too lazy to fully 
describe or which are too fluid to bake into Makefile.am.  For 
example:


# Non-Automake subdirectories to distribute
DISTDIRS = locale scripts www PerlMagick TclMagick
dist-hook:
( \
  builddir=`pwd` ; \
  cd $(srcdir) && \
  ( \
for dir in $(DISTDIRS) ; do \
  find $$dir -depth -print | egrep -v 
'(~$$)|(/\.hg)|(/\.#)|(/\.deps)|(\.pyc)' \
| cpio -pdum $$builddir/$(distdir) 2> /dev/null ; \
done \
  ) \
)

--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

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

[Jerry Lundström]

Hi Nick,

On 9/17/19 8:25 PM, Nick Bowler wrote:
> ... I just ran this example with Automake 1.16.1 and neither ext/built.c
> nor ext/built.o are included in the distribution tar file generated by
> 'make dist'.

Exactly! Then why are they built during `make dist`?

$ make dist
make  dist-gzip am__post_remove_distdir='@:'
make[1]: Entering directory '/home/buildbot/tmp'
 >> echo "int sdkjfhskjhfskjd(void){ return 0; }" > ext/built.c
 >> gcc -c ext/built.c -o ext/built.o


My non-example project has a 3rd party library that needs to be built
before 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 dist.

This change to were `BUILT_SOURCES` is used feel like a quick fix, would
have been a lot nicer if something like `BUILT_DIST_SOURCES` had been
added instead of changing the meaning of an existing step.


Also, the documentation is now wrong:


<https://www.gnu.org/software/automake/manual/html_node/Built-Sources-Example.html#Built-Sources-Example>

> However, as said earlier, BUILT_SOURCES applies only to the all, check, and 
> install targets. It still fails if you try to run ‘make foo’ explicitly: 

Cheers,
Jerry

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

[Nick Bowler]

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 is that $(BUILT_SOURCES) has
> been added to distdir.
>
> 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'm not sure exactly what the problem you are having is, because ...

[...]
> Here is an example:
>
> ```
> bin_PROGRAMS = test
>
> EXTRA_DIST = ext/TEST
>
> test_SOURCES = main.c
> test_LDADD = ext/built.o
>
> BUILT_SOURCES = ext/built.o
>
> ext/built.o:
>   echo "int sdkjfhskjhfskjd(void){ return 0; }" > ext/built.c
>   gcc -c ext/built.c -o ext/built.o
>
> CLEANFILES = ext/built.c ext/built.o
> ```

... I just ran this example with Automake 1.16.1 and neither ext/built.c
nor ext/built.o are included in the distribution tar file generated by
'make dist'.

So it seems to be working exactly as you wanted it to work.

Cheers,
  Nick

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

[Bob Friesenhahn]

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.gnu.org/software/automake/manual/html_node/Sources.html;


It seems that there is a chicken and egg issue that BUILT_SOURCES is 
designed to solve.


"The BUILT_SOURCES variable is a workaround for this problem. A source 
file listed in BUILT_SOURCES is made on ‘make all’ or ‘make check’ (or 
even ‘make install’) before other targets are processed. However, such 
a source file is not compiled unless explicitly requested by 
mentioning it in some other _SOURCES variable."


Unfortunately, I think that it the BUILT_SOURCES requirement which 
makes my non-recursive build still a bit recursive.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

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

[Jerry Lundström]

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 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.

How can I build sources, which should not be distributed, before normal
targets without getting this call on `make dist`?


Here is an example:

```
bin_PROGRAMS = test

EXTRA_DIST = ext/TEST

test_SOURCES = main.c
test_LDADD = ext/built.o

BUILT_SOURCES = ext/built.o

ext/built.o:
echo "int sdkjfhskjhfskjd(void){ return 0; }" > ext/built.c
gcc -c ext/built.c -o ext/built.o

CLEANFILES = ext/built.c ext/built.o
```

And the `make dist` output:

```
$ make dist
make  dist-gzip am__post_remove_distdir='@:'
make[1]: Entering directory '/home/buildbot/tmp'
echo "int sdkjfhskjhfskjd(void){ return 0; }" > ext/built.c
gcc -c ext/built.c -o ext/built.o
make  distdir-am
make[2]: Entering directory '/home/buildbot/tmp'
if test -d "test-1.0.0"; then find "test-1.0.0" -type d ! -perm -200
-exec chmod u+w {} ';' && rm -rf "test-1.0.0" || { sleep 5 && rm -rf
"test-1.0.0"; }; else :; fi
test -d "test-1.0.0" || mkdir "test-1.0.0"
test -n "" \
|| find "test-1.0.0" -type d ! -perm -755 \
-exec chmod u+rwx,go+rx {} \; -o \
  ! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
  ! -type d ! -perm -400 -exec chmod a+r {} \; -o \
  ! -type d ! -perm -444 -exec /bin/bash /home/buildbot/tmp/install-sh
-c -m a+r {} {} \; \
|| chmod -R a+r "test-1.0.0"
make[2]: Leaving directory '/home/buildbot/tmp'
tardir=test-1.0.0 && ${TAR-tar} chof - "$tardir" | eval GZIP= gzip
--best -c >test-1.0.0.tar.gz
make[1]: Leaving directory '/home/buildbot/tmp'
if test -d "test-1.0.0"; then find "test-1.0.0" -type d ! -perm -200
-exec chmod u+w {} ';' && rm -rf "test-1.0.0" || { sleep 5 && rm -rf
"test-1.0.0"; }; else :; fi
```

Cheers,
Jerry

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

[Jim Meyering]

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 files are
>> > generated only when running 'make all', 'make check' or 'make install'.
>> >
>> > So if they are going to be generated on 'make dist' as well, then the
>> > manual needs a corresponding update.
>>
>> Hi Nick,
>> Thanks for the suggestion, but I do not think it is desired. "make
>> dist" is already defined as building everything that goes into the
>> distribution tarball, and that implies it must also build anything
>> (e.g., from BUILT_SOURCES) that happens to be required to do that.
>
> I agree that it *should* but not that it *must*, because BUILT_SOURCES
> explicitly (by design) bypasses the usual prerequisite mechanisms.
>
> If you use normal prerequisites instead of BUILT_SOURCS everything
> works just fine wrt. distribution, of course, and is the approach I
> would personally recommend in all cases.
>
>> Perhaps more importantly, this is an implementation detail that feels
>> like it should not be made part of the contract that the documentation
>> provides ...
>
> But now with the change applied, as it stands the documentation is
> simply wrong.  For example, this passage from the manual (§9.4 Built
> Sources):
>
>   "... BUILT_SOURCES is honored only by ‘make all’, ‘make check’ and
>   ‘make install’."
>
> is no longer true.  This error can be corrected without explicitly
> documenting the new behaviour, for example by making the list of
> targets non-exhaustive in nature.
>
> Perhaps something like:
>
>   ... BUILT_SOURCES is honored only by certain targets, including ‘make
>   all’, ‘make check’ and ‘make install’.

Thanks for keeping us honest.
That sounds reasonable. Send a patch?

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

[Nick Bowler]

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 install'.
> >
> > So if they are going to be generated on 'make dist' as well, then the
> > manual needs a corresponding update.
> 
> Hi Nick,
> Thanks for the suggestion, but I do not think it is desired. "make
> dist" is already defined as building everything that goes into the
> distribution tarball, and that implies it must also build anything
> (e.g., from BUILT_SOURCES) that happens to be required to do that.

I agree that it *should* but not that it *must*, because BUILT_SOURCES
explicitly (by design) bypasses the usual prerequisite mechanisms.

If you use normal prerequisites instead of BUILT_SOURCS everything
works just fine wrt. distribution, of course, and is the approach I
would personally recommend in all cases.

> Perhaps more importantly, this is an implementation detail that feels
> like it should not be made part of the contract that the documentation
> provides ...

But now with the change applied, as it stands the documentation is
simply wrong.  For example, this passage from the manual (§9.4 Built
Sources):

  "... BUILT_SOURCES is honored only by ‘make all’, ‘make check’ and
  ‘make install’."

is no longer true.  This error can be corrected without explicitly
documenting the new behaviour, for example by making the list of
targets non-exhaustive in nature.

Perhaps something like:

  ... BUILT_SOURCES is honored only by certain targets, including ‘make
  all’, ‘make check’ and ‘make install’.

Although not mentioning distribution at all means that someone reading
this section is left to figure out for themselves if and how these two
Automake features work together...

> ... in case some day automake tightens up "make dist" so it builds
> only those BUILT_SOURCES files that are actually required to build
> the tarball components.

There is need to worry about this ever happening, because computing
such a subset of BUILT_SOURCES is impossible in general.

Cheers,
  Nick

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

[Jim Meyering]

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)

[Jim Meyering]

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)
>>
>> * lib/am/distdir.am (distdir-am): New intermediate target.
>> Interpose this target between $(distdir) and its dependency
>> on $(DISTFILES), so that we can ensure $(BUILT_SOURCES) are
>> all created before we begin creating $(DISTFILES).
> [...]
>>  NEWS   |  3 +++
>>  lib/am/distdir.am  |  7 --
>>  t/dist-vs-built-sources.sh | 56 
>> ++
>>  t/list-of-tests.mk |  1 +
>>  4 files changed, 65 insertions(+), 2 deletions(-)
>>  create mode 100644 t/dist-vs-built-sources.sh
>
> The Automake manual unequivocally states that BUILT_SOURCES files are
> generated only when running 'make all', 'make check' or 'make install'.
>
> So if they are going to be generated on 'make dist' as well, then the
> manual needs a corresponding update.

Hi Nick,
Thanks for the suggestion, but I do not think it is desired. "make
dist" is already defined as building everything that goes into the
distribution tarball, and that implies it must also build anything
(e.g., from BUILT_SOURCES) that happens to be required to do that.
Perhaps more importantly, this is an implementation detail that feels
like it should not be made part of the contract that the documentation
provides, in case some day automake tightens up "make dist" so it
builds only those BUILT_SOURCES files that are actually required to
build the tarball components.

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

[Nick Bowler]

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 $(distdir) and its dependency
> on $(DISTFILES), so that we can ensure $(BUILT_SOURCES) are
> all created before we begin creating $(DISTFILES).
[...]
>  NEWS   |  3 +++
>  lib/am/distdir.am  |  7 --
>  t/dist-vs-built-sources.sh | 56 
> ++
>  t/list-of-tests.mk |  1 +
>  4 files changed, 65 insertions(+), 2 deletions(-)
>  create mode 100644 t/dist-vs-built-sources.sh

The Automake manual unequivocally states that BUILT_SOURCES files are
generated only when running 'make all', 'make check' or 'make install'.

So if they are going to be generated on 'make dist' as well, then the
manual needs a corresponding update.

Otherwise this looks like a useful improvement.

Cheers,
  Nick

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

[Mathieu Lirzin]

Hello Jim,

Jim Meyering <j...@meyering.net> writes:

> I was dismayed to discover this patch I wrote over three years ago.
> Today I confirmed that the problem still remains by running these commands:
>
>   git clone git://git.sv.gnu.org/hello.git \
> cd hello && ./bootstrap && ./configure && env make dist
>
> It failed like this:
>
>   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" did not depend on $(BUILT_SOURCES)
>
> * lib/am/distdir.am (distdir-am): New intermediate target.
> Interpose this target between $(distdir) and its dependency
> on $(DISTFILES), so that we can ensure $(BUILT_SOURCES) are
> all created before we begin creating $(DISTFILES).
> * t/dist-vs-built-sources.sh: Test for this.
> * t/list-of-tests.mk (handwritten_TESTS): Add it.
> * NEWS (Bugs fixed): Mention it.
> Assaf Gordon reported that "make dist" (after ./configure
> from a pristine clone of GNU hello) would fail due to the
> absence of configmake.h while compiling lib/localcharset.c.
> https://lists.gnu.org/r/bug-hello/2014-03/msg00016.html
> ---
>  NEWS   |  3 +++
>  lib/am/distdir.am  |  7 --
>  t/dist-vs-built-sources.sh | 56 
> ++
>  t/list-of-tests.mk |  1 +
>  4 files changed, 65 insertions(+), 2 deletions(-)
>  create mode 100644 t/dist-vs-built-sources.sh

OK to push.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

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

[Jim Meyering]

I was dismayed to discover this patch I wrote over three years ago.
Today I confirmed that the problem still remains by running these commands:

  git clone git://git.sv.gnu.org/hello.git \
cd hello && ./bootstrap && ./configure && env make dist

It failed like this:

  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" did not depend on $(BUILT_SOURCES)

* lib/am/distdir.am (distdir-am): New intermediate target.
Interpose this target between $(distdir) and its dependency
on $(DISTFILES), so that we can ensure $(BUILT_SOURCES) are
all created before we begin creating $(DISTFILES).
* t/dist-vs-built-sources.sh: Test for this.
* t/list-of-tests.mk (handwritten_TESTS): Add it.
* NEWS (Bugs fixed): Mention it.
Assaf Gordon reported that "make dist" (after ./configure
from a pristine clone of GNU hello) would fail due to the
absence of configmake.h while compiling lib/localcharset.c.
https://lists.gnu.org/r/bug-hello/2014-03/msg00016.html
---
 NEWS   |  3 +++
 lib/am/distdir.am  |  7 --
 t/dist-vs-built-sources.sh | 56 ++
 t/list-of-tests.mk |  1 +
 4 files changed, 65 insertions(+), 2 deletions(-)
 create mode 100644 t/dist-vs-built-sources.sh

diff --git a/NEWS b/NEWS
index dd057b7b1..7d52aeb93 100644
--- a/NEWS
+++ b/NEWS
@@ -113,6 +113,9 @@ New in ?.?.?:
   - Installed 'aclocal' m4 macros can now accept installation directories
 containing '@' characters (automake bug#20903)

+  - "./configure && make dist" no longer fails when a distributed file depends
+on one from BUILT_SOURCES.
+
   - When combining AC_LIBOBJ or AC_FUNC_ALLOCA with the
 "--disable-dependency-tracking" configure option in an out of source
 build, the build sub-directory defined by AC_CONFIG_LIBOBJ_DIR is now
diff --git a/lib/am/distdir.am b/lib/am/distdir.am
index 653966f0e..4b6543591 100644
--- a/lib/am/distdir.am
+++ b/lib/am/distdir.am
@@ -72,10 +72,13 @@ endif %?SUBDIRS%

 .PHONY: distdir
 if %?SUBDIRS%
-AM_RECURSIVE_TARGETS += distdir
+AM_RECURSIVE_TARGETS += distdir distdir-am
 endif %?SUBDIRS%

-distdir: $(DISTFILES)
+distdir: $(BUILT_SOURCES)
+   $(MAKE) $(AM_MAKEFLAGS) distdir-am
+
+distdir-am: $(DISTFILES)
 ##
 ## For Gnits users, this is pretty handy.  Look at 15 lines
 ## in case some explanatory text is desirable.
diff --git a/t/dist-vs-built-sources.sh b/t/dist-vs-built-sources.sh
new file mode 100644
index 0..94f8b600f
--- /dev/null
+++ b/t/dist-vs-built-sources.sh
@@ -0,0 +1,56 @@
+#! /bin/sh
+# Copyright (C) 2017 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 <https://www.gnu.org/licenses/>.
+
+# Ensure that "make dist" no longer fails when a distributed file
+# depends on a file from the list of BUILT_SOURCES.
+
+. test-init.sh
+
+cat >> configure.ac << 'END'
+AC_PROG_CC
+AC_OUTPUT
+END
+
+cat > Makefile.am << 'END'
+BUILT_SOURCES = h.h
+h.h:
+   rm -f $@ $@-t
+   printf '%s\n' '#define F "F"' > $@-t
+   mv -f $@-t $@
+CLEANFILES = h.h
+
+EXTRA_DIST = gen
+gen: foo
+   ./foo > $@-t && mv $@-t $@
+
+bin_PROGRAMS = foo
+foo_SOURCES = foo.c
+END
+
+cat > foo.c << 'END'
+#include "h.h"
+int main (void) { printf ("%s\n", F); return 0; }
+END
+chmod a-w foo.c
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE
+
+./configure
+$MAKE dist
+
+:
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index 33e5adc49..fde769971 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -409,6 +409,7 @@ t/dist-missing-m4.sh \
 t/dist-readonly.sh \
 t/dist-repeated.sh \
 t/dist-pr109765.sh \
+t/dist-vs-built-sources.sh \
 t/distcleancheck.sh \
 t/distcom2.sh \
 t/distcom3.sh \
--
2.14.1.729.g59c0ea183

Shouldn’t TAGS depend upon and use BUILT_SOURCES?

[Nikolai Weibull]

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

[Akim Demaille]

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 this patch, the Automake-NG implementation would
 have caused a fork bomb should *any* recursive make call be issued in
 a recipe for a $(BUILT_SOURCES), even if such call entailed no infinite
 recursion by itself -- that was a regression, one that hit a real-world
 package like GNU Smalltalk, and which my patch has fixed.  Does this
 clarify the matter?

Crystal clear now, thanks.

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

[Akim Demaille]

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 $(BUILT_SOURCES) (or of any of
 its prerequisites) would have caused an infinite recursion (complete with
 fork bomb, yuck).  Work around the issue.
 
 Shouldn't some error message be sent to diagnose something wrong?
 
 But my patch now *avoids* the error in the first place (see the test case),
 so we shouldn't report anything.  Or am I missing something?

Hi Stefano,

It was unclear to me that the kind of error that would arise
would be *only* be due to Automake-NG's implementation, or
partly due to the user (possibly declaring recursive dependencies).
If the user is somewhat responsible, then she should be told.
But of course if it's only a technical detail, let's keep it
silent, clearly.

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

[Stefano Lattarini]

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,
 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.

 Shouldn't some error message be sent to diagnose something wrong?

 But my patch now *avoids* the error in the first place (see the test case),
 so we shouldn't report anything.  Or am I missing something?
 
 Hi Stefano,
 
 It was unclear to me that the kind of error that would arise
 would be *only* be due to Automake-NG's implementation, or
 partly due to the user (possibly declaring recursive dependencies).

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 this patch, the Automake-NG implementation would
have caused a fork bomb should *any* recursive make call be issued in
a recipe for a $(BUILT_SOURCES), even if such call entailed no infinite
recursion by itself -- that was a regression, one that hit a real-world
package like GNU Smalltalk, and which my patch has fixed.  Does this
clarify the matter?

 If the user is somewhat responsible, then she should be told.
 But of course if it's only a technical detail, let's keep it
 silent, clearly.
 

Thanks,
  Stefano

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

[Stefano Lattarini]

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 caused an infinite recursion (complete with
 fork bomb, yuck).  Work around the issue.
 
 Shouldn't some error message be sent to diagnose something wrong?
 
But my patch now *avoids* the error in the first place (see the test case),
so we shouldn't report anything.  Or am I missing something?

Regards,
  Stefano

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

[Stefano Lattarini]

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/archive/html/help-smalltalk/2012-08/msg00027.html
http://lists.gnu.org/archive/html/automake-patches/2012-08/msg00052.html

* lib/am/common-targets.mk: Here, with the help of ...
(am.hack.making-built-sources): ... this new internal variable.
* Makefile.am (XFAIL_TESTS): Remove 't/built-sources-fork-bomb.sh'.

Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
 Makefile.am  | 1 -
 lib/am/common-targets.mk | 8 
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index e19f3fd..656ebac 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -338,7 +338,6 @@ perl_fake_XFAIL_TESTS = \
 
 XFAIL_TESTS = \
   t/all.sh \
-  t/built-sources-fork-bomb.sh \
   t/override-suggest-local.sh \
   t/comments-in-var-def.sh \
   t/cond17.sh \
diff --git a/lib/am/common-targets.mk b/lib/am/common-targets.mk
index b9eb64f..da8e16c 100644
--- a/lib/am/common-targets.mk
+++ b/lib/am/common-targets.mk
@@ -159,8 +159,16 @@ ifeq ($(am.make.dry-run),true)
 # completely accurate.
 all check install: | $(am.built-early)
 else
+# Also, with this implementation, a recursive make call in the recipe
+# of any $(BUILT_SOURCES) (or any of its prerequisites) could cause an
+# infinite recursion (complete with fork bomb, yuck), if we are not
+# careful.  The following hack takes care of the problem.
+$(am.built-early): am.hack.making-built-sources = yes
+export am.hack.making-built-sources
+ifndef am.hack.making-built-sources
 $(foreach x,$(am.built-early),$(eval -include .am/built-sources/$(x)))
 .am/built-sources/%: | %
@$(am.cmd.ensure-target-dir-exists)
@touch $@
 endif
+endif
-- 
1.7.12

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

[Stefano Lattarini]

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).

See:
http://lists.gnu.org/archive/html/help-smalltalk/2012-08/msg00027.html
http://lists.gnu.org/archive/html/automake-patches/2012-08/msg00052.html

* t/built-sources-fork-bomb.sh: New test.
* Makefile.am (XFAIL_TESTS): Add it.

Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
 Makefile.am  |  1 +
 t/built-sources-fork-bomb.sh | 69 
 2 files changed, 70 insertions(+)
 create mode 100755 t/built-sources-fork-bomb.sh

diff --git a/Makefile.am b/Makefile.am
index 656ebac..e19f3fd 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -338,6 +338,7 @@ perl_fake_XFAIL_TESTS = \
 
 XFAIL_TESTS = \
   t/all.sh \
+  t/built-sources-fork-bomb.sh \
   t/override-suggest-local.sh \
   t/comments-in-var-def.sh \
   t/cond17.sh \
diff --git a/t/built-sources-fork-bomb.sh b/t/built-sources-fork-bomb.sh
new file mode 100755
index 000..8279704
--- /dev/null
+++ b/t/built-sources-fork-bomb.sh
@@ -0,0 +1,69 @@
+#! /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/.
+
+# 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) might cause an infinite recursion (complete with fork
+# bomb, yuck) if not handled correctly.  Verify that this doesn't happen.
+# For more background, see:
+# http://lists.gnu.org/archive/html/help-smalltalk/2012-08/msg00027.html
+# http://lists.gnu.org/archive/html/automake-patches/2012-08/msg00052.html
+
+. ./defs || exit 1
+
+echo AC_OUTPUT  configure.ac
+
+cat  Makefile.am  'END'
+BUILT_SOURCES = foo
+.PHONY: build-foo
+build-foo:
+   echo OK  foo
+foo:
+   $(MAKE) build-foo
+
+# If the bug is still present, we want this test to fail, not to actually
+# go fork bomb and potentially crash the user machine.  Take care of that.
+
+is_too_deep := $(shell test $(MAKELEVEL) -lt 10  echo no)
+
+## Extra indentation here required to avoid confusing Automake.
+## FIXME: now that we assume make is GNU make, this shouldn't happen!
+ ifeq ($(is_too_deep),no)
+   # All is ok.
+ else
+   $(error ::OOPS:: Recursion too deep, $(MAKELEVEL) levels)
+ endif
+END
+
+$ACLOCAL
+$AUTOMAKE
+$AUTOCONF
+
+./configure
+
+$MAKE -n foo output 21 || { cat output; exit 1; }
+cat output
+test ! -f foo
+# Guard against possible infinite recursion.
+$FGREP '::OOPS::' output  exit 1
+
+$MAKE foo output 21 || { cat output; exit 1; }
+cat output
+$MAKE foo
+# Guard against possible infinite recursion.
+$FGREP '::OOPS::' output  exit 1
+
+:
-- 
1.7.12

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

[Stefano Lattarini]

[Adding the Automake-NG list in CC]

On 08/21/2012 08:37 AM, Paolo Bonzini wrote:
 Il 20/08/2012 21:56, Stefano Lattarini ha scritto:
 After these changes, the Smalltalk build system still works with
 mainline Automake (and only with it), but will be much easier to
 modify to convert it to Automake-NG.
 
 Can you send a patch 6 with the remaining changes?
 
 I'm a bit scared of this:
 
 * libgst/Makefile.am ($(srcdir)/match.stamp): No need to specify
 the '$(srcdir)/' explicitly, since the Smalltalk build system is
 assuming GNU make anyway (it was once necessary to avoid a bug
 with FreeBSD VPATH handling); so rename this target simply ...
 (match.stamp): ... like this. Also, depend on 'genbc$(EXEEXT)',
 rather than calling '$(MAKE)' recursively in the recipe to build
 it.  Not only is this more efficient, it also avoid possible
 hanging of make all in the 'libgist' subdir when 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 -- and that's definitely a price worth
paying; however, I agree it shouldn't silently cause hanging
or fork bombs; we should detect and diagnose the situation.
I'll try to cook something up in the next days.

 Isn't it a bug in Automake-NG?

It is just a limitation.  But it is a bug that the breakage
is silent instead of being diagnosed.

Thanks,
  Stefano

Re: How to use BUILT_SOURCES ?

[NightStrike]

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
 code_formatter_SOURCES=code-formatter-parser.yy code-formatter-lexer.ll\
 code-formatter.cc

 I can use autoreconf, automake and ./configure sucessfully, but when trying
 to make I get:

 [adrian@adrian code-formatter]$ make
 make: *** No rule to make target `position.hh', needed by `all'.  Stop.


 The file in question is meant to be generated by yacc from
 code-formatter-parser.cc. I thought automake should know that files listed
 in BUILT_SOURCES are meant to be generated, so it should not expect to find
 them there already before the build. Is there something I need to do to fix
 this ?

 Thank you,
 Timothy Madden



Things in built_sources are simply made to be prereqs of the all:
target.  You still have to make rules for them.

If you want yacc support from automake, try reading this:
http://www.gnu.org/software/automake/manual/html_node/Yacc-and-Lex.html

How to use BUILT_SOURCES ?

[Timothy Madden]

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\
code-formatter.cc

I can use autoreconf, automake and ./configure sucessfully, but when 
trying to make I get:


[adrian@adrian code-formatter]$ make
make: *** No rule to make target `position.hh', needed by `all'.  Stop.


The file in question is meant to be generated by yacc from 
code-formatter-parser.cc. I thought automake should know that files 
listed in BUILT_SOURCES are meant to be generated, so it should not 
expect to find them there already before the build. Is there something I 
need to do to fix this ?


Thank you,
Timothy Madden

problem with BUILT_SOURCES and make distcheck

[Vincent Torri]

Hey,

I have written a library that use mupdf to render PDF document. mupdf must
be linked statically to that library (there is no mupdf package on any
distro, no shared lib). So I included the mupdf source into my lib tree:

mylib/--- tree of my lib
  mupdf-0.9/  --- the sub dir containing mupdf source code

Some source files of mupdf need some header files, these files are
generated by a tool which source files are also part of mupdf. So:

1) I need to compile first the tool (named cmapdump)
2) The I have to generate the header file cmap_cns.h with the command

  cmapdump 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 = scripts/cmapdump.c

generated:
@echo   MKDIR  generated/
@$(MKDIR_P) generated/

cmap_cns.h: cmapdump generated $(cmap_cns_files)
./cmapdump generated/$@ $(cmap_cns_files)

[/code]

Hera are the 3 things I experienced (points A) B) and C) below)

A) Using 'make' is working :

1) cmapdump is compiled
2) cmap_cns.h is generated correctly
3) mupdf is compiled successfully.

B) But using 'make distcheck' is not working just after 'make' : cmapdump
is not compiled, Hence the command

./cmapdump generated/$@ $(cmap_cns_files)

is failing.

C) Now I do a 'make clean', then 'make distcheck,

1) cmapdump is compiled
2) cmap_cns.h is generated correctly
3) mupdf is compiled successfully.

So why do I have to clean first before distcheck ?

Thank you

Vincent Torri

Re: on Windows, BUILT_SOURCES does not append .exe

[Ralf Wildenhues]

* 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; you generally only need to list headers
 there for which automake cannot know that they are generated and needed
 early.  On GNU/Linux, the example code from the second post from Vincent
 should just work.  Vincent, I'm afraid you might just have to debug the
 makefile (make -d etc); maybe there is a 'cmapdump' file that make finds
 to be matching?
 
 Hmm, i tried with parallal build (make -j 4) and it fails without
 BUILT_SOURCES.

If you need more help on this, please send a small reproducible example.
(Wasn't that obvious?)

Thanks,
Ralf

Re: on Windows, BUILT_SOURCES does not append .exe

[Vincent Torri]

On Mon, 22 Nov 2010, Ralf Wildenhues wrote:


* 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 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 $(cmap_tounicode_files)

does ? Note that having that rule is not sufficient on linux (that is, even
if $(EXEEXT) 'should' (but not 'must', as .exe suffix is not necessary) be
added on widnows, it does not work on linux)


In that case you may need to add cmap_tounicode.c to BUILT_SOURCES,
leaving cmapdump out of same.


That shouldn't be necessary; you generally only need to list headers
there for which automake cannot know that they are generated and needed
early.  On GNU/Linux, the example code from the second post from Vincent
should just work.  Vincent, I'm afraid you might just have to debug the
makefile (make -d etc); maybe there is a 'cmapdump' file that make finds
to be matching?


Hmm, i tried with parallal build (make -j 4) and it fails without 
BUILT_SOURCES.


Vincent Torri

on Windows, BUILT_SOURCES does not append .exe

[Vincent Torri]

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 variables ?


Vincent Torri

Re: on Windows, BUILT_SOURCES does not append .exe

[Ralf Wildenhues]

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 that BUILT_SOURCES does not try to see if they are
 binaries in some variables ?

I don't think we've come across an example where it was necessary to put
compiled programs into BUILT_SOURCES.  For one, that would mean that
cross compilation will not work.  For another: can you please explain
what you are trying to achieve?  I'm sure there is another way.

Other than that, you're right: automatic $(EXEEXT) appending is not done
for BUILT_SOURCES.

Thanks,
Ralf

Re: on Windows, BUILT_SOURCES does not append .exe

[Vincent Torri]

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 to

cmapdump fontdump

Is it normal that BUILT_SOURCES does not try to see if they are
binaries in some variables ?


I don't think we've come across an example where it was necessary to put
compiled programs into BUILT_SOURCES.  For one, that would mean that
cross compilation will not work.  For another: can you please explain
what you are trying to achieve?  I'm sure there is another way.


I am building a library that is using mupdf. I have autotooled mupdf for 
my personal project. mupdf is splitted into several libraries:


libfitz libdraw libcmaps libfonts libmupdf

libcmaps source files are generated by a binary named cmapdump.

So I have something like:


noinst_PROGRAMS = cmapdump
cmapdump_SOURCES = mupdf-0.7/mupdf/cmapdump.c

noinst_LTLIBRARIES = libfitz.la libdraw.la libcmaps.la libfonts.la libmupdf.la

...

cmap_tounicode_files = \
mupdf-0.7/cmaps/Adobe-CNS1-UCS2 \
mupdf-0.7/cmaps/Adobe-GB1-UCS2 \
mupdf-0.7/cmaps/Adobe-Japan1-UCS2 \
mupdf-0.7/cmaps/Adobe-Korea1-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, and compilation of 
libcmaps fails.


Is there another solution ?


Other than that, you're right: automatic $(EXEEXT) appending is not done
for BUILT_SOURCES.


ok.

thank you

Vincent Torri

Re: on Windows, BUILT_SOURCES does not append .exe

[Ralf Wildenhues]

* Vincent Torri wrote on Sun, Nov 21, 2010 at 11:14:23PM CET:
 noinst_PROGRAMS = cmapdump
 cmapdump_SOURCES = mupdf-0.7/mupdf/cmapdump.c
 
 noinst_LTLIBRARIES = libfitz.la libdraw.la libcmaps.la libfonts.la libmupdf.la

 cmap_tounicode_files = \
 mupdf-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, and compilation of
 libcmaps fails.
 
 Is there another solution ?

Yes: just specify cmapdump$(EXEEXT) as prerequisite to cmap_tounicode.c.

Cheers,
Ralf

Re: on Windows, BUILT_SOURCES does not append .exe

[Vincent Torri]

On Sun, 21 Nov 2010, Ralf Wildenhues wrote:


* Vincent Torri wrote on Sun, Nov 21, 2010 at 11:14:23PM CET:

noinst_PROGRAMS = cmapdump
cmapdump_SOURCES = mupdf-0.7/mupdf/cmapdump.c

noinst_LTLIBRARIES = libfitz.la libdraw.la libcmaps.la libfonts.la libmupdf.la



cmap_tounicode_files = \
mupdf-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, 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 $(cmap_tounicode_files)

does ? Note that having that rule is not sufficient on linux (that is, 
even if $(EXEEXT) 'should' (but not 'must', as .exe suffix is not 
necessary) be added on widnows, it does not work on linux)


Vincent Torri

Re: on Windows, BUILT_SOURCES does not append .exe

[Dave Hart]

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 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 $(cmap_tounicode_files)

 does ? Note that having that rule is not sufficient on linux (that is, even
 if $(EXEEXT) 'should' (but not 'must', as .exe suffix is not necessary) be
 added on widnows, it does not work on linux)

In that case you may need to add cmap_tounicode.c to BUILT_SOURCES,
leaving cmapdump out of same.

Cheers,
Dave Hart

Re: on Windows, BUILT_SOURCES does not append .exe

[Ralf Wildenhues]

* 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 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 $(cmap_tounicode_files)
 
  does ? Note that having that rule is not sufficient on linux (that is, even
  if $(EXEEXT) 'should' (but not 'must', as .exe suffix is not necessary) be
  added on widnows, it does not work on linux)
 
 In that case you may need to add cmap_tounicode.c to BUILT_SOURCES,
 leaving cmapdump out of same.

That shouldn't be necessary; you generally only need to list headers
there for which automake cannot know that they are generated and needed
early.  On GNU/Linux, the example code from the second post from Vincent
should just work.  Vincent, I'm afraid you might just have to debug the
makefile (make -d etc); maybe there is a 'cmapdump' file that make finds
to be matching?

Cheers,
Ralf

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

[Daily, Jeff A]

 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 particular system is case-insensitive.  I had the 
files wapi.py, wapi.c, and wapi.h.  I renamed wapi.py to wapigen.py and it now 
works for the VPATH build.  Nice.

 On this system, does the build succeed if you don't use a VPATH, i.e.,
 in-tree ./configure  make?

Yep, it always worked without VPATH.

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

[Daily, Jeff A]

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
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 $  foo/bar/wapi.c
libfoo_la_SOURCES += foo/bar/wapi.c
endif
#*snip*

It turns out that $(PYTHON) is located by configure such that HAVE_PYTHON is 
true.  When I configure and build from a subdirectory within my source tree 
e.g. mkdir bld; cd bld; ../configure the build fails because make is looking 
for the target ../foo/bar/wapi.c which doesn't exist, and never will, since 
it is located in the build tree instead of the source tree (it is a 
BUILT_SOURCE, after all, and belongs in the build tree).  Further, I require 
that the built source be placed in the appropriate subdirectory within my build 
tree just like subdir-objects would do (I am using subdir-objects so this makes 
sense).  I use this strategy for building headers, and then adding 
-I$(top_build_prefix)foo to my CPPFLAGS.  But this is the only built source 
file (*.c) and it fails as I've mentioned:

Make: *** No rule to make target `../foo/bar/wapi.c', needed by 
'foo/bar/wapi.lo'.  Stop.

What am I doing wrong?  Thanks.
__
Jeff Daily
Scientist
Pacific Northwest National Laboratory

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

[Ralf Wildenhues]

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: foo/bar/papi.h $(top_srcdir)/build-aux/wapi.py
 -rm -f foo/bar/wapi.c  \
 $(PYTHON) $(top_srcdir)/build-aux/wapi.py $  foo/bar/wapi.c
 libfoo_la_SOURCES += foo/bar/wapi.c
 endif
 #*snip*
 
 It turns out that $(PYTHON) is located by configure such that
 HAVE_PYTHON is true.  When I configure and build from a subdirectory
 within my source tree e.g. mkdir bld; cd bld; ../configure the build
 fails because make is looking for the target ../foo/bar/wapi.c which
 doesn't exist,

Which make version and implementation, which Automake version?
Do you somehow ensure foo/bar exists in the build tree beforehand?
Does the file foo/bar/papi.h exist in the source or in the build tree?

The above works for me; but VPATH target lookup is tricky across
make implementations, see 'info Autoconf VPATH and Make' and
the last node referenced therein.

Using $ in non-inference rules is not portable to non-GNU make.

Cheers,
Ralf

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

[Daily, Jeff A]

  #*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 $  foo/bar/wapi.c
  libfoo_la_SOURCES += foo/bar/wapi.c
  endif
  #*snip*
 
  It turns out that $(PYTHON) is located by configure such that
  HAVE_PYTHON is true.  When I configure and build from a subdirectory
  within my source tree e.g. mkdir bld; cd bld; ../configure the build
  fails because make is looking for the target ../foo/bar/wapi.c which
  doesn't exist,
 
 Which make version and implementation, which Automake version?

I'm using autoconf 2.67, automake 1.11.1.

 Do you somehow ensure foo/bar exists in the build tree beforehand?

Not explicitly, no.  But foo/bar does exist beforehand, perhaps because foo/bar 
contains other source files and the build directory constructs the hidden 
dependency directories before I ever run make the first time.

 Does the file foo/bar/papi.h exist in the source or in the build tree?

foo/bar/papi.h exists in the source tree.

 
 The above works for me; but VPATH target lookup is tricky across
 make implementations, see 'info Autoconf VPATH and Make' and
 the last node referenced therein.

...never rely on VPATH searches for targets. In other words, VPATH should be 
reserved to unbuilt sources.
I'm not sure how to apply that information.

 
 Using $ in non-inference rules is not portable to non-GNU make.

I'll replace it with $(top_srcdir)/path/to/dependency then?  Thanks the tip.

Still no luck.  I replaced $ appropriately first, but that didn't change 
anything.
Next I tried replacing

libfoo_la_SOURCES += foo/bar/wapi.c with
libfoo_la_SOURCES += $(top_build_prefix)foo/bar/wapi.c

But that produces warnings at make time of overriding commands for target 
`foo/bar/.dirstamp' and overriding commands for target 
`foo/bar/.deps/.dirstamp'

I also tried distilling the problem down to a simpler Makefile.am, but I 
couldn't reproduce the problem either.  Thanks so far, but any other ideas?

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

[Ralf Wildenhues]

* 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

[Daily, Jeff A]

   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

[Adam Mercer]

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 to
have the above in a file that is included in each Makefile.am with
something like

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?

Cheers

Adam

Re: appending to BUILT_SOURCES, if appropriate

[Eric Blake]

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 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.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: appending to BUILT_SOURCES, if appropriate

[Adam Mercer]

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

[Ralf Wildenhues]

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

the BUILT_SOURCES line should not be necessary for this to work at all.
Typically, it's needed for header files, where, during the first build,
`make' otherwise doesn't know that the header is needed at all, or for
which object files.

 Automake is 1.9.6 on debian/unstable

Please update to a newer Automake release, for any number of reasons,
including security-related ones.  The current release is 1.11.1.

Cheers,
Ralf

BUILT_SOURCES

[Russell Shaw]

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


Automake is 1.9.6 on debian/unstable

Inspecting the generated Makefile doesn't seem to do anything
with BUILT_SOURCES.

Re: BUILT_SOURCES

[Russell Shaw]

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

[Ralf Wildenhues]

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 help to see a reduced example package that still has the cycle.

Cheers,
Ralf

Re: QT Plugins, target build order AND BUILT_SOURCES

[Andre Heine]

Hello all,

the only idea at this time is to add another subproject and
put the special test forms in there...

I must copy some other source files or use in XXX_SOURCES = ../src/files.cpp
(ugly??)

The build order can modified via SUBDIRS in the toplevel Makefile.am...

Greetings 

andre


Am Donnerstag, 29. Oktober 2009 15:02 schrieb Andre Heine:
 Hello all,

 I've a litte problem to build subproject correctly...

 In my Makefile.am are one bin_programs and one lib_LTLIBRARIES.

 The plugin is a shared linked library, so that it can loaded into QT's
 designer. The program should test all plugin widgets, features etc...

 bin_programs has some UI files more, that UI's needed the plugin (.so)

 All other source and header files are shared, so all files are in one
 directory...

 And that is the problem, the uic needs the plugin to load at runtime. The
 uic will load the plugin via dlopen, so I must build the lib first.

 In my Makefile.am I call the uic with an extra switch (-L) to add the
 libpath to my shared object:

 $(UIC) -L $(top_builddir)/dvplugins/.libs

 The uic will load the lib and generate some include defines into the qt
 class files. But when uic  can't load the plugin my header is broken;()

 Our source are bad organized, 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?


 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$(top_srcdir)/. -I$(top_srcdir)/src -I$(QTDIR)/include \
   -I$(QTDIR)/mkspecs/linux-g++ -I$(top_srcdir)/../libdvutil/include \
   -I$(top_srcdir)/../libsettings/include/ -I.

 MOC  = $(QTDIR)/bin/moc
 UIC  = $(QTDIR)/bin/uic

 # global DV
 ISAMFLAGS = -DREALLY_DB_ONLY -DITOOLS -DDB_ONLY -DLATIN1KONV
  -DDVPLUGINS -DDAVIDX

 bin_PROGRAMS= qplugin
 lib_LTLIBRARIES = libCustomPlugin.la

 DVHEADER  =
 DVSOURCE  =
 DVXSOURCE =
 DVXHEADER =

 # only qplugin, it got the dynamic widgets from the plugin
 FORMS_TEST  = Test.ui dialogimplform.ui

 # all
 FORMS   = dialogbase.ui
 FORMS_HPP   = consdatum_dlg.ui adt_wizard.ui


 MOC_HEADERS = DialogImpl.h \
   messagebox.hpp \
   lineedit.hpp \
   consdatum_dlg_impl.hpp \
   datum_le.hpp

 SHARED_SRC  = messagebox.cpp DialogImpl.cpp \
   lineedit.cpp \
   isam2x_str.cpp \
   x2isam_str.cpp \
   setwindow.cpp \
   custom_event.cpp \
   consdatum_dlg_impl.cpp \
   datum_le.cpp

 SHARED_INC  = isam2x_str.hpp \
   x2isam_str.hpp \
   setwindow.hpp \
   custom_event.hpp


 qplugindir = $(prefix)/include
 qplugin_SOURCES = $(SHARED_SRC)\
   qplugin.cpp

 qplugin_HEADERS = $(SHARED_INC) $(MOC_HEADERS)


 MOCdir = $(prefix)/include
 FORMHEADERS = $(FORMS:.ui=.h) $(FORMS_HPP:.ui=.hpp)
 MOC_CC= $(FORMS:.ui=.moc.cpp) $(MOC_HEADERS:.h=.moc.cpp) \
 $(MOC_HEADERS:.hpp=.moc.cpp) $(FORMS_HPP:.ui=.moc.cpp)

 MOC_CC_QP = $(FORMS_TEST:.ui=.moc.cpp)
 UIC_CC_QP   = $(FORMS_TEST:.ui=.uic.cpp)

 UIC_CC = $(FORMS:.ui=.uic.cpp)
 UIC_CXX= $(FORMS_HPP:.ui=.uic.cxx)

 nodist_qplugin_SOURCES= $(UIC_CC) $(MOC_CC) $(UIC_CXX) $(MOC_CC_QP)
 $(UIC_CC_QP)


 qplugin_LDFLAGS = $(all_libraries)
 $(SUBLIBS) -L$(QTDIR)/lib -L/usr/X11R6/lib -lqt-mt \
  -lqui -lXext -lX11 -lm -lpthread \
  -ldvutil $(top_builddir)/src/libISAMCore.la \
  $(BOOST_ROOT)/lib/libboost_regex.a \
  -export-dynamic
 # $(DVSTATICS_ROOT)/lib/libsettings.a

 qplugin_LDADD   =
 qplugin_CPPFLAGS= $(ISAMFLAGS)
 qplugin_CFLAGS
 = -pipe -Wall  -Wno-write-strings -Wno-parentheses -Werror -O2 \
 -D_REENTRANT  -DQT_THREAD_SUPPORT -DQT_SHARED

 qplugin_CXXFLAGS
 = -pipe -Wall  -Wno-write-strings -Wno-parentheses -Werror -O2 \
 -D_REENTRANT  -DQT_THREAD_SUPPORT -DQT_SHARED



 # This line ensures that generated moc_*.cpp and resources.cpp files are
 # deleted when we make clean.
 # CLEANFILES = $(filter moc_%.cpp, $(qplugin_SOURCES))

 # This is to ensure the myapp.h file is distributed in your
 myapp-0.1.tar.gz # I also have a resources.qrc I need to include. The png
 is used in myapp.


 libCustomPlugin_ladir = $(exec_prefix)/include
 #libCustomPlugin_la_MOCdir

QT Plugins, target build order AND BUILT_SOURCES

[Andre Heine]

Hello all,

I've a litte problem to build subproject correctly...

In my Makefile.am are one bin_programs and one lib_LTLIBRARIES.

The plugin is a shared linked library, so that it can loaded into QT's 
designer. The program should test all plugin widgets, features etc...

bin_programs has some UI files more, that UI's needed the plugin (.so)

All other source and header files are shared, so all files are in one  
directory...

And that is the problem, the uic needs the plugin to load at runtime. The
uic will load the plugin via dlopen, so I must build the lib first.

In my Makefile.am I call the uic with an extra switch (-L) to add the 
libpath to my shared object:

$(UIC) -L $(top_builddir)/dvplugins/.libs

The uic will load the lib and generate some include defines into the qt 
class files. But when uic  can't load the plugin my header is broken;()

Our source are bad organized, 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?


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$(top_srcdir)/. -I$(top_srcdir)/src -I$(QTDIR)/include \
-I$(QTDIR)/mkspecs/linux-g++ -I$(top_srcdir)/../libdvutil/include \
-I$(top_srcdir)/../libsettings/include/ -I.

MOC  = $(QTDIR)/bin/moc
UIC  = $(QTDIR)/bin/uic

# global DV
ISAMFLAGS = -DREALLY_DB_ONLY -DITOOLS -DDB_ONLY -DLATIN1KONV 
 -DDVPLUGINS -DDAVIDX

bin_PROGRAMS= qplugin
lib_LTLIBRARIES = libCustomPlugin.la

DVHEADER  =
DVSOURCE  =
DVXSOURCE =
DVXHEADER =

# only qplugin, it got the dynamic widgets from the plugin
FORMS_TEST  = Test.ui dialogimplform.ui

# all
FORMS   = dialogbase.ui
FORMS_HPP   = consdatum_dlg.ui adt_wizard.ui


MOC_HEADERS = DialogImpl.h \
  messagebox.hpp \
  lineedit.hpp \
  consdatum_dlg_impl.hpp \
  datum_le.hpp

SHARED_SRC  = messagebox.cpp DialogImpl.cpp \
  lineedit.cpp \
  isam2x_str.cpp \
  x2isam_str.cpp \
  setwindow.cpp \
  custom_event.cpp \
  consdatum_dlg_impl.cpp \
  datum_le.cpp

SHARED_INC  = isam2x_str.hpp \
  x2isam_str.hpp \
  setwindow.hpp \
  custom_event.hpp


qplugindir = $(prefix)/include
qplugin_SOURCES = $(SHARED_SRC)\
  qplugin.cpp

qplugin_HEADERS = $(SHARED_INC) $(MOC_HEADERS)


MOCdir = $(prefix)/include
FORMHEADERS = $(FORMS:.ui=.h) $(FORMS_HPP:.ui=.hpp)
MOC_CC= $(FORMS:.ui=.moc.cpp) $(MOC_HEADERS:.h=.moc.cpp) \
$(MOC_HEADERS:.hpp=.moc.cpp) $(FORMS_HPP:.ui=.moc.cpp)

MOC_CC_QP = $(FORMS_TEST:.ui=.moc.cpp)
UIC_CC_QP   = $(FORMS_TEST:.ui=.uic.cpp)

UIC_CC = $(FORMS:.ui=.uic.cpp)
UIC_CXX= $(FORMS_HPP:.ui=.uic.cxx)

nodist_qplugin_SOURCES  = $(UIC_CC) $(MOC_CC) $(UIC_CXX) $(MOC_CC_QP) 
$(UIC_CC_QP)


qplugin_LDFLAGS = $(all_libraries) 
$(SUBLIBS) -L$(QTDIR)/lib -L/usr/X11R6/lib -lqt-mt \
 -lqui -lXext -lX11 -lm -lpthread \
 -ldvutil $(top_builddir)/src/libISAMCore.la \
 $(BOOST_ROOT)/lib/libboost_regex.a \
 -export-dynamic
# $(DVSTATICS_ROOT)/lib/libsettings.a

qplugin_LDADD   =
qplugin_CPPFLAGS= $(ISAMFLAGS)
qplugin_CFLAGS  
= -pipe -Wall  -Wno-write-strings -Wno-parentheses -Werror -O2 \
-D_REENTRANT  -DQT_THREAD_SUPPORT -DQT_SHARED

qplugin_CXXFLAGS
= -pipe -Wall  -Wno-write-strings -Wno-parentheses -Werror -O2 \
-D_REENTRANT  -DQT_THREAD_SUPPORT -DQT_SHARED



# This line ensures that generated moc_*.cpp and resources.cpp files are
# deleted when we make clean.
# CLEANFILES = $(filter moc_%.cpp, $(qplugin_SOURCES))

# This is to ensure the myapp.h file is distributed in your myapp-0.1.tar.gz
# I also have a resources.qrc I need to include. The png is used in myapp.


libCustomPlugin_ladir   = $(exec_prefix)/include
#libCustomPlugin_la_MOCdir   = $(exec_prefix)/include
libCustomPlugin_la_SOURCES  = $(SHARED_SRC) CustomPlugin.cpp
#dialogbase.moc.cpp dialogbase.uic.cpp
#libCustomPlugin_la_MOC_HEADERS  = DialogImpl.h
libCustomPlugin_la_HEADERS  = $(SHARED_INC) $(MOC_HEADERS) CustomPlugin.h
# dialogbase.h

nodist_libCustomPlugin_la_SOURCES   = $(UIC_CC) $(MOC_CC) $(UIC_CXX)

libCustomPlugin_la_CFLAGS   
= -pipe -Wall -Wno-pointer-sign -Wno-parentheses -Werror -O2

Re: BUILT_SOURCES doesn't seem to work

[Stepan Kasal]

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 this?

BUILT_SOURCES is just a list of targets which get built at the
beginning of target all (and a few other targets).

This means that it has no influence if you call make pkgmaker.
You have to call make all.

See also this for deatils about built sources:
http://www.gnu.org/software/automake/manual/html_node/Built-sources-example.html

 pkgmaker/Makefile.am:12: `%'-style pattern rules are a GNU make extension
 How do I modernize these rules?

Well, it's actually the opposite of modernization.

Automake does produce portable makefiles, which work with many
implementations of make, not only with GNU make.
That's why it does not use %-rules.  The rules get copied to the
resulting Makefile, but Automake does not understand them.

So, to make your Makefile.am more portable, using the fact that
Automake can support new extensions (.ui) once you define how to
build an object file from them (in this case, indirectly, through
.cpp), you can do this:

.ui.h:
$(UIC) -o $@ $
.ui.cpp:
$(UIC) -o $@ -impl $*.h $
bin_PROGRAMS = pkgmaker
pkgmaker_SOURCES = pkgmaker.cpp sigcreatedlg.ui
# Create this before make all
BUILT_SOURCES = sigcreatedlg.h
# we cannot rely that UIC is available on the customer's machine:
EXTRA_DIST = sigcreatedlg.h sigcreatedlg.cpp

 pkgmaker_SOURCES = pkgmaker.cpp $(pkgmaker_UI)
 BUILT_SOURCES = $(pkgmaker_UI)
...
 CLEANFILES = $(BUILT_SOURCES)

These two are contradictory:
If files $(pkgmaker_UI) are in pkgmaker_SOURCES, then they are
distributed, so they will be included in the tarball.
But then they should not be in CLEANFILES nor in DISTCLEANFILES,
since make clean or make distclean shouldn't usually clean files
originating from the tarball.

The question is: can you suppose that $(UIC) is available on each
machine where you want to unpack and build the tarball?
If not, then you need the EXTRA_DIST as in my examle above.
If yes, then that EXTRA_DIST should probably be changed to
CLEANFILES.

 INCLUDES= $(all_includes)

This can be modernized:
s/INCLUDES/AM_CPPFLAGS/

Hope these notes are helpful,
Stepan

BUILT_SOURCES doesn't seem to work

[Bobby Dill]

I have written a Makefile.am and processed it with automake 1.10. Here's how
the file looks.
METASOURCES = AUTO

bin_PROGRAMS = pkgmaker

# This rule lets GNU make create any moc_*.cpp from the equivalent *.h
%.h: %.ui
$(UIC) -o $@ $
%.cpp: %.ui
$(UIC) -o $@ -impl $*.h $
# You have one .h file, it's called myapp.h. Therefore, here I list
# its mocced name, moc_myapp.cpp.
moc_%.cpp: %.h
moc $ -o $@

pkgmaker_UI =
sigcreatedlg.h
sigcreatedlg.cpp

sigcreatedlg.h: sigcreatedlg.ui
sigcreatedlg.cpp: sigcreatedlg.ui sigcreatedlg.h

pkgmaker_SOURCES = pkgmaker.cpp $(pkgmaker_UI)
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/Makefile.am:6: `%'-style pattern rules are a GNU make extension
pkgmaker/Makefile.am:8: `%'-style pattern rules are a GNU make extension
pkgmaker/Makefile.am:12: `%'-style pattern rules are a GNU make extension
How do I modernize these rules?
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 this?

Re: BUILT_SOURCES doesn't seem to work

[Ben Pfaff]

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 territory,
 but to keep the structure of society intact.
--George Orwell, _1984_

Re: BUILT_SOURCES automagically made MAINTAINERCLEANFILES

[Ralf Wildenhues]

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');
 ...
 
 I see many, many people who manually list their BUILT_SOURCES in CLEANFILES or
 MAINTAINERCLEANFILES.  Actually even the manual shows an example in which
 BUILT_SOURCES are listed in CLEANFILES.

Side note: the example isn't completely redundant: upgrading a file from
being cleaned by `maintainer-clean' to `clean' may be a useful thing.
Of course that doesn't refute your general point.

 Since this behavior isn't documented, can we considere that it's simply an
 omission and rely on it, or has it been done on purpose for some reason?

Frankly, I don't know.  I see two sides of it here:  First, the
automatic adding to maintainer-clean is consistent with the notion of
what the several `*clean' targets should do (see @node{Clean}).  Second,
can there be a useful setup in which it is harmful if `maintainer-clean'
removes the file?  If no, then a patch to document the existing behavior
(manual + NEWS file) would be best.  ;-)

Cheers,
Ralf

BUILT_SOURCES automagically made MAINTAINERCLEANFILES

[Benoit Sigoure]

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)'} = MAINTAINER_CLEAN
if var ('BUILT_SOURCES');
...

I see many, many people who manually list their BUILT_SOURCES in CLEANFILES or
MAINTAINERCLEANFILES.  Actually even the manual shows an example in which
BUILT_SOURCES are listed in CLEANFILES.

Since this behavior isn't documented, can we considere that it's simply an
omission and rely on it, or has it been done on purpose for some reason?

Cheers,

-- 
SIGOURE Benoit aka Tsuna
   _
  /EPITA\ Promo 2008, LRDE

Re: BUILT_SOURCES: dependencies not copied to build_dir

[Ralf Wildenhues]

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 sure if it will work, but perhaps you could just use the .ngci file
 without copying it?

Yes, that was my thinking as well.  Copying is a bad idea, if that file
ends up in the distribution tarball some make implementations will
behave interestingly and subtly different when both source and build
tree have different versions of this (described in the Autoconf manual).

  Perhaps rules like:
 
 ngcs_marshal.c: $(srcdir)/ngcs_marshal.ngci $(srcdir)/idef.py
 $(srcdir)/idef.py ngcs_marshal
 
 ngcs_marshal.h: $(srcdir)/ngcs_marshal.ngci $(srcdir)/idef.py
 $(srcdir)/idef.py ngcs_marshal
 
 would work?

No, the rules are fine without the `$(srcdir)/', thanks to the VPATH
feature that most make implementations offer.

 Or do the files need to be copied for other reasons as
 well?

I suppose the idef.py program wants to know about their location.
But since we don't know what it does, nor whether it can be told
(maybe by a command line argument) where to look for its input,
Michael has to find this out by himself, or enlighten us.  :-)

Cheers,
Ralf

Re: BUILT_SOURCES: dependencies not copied to build_dir

[Michael Biebl]

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: 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 it?
 
 Yes, that was my thinking as well.  Copying is a bad idea, if that file
 ends up in the distribution tarball some make implementations will
 behave interestingly and subtly different when both source and build
 tree have different versions of this (described in the Autoconf manual).

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 $(srcdir)/ngcs_marshal @

ngcs_marshal.h: ngcs_marshal.ngci idef.py
$(srcdir)/idef.py $(srcdir)/ngcs_marshal @

This way idef.py and ngcs_marshal.ngci are not copied to the builddir
and whenever they change one of them in the srcdir the header and c file
are regenerated.
I don't need srcdir in the dependency line, but if I omit them in the
build rule I either get:
make: idef.py: Command not found
or
IOError: [Errno 2] No such file or directory: 'ngcs_marshal.ngci'

I also had to change idef.py to take an additional parameter (@) where I
can tell the location of the output file. Otherwise the file is created
in the srcdir. I wanted to avoid changing idef.py first (that's why the
copying) but it seemed not to be possible.

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

[Ralf Wildenhues]

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 $(srcdir)/ngcs_marshal @

Do you mean `$@' instead of `@' here?  If not: what is the `@' supposed
to do?

 ngcs_marshal.h: ngcs_marshal.ngci idef.py
 $(srcdir)/idef.py $(srcdir)/ngcs_marshal @
 
 This way idef.py and ngcs_marshal.ngci are not copied to the builddir
 and whenever they change one of them in the srcdir the header and c file
 are regenerated.
 I don't need srcdir in the dependency line, but if I omit them in the
 build rule I either get:
[errors]

Well, yes, you do need it in the rule.  Were they inference rules, could
you use `$', but in an explicit rule like above that is not portable.

 I also had to change idef.py to take an additional parameter (@) where I
 can tell the location of the output file. Otherwise the file is created
 in the srcdir. I wanted to avoid changing idef.py first (that's why the
 copying) but it seemed not to be possible.

That's definitely the better way.

Cheers,
Ralf

Re: BUILT_SOURCES: dependencies not copied to build_dir

[Michael Biebl]

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
 $(srcdir)/idef.py $(srcdir)/ngcs_marshal @
 
 Do you mean `$@' instead of `@' here?  If not: what is the `@' supposed
 to do?
 

Sure, I meant '$@'. Thanks for the catch ;-)

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

[Stepan Kasal]

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: ngcs_marshal.ngci idef.py
 $(srcdir)/idef.py $(srcdir)/ngcs_marshal $@

yes, this is a good solution.

One question, though?  Does `idef.py ... *.c' produce both files, or only
the .c one?

If it produces only one of the files, the makefile is correct.

If it produces both of them, it may not work with parallel make.
(See http://sourceware.org/automake/automake.html#Multiple-Outputs .)

Alternatively, you might make use of the Automake's ability to use new
extensions, something like:

EXTRA_DIST = idef.py ngcs.py
foobar_SOURCES = ngcs_marshal.ngci \
this.c \
that.c ...

.ngci.c:
$(srcdir)/idef.py $ $@

.ngci.h:
$(srcdir)/idef.py $ $@

If the Python script produces both output files, the latter rule should be
something like:

ngcs_marshal.h: ngcs_marshal.c
@if test -f $@; then :; else \
  rm -f data.c; \
  $(MAKE) $(AM_MAKEFLAGS) data.c; \
fi

Have a nice day,
Stepan

Re: BUILT_SOURCES: dependencies not copied to build_dir

[Michael Biebl]

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

[tom fogal]

 [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 it?  Perhaps rules like:

ngcs_marshal.c: $(srcdir)/ngcs_marshal.ngci $(srcdir)/idef.py
$(srcdir)/idef.py ngcs_marshal

ngcs_marshal.h: $(srcdir)/ngcs_marshal.ngci $(srcdir)/idef.py
$(srcdir)/idef.py ngcs_marshal

would work?  Or do the files need to be copied for other reasons as
well?

-tom

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

[Duncan Gibson]

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 are not portable to ancient hosts.  In practice
 they will work fine, though.  I'd write

 cp $ $(top_builddir)/$$d/$$f  \
 cd $(top_builddir)/$$d  \
 fluid -c $$f

 ...
 Can't the `fluid' program be taught to accept input files with a path
 and still output in the current directory?

I raised that as a possible feature request on the fltk mailing list and
the wizard there provided a lateral thinking solution instead:

Well, if you actually need to generate the files in the output
directory (vs. treating them as source files with the object
files sent to the output directory), then using:

fluid -c $(srcdir)/input.fl

is your friend - FLUID will put the output files in the current
directory, not the directory of the input file.

I hope it's just a question of putting all of the different strands
together now. I'll post the result once I've worked it out.

Cheers
Duncan

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

[Ralf Wildenhues]

Hi Duncan,

Note: I don't know whether and how much of this was already addressed.

* Duncan Gibson wrote on Sat, Mar 04, 2006 at 06:09:22PM CET:
 
 use 'fluid -c foo.fl' to create foo.h and foo.cxx
 create libfoo.a from foo.cxx
 compile foo_test.cxx and link against libfoo.a

*snip*
 The src/Makefile.am looks like:
 
 bin_PROGRAMS += src/foo_test
 noinst_LIBRARIES += src/libfoo.a
 
 AM_CPPFLAGS = -I$(srcdir)/src -I$(top_builddir)/src $(FLTK_CXXFLAGS)
 
 .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
 
 nodist_src_libfoo_a_SOURCES = src/foo.cxx
 
 src_foo_test_LDADD = src/libfoo.a $(FLTK_LIBRARYS)
 src_foo_test_LDFLAGS = $(FLTK_LDSFLAGS)
 src_foo_test_SOURCES = src/foo_test.cxx
 
 After a lot of trial and error, the src/Makefile.am *appears* to work,
 but I'm concerned about the filename manipulations in the .fl.h rule,

dirname and basename are not portable to ancient hosts.  In practice
they will work fine, though.  I'd write

cp $ $(top_builddir)/$$d/$$f  \
cd $(top_builddir)/$$d  \
fluid -c $$f

so that you get failures if something fails.  But even then this
construction is not really safe: Automake will put
  VPATH = @srcdir@

in your Makefile.in.  And the fact that after the first build you have
two copies of the source will confuse `make': it may look at the wrong
one and decide nothing needs updating, when in fact it would need to.

I'm not totally sure how to go about this.  Can't the `fluid' program be
taught to accept input files with a path and still output in the current
directory?  That's what I'd expect from a halfway sane tool even if the
output file can't be specified.

I guess you could use symlinking instead of copying to work around this
limitation.  Take a look at Autoconf's AC_PROG_LN_S description and use
$(LN_S) to at least fix this on all systems where sym- or hardlinking
works.  Oh, that complicates it: you'd need to know the
relative-or-absolute path starting from the output directory.. :-/

 the lack of checking so that I don't zap things if building in $(srcdir),

Ahh, right.  There should probably be a
  test $(srcdir) != .

guarding the copy.  I usually don't care that users get busted if they
enter this in the top level source directory:
  `pwd`/configure
instead of this:
  ./configure

I guess we end up with something like this then (untested):

 .fl.h:
d=`dirname [EMAIL PROTECTED]; f=`basename $@ .h`.fl;  \
h=`basename [EMAIL PROTECTED];\
cd $$d  test $(srcdir) != .  {\
  $(LN_S) $(abs_top_srcdir)/$$d/$$h $$f ||  \
  rm -f $$f;\
}  fluid -c $$f

The absolute path is ugly, but I don't know a better way off-hand, given
the LN_S restrictions.  You may need to AC_SUBST abs_top_srcdir in
configure.ac (not sure).

 AM_CPPFLAGS needing both $(srcdir) and $(top_builddir),

That's quite normal.

 the fact that src/foo.fl doesn't appear anywhere,

Oh.  It should probably be listed in EXTRA_DIST so that it gets
distributed, I guess.

No I get to wait and see if I get corrected.  :-)

Cheers,
Ralf

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

[Thomas Dickey]

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
ftp://invisible-island.net

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

[Ralf Wildenhues]

* 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 idea myself.  Where does dirname not work?  :-)

Cheers,
Ralf

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

[Thomas Dickey]

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 what platform did not support basename?


No idea myself.  Where does dirname not work?  :-)


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...

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

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

[Thomas 'Tom' R. Treadway III]

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, though.  I'd write


I know that dirname is not, but what platform did not support  
basename?


No idea myself.  Where does dirname not work?  :-)


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. It has evolved through  
the System V releases to a version that matches the requirements  
specified in this description in System V Release 3. 4.3 BSD and  
earlier versions did not include dirname.





--
Thomas R. Treadway
Computer Scientist
Lawrence Livermore Nat'l Lab
7000 East Avenue, L-270
Livermore, CA 94550-0611

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

[Thomas Dickey]

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. It has evolved through the 
System V releases to a version that matches the requirements specified in 
this description in System V Release 3. 4.3 BSD and earlier versions did not 
include dirname.


yes - for instance, Apollo supported BSD 4.3 and Systerm V environments.
Scripts written for the latter could have used dirname, while the former
could not.

(There are still hobbyists running Apollos of course - not I).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

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

[Thomas 'Tom' R. Treadway III]

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
ancient...
The dirname utility originated in System III. It has evolved  
through the System V releases to a version that matches the  
requirements specified in this description in System V Release 3.  
4.3 BSD and earlier versions did not include dirname.


yes - for instance, Apollo supported BSD 4.3 and Systerm V  
environments.
Scripts written for the latter could have used dirname, while the  
former

could not.

(There are still hobbyists running Apollos of course - not I).

Both Apollo, and HP-UX were SysV/BSD hybrids. Sun's under SunOS
(pre Solaris) were BSD.
   trt


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

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

[Duncan Gibson]

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 progress last night. The reason for the
repost was that from where I'm sitting, there seems to have been a
major glitch with the automake list server, and I thought my message
had disappeared into the bit-bucket.

BTW, it seems that the automake archive has still not caught up yet.
See http://lists.gnu.org/archive/html/automake/2006-03/
Do the archive administrators know? How do we tell them?

Cheers
Duncan

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

[Alexandre Duret-Lutz]

 DG == Duncan Gibson [EMAIL PROTECTED] writes:

[...]

 DG # autotools object to --libs, FLTK_LIBRARIES  FLTK_LDFLAGS :-(
 DG # FLTK_CXXFLAGS = `fltk-config --cxxflags`
 DG # FLTK_LIBRARYS = `fltk-config --libs`
 DG # FLTK_LDSFLAGS = `fltk-config --ldstaticflags`

You could AC_SUBST these variables from configure.ac (after
ensuring that fltk-config exists).  It's better anyway: this way you
don't run `fltk-config --cxxflags` for each compilation.

[...]

 DG AM_CPPFLAGS = -I$(srcdir)/src $(FLTK_CXXFLAGS)

 DG .fl.h:
 DG fluid -c $

 DG .fl.cxx:
 DG fluid -c $

 DG 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 in there, the make fails with
 DG find g++: src/foo.cxx: No such file or directory

(find g++?  I'll assume it's a typo.)
[...]
 DG If I run 'fluid -c foo.fl' manually in the src directory, then I can
 DG run make successfully 

Yeah, but your Makefile does not run fluid from the src/ directory, it
runs it from the top-level directory.
I guess fluid builds foo.cxx and foo.h in the current directory,
doesn't it?  I hope fluid has some options to help you specify that
the files should be output in src/ (if you do not plan distributing them)
or $(srcdir)/src/ (if you plan to) rather than in the current directory.
Otherwise you'll have to move them (if it wasn't a suffix rule you could
also cd in the right directory before running fluid).

 DG Once I've solved this basic problem, I have another issue to address.
 DG I need to be able to tweak foo.h once it has been created by fluid.
 DG In a standard makefile I could use:

 DG foo.h foo.cxx: foo.fl
 DG fluid -c foo.fl
 DG mv foo.h foo.h.tmp
 DG sed 's/old/new/' foo.h.tmp  foo.h

 DG Can I still do that here? 

Sure.  But 
1) you should try not to create foo.h before the rule finishes (if it's 
   possible to have fluid create foo.h.tmp directly, that's better)
2) you will want to find a way to mix this with the
   idiom described in the Automake FAQ under Handling Tools that
   Produce Many Outputs.

Probably something along the lines of

.fl.cxx:
fluid -c $ + options to get src/$*.{cxx,h.tmp}
sed whatever $*.h.tmp  $*.h

src/foo.h: src/foo.cxx
@if test ! -f \$@; then \
   rm -f src/foo.cxx; \
   $(MAKE) $(AM_MAKEFLAGS) src/foo.cxx; \
else :; fi

 DG Should I even be using the .fl.cxx suffix
 DG rules as I am doing at the moment, or should I be using SUFFIXES?

SUFFIXES is something you use in addition to suffix rules to support
weird extensions (not starting with one dot, or with more than one).
Not your case.
-- 
Alexandre Duret-Lutz

Shared books are happy books. http://www.bookcrossing.com/friend/gadl

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

[Duncan Gibson]

I've been trying to set up a multi-directory project using non-recursive
auto{conf,make} to build an FLTK application (see http://www.fltk.org).
I have created a simple example for testing, where I have a sub-directory
containing foo.fl and foo_test.cxx, and what I need to do is:

use 'fluid -c foo.fl' to create foo.h and foo.cxx
create libfoo.a from foo.cxx
compile foo_test.cxx and link against libfoo.a

A long time ago I asked 'How to specify 2 stage build in Makefile.am'
(see http://lists.gnu.org/archive/html/automake/2002-10/msg00068.html)
that gave me some idea on how to call 'fluid'.

More recently, I had a thread 'Autoconfisticating a multi-directory,
non-recursive, GNU-make specific project' and I thought that I had all
that I needed to set up the auto{conf,make} framework for my project.
(see http://lists.gnu.org/archive/html/automake/2006-02/msg00036.html)

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 currently have is:

The configure.ac looks like:

AC_PREREQ(2.59)
AC_INIT([foo], [0.0.1], [EMAIL PROTECTED])
AM_INIT_AUTOMAKE([1.9 foreign subdir-objects])
AC_CONFIG_SRCDIR([src/foo_test.cxx])
AC_CONFIG_HEADER([config.h])

AC_PROG_CC
AC_PROC_CXX
AC_PROG_RANLIB

AC_CONFIG_FILES([Makefile])
AC_OUTPUT

The top level Makefile.am looks like:

bin_PROGRAMS =
lib_LIBRARIES =
noinst_LIBRARIES =
BUILT_SOURCES =

# in my file these variables have been expanded, but anyway will
# be handled differently via autoconf once everything works
FLTK_CXXFLAGS = `fltk-config --cxxflags`
FLTK_LIBRARYS = `fltk-config --libs`
FLTK_LDSFLAGS = `fltk-config --ldstaticflags`

include src/Makefile.am

The src/Makefile.am looks like:

bin_PROGRAMS += src/foo_test
noinst_LIBRARIES += src/libfoo.a

AM_CPPFLAGS = -I$(srcdir)/src -I$(top_builddir)/src $(FLTK_CXXFLAGS)

.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

nodist_src_libfoo_a_SOURCES = src/foo.cxx

src_foo_test_LDADD = src/libfoo.a $(FLTK_LIBRARYS)
src_foo_test_LDFLAGS = $(FLTK_LDSFLAGS)
src_foo_test_SOURCES = src/foo_test.cxx

After a lot of trial and error, the src/Makefile.am *appears* to work,
but I'm concerned about the filename manipulations in the .fl.h rule,
the lack of checking so that I don't zap things if building in $(srcdir),
AM_CPPFLAGS needing both $(srcdir) and $(top_builddir), the fact that
src/foo.fl doesn't appear anywhere, and how to tidy up.

Am I really going about this in the best way?

Cheers
Duncan

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

[Duncan Gibson]

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 build in Makefile.am
(see http://sources.redhat.com/ml/automake/2002-10/msg00066.html)

Now I want to put them both together, but am having problems. I've
simplified my project down to a single source directory to show what
I want to do, and how far I have got. What I want to happen is:

foo.fl is processed by 'fluid' to give foo.cxx and foo.h
foo.cxx is then compiled and archived in libfoo.a
foo_test.cxx is compiled and linked against libfoo.a


My configure.ac looks like:

AC_PREREQ(2.59)
AC_INIT([foo], [0.0.1], [EMAIL PROTECTED])
AM_INIT_AUTOMAKE([1.9 foreign subdir-objects])
AC_CONFIG_SRCDIR([src/foo_test.cxx])
AC_CONFIG_HEADER([config.h])

# Checks for programs.
AC_PROG_CC
AC_PROG_CXX
AC_PROG_RANLIB

# Checks for libraries.
# Checks for header files.
# Checks for typedefs, structures, and compiler characteristics.
# Checks for library functions.

AC_CONFIG_FILES([Makefile])
AC_OUTPUT


My Makefile.am looks like:

bin_PROGRAMS =
check_PROGRAMS =
lib_LIBRARIES =
noinst_LIBRARIES =
BUILT_SOURCES =

# autotools object to --libs, FLTK_LIBRARIES  FLTK_LDFLAGS :-(
# FLTK_CXXFLAGS = `fltk-config --cxxflags`
# FLTK_LIBRARYS = `fltk-config --libs`
# FLTK_LDSFLAGS = `fltk-config --ldstaticflags`

FLTK_CXXFLAGS = -O2 -march=i686 -I/usr/X11R6/include
FLTK_LIBRARYS = /usr/lib/libfltk.a
FLTK_LDSFLAGS = -L/usr/X11R6/lib -s /usr/lib/libfltk.a -lm -lXext -lX11

include src/Makefile.am


and my src/Makefile.am looks like:

check_PROGRAMS += src/foo_test
noinst_LIBRARIES += src/libfoo.a

AM_CPPFLAGS = -I$(srcdir)/src $(FLTK_CXXFLAGS)

.fl.h:
fluid -c $

.fl.cxx:
fluid -c $

BUILT_SOURCES += src/foo.h

src_libfoo_a_SOURCES = src/foo.fl

src_foo_test_LDADD = src/libfoo.a $(FLTK_LIBRARYS)
src_foo_test_LDFLAGS = $(FLTK_LDSFLAGS)
src_foo_test_SOURCES = src/foo_test.cxx


My problem is that if I create a separate build directory, and run
sh ../configure and make in there, the make fails with
find g++: src/foo.cxx: No such file or directory

I've tried putting explicit dependencies instead of the suffix rules,
and all sorts of variations of src/foo.h, src/foo.cxx and src/foo.fl
in BUILT_SOURCES, src_libfoo_a_SOURCES and nodist_src_libfoo_a_SOURCES
but to no avail. I haven't found the magic combination yet.

If I run 'fluid -c foo.fl' manually in the src directory, then I can
run make successfully in the separate build directory, but that's not
really what I want. I assume that I have some mismatch between the
build directory and $(srcdir) but I can't see how to correct it.

Once I've solved this basic problem, I have another issue to address.
I need to be able to tweak foo.h once it has been created by fluid.
In a standard makefile I could use:

foo.h foo.cxx: foo.fl
fluid -c foo.fl
mv foo.h foo.h.tmp
sed 's/old/new/' foo.h.tmp  foo.h

Can I still do that here? Should I even be using the .fl.cxx suffix
rules as I am doing at the moment, or should I be using SUFFIXES?

Cheers
Duncan

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

[Alexandre Duret-Lutz]

 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: doc/automake.texi
 RW ===
 RW RCS file: /cvs/automake/automake/doc/automake.texi,v
 RW retrieving revision 1.127
 RW diff -u -r1.127 automake.texi
 RW --- doc/automake.texi   5 Feb 2006 05:53:38 -   1.127
 RW +++ doc/automake.texi   21 Feb 2006 08:29:58 -
 RW @@ -4509,11 +4509,12 @@
 RW The extension of a yacc source file is used to determine the extension
 RW of the resulting C or C++ file.  Files with the extension @file{.y}
 RW will be turned into @file{.c} files; likewise, @file{.yy} will become
 RW [EMAIL PROTECTED]; @file{.y++}, @file{c++}; and @file{.yxx}, @file{.cxx}.
 RW [EMAIL PROTECTED]; @file{.y++}, @file{c++}; @file{.yxx}, @file{.cxx}; and
 RW [EMAIL PROTECTED], @file{.cpp}.

 RW Likewise, lex source files can be used to generate C or C++; the
 RW -extensions @file{.l}, @file{.ll}, @file{.l++}, and @file{.lxx} are
 RW -recognized.
 RW +extensions @file{.l}, @file{.ll}, @file{.l++}, @file{.lxx}, and
 RW [EMAIL PROTECTED] are recognized.

 RW You should never explicitly mention the intermediate (C or C++) file
 RW in any @code{SOURCES} variable; only list the source file.

-- 
Alexandre Duret-Lutz

Shared books are happy books. http://www.bookcrossing.com/friend/gadl

Re: Automake doesn't invoke bison even with BUILT_SOURCES

[Kototama]

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

[Harald Dunkel]

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 @@
 ## along with this program; if not, write to the Free Software
 ## Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
 ## 02111-1307, USA.
+$(%XLIBRARY%_OBJECTS): $(%XLIBRARY%_PREDEPEND)
 %LIBRARY%: $(%XLIBRARY%_OBJECTS) $(%XLIBRARY%_DEPENDENCIES) %DIRSTAMP%
-rm -f %LIBRARY%
$(%XLIBRARY%_AR) %LIBRARY% $(%XLIBRARY%_OBJECTS) $(%XLIBRARY%_LIBADD)


It makes sure that the stuff in $(libmy_a_PREDEPEND) gets built
before the library objects. The patches for *_LTLIBRARIES and
*_PROGRAMS look the same.


What do you think? Would you expect any problems with this?


Regards

Harri

Re: BUILT_SOURCES too clumsy

[Stepan Kasal]

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 for an optional convenience
 library exactly when needed.

Perhaps you could place the library to a separate directory.
Then you'd use AM_CONDITIONAL(MYLIB, ...) in configure.ac
and

if MYLIB
  SUBDIRS += mylib
endif

to control whether the recursion of make goes into that dir.

If the make won't recurse, it won't build BUILT_SOURCES there.

Yes, this is just another workaround, but perhaps it'll help you.

Stepan Kasal