-
Notifications
You must be signed in to change notification settings - Fork 0
bac is a command-line tool written in Python that is responsible for managing the build artifact cache directory. The most important aspect of BAC is what it does not do, but leave as the responsibility of the caller.
BAC is a tool which is only used by package management systems (or a package developer during debugging).
The BAC store is a directory structure on disk that looks roughly like this:
$bacstore/sources/python-2.7.1.tar.gz # cached downloaded tarball $bacstore/sources/numpy.git # raw git repository $bacstore/sources/... $bacstore/sources/links/hKUWhBuneltGSN4s0N-LMOpG27Q -> ../python-2.7.1.tar.gz # lookup by hash $bacstore/builds/python-hvfkN-qlp-zhXR3cuerq6jd2Z7g/bin/python # already produces builds $bacstore/builds/... $backstore/tmp/numpy-6dcfXufJLW3J6S-9rRe4vUlBj5g/.... # build in progress or failed
bac fetch /path/to/bacstore http://python.org/ftp/python/2.7.2/Python-2.7.2.tar.bz2
Downloads a tarball to the store, and prints the hash for it to standard output. Then that tarball can be looked up by that hash in the future.
bac build /path/to/bacstore mybuild.json
Attempts to do a specific build, as specified by the mybuild.json build specification file. The build specification file is described below.
On success, returns (on standard output) the resulting path to the built package. This could have been built on the fly, or been found already existing in the cace. (Some status information should be provided as one goes too so that one can tail logfiles etc. too; all easily parseable by a scripted called).
In the event of a failure, a directory will be left in $bacstore/tmp that can be inspected for post-mortem debugging. It is the responsibility of the caller to remove this.
bac check /path/to/bacstore mybuild.json
Checks if the build is already present
bac debug /path/to/bacstore mybuild.json
Like build, but only goes through setting up the environment for the build, then echoes the commands that it would have executed had a build been requested, then drops into a shell.
More commands that should be the responsibility of BAC:
- Garbage collection
The build specification fully describes a build, so that it can be hashed. Example:
{ 'dependencies' :
{ 'numpy' : 'numpy-345wr23wrfw3r4w',
'blas' : 'ATLAS-32rasdfasdfasdf',
'gcc' : 'gcc-324qwed32e2q3d',
'python' : 'python-q324rfaewfcwqrf',
'bash' : 'bash-34raewfvq23rw'
},
'files' : ['/home/dagss/qsnake/foo/spkgs/mypackage.install'],
'sources' : '6dcfXufJLW3J6S-9rRe4vUlBj5g',
'build' :
{ 'interpreter' : '$bash/bin/bash --someflag $1',
'script' : [
'source $gcc/build_env',
'export USE_FROBNICATOR=True',
'export CFLAGS=-O3',
'bash mypackage.install']
},
}
- name
- Will be prepended to the hash string in the cache (for human-readability).
- dependencies
- Specifies existing build artifacts that is depended upon by this build. If these are not present already, fail. The full expanded list of dependencies should be present (it is not known that numpy once upon a time depended on Python). Each dependency will be present in the environment variables when running the build script. These strings are included in the hash.
- files
- Lists files reachable on the local filesystem. The contents of these files are included in the hash, and the file copied to the build directory.
- sources
- The hash-key for a tarball or git commit for the sources that should be built.
This must have been previously downloaded using
bac fetch. - build/interpreter
- The interpreter command that is used (including arguments).
Can be a command to be looked up in the environment PATH (
bash), or a full path (starts with/), or it can start with$and one of the keys of thedependenciesdict, in which case one can select a binary from a previously built artifact. - build/script
- Simply the script given to the interpreter. If
$1is found in the interpreter command line, this is saved to file and passed as that argument. Otherwise, feed on standard input.