Shouldn't re-run targets listed in Deps that were already run from command line

[mgabeler-lee-6rs]

If I explicitly specify a target on the command line which is also a dependency of another target I specify on the command line, it should only run that target once.

Instead it seems it runs a target once per target on the command line

Example magefile.go:

// +build mage

package main

import (
    "fmt"

    "github.com/magefile/mage/mg"
)

func A() {
    fmt.Println("A")
}

func B() {
    fmt.Println("B(deps)")
    mg.Deps(A)
    fmt.Println("B")
}

Invocation: mage a b

Expected:

A
B(deps)
B

Actual:

A
B(deps)
A
B

More fun:

$ mage a b b
A
B(deps)
A
B
B(deps)
B

I'd expect this to be equivalent to just running mage a b, which should be functionally equivalent to running mage b

[natefinch]

Yeah, this is an interesting point. That seems correct, and is probably fixable.

[mgabeler-lee-6rs]

In light of the post about co-maintainers ... if I find some time to work on this (it's admittedly a pretty small issue and doesn't really get in my way :wink:) I'll see if I can put up a PR for it 🙂

[imker25]

Hi everybody,

I just wonder why this bug has not more attention. I my case this is pretty annoying. I have something like

// +build mage

package main

import (
    "fmt"

    "github.com/magefile/mage/mg"
)

func Clean() {
}

func Build() {
    mg.Deps(Clean)
}

func Test() {
    mg.Deps(Clean)
}

func Pack() {
    mg.Deps(Clean, Build)
}

Since clean obviously removes all build, test and pack output, I end up without any build, or pack output if I run the targets in wrong order.

For example if I do mage build pack test I end up with only the test results left. If I want a fast run, so also build is only done once I need to run mage test pack and not calling the build target (directly) at all. And in this case my test result files get lost.

I mean, yes we can workaround it. And since go compiles fast it's not even so bad to run the build twice. But hey, targets and resolving the dependencies between them is kind of a core feature of make file like systems.

So if somebody has a hint for me how to fix this, I may give it a try.

Best regards imker