Convert Figma logo to code with AI

laher logogoxc

a build tool for Go, with a focus on cross-compiling, packaging and deployment

1,677
80
1,677
12

Top Related Projects

Deliver Go binaries as fast and easily as possible

4,595

A dead simple, no frills Go cross compile tool

4,104

a Make/rake-like dev tool using Go

Commandline app to create and edit releases on Github (and upload artifacts)

1,234

Upload multiple artifacts to GitHub Release in parallel

Quick Overview

Goxc (Go Cross Compiler) is a tool for cross-compiling and packaging Go applications. It simplifies the process of building Go projects for multiple platforms and architectures, and provides additional features like versioning and artifact management.

Pros

  • Simplifies cross-compilation for multiple platforms and architectures
  • Supports custom build tasks and hooks
  • Integrates with various packaging formats (e.g., deb, rpm, zip)
  • Provides versioning and artifact management features

Cons

  • No longer actively maintained (last commit in 2017)
  • May not support the latest Go versions and features
  • Limited documentation and community support
  • Some users report issues with certain platforms or configurations

Getting Started

To get started with Goxc, follow these steps:

  1. Install Goxc:

    go get github.com/laher/goxc
    
  2. Create a .goxc.json configuration file in your project root:

    {
      "ArtifactsDest": "build",
      "Tasks": [
        "xc",
        "archive-zip",
        "rmbin"
      ],
      "BuildConstraints": "linux,windows,darwin",
      "PackageVersion": "1.0.0",
      "TaskSettings": {
        "archive-zip": {
          "include-top-level-dir": "windows darwin"
        }
      }
    }
    
  3. Run Goxc in your project directory:

    goxc
    

This will cross-compile your Go application for the specified platforms and create zip archives in the build directory.

Competitor Comparisons

Deliver Go binaries as fast and easily as possible

Pros of goreleaser

  • More actively maintained with frequent updates and releases
  • Supports a wider range of build and release options, including Docker images
  • Integrates well with CI/CD pipelines and GitHub Actions

Cons of goreleaser

  • Steeper learning curve due to more complex configuration options
  • May be overkill for simpler projects that don't require advanced features

Code comparison

goreleaser configuration example:

builds:
  - env:
      - CGO_ENABLED=0
    goos:
      - linux
      - windows
      - darwin
archives:
  - replacements:
      darwin: Darwin
      linux: Linux
      windows: Windows
      386: i386
      amd64: x86_64

goxc configuration example:

{
  "ArtifactsDest": "build",
  "Tasks": [
    "xc",
    "archive-zip",
    "rmbin"
  ],
  "Arch": "386,amd64",
  "Os": "linux,darwin,windows"
}

Both tools aim to simplify the process of building and releasing Go applications for multiple platforms. goreleaser offers more advanced features and integrations, while goxc provides a simpler approach for basic cross-compilation needs. The choice between the two depends on the project's complexity and release requirements.

4,595

A dead simple, no frills Go cross compile tool

Pros of gox

  • Simpler and more straightforward to use
  • Faster build times due to parallel compilation
  • Actively maintained with more recent updates

Cons of gox

  • Less configurable than goxc
  • Lacks some advanced features like packaging and distribution
  • No built-in support for versioning or metadata

Code comparison

gox:

gox \
  -os="linux darwin windows" \
  -arch="386 amd64" \
  -output="dist/{{.Dir}}_{{.OS}}_{{.Arch}}" \
  ./...

goxc:

BuildSettings:
  LdFlags: "-X main.VERSION {{.Version}}"
  Resources:
    Include: "README*,LICENSE*,*.json"
Tasks:
  - xc
  - archive-zip
  - rmbin

Both tools serve the purpose of cross-compiling Go projects, but they differ in their approach and feature set. gox focuses on simplicity and speed, making it ideal for straightforward cross-compilation tasks. On the other hand, goxc offers more advanced features and configuration options, making it suitable for complex build and distribution workflows. The choice between the two depends on the specific needs of your project and the level of control you require over the build process.

4,104

a Make/rake-like dev tool using Go

Pros of mage

  • Written in Go, allowing for easier integration with Go projects
  • More flexible and extensible, supporting custom tasks and plugins
  • Actively maintained with regular updates and improvements

Cons of mage

  • Steeper learning curve for users new to Go-based build tools
  • Requires writing build scripts in Go, which may be less familiar to some developers

Code comparison

mage:

func Build() error {
    mg.Deps(InstallDeps)
    fmt.Println("Building...")
    cmd := exec.Command("go", "build", "-o", "myapp", ".")
    return cmd.Run()
}

goxc:

tasks:
  - go-vet
  - xc:
      arch: amd64
      os:
        - linux
        - darwin

Key differences

  • mage uses Go code for build scripts, while goxc uses YAML configuration
  • goxc is specifically designed for cross-compilation, while mage is a more general-purpose build tool
  • mage offers more flexibility in defining custom tasks and dependencies
  • goxc provides built-in support for common Go-related tasks, making it easier to get started for simple projects

Conclusion

mage is better suited for complex Go projects requiring custom build processes, while goxc excels in straightforward cross-compilation scenarios. The choice between the two depends on project requirements and team preferences.

Commandline app to create and edit releases on Github (and upload artifacts)

Pros of github-release

  • Focused specifically on GitHub releases, providing a streamlined experience
  • Supports uploading multiple assets to a release in a single command
  • Lightweight and easy to integrate into CI/CD pipelines

Cons of github-release

  • Limited to GitHub releases only, not as versatile for other build tasks
  • Lacks cross-compilation features for different platforms and architectures
  • Does not provide additional build automation or packaging capabilities

Code Comparison

goxc example:

TaskSettings:
  package:
    platforms:
      - linux/amd64
      - windows/386
  publish-github:
    owner: myuser
    repository: myrepo

github-release example:

github-release release \
    --user myuser \
    --repo myrepo \
    --tag v1.0.0 \
    --name "Release 1.0.0" \
    --description "Description of the release"

github-release upload \
    --user myuser \
    --repo myrepo \
    --tag v1.0.0 \
    --name "myapp-1.0.0-linux-amd64" \
    --file dist/myapp-1.0.0-linux-amd64

Summary

goxc is a more comprehensive tool for Go projects, offering cross-compilation, packaging, and various build tasks, including GitHub releases. github-release, on the other hand, is a specialized tool focused solely on managing GitHub releases and uploading assets. While github-release excels in its specific domain, goxc provides a broader range of features for Go project management and deployment.

1,234

Upload multiple artifacts to GitHub Release in parallel

Pros of ghr

  • Simpler and more focused on GitHub releases
  • Faster execution due to its streamlined functionality
  • Better support for cross-platform builds and multiple architectures

Cons of ghr

  • Less flexible compared to goxc's broader feature set
  • Limited to GitHub releases, while goxc supports multiple platforms
  • Fewer configuration options for customizing the build process

Code Comparison

ghr:

assets, err := ghr.GetLocalAssets(path)
if err != nil {
    return fmt.Errorf("failed to get local assets: %s", err)
}

goxc:

err := bc.GeneratePlatformSpecificBuildSettings(platforms)
if err != nil {
    return err
}
bc.Resources = append(bc.Resources, res...)

Both projects aim to simplify the process of creating and managing releases for Go projects, but they take different approaches. ghr focuses specifically on GitHub releases, offering a streamlined experience for developers who primarily use GitHub. It excels in speed and simplicity, making it ideal for projects with straightforward release requirements.

On the other hand, goxc provides a more comprehensive toolset for cross-compilation and release management across multiple platforms. It offers greater flexibility and customization options, making it suitable for complex projects with diverse build and release needs.

The code comparison highlights the different focus areas of each project. ghr's code snippet demonstrates its emphasis on managing GitHub release assets, while goxc's code shows its broader approach to handling cross-platform build settings and resources.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

goxc build status

NOTE: goxc has long been in maintenance mode. Ever since Go1.5 supported simple cross-compilation, this tool lost much of its value. There are still many aspects of goxc which I'm very proud of, and some packaging features in particular, which are still useful. I'm very much a go user, but I myself haven't had any need for goxc for a long while.

If you see something you'd like to add to goxc, please go ahead, fork and PR. Good PRs will earn you commit access to the repo. Thanks for everyone's help over the years.

goxc is a build tool for Go, with a focus on cross-compiling and packaging.

By default, goxc [g]zips (& .debs for Linux) the programs, and generates a 'downloads page' in markdown (with a Jekyll header).

goxc is written in Go but uses os.exec to call 'go build' with the appropriate flags & env variables for each supported platform.

goxc was inspired by Dave Cheney's Bash script golang-crosscompile.

  • goxc crosscompiles to all platforms at once.
  • The artifacts are saved into a directory structure along with a markdown file of relative links.
  • Artifacts are packaged as zips, tgzs, or debs. Defaults for each OS/architecture.
  • AND, goxc can now upload your files to github releases OR bintray.com.
  • See ‘Github Releases’ section below.

Notable Features

  • Cross-compilation, to all supported platforms, or a specified subset.
    • Validation of toolchain & verification of cross-compiled artifacts
    • Specify target platform, via 'Build Constraint'-like syntax (via commandline flag e.g. -bc="windows linux,!arm", or via config)
  • Automatic (re-)building toolchain to all or specified platforms.
  • 'task' based invocation, similar to 'make' or 'ant'. e.g. goxc xc or goxc clean go-test
    • The 'default' task alias will, test, cross-compile, verify, package up your artifacts for each platform, and generate a 'downloads page' with links to each platform.
    • Various go tools available via tasks: go-test, go-vet, go-fmt, go-install, go-clean.
    • You can modify task behaviour via configuration or commandline flags.
  • JSON-based configuration files for repeatable builds.
    • Most config data can be written via flags (using -wc option) - less JSON fiddliness.
    • Includes support for multiple configurations per-project.
    • Per-task configuration options.
    • 'Override' config files for 'local environment' - working-copy-specific, or branch-specific, configurations.
  • Packaging & distribution
    • Zip (or tar.gz) archiving of cross-compiled artifacts & accompanying resources (READMEs etc)
    • Packaging into .debs (for Debian/Ubuntu Linux)
    • Upload to github.com releases.
    • bintray.com integration (deploys binaries to bintray.com). bintray.com registration required
    • 'downloads page' generation (markdown/html format; templatable).
  • Versioning:
    • track your version number via configuration data.
    • version number interpolation at compile-time (uses go's -ldflags compiler option to populate given constants or global variables with build version or build date)
    • version number interpolation of source code. goxc interpolate-source (new task available in 0.10.x).
    • the bump task facilitates increasing the app version number.
    • the tag task creates a tag in your vcs (currently only 'git' supported).
  • support for multiple binaries per project (goxc now searches subdirectories for 'main' packages)
  • support for multiple Go installations - choose at runtime with -goroot= flag.

Installation

goxc requires the go source and the go toolchain.

  1. Install go from source. (Requires gcc (or MinGW) and 'hg')

    • OSX Users Note: If you are using XCode 5 (OSX 10.9), it is best to go straight to Go 1.2rc5 (or greater). This is necessary because Apple have replaced the standard gcc with llvm-gcc, and Go 1.1 compilation tools depend on the usual gcc.

      • There is another workaround incase Go 1.2rc5 is not an option:

          brew tap homebrew/versions
          brew install apple-gcc42
          go get github.com/laher/goxc
          CC=`brew list apple-gcc42 | grep bin/gcc-4.2` goxc -t
        
  2. Install goxc:

    go get github.com/laher/goxc
    	
    
  3. a. (just once per Go version): to pre-build the toolchains for all platforms:

    goxc -t
    
    • Note that rebuilding the toolchain is only required for Go up until v1.4. This step will become unnecessary in Go 1.5.
    • Note that, until goxc v0.16.0, rebuilding the toolchain was triggered automatically. This has now been switched off (by default). Automatic rebuilding was causing a number of subtle bugs for different users, and has been switched off since v0.16.0.
    • Also note that building the toolchain takes a while. Cross-compilation itself is quite fast.

Basic Usage

cd path/to/app/dir
goxc

More options

Use goxc -h to list all options.

  • e.g. To restrict by OS and Architecture (using the same syntax as Go Build Constraints):

     goxc -bc="linux,!arm windows,386 darwin"
    
  • e.g. To set a destination root directory and artifact version number:

     goxc -d=my/jekyll/site/downloads -pv=0.1.1
    
  • 'Package version' can be compiled into your app if you define a VERSION variable in your main package.

"Tasks"

goxc performs a number of operations, defined as 'tasks'. You can specify tasks as commandline arguments

  • goxc -t performs one task called 'toolchain'. It's the equivalent of goxc -d=~ toolchain
  • The default task is actually several tasks, which can be summarised as follows:
    • validate (tests the code) -> compile (cross-compiles code) -> package ([g]zips up the executables and builds a 'downloads' page)
  • You can specify one or more tasks, such as goxc go-fmt xc
  • You can skip tasks with '-tasks-='. Skip the 'package' stage with goxc -tasks-=package
  • For a list of tasks and 'aliases', run goxc -h tasks
  • Several tasks have options available for overriding. You can specify them in config or via flags. Just use goxc <taskname> -task-setting=value <othertask>
  • For more info on a particular task, run goxc -h <taskname>. This will also show you the options available for that task.
  • The easiest way to see how to configure tasks in config is to write some task config via -wc, e.g. goxc -wc xc -GOARM=5

Outcome

By default, artifacts are generated and then immediately archived into (outputdir).

Examples:

  • /my/outputdir/0.1.1/myapp_0.1.1_linux_arm.tar.gz
  • /my/outputdir/0.1.1/myapp_0.1.1_windows_386.zip
  • /my/outputdir/0.1.1/myapp_0.1.1_linux_386.deb

The version number is specified with -pv=0.1.1 .

By default, the output directory is ($GOBIN)/(appname)-xc, and the version is 'unknown', but you can specify these.

e.g.

  goxc -pv=0.1.1 -d=/home/me/myuser-github-pages/myapp/downloads/

NOTE: it's bad idea to use project-level github-pages - your repo will become huge. User-level gh-pages are an option, but it's better to use the 'bintray' tasks.:

If non-archived, artifacts generated into a directory structure as follows:

(outputdir)/(version)/(OS)_(ARCH)/(appname)(.exe?)

Be careful if you want to build a project with multiple executables. You need to add {{.ExeName}} to your OutPath-setting in your '.goxc.json'. So it may look like the following code snippet.

"OutPath": "{{.Dest}}{{.PS}}{{.AppName}}{{.PS}}{{.Version}}{{.PS}}{{.ExeName}}_{{.Version}}_{{.Os}}_{{.Arch}}{{.Ext}}"

Configuration file

For repeatable builds (and some extra options), it is recomended to use goxc with one or more configuration file(s) to save and re-run compilations.

To create a config file (.goxc.json), just use the -wc (write config) option.

goxc -wc -d=../site/downloads -bc="linux windows" xc -GOARM=7

You can also use multiple config files to support different paremeters for each platform.

The following would add a 'local' config file, .goxc.local.json. This file's contents will override .goxc.json. The idea of the .local.json files is to git-ignore them - for any local parameters which you only want on this particular computer, but not for other users or even for yourself on other computers/OS's.

goxc -wlc -d=../site/downloads

The configuration file(s) feature is documented in much more detail in the wiki

Github Releases

This is the good stuff, so let’s go from the top.

  • First, install Go from source, and goxc. See ‘Installation’, above

  • If you haven’t already, build toolchain (all platforms!). This takes a while.

	goxc -t
  • Write a config file .goxc.json with info about your repo
	goxc -wc default publish-github -owner=<username> 
	goxc -wc default publish-github -repository=<reponame>
	cat .goxc.json
  • Bump a version, to get a meaningful version number.
	goxc bump
  • Go to your github account and create a personal access token

https://github.com/settings/tokens

  • Write a local config file .goxc.local.json with your key info, ensuring that the key doesn’t end up in your git repo. See more about config files in the wiki
	goxc -wlc default publish-github -apikey=123456789012
	echo ".goxc.local.json" >> .gitignore

Note that you can put a dummy key into the commandline and edit the file later with the real key.

  • Now, cross-compile, package and upload. All in one go.
	goxc

There’s heaps of ways to reconfigure each task to get the outcome you really want, but this produces some pretty sensible defaults. Have fun.

Limitations

  • Tested on Linux and Mac recently. Windows - some time ago now.
  • Currently goxc is only designed to build standalone Go apps without linked libraries. You can try but YMMV
  • The API is not considered stable yet, so please don't start embedding goxc method calls in your code yet - unless you 'Contact us' first! Then I can freeze some API details as required.
  • Bug: issue with config overriding. Empty strings do not currently override non-empty strings. e.g. -pi="" doesnt override the associated config setting PackageInfo

License

Copyright 2013 Am Laher

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

See also