Building multiple binaries using different packages and build tags

I have an application that needs to use different packages depending on the target operating system and then generate an executable. The core package has an interface that needs to be populated depending on the package that is used.

I've recently found out the best way to achieve this is by using build tags. But what I'm struggling with is getting the interface populated by the loaded package with the correct build tag(s). Or perhaps there is a better alternative approach.

Here is a visual of how I imagined this to look like:

Whichever Build Constraints you chose, you can achieve this with interfaces and implementing the interface with New() constructors. And each of those special files will have the special packages you seek, on a per file basis. This approach also enforces good decoupling by forcing you to break off only the raw parts you need to implement specific to each architecture.

I am a personal fan of file suffixes, instead of build tags, as it makes it extremely easy to know which file binds to what architecture - just by looking at the filename. A big plus is you don't have to mess with any build tags and it will JustWork™. So my examples below will use file file suffixes. Specifically, the format is:

*_GOOS
*_GOARCH
*_GOOS_GOARCH

For example, renderer_windows_amd64.go, renderer_windows_amd64_test.go, renderer_linux.go, renderer_linux_test.go, etc. You can find all the GOOS and GOARCH that Go supports here.

EDIT: Validated code on kiddo's laptop (tweaking a build error). Note though, you can't call go run main.go as the architecture isn't known. You'll have to go build && ./mybinary to execute it locally to test.

main.go

package main

import (
	"fmt"
	"os"
)

func main() {
	r, err := NewRenderer()
	if err != nil {
		fmt.Println(err)
		os.Exit(1)
	}

	// call the Render() method for the specific goarch-goos.
	if err := r.Render(); err != nil {
		fmt.Println(err)
	}
}

renderer.go

This is a simple file that only defines the interface. And maybe some common enums.

package main

// Renderer renders performs the platform-specific rendering.
type Renderer interface {
    Render() error
}

// alternatively, you could define a global renderer struct
// here to use in each of hte files below if they are always
// the same.  often not though, as you want to keep states of
// of specific architectures within each struct.
// type renderer struct {
//     ...
// }
//
// func (r *renderer) Render() error {
// 	...
// }

renderer_windows.go

Includes 32 and 64 bit builds. If you want to target, say 64 bit only for specific 64bit compiled DLLs, then you can target more specifically with renderer_windows_amd64.go.

package main

import (
	"fmt"
	// "WindowsDLLPackage"  specific package to import for Windows
)

// renderer implements Renderer interface.
type renderer struct {
	// you can include some stateful info here for Windows versions,
	// to keep it out of the global heap.
    GOOS         string
    WindowsRules bool
}

// NewRenderer instantiates a Windows version.
func NewRenderer() (Renderer, error) {
    return &renderer{
    	GOOS:         "Windows",
	    WindowsRules: true,
    }, nil
}

// Render renders the Windows version.
func (r *renderer) Render() error {

	// use WindowsDLLPackage.NewSomething()

	fmt.Println(r.GOOS, r.WindowsRules)
	return nil
}

renderer_linux.go

Linux does not include Android (nor darwin, aka macOS) builds.

package main

import (
	"fmt"
	// "LinuxPackage"  specific package to import for Linux
)

// renderer implements Renderer interface.
type renderer struct {
	// you can include some stateful info here for Linux versions,
	// to keep it out of the global heap.
    GOOS       string
    LinuxRules bool
}

// NewRenderer instantiates a Linux version.
func NewRenderer() (Renderer, error) {
    return &renderer{
    	GOOS:       "Linux",
    	LinuxRules: true,
    }, nil
}

// Render renders the Linux version.
func (r *renderer) Render() error {

	// use LinuxPackage.NewSomething()

	fmt.Println(r.GOOS, r.LinuxRules)
	return nil
}

renderer_android.go

Android only specific version.

package main

import (
	"fmt"
	// "AndroidPackage"  specific package to import for Android
)

// renderer implements Renderer interface.
type renderer struct {
	// you can include some stateful info here for Android versions,
	// to keep it out of the global heap.
    GOOS         string
    AndroidRules bool
}

// NewRenderer instantiates a Android version.
func NewRenderer() (Renderer, error) {
    return &renderer{
    	GOOS:         "Linux",
    	AndroidRules: true,
    }, nil
}

// Render renders the Android version.
func (r *renderer) Render() error {

	// use AndroidPackage.NewSomething()

	fmt.Println(r.GOOS, r.AndroidRules)
	return nil
}

generate different binaries

All that's left is to cross-compile:

$ GOOS=windows GOARCH=amd64 go build -o mybinary.exe
$ GOOS=linux GOARCH=amd64 go build -o mybinary_linux
$ GOOS=darwin GOARCH=amd64 go build -o mybinary_macos
# and whatever u do to get ios/android builds...

Notice how all of the files above are part of the single package main and they exist all in the same directory? This works because the compiler only picks the one file suffix for the GOOS (windows, linux or android - you can do darwin, freebsd and a lot more). During compilation, the compiler only implements NewRenderer() once by using that one file. This is also how you can use specific packages per file.

Also notice how func NewRenderer() (Renderer, error) returns the Renderer interface, not the renderer struct type.

The type renderer struct is completely agnostic to the rest of the package, and can be used for any architecture's means by holding any state you need.

Also note that there aren't any global variables here. I've often use this pattern with goroutines and channels for highly concurrent applications - with no mutex locking bottlenecks. Keeping things off the heap is critical to avoid mutex locking. You could easily do go r.Render() and let it spawn a goroutine. Or, call it a few million times.

Finally, notice how all of the filenames above are easily distinguishable of what platform they target?

Don't fight the tooling with build tags, let the tools work for you.

Coding tips above:

• I exported the interface, Renderer, as all of this could be moved to a package outside of main quite easily. You don't want to export the struct versions. But, you may want to export the NewRenderer() init method.

• Renderer follows GoLang Effective Go guidelines in using simple interfaces with a single function: Render. And those functions become the name of the interface with the suffix of "er" - yes, even if the name ends in 'er', we add 'er' to the end and it becomes type Renderer interface. IOW: it shouldn't be called RenderEngine and instead it should be called Renderer with a single method you are manipulating: Render(). This clearly defines a single focus for the tooling and code. Aka, "the Go Way."

Create two files somewhat like these:

// +build myBuildFlag

package mypackage

import package1

var important = package1.Foo

Other one:

// +build !myBuildFlag

package mypackage

import package2

var important = package2.Foo

Now whenever you use important it something different depending on your build flag.

Take a look at Dave Chaney's post which explains how to deal with building for specific platforms/architectures quite clearly: https://dave.cheney.net/2013/10/12/how-to-use-conditional-compilation-with-the-go-build-tool