I actually like that each variant is marked by a config file at the top of the variant output directory. It keeps each variant in a pocket universe by itself, separate from all other variants, and from the immutable input tree.
And I like both how the tup files are stored in the input tree, and how the rules are executed by first CDing into the corresponding output tree. The only current problem (as I see it), is that variants do not work on Windows. The reason for this is that the implementation is depending heavily upon OS specific functionality, when it doesn't need to. The file access detection with FUSE is working, so you are correct, that needs to stay. But whatever variant logic is bugged, which is responsible for implicitly mapping the input tree inside the output tree, can simply be removed. Simply replace the input expression in the rule with %I to indicate explicitly that this input is in the input tree. So the proposal as stated still stands, and hopefully the implementation implications are more clear. Many thanks for your clarifications. Cheers, 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.
