[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [buckminster-dev] Action properties [WAS Action output?]
|
Kenneth Ölwing wrote:
Don't know if we'd be going to far but consider that you might want to
declare a prop to be sent to 'some components, but not all' - i.e.
would it be overkill to have the action qualified name be a regexp
instead? There are benefits to that, but also drawbacks - e.g., it
makes the command line potentially even more horrible, the user must
understand regexps, and to make parsing as easy and safe as possible,
the 'global' props should all be listed as '.*!foo=bar'...hmm.
Perhaps it's a good idea to avoid using characters that many shell might
try to expand one way or another and simply use the '/' to separate? We
could then do:
Global foo:
foo
'foo' for all 'flmberry' actions (in all components):
flmberry/foo
'foo' for the 'flmberry' action in 'Z':
Z/flmberry/foo=bar
'foo' for all actions in 'Z'
Z//foo=bar
Note that somewhere in all this is also where we started out - the
idea of having a --output that just mapped to a property...this has
the same needs, i.e. you must (for that particular property, I'd say
that there is never correct to send the same output root to >1
component) be able to steer one setting for buckminster.output to one
place for component X and to another place for Y...We'd sort of need
to duplicate similar ideas to that flag - or skip that option flag
entirely. Don't know what's best. Or if there's a third, better option...
Let's skip it entirely for now. Inventing yet another mechanism for this
special property alone seems rather pointless.
Thinking about it gives me the idea that maybe we should consider to
be conservative and say that the default is 'mutable=false'. The
rationale is that since the usage of props in the actions becomes a
very explicit part of the contract, it stands to some reason that the
designer of such things specifically *have* to mark the ones that is
mutable. Less chance for the component/action designer to accidentally
forget and then have someone else make use of a prop that wasn't
intended (and that the designer then *has* to support...).
Yes, I agree. Let's make it mutable=false by default.
Finally, I was thinking about the perform command line: we have said
that it is (will be) correct to say this:
perform C1#A C2#B [...and so on]
I think it would be wise to code the execution so that it's illegal to
mention two actions that actually belong to the same dependency chain.
I admit that I can't see a great drawback to allowing it, but neither
can I see any benefit. It's more a hunch that it might come back and
haunt us one day, and it might give the user the incorrect expectation
that they can control/influence a dependency order...
Should be easy enough to implement. Perhaps issue a warning rather then
say it's illegal?
- thomas
