Fetching latest commit…
Cannot retrieve the latest commit at this time
|Failed to load latest commit information.|
(up-to-date documentation at http://code.google.com/p/go-gb) To install, go-gb/gb> make install or (to track release) > goinstall github.com/skelterjohn/go-gb/gb or (to track weekly) > goinstall go-gb.googlecode.com/hg/gb Overview gb is nearly configuration-free project builder for the go language. With gb, one only has to run the simple command line, gb, in order to bring all binaries up to date. To clean, gb -c. To install, gb -i. There are a few other options to do other tasks, but never should one have to write scripts that, for instance, specify lists of which source files should be used. gb figures that out by analyzing the directory structure and source. It works on a "one target per directory" rule to discover which source files are to be compiled with one another. The idea is to obviate the need for any sort of build script. gb will compile a set of "relevant targets" that exist within directories listed on the command line, and any other targets that these have an import depedence on. Note that a target in directory a/b/c will be included in this set if the directory a/b is listed in the command line. The most effective way to use gb is to have a top-level workspace directory for all your code, similar to the concept of a workspace with eclipse. Within the root directory, each target (whether it be a cmd or pkg) must reside entirely within its own subdirectory. Nested targets are allowed; source in a directory a/b will not be compiled with source in a directory a. When gb is run, it first recursively scans all subdirectories from its working directory to identify targets. Any directory that contains .go files or .c files will be identified as a target. Each target's name is then determined by first looking at its relative path, but can be overridden by either a target.gb file containing a new name, or a //target:<name> comment in one of the source files, before the package statement. (See `./examples/*`.) This renaming of targets is primarily useful for projects that are intended to be installed with goinstall, which requires that the target name match a URL. If gb is run within a directory that has a valid target, the target's name will be taken from the containing directory, rather than the relative path, ".". gb will match target names with import statements found in the source to determine the workspace dependency structure. It will use this structure to do incremental building correctly. Packages are all built to the _obj directory in the root, and commands are built to the bin directory in the root. If -i is on, they will be copied to $GOROOT/pkg/$GOOS_$GOOARCH and $GOROOT/bin. Tips If you want to run gb from within a target's directory, but still have it know about a larger workspace, create a file workspace.gb containing the path to the workspace directory. If your root contains a few packages and a few commands, but you only want to install the packages, run gb -Pi. You can encode some information in file names. If a common value for $GOOS or $GOARCH appears in the file name in the form of *_VALUE*.go, that file will only be included if it matches $GOOS or $GOARCH. The flag *_unix*.go will match any of the unix-based $GOOS options. gb can automatically build cgo projects. Quickly check the build status of any target with gb -s. It will print out a list of targets, and will tell you if they are up to date or installed (if a target is installed, it is also up to date). Tell gb to use goinstall to download packages with gb -g. To build a simple one-target package or command, you can run gb from within its directory if you use either target.gb or a //target:<name> comment. If you are working on something in $GOROOT/src and something outside at the same time, you can run gb -R to build dependencies in $GOROOT. To include extra files in a distribution, create a file 'dist.gb' that lists the additional files to copy. gb passes any command line arguments that begin with "-test." to testing binaries, when you run gb -t. Options: -i Install build pkgs and cmds to $GOROOT/pkg/$GOOS_$GOARCH and $GOROOT/bin, respectively. -c Remove all intermediate binaries. -N Remove all installed binaries. -b Definitely try to build. Useful when used as "-cb", to tell gb to first clean and then build. -g Tell gb to use goinstall to build remote packages available at one of the following websites: googlecode.com, github.com, bitbucket.org and launchpad.net. -G Same as -g, except goinstall fetches new code from the repository. -p Attempt to build a package immediately once its dependencies are met and a processor is free. -s List all targets that are relevant to the current build plan. If no directories are listed on the command line, all targets found will be listed. Otherwise, only targets that need to be up to date in order to bring the listed targets up to date will be listed. -S Same as "-s", except import dependencies are also printed. -t Run all tests contained in *_test.go source for the relevant targets. Behaves similarly to "make test". All additional command line arguments beginning with "-test." are passed to the test binary (see http://golang.org/cmd/gotest for details). -e Exclusive target list. Do not attempt to build any packages that aren't in the directories listed on the command line. -v Verbose. Print out all build instructions used. -m Use makefiles. If this flag is set, and a target contains a makefile, that makefile will be used to build. -f For use with "-M", force overwriting of makefiles. Otherwise you will be prompted when attempting to create a makefile for a target that already has one. -P Build/clean/install only packages. Useful if you have a set of helper commands to test your packages, but don't want to install them to $GOROOT. -C The same as "-P", but for commands. -R Add targets in $GOROOT/src to those that gb can build. They will not be built automatically, but if a local target has an import dependence on a target in $GOROOT/src, it will be brought up to date. This works with the "-s" option. Using "-Rs" will list any targets in $GOROOT/src that the local targets depend on. --makefiles Generate makefiles and a build script. In each relevant target, create a makefile that supports incremental building with the rest of the targets. The build script invokes each of the makefiles in a topological order, ensuring that running "./build" will always result in a correct build. --workspace Create workspace.gb files for all listed targets. Doing this allows you to run gb from within the target directories as if you were running gb from the directory you ran --create-workspace in. --dist Create a distribution directory for the relevant targets in a new directory "_dist_". All source files, including "*.go", "*.c", "*.s", and build files, including "makefile" and a top level "build" script, will be copied to this directory. --gofmt Run gofmt on all source for relevant targets.