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
On Friday, October 24, 2014 12:58:49 PM UTC-7, Freddie Chopin wrote:
>
> On 10/24/2014 09:39 PM, Ben Robinson wrote:
> > 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.
>
> That's not so simple - FUSE is used not only for variants but also (or
> rather - "especially") for file access detection. That is the most
> essential part of tup and this cannot be ditched with the change you
> propose.
>
> Something has to be done with FUSE anyway, as - from a recent issue
> report - FUSE no longer works on new OS X. This will probably leave FUSE
> Linux-only.
>
> As for your proposal - today I've thought about that briefly and one
> (not necessarily the only one (; ) thing that is missing for
> implementing variants with lua, groups and stuff like that is the
> ability to have multiple tup.config files in the tree... Currently only
> tup.config in the top dir is used, tup.config "one level down" must be
> in empty directories and tup.config files in any other location ("to
> levels down" or below) are simply ignored. You can use any other file
> with configuration assignments, but:
> - these cannot be named CONFIG_*,
> - these will not produce @-variables,
> - these will not work with tup varsed,
> - these will not be immutable,
> - there will be no way to automatically convert "# ... is not defined"
> to "n",
> - there will be no dependency of outputs on each assignment.
> There are probably some more (;
>
> 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 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.
