I'm a colleague of the original poster, and have spent the majority of
today trying to get this work. It can be done, but requires a gruesome hack.
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).
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.)
My third attempt was to try to create a rule that would always need to be
executed. I achieved this by introducing a circular dependency.
To achieve this, have a script, say alwaysRun.sh that you would like to
always run. Add a rule for this script to generate whatever output files
you need, then add the following or something similiar to alwaysRun.sh.
Please note, that I am not at work atm, so I'm not sure if this will work
verbatim.
function cdToActualProjectRoot() {
while [[ $PWD != / ] && [[ $PWD != '.tup' ] ; do cd ..; done
cd ..
}
cdToActualProjectRoot
touch path/to/alwaysRun.sh
The reason this works is that tup detects the script as changed, and so
needs to rerun it, however this is also a circular dependency, as even
after running a full tup upd, there is still potential work to be done. Tup
however does not complain about this, as the write to the script occured
once we broke out of the fuse repository, and so tup thinks that a user has
modified the script.
If you use this, I recommend using the ^o flag in your rule, so if the
output of your alwaysRun.sh is the same as before, the build steps that it
influences do not have to be run again.
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.
Hope that helps,
Matt
--
--
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.
