Open koljakube opened 3 weeks ago
On further reflection, I underestimated the problem, since parameterized goals do not get instantiated without a dependency on them and the specific argument list. That makes even recursive makesure calls a non-viable workaround. I could still call @glob
goals recursively, but then I need to implement the globbing in shell scripts as well.
I still think a lot would be gained by glob-forwarding and allowing ITEM
after @args
.
Thank you for this case. Indeed this looks like a useful feature to have. I’ll try to assess a viable implementation strategy.
I have, not for the first time, encountered the following situation:
A directory contains a set of similar files, lets call them definitions.
A Makesurefile contains glob goals for these definitions.
Now
upload-foo
cannot depend onmake-foo
by forwarding itsITEM
. I tried:@depends_on 'make-foo@$ITEM'
@depends_on "make-foo@$ITEM"
@depends_on 'make-foo' @args ITEM
@depends_on 'make-foo' @glob
@depends_on 'make-foo' @glob ITEM
@depends_on 'make-foo' @args "$ITEM"
@depends_on 'make-foo' @args '$ITEM'
(I know not all are legal)
I also can not build a hybrid
@param
-@glob
solution, since@globs
are not callable (outside of calling makesure recursively), and@globs
also can not forward their item.I have two suggested solutions, in order of preference:
ITEM
like any other parameter, without any restrictions; and also allow calling@glob
goals (with unmatched globbed items simply resulting in "goal not found" errors).@glob
goals with identical glob strings by appending@glob
to the@depends_on
(here, a more descriptive error message might be appropriate).I can't think of really evil ways of abusing the first proposal, but the second one would of course be a lot more restricted and declarative. What do you think? I might even try contributing a patch if I find the time.