Another reason copies are bad: If there is a compilation error, emacs (and perhaps other IDEs) will offer to edit the file there the error occurred. It's too easy to follow the suggestion and edit the copy instead of fixing the "primary" source.
Andrei On Fri, 31 Oct 2014, David Roundy wrote: > I am aware of that argument against copies, but think the simplicity and > portability would benefit from copies (or maybe symlinks). It is > relatively rare that output is much smaller than input, so in the case of > 10GB of input files with many variants, you're already looking at a huge > amount of disk space and very slow build. > > David > > On Fri, Oct 31, 2014 at 6:28 AM, Freddie Chopin <[email protected]> > wrote: > > > On 10/31/2014 02:12 PM, David Roundy wrote: > > > >> What about explicitly copying the input files to the variant output > >> directory? There are programs (that annoy build authors) such as latex that > >> explicitly require that the input and output be in the same directory. The > >> current approach of pretending that the input files are in the output > >> directory works, but it seems simpler to actually copy them there. Then > >> when you modify the "real" input files, there would be a rule to update the > >> ones in the variant build, and that would trigger a rebuild in the > >> variant. It seems (to my naive self) like this implicit set of copy rules > >> (combined with the configuration handling in the variant) would be all that > >> is needed for variants to work. > >> > >> David > >> > > > > As simple as it sounds I don't think it's a good solution. Imagine that > > there are 10GB of "input" files and you have 15 variants - you'd end up > > with 150GB of copies... I know this example is exaggerated, but someday > > someone will come with such problem anyway... > > > > I still think variants could actually be replaced with some clever lua > > scripting, which would also require some (probably minimal) changes to > > tup's behavior... > > > > Regards, > > FCh > > > > > > -- > > -- > > 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 a topic in the > > Google Groups "tup-users" group. > > To unsubscribe from this topic, visit https://groups.google.com/d/ > > topic/tup-users/wMonJRxI75w/unsubscribe. > > To unsubscribe from this group and all its topics, send an email to > > [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > David Roundy > > -- > -- > 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. > -- -- 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.
