My understanding was that order does not necessarily need to matter as
rules are indeed declarative.
But, as your examples shows, it is non trivial to make tup able to
understand the rules in any order.
You basically require two passes, or a way to encode glob patterns in
the dependency tree. Globs can only range over files in the current
directory, so that helps a bit. Now, encoding globs in the dependency
tree would be funny becaus you could theoretically glob in other
directories...
Tup dependency on rules order is not a fatality, but requires
non-trivial patches to work.
-- G.
On 8/09/19 20:57, Todd Doucet wrote:
Looking into some more, I guess tup has the idea that the rules
generally are executed in order and that is a design decision that
goes beyond order-only dependencies.
For example, even without any order-only dependencies, the following
two Tupfiles would do different things (only the order of the lines is
swapped):
First:
: foreach *.cpp |> g++ -Wall -c %f -o %o |> %B.o
: *.o |> g++ %f -o %o |> hello
Second:
: *.o |> g++ %f -o %o |> hello
: foreach *.cpp |> g++ -Wall -c %f -o %o |> %B.o
The first one would build the target “hello”, but the second one would
not.
So I gather that one thinks of a Tupfile as a kind of build script
with annotations and wildcards and similar, really designed to be
executed in sequence. That might be in the docs even; I am quite new
with tup.
If that is right, then my suggestion to make the order-only dependency
not matter probably would not make much sense. Order is supposed to
matter, for normal everyday things, if I understand it right.
--Todd
On Sun, Sep 8, 2019 at 12:59 PM Todd Doucet <[email protected]
<mailto:[email protected]>> wrote:
Thank you for the reply—I read the thread you cited.
I thought about how I would phrase the change to the doc, and
interestingly I cannot think of what I would say that is both
simple and true.
For example, it is not correct to say (as I did in the post for
clarity) that tup must know how to make the file if it does not
already exist. Because the file can exist and it would still be
an error if it is “scheduled for deletion”. Further, there could
very well be additional cases that I am not aware of.
In my view, there seems to be no fundamental (mathematical or
logical) reason for the rules to be required to be in a particular
order. They are required to be in the order that the program
expects them to be in, and I just do not know enough about how tup
internals work to be able to describe its expectations.
In my view, the biggest reason to make the rule order not matter
(if that is indeed possible) is that it gets both the user and the
documentation writer out of the business of describing these
limitations on order (because there would be none). It is a
powerfully good reason to have the rules be “declarative”, and in
my view far more persuasive than the specific use case
contemplated in the thread you cited.
I acknowledge, however, that it might be impractical to make the
rule order not matter, for reasons of code inertia or even related
to performance. What I am suggesting, though, is that if it is
practical to remove the hard-to-describe limitations, doing so
would be really good.
Thanks,
Todd
On Sun, Sep 8, 2019 at 2:36 AM Layus <[email protected]
<mailto:[email protected]>> wrote:
Yep, I also got bitten by this one :-).
There is some discussion about this in the ill-named issue on
github https://github.com/gittup/tup/issues/247.
Basically, it is not considered a pressing issue, and not
really a bug.
I guess a pull request on the doc would be trivial. Would you
feel like doing it ?
You can do it directly in github
(https://github.com/gittup/tup/edit/master/tup.1) or send your
updated/new text here and I would happily make the PR.
Regards,
-- Layus.
On 8/09/19 01:50, Todd Doucet wrote:
The documentation gives the following Tupfile in the section
describing how to handle a generated header file:
:|> sh gen_triangle.sh > %o |> triangle.h
: foreach *.c | triangle.h |> gcc -Wall -c %f -o %o |> %B.o
: *.o |> gcc %f -o %o |> hello
That works fine in the example, but if you switch the order
of the first two lines, yielding:
: foreach *.c | triangle.h |> gcc -Wall -c %f -o %o |> %B.o
: |> sh gen_triangle.sh > %o |> triangle.h
: *.o |> gcc %f -o %o |> hello
then tup generates an error on the first rule, saying that
the file triangle.h does not exist. Of course it does not
exist, it is generated. Apparently it needs to know how
before it is willing to accept an order-only dependency on
that file.
It took me a while to reduce the problems I was having to
this, perhaps in part because the documentation is silent on
the order dependency. It is odd that there is one and it
took me a long time to realize this was the problem.
(In my case, I build an executable that in turn is run by a
rule to generate a header, which in turn is used to build the
final executable. I must have all three in the right order
or it does not work.
Perhaps a note about order dependency would be useful to
others. Even better, if possible simply make the rule order
not relevant.
--
--
tup-users mailing list
email: [email protected]
<mailto:[email protected]>
unsubscribe: [email protected]
<mailto:[email protected]>
options: http://groups.google.com/group/tup-users?hl=en
---
You received this message because you are subscribed to the
Google Groups "tup-users" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tup-users/2ea8d4ad-bb85-4ae7-8334-33d2439de175%40googlegroups.com
<https://groups.google.com/d/msgid/tup-users/2ea8d4ad-bb85-4ae7-8334-33d2439de175%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
--
tup-users mailing list
email: [email protected]
unsubscribe: [email protected]
options: http://groups.google.com/group/tup-users?hl=en
---
You received this message because you are subscribed to the Google Groups "tup-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tup-users/331515a7-14a5-84f9-7cff-c787f209ebe7%40gmail.com.
