bgo

Bgo manages exe, not lib

preface

Before the preface:

The preface is long and can be skipped.

Bgo is a build aid that is not so different from the tools known to build go applications in that it can cross-compile and build go application executables in your work environment.

Although this capability comes naturally with Go Build, the ability to wrap the auxiliary build tools around once can save you a lot of effort, whether it’s the hard-to-remember Go Build command-line arguments, or the pre-preparation and post-processing steps you have to use, such as Go Generate, Copy to a public location, etc.

So that’s what tools like BGO are for, to save effort.

origin

Of course, why would I want to develop another helper?

The reasons are not complicated, as follows:

Now I often have a lot of small projects in a big directory. Maybe IT’s just to test out a feature or do something, or maybe IT’s because I need to list a lot of examples for users to see. But in a small cycle, I usually focus on one or two or three of them, and for that reason, switching directories and building is tiring. Goland was nice enough to spare me those command-line environments, but its results window didn’t support full keyboard interaction, so I had to open a terminal for some actions. There are a lot of other things Goland can’t do, but it’s a specific problem. For that, why not vscode? Have you used it? You need to know that vscode can only debug a single main application in goapp. If you want to debug or multiple apps, you need to go to its embedded terminal and type the command line. Also, vscode has a lot of problems if you don’t open your workspace with go.mod — in other words, vscode supports only a single module represented by go.mod.

Another reason is that, as a more formal release, I might need to use -x or go generate frequently. For this, I originally had a complex Makefile that would solve these problems automatically. However, they are not very useful for me on large-scale projects, because I may have many different directories for different submodules.

Another reason is the order of the build. Sometimes I need to do a series of builds in an orderly fashion, and sometimes I need to quickly build a single target to run in ExeuTable mode and view the results.

There are other reasons, too, but not the lesbians.

The main reason you’ll notice is that I’m maintaining a large project structure. Why not cut it up into lots and lots of repos? This brings up another issue: Go modules don’t support multiple nested go.mod. That is, if your parent directory has go.mod, then the parent directory can’t have any more. This is a complicated situation, but ultimately the constraint is too hard for you, so this structure won’t work:

/complex-system
  go.mod
  /api
    /v1
      go.mod
  /common
    go.mod
  /account
    go.mod
  /backends
    /order
      go.mod
    /ticket
      go.mod
Copy the code

Only part of the directory structure is listed here, and it’s just a hint.

Also, there will be those who say that a repo for every go.mod would be fine. Well, yes, it is possible, it is the only way.

After that, you need to figure out how to resolve the dependency.

Go 1.18’s Go.work doesn’t help or is even difficult to use.

Git submodules? It’s cumbersome, it’s hard to use, you lose track of your status, and then you’re screwed.

The next thing you know, people are going to say, well, go. Mod, don’t use anything else, just separate out the directory structure. Yeah, that’s what I did when I did a similar large-scale project a few years ago, but the API’s Protobuf reference, common’s ETCD reference, etc., were all jumbled up, and they were all cumbersome to solve, and ended up making the whole mega-project bloated and unnecessarily confusing.

In fact, there was a time when multiple nested go.mods worked just fine, but that period was so short that I forget if it was 1.13 or what, but it’s a distant memory. I was happy with the configuration of the project for a while, but it was more painful to go back to the single go.mod.

so

There are a lot of reasons, but BGO only solves part of the problem, which is the problem of building a lot of small apps in a bunch of complex subdirectories.

With bgo, we can use a large top-level directory to manage several subprojects. Of course, because of go modules’ limitations, we can’t build go.mod in the top-level directory (in case of go.mod in the subdirectory), it just acts as an aggregation. We can open this structure with Goland or vscode just fine.

The current configuration:

/atonal
  .bgo.yml
  /api
    /v1
      go.mod
  /common
    go.mod
  ...
Copy the code

You will notice that the top level directory contains a.bgo.yml file, which is the bGO configuration file, which is automatically generated by bgo init after scanning subdirectories, and from there you can make further adjustments.

The only problem is that it only collects directories where the main package is located, which is where the executable can be made, and your directories with go.mod are not really managed.

This is a limitation of BGO, but this is the design goal of BGO: we scan and manage a series of CLI apps and build them in a lightweight way. We don’t offer multiple modules under the go.mod logo, either we’ll design a separate tool for that or we won’t do it in case Google gets crazy and comes up with a go.zone.

Of course, you can give each go.mod a main.go to let BGO manage it as well. But in general, BGO handles exe, not lib

Disappointing go evolution

In other words, go.mod go.work is available, but all of them are not effective solutions for large projects, but only limited to a module of mine.

In the engineering management of Go, there are always many problems:

  • Resolution of private Repos
  • Resolution of a problem REPO or missing REPO
  • Complex multi-module construction and organization
  • Poor generics, might as well have none
  • , etc.

To be honest, I had high hopes. But I’m probably in a similar mood to the people at YAML, like, wow, generics are here, oh, generics go. In this area (automatic type resolution, unknown type resolution), Golang’s generics are practically useless. At the current pace of evolution, it is also unlikely to be expected to solve free predictive unknown types.

How to start?

The installation

The first step, of course, is to install bGO.

Releases

Bgo is designed to work with a single executable, so download the pre-compiled version in Releases and put it in your search path.

go get

Alternatively, you can go through the Go Get system:

go get -u -v github.com/hedzr/bgo
Copy the code
From source code

Homebrew

Homebrew is available:

brew install hedzr/brew/bgo
Copy the code

Package management is not supported on other platforms because it is just a gadget.

Docker

It can also be run in Docker mode, but it is a bit more complicated because it needs to be loaded with native volume:

docker run -it --rm -v $PWD:/app -v /tmp:/tmp -v /tmp/go-pkg:/go/pkg hedzr/bgo
Copy the code

This is consistent with implementing native BGO.

Docker containers can be obtained from these places:

docker pull hedzr/bgo:latest
docker push ghcr.io/hedzr/bgo:latest
Copy the code

run

In the directory you want to build, run bgo.

For example, we run ini-op from source code:

That’s the easiest way to start.

The characteristics of

But if that’s the case, what’s the value? Command line shortener?

Bgo can do two things in particular:

  • Tags etc. The go Build command line is too long and difficult to edit
  • You want to orchestrate build instructions and their pre – and post-processing behavior. Post-processor, etc.
  • There are a whole bunch of subdirectories that have CLIs, but you don’t want to build them individually, or you don’t want to build them all at once with different build parameters.
  • Have a series of go modules, but want to be unified.

These goals can be addressed through configuration files.

Create a build profile

Based on the current directory, bgo looks for the.bgo.yml file in the current directory, loads the projects configuration information in it, and builds in a specific order.

Because of our emphasis on orderliness, BGO does not support parallel compilation of multiple projects.

In fact, this feature is worthless because it only slows down the overall compilation speed.

So the first question is, how is.bgo.yml prepared?

To do this, choose your root directory to run BGO for the first time.

bgo -f --save          # Or: bgo init
mv bgo.yml .bgo.yml
Copy the code

This command scans all subdirectories and compiles a build configuration table and saves it as a bgo.yml file.

You can then choose to rename the configuration file (this is recommended to prevent the possible side effects of running the save incorrectly). But you can leave the file name the same if you want.

A synonym for

bgo init
bgo init --output=.bgo.yml
Copy the code

If you need an annotated example, check it out:

Github.com/hedzr/bgo/b…

Begin to build

Once the configuration file is ready, you can run:

bgo
Copy the code

This will build all projects in the configuration file.

In fact, if there is no configuration file, BGO will automatically scan for the first main CLI and build it.

Use different build scopes

Bgo supports three scopes, which differ in how projects in the configuration file are handled and whether projects in the current folder are scanned:

  [Scope?]
  -a, --auto      ⬢ Build all modules defined in .bgo.yaml recursively (auto mode) [env: AUTO] (default=true)
  -f, --full      ⬡ Build all CLIs under work directory recursively [env: FULL](default=false-s, --short ⬡ Buildfor current CPU and OS Arch ONLY [env: SHORT] (default=false)
Copy the code

Normally bGO is in automatic mode (–auto), when only projects in the configuration file are considered into the build sequence. If no configuration file is found, bGO attempts to scan the current folder for the first Main app.

Full scan mode (–full) scans all possible projects in the current folder.

Short mode (–short) will only extract the first project from the configuration file, but if you don’t have a configuration file in your root directory, it will scan the first project to build. It is special in that only the current GOOS+GOARCH of the worker will be built.

In addition, you can explicitly specify a name to run bGO. Bgo retrieves the project of the same name in the configuration table and runs the build sequence against it separately.

bgo -pn whoami   # Or `--project-name`
Copy the code

In the configuration file, you can set disabled: true to disable a project, or to disable a project team.

Grouping of projects

Multiple projects can be grouped into one group, with the benefit that build parameters can be specified uniformly. Such as:

---
app:
  bgo:
    build:
      cgo: false

      projects:
        000-default-group:
          # leading-text:
          cgo: false
          items:
            001-bgo:   # <- project name
              name:    # <- app name
              dir: .
              gen: false
              install: true
              cgo: false
            010-jsonx: # <- project name
              name:    # <- app name
              dir: . /.. /tools/jsonx
Copy the code

In this example, we define a default-group and then bGO and Jsonx projects.

Their name prefixes (such as 001-fragment) are used for sorting purposes and are ignored in the build behavior and not treated as part of the name.

The project team’s build configuration Settings (such as the CGO parameter) are pulled down and applied to each project unless you specify it explicitly; Similarly, cGO, for, OS, ARCH and so on can be defined at the app.bgo.build level, which have higher precedence.

In the sample snippet, the cGO parameter is defined at all levels, with the project-level CGO having the highest priority.

Configuration parameters of Project

All parameters are public except the name, dir, and package fields. That is, all other parameters can be used at the top or project level.

name, dir, package

Every project requires dir as a basic definition, which is mandatory:

---
app:
  bgo:
    build:

      projects:
        000-default-group:
          # leading-text:
          items:
            001-bgo:   # <- project name
              name:    # <- app name
              dir: .
              package: # optional

Copy the code

Can adopt.. /, out of the current directory limit. In theory, you can include everything.

Bgo checks go.mod in that directory to determine if go Modules compilation should be started.

Whenever specific go build is executed, it will always switch to the location pointed to by dir as a baseline, unless you specify keep-workdir, which tells BGO to keep the current working directory. You can also use use-workdir to specify a go-build base working directory for a project.

Name can be used to explicitly specify the project’s app name, otherwise the value will be taken from the project name. The project name is the developer’s project management name, and the App name is the base name of the Executable that will be included as the output for the end user.

Package is optional, and you usually don’t have to specify it manually. This field is filled in automatically in the result of the bGO init scan, but it is always reextracted during the actual build.

disabled

This field causes the corresponding item to be skipped

disable-result

Bgo automatically ll the result executable after completing the build. This field can disallow this behavior of BGO.

keep-workdir, use-workdir

In general, bgo jumps to the project directory and starts to go Build. Then it returns to the current directory.

But keep-workdir allows you to stay in the current directory (that’s where you started bgo) and build with a syntax like go build./tools/bgo. You can set keep-workdir to true.

If you want a particular base directory for a project (most likely because that base directory has go.mod), you can specify one using the use-workdir field.

    use-workdir: ./api/v1
    keep-workdir: false
Copy the code

gen, install, debug, gocmd, cgo, race, msan,

Gen decides whether to run Go generate before Go Build./…

Install determines whether to copy the execution file to $GOPATH/bin, as Go Install does.

Debug produces larger executables, and typically uses -trimpath -s -w to reduce the size of the executable by default.

Gocmd is useful when you want to build with different versions of Go, just set it to point to your particular version of go executable. You’ll probably keep it empty for the most part. But goCmd can be useful if you have an experimental piece of code in a folder that requires generics.

Cgo determines the value of the environment variable CGO_ENABLED and whether the GCC segment is enabled at build time. Note that the CGO feature is only available for current GOOS/GOARCH, it is not well supported for cross-compilation.

Race indicates whether race condition detection is enabled.

The MSAN is passed as-is to the Go Build to produce in-memory diagnostics and audit code.

Target platform:for.os.arch

In the configuration file, you can specify which target platforms to build on.

---
app:
  bgo:
    build:
      # the predefined limitations
      # for guiding which os and arch will be building in auto scope.
      #
      # If 'bgo.build.for' is empty slice, the whole available 'go tool dist list'
      # will be used.
      #
      #for:
      # - "linux/amd64"
      # - "windows/amd64"
      # - "darwin/amd64"
      # - "darwin/arm64"

      # the predefined limitations
      os: [ linux ]

      # the predefined limitations
      #
      arch: [ amd64."386".arm64 ]

Copy the code

Note that these keys can also be used with project-groups or projects, for example:

      projects:
        000-default-group:
          # leading-text:
          items:
            001-bgo:   # <- project name
              name:    # <- app name
              dir: .
              gen: true
              install: true
              # os: [ "linux","darwin","windows" ]
              # arch: [ "amd64" ]
              # for: [ "linux/riscv64" ]
Copy the code

For specifies an array of target platforms, each of which is an OS/ARCH pair.

But if you specify OS and ARCH arrays, they will do cartesian product to produce the final target platform, Martrix.

Post – the action, the pre – action

You can specify that shell scripts are executed before or after go build.

A post-action might look like this:

post-action: | if [[ "$OSTYPE" == *{ {.OS}}* && "{ {.Info.GOARCH}}" == { {.ARCH}} ]]; then cp { {.Output.Path}} $HOME/go/bin/ fi echo "OS: $OSTYPE, Arch: { {.Info.GOARCH}}"
Copy the code

It uses template expansion. The corresponding data source comes from our build.Context variable, whose definition is described at the end of this article.

Specifically, {{.info.goarch}} represents the running go Runtime value, runtime.goarch, while {{.os}} and {{.arch}} are the corresponding values for the target being built.

Due to the jekyll template expansion, all {{are inserted with Spaces in case the article fails to publish.

Post – action – the file, the pre – action – the file

You can use script files if you want.

Pay attention to

These Settings are only applicable to each project and are not supported to be applied to the project-group level. The reason is that the group level was removed at the end of our code implementation.

ldflags, asmflags, gcflags, tags

These optional arguments are passed to the corresponding command line arguments for Go Build.

But in our case, you should specify them as arrays, for example:

---
app:
  bgo:
    build:
      ldflags: [ "-s"."-w" ]
Copy the code

Specifies the global LDFlags parameter, which will be used in all projects builds unless you explicitly specify a specific LDFlags version in a project.

extends

Write variable values to specific packages of the code you are building by going build-LDFlags -x… To achieve. There are also config file entries to simplify the problem:

            001-bgo: # <- project name
              name:    # <- app name
              dir: tools/bgo
              gen: false
              install: true
              cgo: true
              extends:
                - pkg: "github.com/hedzr/cmdr/conf"
                  values:
                    AppName: "{ {.AppName}}"
                    Version: "{ {.Version}}"
                    Buildstamp: "{ {.BuildTime}}" # or shell it
                    Githash: "`git describe --tags --abbrev=16`"
                    # Githash: "{{.GitRevision}}" # or shell it: "`git describe --tags --abbrev=9`"
                    GoVersion: "{ {.GoVersion}}"  # or shell it
                    ServerID: "{ {.randomString}}"

Copy the code

You can use template expansion or embed small shell scripts.

But writing a lot of scripts is not encouraged here.

The build parameters for hedZR/CMDR CLI app are given in the example, but they are actually redundant: as a family, we automatically try to identify if your go.mod contains a reference to CMDR, which determines whether or not we automatically fill in this set of parameters.

Obviously, writing package variables at build time is not exclusive to CMDR, so you can use it for your own configuration.

Top-level unique configuration parameters

In the configuration file, app.bgo.build is the top layer of configuration items, where you can specify the exclusion directory and output file name template:

---
app:
  bgo:
    build:
      output:
        dir: ./bin
        # split-to sample: "{ {.GroupKey}}/{ {.ProjectName}}"
        #
        # named-as sample: "{ {.AppName}}-{ {.Version}}-{ {.OS}}-{ {.ARCH}}"

      # wild matches with '*' and '? '
      # excludes patterns will be performed to project directories.
      # but projects specified in .bgo.yml are always enabled.
      excludes:
        - "study*"
        - "test*"

Copy the code

{{.appName}}-{{.os}}-{{.arch}} by default bGO uses {{.arch}}.

Dir specifies the output folder to which the executable is pointed.

You can also specify split-to-set additional subfile levels for each project, such as {{.projecname}}, and so on.

Excludes is an array of strings that provides a set of filename wildcard templates, and folders that match those templates will not be scanned.

Build Context

In some fields we allow you to embed dynamic variable values that change with each project build. For example {{.appName}} can be expanded to the app name of the project currently being built.

These values are included in the build.context declaration.

The corresponding snippet of the BGO source code is shown below, so I don’t have to explain it.

This is not the latest version, it is still being iterated

type (
	Context struct {
		WorkDir    string
		TempDir    string
		PackageDir string

		// Output collects the target binary executable path pieces in building
		Output PathPieces

		*Common
		*Info
		*DynBuildInfo
	}
)

type PathPieces struct {
	Path    string
	Dir     string
	Base    string
	Ext     string
	AbsPath string
}

type (
	Info struct {
		GoVersion   string // the result from 'go version'
		GitVersion  string // the result from 'git describe --tags --abbrev=0'
		GitRevision string // revision, git hash code, from 'git rev-parse --short HEAD'
		BuildTime   string //
		GOOS        string // a copy from runtime.GOOS
		GOARCH      string // a copy from runtime.GOARCH
		GOVERSION   string // a copy from runtime.Version()

		RandomString string
		RandomInt    int
		Serial       int
	}
  
	DynBuildInfo struct {
		ProjectName         string
		AppName             string
		Version             string
		BgoGroupKey         string // project-group key in .bgo.yml
		BgoGroupLeadingText string // same above,
		HasGoMod            bool   //
		GoModFile           string //
		GOROOT              string // force using a special GOROOT
		Dir                 string})type (
	CommonBase struct {
		OS   string `yaml:"-"` // just for string template expansion
		ARCH string `yaml:"-"` // just for string template expansion

		Ldflags    []string `yaml:"ldflags,omitempty,flow"`    // default ldflags is to get the smaller build for releasing
		Asmflags   []string `yaml:"asmflags,omitempty,flow"`   //
		Gcflags    []string `yaml:"gcflags,omitempty,flow"`    //
		Gccgoflags []string `yaml:"gccgoflags,omitempty,flow"` //
		Tags       []string `yaml:"tags,omitempty,flow"`       //
		// Cgo option
		Cgo bool `yaml:",omitempty"` //
		// Race option enables data race detection.
		// Supported only on linux/amd64, freebsd/amd64, darwin/amd64, windows/amd64,
		// linux/ppc64le and linux/arm64 (only for 48-bit VMA).
		Race bool `yaml:",omitempty"` //
		// Msan option enables interoperation with memory sanitizer.
		// Supported only on linux/amd64, linux/arm64
		// and only with Clang/LLVM as the host C compiler.
		// On linux/arm64, pie build mode will be used.
		Msan          bool   `yaml:",omitempty"`               //
		Gocmd         string `yaml:",omitempty"`               // -gocmd go
		Gen           bool   `yaml:",omitempty"`               // go generate at first?
		Install       bool   `yaml:",omitempty"`               // install binary to $GOPATH/bin like 'go install' ?
		Debug         bool   `yaml:",omitempty"`               // true to produce a larger build with debug info
		DisableResult bool   `yaml:"disable-result,omitempty"` // no ll (Shell list) building result

		// -X for -ldflags,
		// -X importpath.name=value
		// Set the value of the string variable in importpath named name to value.
		// Note that before Go 1.5 this option took two separate arguments.
		// Now it takes one argument split on the first = sign.
		Extends      []PackageNameValues `yaml:"extends,omitempty"` //
		CmdrSpecials bool                `yaml:"cmdr,omitempty"`
	}

	PackageNameValues struct {
		Package string            `yaml:"pkg,omitempty"`
		Values  map[string]string `yaml:"values,omitempty"`
	}

	Common struct {
		CommonBase     `yaml:"base,omitempty,inline,flow"`
		Disabled       bool     `yaml:"disabled,omitempty"`
		KeepWorkdir    bool     `yaml:"keep-workdir,omitempty"`
		For            []string `yaml:"for,omitempty,flow"`
		Os             []string `yaml:"os,omitempty,flow"`
		Arch           []string `yaml:"arch,omitempty,flow"`
		Goroot         string   `yaml:"goroot,omitempty,flow"`
		PreAction      string   `yaml:"pre-action,omitempty"`       // bash script
		PostAction     string   `yaml:"post-action,omitempty"`      // bash script
		PreActionFile  string   `yaml:"pre-action-file,omitempty"`  // bash script
		PostActionFile string   `yaml:"post-action-file,omitempty"` // bash script})Copy the code

Please go directly to the latest version or go.dev.

Command Line use

Bgo is a command line program based on HedZR/CMDR with basic features supported by CMDR, such as free multilevel subcommand parameter input and recognition, and so on.

In general, you should use BGO in two steps:

  1. Use bgo init to generate a bgo.yml template, which organizes the scanned CLI apps into this configuration template. Please rename it to.bgo.yml for automatic bgo loading.

    Bgo looks for the existence of.bgo.yml files from several automatic locations. It actually looks at bgo.yml as well, and it automatically extends to the appropriate conf.d folder for auto-loading and merging, so you can write a YAML fragment for each project separately in conf.d, which is great for continuous integration.

  2. With.bgo.yml in place (you can manually edit it to add custom properties), you can build it once using bgo.

In addition to the automatic mode described above, there are also ways to leave automatic mode for temporary specific operations.

  1. If BGO does not find the configuration file, we try to scan the current folder to try to build.
  2. If you don’t want unexpected build behavior to occur, bring--dry-runParameters.

Some commands may be useful in the following list, they are not compelled the configuration file is present, but as mentioned above, the configuration file can be in a format that is easy to adjust to make you full of control, and the command line no matter how to optimize, also can’t cover the content of the control parameters such as – ldflags so complicated and difficult to edit.

To shorten command line input, running bgo is implicitly equivalent to executing the bgo build subcommand. That is, bGO-S essentially performs bGO build-s, which initiates a short build mode.

So to see the possible command-line arguments, you should use bgo build –help.

For the current GOOS/GOARCH build

bgo -s
bgo -s -pn project-one
Copy the code

The purpose of the latter form is to compile project-One only for the current GOOS/GOARCH project, ignoring other projects in the configuration file.

If there is no configuration file, it automatically looks for the first main CLI and builds.

Full scan mode

bgo -f
Copy the code

In this case, bGO scans for all CLI apps in the folder, except projects defined in the configuration file.

Specify the target platform to build on

For example, only compile the specified target platform Linux /386 executable file, ignoring other target platform definitions that may exist in the configuration file:

bgo build --for linux/386
bgo -os linux -arch 386
Copy the code

The two commands have the same purpose.

Also, an array can be specified multiple times:

bgo -os linux --arch 386 --arch amd64,arm64
Copy the code

And you can optionally use the comma separator (,) to tell BGO to recognize the arraylist. For example, the above example actually gives an array of three ARCHs as arguments: [“386”, “AMd64 “, “arm64”].

In addition, for, OS, and ARCH work with both short and long parameter forms, either –for or -for, in order to reduce memory burden.

Similarly, this works:

bgo --for linux/386 --for darwin/am64
bgo --for linux/386,darwin/amd64
Copy the code

Specify the build project name

bgo -pn bgo
Copy the code

Bgo is used as a build abbreviation and is a shortened form of bgo build.

You can specify both the project name and the target platform:

bgo -os linux,windows -arch 386,amd64 -pn project-one
Copy the code

Enable Shell auto-complete

Currently, BGO can provide Shell auto-completion. Enter Bgo and press TAB.

As well as

and

If you are running BGO by downloading binary executables, a few steps are required to enable Shell auto-complete.

zsh

For the ZSH environment, the autocomplete script is generated as follows:

$ bgo gen sh --zsh

# "/usr/local/share/zsh/site-functions/_bgo" generated.
# Re-login to enable the new zsh completion script.
Copy the code

If bGO can’t find a place to put the _bgo completion script, it will output the script to the console, you need to save it as _bgo and put it in your ZSH autocomplete script search location.

ZSH uses the environment variable fpath to indicate where the autocomplete script should be placed. Such as:

❯ print -l $fpath
/Users/hz/.oh-my-zsh/custom/plugins/zsh-syntax-highlighting
/Users/hz/.oh-my-zsh/custom/plugins/zsh-autosuggestions
/Users/hz/.oh-my-zsh/plugins/z
/Users/hz/.oh-my-zsh/plugins/docker
/Users/hz/.oh-my-zsh/plugins/git
/Users/hz/.oh-my-zsh/functions
/Users/hz/.oh-my-zsh/completions
/Users/hz/.oh-my-zsh/cache/completions
/usr/local/ share/ZSH/site - functions provides the/usr/share/ZSH/site - functions provides the/usr/share/ZSH / 5.7.1 /functions
Copy the code

Bgo will automatically interpret these path locations and find the best place to go. However, if bGO cannot write successfully due to write permissions or other issues, then you need to do this manually.

You can also generate the script to the specified location:

bgo gen sh --zsh -o /some/where/for/_bgo
Copy the code
bash

Bash autocomplete scripts

Afterword.

Bgo may seem useful, but it probably won’t work for you either.

Bgo looks like a modules manager and build aid, but it’s not really a Modules manager, it’s more of a Main Packages automatic builder.

So the important thing to say three times: bgo exe not lib.

The last

Finally, I have to say that bGO is very rude, because the initial idea was just to have a Disabled flag to kill some projects, and then to have a –project-name filter, then -os, then -arch, and then realized that it was necessary to have –for.

And then it almost got out of hand.

But anyway, he can run now.

Pictured above

digression

Does anyone else remember Newegg?

It turns out that newegg’s American parent is alive and well, far from collapsing, and went public last year.

At the turn of the year, it is difficult to look back on the changes of the Internet in the past 20 years.

REFs

  • GOOS/GOARCH combos on macOS – Marcelo Cantos
  • Project: github.com/hedzr/bgo
  • Example configuration file: github.com/hedzr/bgo/b…
  • Docker Hub： hedzr/bgo – Docker Image | Docker Hub

🔚