> From: Edward Welbourne
> CC: "bug-make@gnu.org" , "psm...@gnu.org"
> Date: Thu, 24 Jan 2019 10:16:01 +
>
> A suggestion for a kludge-around for this: part of your make-file says
> how to regenerate the header from the data file, using an emacs binary.
> Condition that part of your make-fil
Eli Zaretskii (23 January 2019 20:21)
> In Emacs, we have a header file that is generated from an certain data
> file, but its generation requires an Emacs binary, which runs a Lisp
> command to massage the data file into a C header. And the binary
> depends on that header because one of the sourc
On Wed, 2019-01-23 at 21:21 +0200, Eli Zaretskii wrote:
> > From: Paul Smith
> > Cc: bug-make@gnu.org
> > Date: Wed, 23 Jan 2019 13:55:49 -0500
> >
> > That's not how it works. Order-only prerequisites are considered
> > identically to normal prerequisites in every way except one: after
> > all
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Wed, 23 Jan 2019 14:49:42 -0500
>
> One way this can be done is by using a recursive invocation of make.
Wouldn't that cause an infinite recursion?
___
Bug-make mailing list
Bug-make@gnu.org
https://l
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Wed, 23 Jan 2019 13:55:49 -0500
>
> That's not how it works. Order-only prerequisites are considered
> identically to normal prerequisites in every way except one: after all
> the prerequisites, including order-only prerequisites, are brought up
On Wed, 2019-01-23 at 19:55 +0200, Eli Zaretskii wrote:
> > From: Paul Smith
> > Date: Wed, 23 Jan 2019 12:00:20 -0500
> >
> > GNU make's internal dependency graph determines the order in which
> > targets are built. It must be acyclical, otherwise make can never
> > choose which target to build
> From: Paul Smith
> Date: Wed, 23 Jan 2019 12:00:20 -0500
>
> GNU make's internal dependency graph determines the order in which
> targets are built. It must be acyclical, otherwise make can never
> choose which target to build before others.
>
> In your example makefile you have a cycle:
>
>
On Wed, 2019-01-23 at 18:35 +0200, Eli Zaretskii wrote:
> I was surprised to see it complain and drop the a.h <- b dependency,
> since it is an order-only dependency. Is this a bug? If not, what
> kind of problems can happen due to such "circular" dependencies?
I don't think it's a bug.
GNU mak
The following short Makefile:
all: b
a.o: a.h
touch a.o
a.h: foo | b
touch a.h
t: a.o
touch t
b: t
touch b
followed by these commands:
touch foo
make
produces:
make: Circular a.h <- b dependency dropped.
touch a.h
touch a.o
touch t
touch b
I
