On Monday, June 16, 2014 11:24:44 PM UTC-4, Rendaw wrote:
>
>
> I haven't used groups myself or had a chance to try them out, so I
> apologize in advance if this is obviously unworkable.
>
> My preferred interface would be something like this:
> name = tup.group('name') -- Returns group reference
> name += 'obj1.o' -- Name depends on this file
>
I personally think that the first statement is fantastic -- it makes the
code / rule very clear and obvious as to what it is trying to accomplish.
I am a bit confused about the meaning of the second statement. I would
have thought that dependencies are specified with rules. My understanding
of groups is that they are effectively 'global variables'
> name = tup.group('name') -- Returns group reference
> for index, obj in ipairs(name) do print(obj) done -- This file depends on
> name group
>
> -- This file depends on name group. App group depends on this file
> tup.group('apps') += tup.frule{inputs = {'main.o'} .. name, command = 'gcc
> -o %o %f', outputs = {'app'}}
>
Exactly. Although might it be possible to prevent the use of operator= ?
Or at least throw a warning that the user is overwriting an existing
group. I think that from a semantic point-of-view, this is the correct
syntax. However, it differs from the legacy group usage pattern, and might
lead to confusion.
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.
I see 2 possible approaches. Consider the following snippet:
(1) name = tup.group('name') -- Returns group reference
(2) tup.group('apps') += tup.frule{inputs = {'main.o'} .. name, command =
'gcc -o %o %f', outputs = {'app'}}
(3) tup.group('name') += tup.frule(inputs = {'name.o'}, command = 'gcc -o
%o %f', outputs = {'mynamed'}}
- 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.
- 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...
> Groups could be integer indexed and provide a length implementation, but
> disallow overwriting elements.
>
There is already support for groups (as TUP_NODE_GROUP, iirc) in the
codebase. Isn't it possible to 'piggyback' on this functionality?
Delegating to the existing implementation? Alternatively, if there are
any shortcomings in the implementation of 'Groups', then we should find a
different name for this function in the Lua Parser to distinguish between
the two. I can imagine some issues where a directory structure uses a
mixture of legacy and Lua Tupfiles.
> 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?
Thanks,
Shmuel
--
--
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.
