I have a humble proposal which would 'fix' variants on Windows, and improve
the capability and flexibility of TUP for multi variant builds.
"So variants are just directories - you specify the folder and tup
> updates everything in this folder..."
>
Yes. That's all they are, they are output directories which vary only in
the values of certain pre-defined configuration variables. Each variant
output directory is distinct, and separate from the immutable input
directory.
I think the current variant implementation is good in that it defines
distinct output directories, with pre-defined configuration variables. But
I think a mistake was made trying to make the input directory tree appear
as if it is part of the output tree. This was done by using FUSE to making
the input files 'magically' accessible from the corresponding output
directory. I understand why this was done, to allow the rule author to not
need to know whether input files are in the input tree, or are output
produced from an earlier rule. Besides the fact that FUSE doesn't work on
Windows, I think there are benefits to writing rules which explicitly state
where the input files are located.
*I am proposing that Tup rules assume that inputs and output are in the
output tree, unless the input is decorated to indicate that the file is
located in the input tree. * This could be a %I symbol which Tup would
expand to the relative path back to the input tree ('I' could stand for
Immutable Input). This would work on Windows and Linux, since FUSE would
no longer be necessary. Less code to maintain, and fewer bugs = win win.
Here are a couple of Tup rules which demonstrate this proposed capability:
: foreach %I*.c |> gcc -Wall -c %f -o %o |> %B.o
: *.o |> gcc %f -o %o |> hello
Notice the addition of %I. That's it. Now variants work on Windows too,
and FUSE is no longer necessary. All that is needed it to ditch FUSE, and
make the %I symbol available to rule authors. Tup would continue to CD
into the output directory and execute the rules from that directory.
Also, 'in-tree' builds would continue to work for simple projects which
don't require variants. %I would simply evaluate to the current directory.
Feedback is appreciated!
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.