On Fri, May 16, 2014 at 12:16:31 -0700, Matthias Vegh wrote: > My first attempt was to add an environment variable to the mix, one that > always > changes, and would influence the rule that generated the git hash. Seeing as > various shells provide such a variable-like thing ($RANDOM) I started there. > It > turns out, that $RANDOM is not exactly an environment variable (I'm not sure > how exactly, but tup couldn't export it).
It's a shell builtin. > My second attempt was to add a symbolic link to one of the files in the .git > folder, which would be updated when a new commit is made. The file I chose for > this purpose was .git/index. I'm not sure if this is a correct choice, but > making a commit, and then resetting updated the times in it. However, once I > added the symbolic link as an input file to a rule, I realized, that even > though the file pointed to by the link was updated, the link itself was not, > so > tup was unaware of the changes. (This solution is also not portable, as the > .git folder can be renamed, in which case the link would be broken.) Symlinks are also notoriously fickle on Windows (needing Administrator rights). > I'm sure you will all agree that this is a dirty hack, however I didn't want > to > opt for the post commit hook, as AFAIK, hooks themselves cannot be added to > the > git repo, so if a new user clones our code, they would not have this > functionality. An ideal solution would be an always run rule, or to be able to > add hidden files as dependencies. I solve this by having a build rule clone the hooks branch into .git/hooks. This won't work in Tup either though :/ . --Ben -- -- 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.
