On Wednesday, June 18, 2014 12:13:29 AM UTC+9, Michael Levine wrote:
>
> On Monday, June 16, 2014 11:24:44 PM UTC-4, Rendaw wrote:
>>
>> I imagine you wouldn't be able to read and write a group in the same
>> tupfile.
>>
>
> I was going to ask you "Why Not"? But as I was writing the following
> paragraphs, the complications became more clear to me.
>
Okay, I'd like to take back pretty much everything I said.
I think Tup groups right now don't factor in until after all Tupfile
parsing is finished. Once the depedency tree is determined, groups can be
tracked on the fly during rule processing. This way the file processing
order and statement order doesn't matter, but on the other hand they can't
be read within the Tupfiles and they have to be explicitly marked within
the rule (as a special input/output argument).
If we go with the plan of being able to read groups in the Tupfiles, even
if we restrict reading and writing groups in the same file it would be
unsafe since Tupfiles can be parsed/re-parsed in any order. It might be
possible to add Tupfile interdependencies to the dependency tree but I
think it might require iteration with stability testing - more on that
later.
But anyways, I think your example use case is good enough that we wouldn't
want to restrict reading and writing in the same file anyway.
>
> - Either the parser treats tup.group similar to all other dependencies.
> Except that in this case, it is not the invocation of command, but rather
> the parsing/expansion of variables which is ordered based on the dependency
> graph.
> tup.group('apps') += ... --> name = tup.group('name') --> tup.group('name')
> += ...
> (2) --> (1) --> (3)
> and therefore, the rules and expansions must be ordered based on their
> dependency graph.
>
I think this would not be feasible. Lua isn't strict enough to be able to
reorder statements and we have the file ordering problem from above.
>
> - Alternatively, the rules are parsed in order. Here, it might be
> necessary to have a flag to re-parse the file wherever there are groups
> being used until there are no more db changes (I don't imagine that the
> rule parsing should take very long). Obviously, tup itself re-parsing the
> file until the rules stop changing, then the user would experience this --
> the rules behave differently, depending on how many times tup is
> executed...
>
There have been a couple requests for complete automatic dependency
detection in Tup, so that input and output files would be completely
unspecified, but that's been rejected on the grounds that you'd need to do
a similar style of iteration and stability detection.
I'm sorry my reply is totally unconstructive. I'm starting to feel the
deferred route might be pretty good. We might be able to make a
input_group and output_group parameter to definerule or something, but
otherwise I think it would be the same as the existing group functionality.
>
>> I'll try to help out where I can, I've been really busy with
>> administrative stuff the last couple months and will continue to be busy
>> for another couple months probably.
>>
> I'd also be happy to help out if I can, but I am really unfamiliar with
> the codebase in all regards. I took a quick look over the code yesterday,
> but will need more time to study and understand it. Can I contact you
> directly for help and clarifications?
>
> That would be fine. It might just be easier to just post in this group,
on the off chance it could help someone else or someone else is able to
help with the answers.
--
--
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.
