On Mon, Jun 30, 2014 at 10:44 AM, tupper <[email protected]> wrote:
> I'm reading about tup for the first time and scanning through the examples > <http://gittup.org/tup/ex_dependencies.html>. My expectation is that tup > rules are declarative so the order in which they appear in the Tupfile > should be immaterial but I'm seeing that this ordering is fine... > > : |> echo "generated text" > %o |> generated.txt >> : generated.txt |> ./test.sh > %o |> output.txt >> > > But when the order of the lines is reversed then tup complains... > > $ tup upd >> [ tup ] [0.000s] Scanning filesystem... >> [ tup ] [0.001s] Reading in new environment variables... >> [ tup ] [0.001s] Parsing Tupfiles... >> * 1) [0.001s] . >> tup error: Explicitly named file 'generated.txt' in subdir '.' is >> scheduled to be deleted (possibly the command that created it has been >> removed). >> tup error: Error parsing Tupfile line 1 >> Line was: ': generated.txt |> ./test.sh > %o |> output.txt' >> [ ] 100% >> *** tup: 1 job failed. >> $ >> > > Am I missing something here? Or does it have to do with 'generated' vs > 'normal' files? > A related issue is that rules are not idempotent. They are bound to the Tupfile/directory in which they are defined. And they cannot be activated in arbitrary order. So it is not currently possible to e.g., have a first rule in a first tup file that generates an object module, a second rule in a second tup file that consumes that object module, and a third rule back in the first tup file that runs a unit test on the object module by linking with the library. It is not clear whether crossed rules are possible. I think not. Crossed rules are a first rule in a first tup file that generates an output that is consumed by a second rule in a second tup fiel crossed with a third rule in the second tup file that generates an output that is consumed by a fourth rule in the first tup file. AFAICT this is part of tup's enforcement of the A in DAG. I hope that eventually that enforcement is limited to forbidding cycles in the rules/dependencies rather than harmless (and technically meaningless) cycles in tup files. Tup has warts, but it is most rigorous build system currently available, paid or free. Good luck. -- -- 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]. For more options, visit https://groups.google.com/d/optout.
