xgo does only work with the go import path

[zimmski]

I do not see a way to give xgo just a file to compile. e.g.

xgo path/to/a/main.go

[karalabe]

Yes, you're right. I haven't had personally the need for this, hence why I didn't add it. Although it shouldn't be too hard, it's not trivial either as you'll need a mechanism to upload code into the container.

Simply specifying a path and expecting xgo to figure out if it's a local private path or a remote public on isn't really doable, but I guess I could introduce an extra flag to signal a path to import into the container before compilation. So in the end, compiling your code could look something like:

xgo -lib path/to/private/package path/to/package/to/compile

where the two could obviously be the same.

[Ok, I could implement a mechanism to pick the local version of some package and only go remote if not available locally, but that's a tad overkill and will quickly introduce quirks, bugs and whatnot that the current always-remote-clone cannot have since it always uses virgin states).

Anyway, I'll think about this a bit and get back to the issue. In the mean time, if you have a particular idea on how you think this would be useful, or how you imagine it doable, do share :)

[zimmski]

Unfortunately I do not know how Docker works so I have (currently) no idea on how to implement this. But I do understand that the docker approach is more superior in terms of user-friendliness. Since the only steps for a complete cross-compile setup are just installing Docker, your Docker images and xgo. Giving my experience on doing cross-compile setups manually I find xgo's simplicity amazing!
So my current idea wish would be that xgo supports the following features:

• choice of architectures
• distinction between setting up xgo and building e.g. "xgo setup" and "xgo build"
• choice for compiling remote/local package/file
• support for some of "go"'s building parameters like "-v" "-race" "-ccflags" ...
• prefix argument for the name of the resulting binaries
• support for different Go versions (e.g. what happens when there is a new Go version?)

I am eager to help implementing (in two weeks i will have more time since i am relocating 👍 ) but as mentioned I currently do not possess the necessary Docker knowledge.

[karalabe]

Most of these seem reasonable requests so I'll just turn your wish list into a checklist to be able and check them off one by one eventually :) I myself will also be unavailable until the end of next week, so I guess most of these will have to wait till then, but I'll see if I have enough time to address one or two.

Docker is really cool but it has quite some quirks, so you do have to jump through some hoops to get everything going (e.g. you can't stream the stdout of docker through your own program (hence why I needed the extra docker pull step for my container).

[karalabe]

Blah... ok, I have the whole thing working for different Go releases, just can't convince docker to automatically build them with the correct dependencies. Their build service is very very limited. I'll try and look around to see if I can do it properly without needing to go down their suggested path (separate repo for every single dockerfile).

[karalabe]

Ok, after a long battle with docker, versioned containers work :) Although for now only Go 1.3.0 is supported, adding additional ones are trivial and I also introduced two wildcard versions: "1.3.x" matching the latest point release and "latest" matching the latest major release of Go.

These can be configured via the -go flag.

xgo -go 1.3.x github.com/project-iris/iris

[zimmski]

Just in time for 1.3.1 :-)

[karalabe]

Added support for output prefixing through -out, and also supporting -v and -race now :) See README for more.

[karalabe]

Btw, I've talked to Dave Cheney about his arm packages for 1.3.1, and he said that maybe during the weekend he'll do it, so I'll be able to support the next Go release too afterwards.

[kdar]

@zimmski I made a fork and implemented what you were requesting. It doesn't build single files, but it builds local packages (a local package can just contain main.go, in your case).

Get it here: https://github.com/kdar/xgo/tree/localpkg

If looks for a "." or "/" at the beginning of the path to determine if it's a local package. So you can do xgo ./ or something similar.

Example:

cd $GOPATH/src
mkdir test
echo -e 'package main\n import "fmt"\n func main(){\nfmt.Println("Hello")\n}' > main.go
xgo -out "build/test" ./

This works with karalabe's dockerfiles. The only downside is it will error when copying files because the directories overlap (but it works fine regardless of the error displayed). This can be remedied if we modify the Dockerfiles as well to support this.

[zimmski]

I am sorry to tell you guys that I switched to https://github.com/mitchellh/gox for new projects some time ago. But @kdar I will definitely will try your changes with the next cgo-dependent project!

[bdesham]

@kdar This is excellent, thank you!

Your example instructions are missing a cd command… in case it will save someone else a couple of seconds, the instructions should be

cd $GOPATH/src
mkdir test
cd test
echo -e 'package main\n import "fmt"\n func main(){\nfmt.Println("Hello")\n}' > main.go
xgo -out "build/test" ./

[karalabe]

Had been doing some work lately requiring xgo, so I've added a lot of new features, including building local code. If instead of the import path you specify a local path (begins in either . or /), it will resolve the import path, mount in all source code found in the various GOPATH components and cross compile using all code found on the host machine. Also, it will mount every local folder as read only to ensure that no modifications are made to your local files.

The idea is based on @kdar's code, so I thank him for that, though it needed a bit of rework to enable read only filesystems and multiple GOPATH components. Hope it's useful :)