Well, I also think it's a wheel in need of some re-invention. That's why I'm (in my CFT) reinventing it myself, though I'm aimed in a somewhat different way.

On the POD, it would be nice to say a little more inline with the example in the SYNOPSIS section about what each block is doing. They're reasonably guessable, and hopping back and forth with the long description is good for checking the guesses, but it's documentation; the goal is to not have to guess :)

On the code (or rather the API), one thing I do with my own replacement is to make use of passing args in pairs that can unroll into a hash, in pseudo-named-args fashion. That makes it more readable when you have more than 2 args, and also gives the user more flexibility in arranging things. It also means you can make things explicit instead of implicit (like :flags:, at a glance; I could be wrong about how it works, though).

I can't say I've looked at it terribly in depth; just glanced at the docs and examples. It superficially seems a reasonable tack to take in solving the problems you're aiming at.

You are right on the Docs, next dist I will add to the synopsis to make it more clear.

I considered using named arguments, but one thing I like about make is the syntax when defining a rule. I wanted to mirror that syntax as closely as possible, not only because I like it, but it will be more familiar for people experienced in make.

':flags:' is something I do not like, and I am currently trying to think of a better system. One alternative is to have flags specified in an optional arrayref at the end of the Task declaration. Or perhaps since the only flag is always, I can make an 'always' task. Flags were not something I originally intended to have at all, but they were brought in because of someone else who is now interested in using this.

I considered using named arguments, but one thing I like about make is the syntax when defining a rule.

Yeah, I do too. My initial mental ramblings had a syntax much closer to make's. I eventually decided that greater departure was called for, as I started thinking about the greater flexibility I wanted, and how ugly and shoehorn-ish it would be trying to cram it in without changing the syntax more significantly.

I figure enough things will differ from make anyway, for just the reasons I'm wanting to replace it in the first place, that trying to put the syntax too close would just make things harder. The user will have to move in a bit different direction anyway, so I might as well favor internal consistency over external. And named args make things more readable and easier; for instance, I'd just put describe as another named arg on task/file.

Actually, I may go do that. I don't have any description-ish stuff right now; have to think about how that fits in... thanks for the idea 8-}

Better system:

• flags are specified in arrayrefs, flag arrayrefs can go anywhere in the list just like :flags: did.
• task { named params }; is an alternative to using ordered. You can use either.

This is done in version 0.12, docs have been updated.