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]> 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]> 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] >> 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/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/CACM4L_K0mZ7NB%2BhU70_u7U7ChX34kP%2B_XHg%2BJc6aJurPa7MPvQ%40mail.gmail.com.
