| Age | Commit message (Collapse) | Author |
|---|
|
|
|
with right now for these until they're integrated and it won't matter anymore.
|
|
that, also good to know, but annoying.
|
|
to see what happens. If this works out the filters will become a fixture either
later in M2 or early in M3
|
|
|
|
isn't already one with the same name.
|
|
work just fine for what I want. They're cute though, you can put each target
in as many groups as you'd like.
|
|
create groups, you can't do anything with them yet (although the syntax is
supported already.)
|
|
command and captures the output. This nicely solves many of my problems for
now. Is it a hack? You be the judge...
|
|
|
|
|
|
|
|
|
|
|
|
work, but targets built as a result of a requires chain no longer count towards/ nor display the total count. also added a color view for fun
|
|
everything in the produces list.
|
|
|
|
|
|
for target chaining before performing any other operations. This means libs
will be built before anything may reference them, instead of just the exe.
|
|
long it took for that one to crop up...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
cool looking.
|
|
maybe more later. -c or --clean will set all of the commands in the current
action to clean, so now you don't have to create clean rules.
Also, every viewer should now support stacks of targets, they don't now, and it
can look a little funny.
|
|
a requirement is set for a target that needs to be built, and that requirement
is another target, that target will be processed when it is needed.
|
|
|
|
|
|
|
|
|
|
|
|
levels of contextual inheritance, so now sub-targets automatically get their
parent target's context variables, if they need them.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fortunately, filtering is more of a nicety, and build is still useful. I'll put
filtering back in next.
|
|
|
|
Now we have to add cleaning, caching, and more viewer hooks / viewers.
|
|
"extra" variables.
|
