> From: Paul Smith <psm...@gnu.org> > 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 > to date following the standard algorithm and we're determining whether > the target is outdated, we skip order-only prerequisites. > > In the case of your example, make considers "all", then considers "b", > then considers "t", then considers "a.o", then considers "a.h", then > considers "foo", then considers "b". It doesn't matter what the result > of considering "foo" was: make still needs to see if "b" needs to be > brought up to date. In order to see if "b" is out of date, it needs to > consider "t", etc. and you have a cycle.
That's too bad, because it doesn't allow to have targets which can only be updated by one of their dependencies. 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 source files #include's the header. The header is also kept in the VCS, so some, perhaps outdated version of it is always available. But I cannot find a way of having a target that remakes the header when the data file changes, because this creates a circular dependency which Make throws away. I thought order-only dependencies could be a way out of this conundrum, but they aren't :-( Thanks. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
