Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Magefile can't use application code defined in the same directory #188

Closed
dradtke opened this issue Oct 12, 2018 · 9 comments
Closed

Magefile can't use application code defined in the same directory #188

dradtke opened this issue Oct 12, 2018 · 9 comments
Labels

Comments

@dradtke
Copy link

dradtke commented Oct 12, 2018

I have an application whose design is inspired by this post; in particular, domain objects are all stored in the application's root package, which is also the top-level folder of the repository. Since it's the top of the repository, I also have my main Magefile defined there, and lately it's been failing to compile because it finds two packages in that directory: main and (for example) app:

Mage.go:20:2: found packages main (Mage.go) and app (app.go) in /Users/dradtke/Workspace/app

This used to work, so I'm not sure what recent change actually caused it to break. The version of Mage I'm using:

$ mage -version
Mage Build Tool v1.7.0
Build Date: 2018-10-12T10:40:22-05:00
Commit: 0f9693c
built with: go1.11

The workaround seems to be pretty simple, which is to move application code down one level, leaving the Magefile as the sole Go file at the root. This is kind of annoying though, since it requires re-architecting the application in order to avoid compilation errors.

@natefinch
Copy link
Member

Can you run mage -l -debug in that directory and paste that here? This sounds like a bug, probably introduced with the changes I made for 1.7.

@dradtke
Copy link
Author

dradtke commented Oct 12, 2018

Sure thing. Here's a simple case, with just these two files saved in github.com/magefile/test:

// +build mage

// Mage.go
package main

import (
        "fmt"
        "github.com/magefile/test"
)

func Run() {
        fmt.Println(test.Message())
}
// app.go
package app

func Message() string {
        return "success!"
}

Output:

DEBUG: 11:06:33.830955 getting all non-mage files in .
DEBUG: 11:06:33.856038 found non-mage files app.go
DEBUG: 11:06:33.856063 marked file as non-mage: "app.go"
DEBUG: 11:06:33.856066 getting all files plus mage files
DEBUG: 11:06:33.877148 time to scan for Magefiles: 46.197927ms
DEBUG: 11:06:33.877165 found magefiles: Mage.go
DEBUG: 11:06:33.898578 output exe is  /Users/dradtke/.magefile/b03ddfebe208872194e13c2a2576ad2e85f8c7b6
DEBUG: 11:06:33.898604 running go env GOCACHE
DEBUG: 11:06:33.920920 build cache exists, will ignore any compiled binary
DEBUG: 11:06:33.920942 parsing files
DEBUG: 11:06:33.921284 found target Run
DEBUG: 11:06:33.921300 time parse Magefiles: 350.349µs
DEBUG: 11:06:33.921310 Creating mainfile at mage_output_file.go
DEBUG: 11:06:33.921500 writing new file at mage_output_file.go
DEBUG: 11:06:33.922011 compiling to /Users/dradtke/.magefile/b03ddfebe208872194e13c2a2576ad2e85f8c7b6
DEBUG: 11:06:33.922019 compiling using gocmd: go
DEBUG: 11:06:33.922022 running go version
DEBUG: 11:06:33.944415 go version go1.11 darwin/amd64

DEBUG: 11:06:33.944435 running go env
DEBUG: 11:06:34.088456 GOARCH="amd64"
GOBIN="/Users/dradtke/Workspace/go/bin"
GOCACHE="/Users/dradtke/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/dradtke/Workspace/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/w1/f3bh6jkx0vx95g4885d2yr5h3kfr1q/T/go-build377864416=/tmp/go-build -gno-record-gcc-switches -fno-common"

DEBUG: 11:06:34.088501 running go -tag=mage build -o /Users/dradtke/.magefile/b03ddfebe208872194e13c2a2576ad2e85f8c7b6 Mage.go mage_output_file.go
Mage.go:7:2: found packages main (Mage.go) and app (app.go) in /Users/dradtke/Workspace/go/src/github.com/magefile/test
DEBUG: 11:06:34.212394 time to compile Magefile: 123.799667ms
Error: error compiling magefiles

@natefinch
Copy link
Member

Oh, actually, I am pretty sure I know exactly what it is. Is your magefile importing a package that has some files marked as //+build mage ? I just added -tag=mage to the build script, which means it'll now find both the mage files and the non-mage files on imports, which is probably never the right thing to do.

(actually... it looks like your magefile is importing the current directory it's in, is that right?)

@dradtke
Copy link
Author

dradtke commented Oct 12, 2018

Yeah, that directory has application code sitting side-by-side with the Magefile, and the application code doesn't have the mage build tag. It looks like the error is coming straight from the Go tool, though. Is there a way to somehow specify a build constraint on a package import? The ideal fix would be for the Magefile's import to be treated as a !mage constraint.

@dradtke
Copy link
Author

dradtke commented Oct 12, 2018

Adding // +build !mage to the top of app.go results in a different error:

import cycle not allowed
package main
        imports github.com/magefile/test
        imports github.com/magefile/test
Error: error compiling magefiles

@dradtke
Copy link
Author

dradtke commented Oct 12, 2018

Yeah, it looks like removing the -tags=mage argument from the command in mage.Compile fixes the problem. As long as the mage build tag is respected when searching for Magefiles, it should be fine not to pass it on on compilation, right?

@natefinch
Copy link
Member

natefinch commented Oct 12, 2018

This is just my mistake for adding the mage build tag to what's being built. I'll fix it and make a v1.7.1 ASAP.

Yeah... I thought it would be harmless in case someone marked imported code with the mage build tag, but it didn't occur to me that this means you can't import code from a package that has both magefile main code and regular non-main code.

@dradtke
Copy link
Author

dradtke commented Oct 12, 2018

No worries at all, thanks for the quick response!

@natefinch
Copy link
Member

If you don't mind, can you try checking out the fix-build-tags branch, rebuild mage, and give it a try?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants