gittup
commented
1 year ago Interesting idea - I don't think it would be too hard to add. It may be as simple as adding a call to prune_graph() after build_graph() in the generate() function here: https://github.com/gittup/tup/blob/4e9f5b328f43fbfbdff88da7b4520efb1f1a5263/src/tup/updater.c#L491
You can see a similar construction in the 'update' path here: https://github.com/gittup/tup/blob/4e9f5b328f43fbfbdff88da7b4520efb1f1a5263/src/tup/updater.c#L1607-L1611
One pitfall is probably going to be accounting for the fact that the script.sh/script.bat argument would need to be accounted for.
To be a complete feature it'd be nice to have a test case (something similar to t2204-generate-shell-script-mkdir.sh maybe?) and update the man page as well. I can take a stab at this some point in November, but if you want to give it a try and see if it works for your use-case that would be helpful!
Side note, what issues are you running into getting tup to run in docker?
Something that would really help my use of tup in CI - the ability to specify the required output(s) in 'tup generate' in the same way as you can with 'tup' itself. At the moment it creates a script to build the entire world.
Background, I have a single repo which builds multiple products, each with their own branches (yes I know, not ideal, but rather stuck with it for now). I have a CI system which previously used build VMs for multiple Linux distros, and used tup with specified outputs to only built the required product for the particular branch being done. Now moving to docker, where tup doesn't work well, and using 'tup generate' to create a batch file. Unfortunately that means building all products across all branches, which is (a) slow and (b) a nightmare to keep up to date as compilers get fussier / underlying libraries change.
Is this something that would be relatively easily for a tup-source-newbie to add? Happy to try if I can have some pointers.
Thanks
Paul