BuildAMation is an open source build system and project generator for Windows, Linux and OSX desktop software development in C/C++. It has a declarative markup language based on C# runtime compilation (using Mono on Linux and OSX), and has a plugin system to implement different backends, such as multi-threaded command line builds, VisualStudio or Xcode project generation, or MakeFiles. Common compiler/linker/archiver settings are exposed via C# properties, so you can configure the build using named settings rather than having to remember each toolchain's command line switches (handy for cross-platform development). Build scripts are debuggable in VisualStudio or Xamarin Studio. You can profile it with any standard tools. A number of standard open source projects have had build scripts written for them already, such as Qt, flex, bison, Python, zeromq, libtiff, zlib. CMake is a similar product.
1.0.4b204 Jan 2017 12:27
Bug fixes and performance improvements.
1.0.4b125 Aug 2016 16:16
* Improved speed of dependency sorter
* VisualStudio and Xcode projects now use relative paths within them (except for custom build steps)
* Xcode UUIDs are now deterministic
* Header libraries with linkable code dependencies now forward those to the module that eventually links.
1.0.302 Aug 2016 12:00
Some of the highlights of this new version:
* Cyclic dependencies are now detected
* Progress is displayed on the command line
* Windows binaries now include a versioning resource file, using module metadata already in use on Linux and OSX.
1.0.3b312 Jul 2016 10:33
Cyclic dependencies between modules are now identified, and an exception thrown if found. For example, if module A depends on B depends on A.
VisualC link command lines now specify the MACHINE option, honouring the C.ICommonLinkerSettings.Bits property that all the other supported linkers already do.
Bam.Core.ProcessState has acquired a BuildStartTime property (of type System.DateTime) that marks the beginning of the build on the local machine. This may be useful in conjunction with Bam.Core.IProductDefinition in your software build.
Using the indexer on C.CModuleContainer to get the module for an individual source file will now throw an exception if the path specified does not match any file on disk.
In Native build mode, C modules that refer to a number of object files, now detect when new files are added to them in incremental (i.e. non-clean) builds.
1.0.3b230 Jun 2016 01:44
Automatic generation of Windows .rc files for binary versioning.
For all fixes, see the changelist at https://github.com/markfinal/BuildAMation/releases/tag/v1.0.3b2
1.0.3b109 Jun 2016 15:58
- Native 64-bit Mono on OSX
- Progress updates
- Plugins that fail to build now don't have to cause the entire build to be fatal
1.0.218 May 2016 13:15
Optimisations, new features, and bug fixes.
See https://github.com/markfinal/BuildAMation/releases/tag/v1.0.2 for details.
1.0.2b310 May 2016 07:08
Optimisations in the Bam.Core assembly have sped up TokenizedString creation, dependency graph population, scanning of package repositories, to name a few areas. Improvements are most obvious in project generation build modes, like VSSolution or Xcode, which are not swamped by individual compilation/link times. Some larger builds tested now take less than 50 of the previous time in Bam (YMMV).
Bam.Core.Module.ClosingPatch is now applied to all child modules of a container (e.g. a collection of source files).
An indexer on C source collections has been added, accepting a string, which will return a list of child modules whose path contains the string. This is a simpler API for identifying individual source files from a collection created from a wildcarded path; patches can then be applied to individual sources. For example var source = this.CreateCSourceContainer("*.c"); var foo = source "foo.c" ; foo.PrivatePatch(settings = ...);.
Added Bam.Core.IOWrapper.CreateDirectory and CreateDirectoryIfNotExists functions, which wrap System.IO.Directory.Creates, but upon any exceptions thrown, will append details of the directory path in use, to provide context to the error.
1.0.2b220 Apr 2016 09:07
- OSX dynamic libraries and plugins now default to using an install name of @rpath/ lib filename . This requires an executable loading such files to define RPATHs - by default, a application built with Bam defines @executable_path/ as an initial RPATH. This restores previous behaviour, but this change allows applications to define additional RPATHs to just the application, rather than each dynamic library, to locate those dependencies.
- VisualStudio project files, project filter, and solution files are now only rewritten to disk if they don't exist, or differ from the existing file. For larger projects, this reduces the time in which the VisualStudio IDE becomes responsive after incremental changes to the build scripts. Note that Xcode project generation does not support this feature yet.
- Multiple Xcode projects referencing the same source file now honour per-module compiler options of those files. (Not per configuration - Xcode does not support this.)
- Added an assembly level attribute, Bam.Core.PackageDirectoryRedirect, which redirects where the (packagedir) macro refers to, so that source for a package can reside elsewhere. For example, if package build scripts and package source reside in different source control repositories, or don't support nested checkouts.
- Added Bam.Core.Module.ClosingPatch, which is similar to a private patch, but is guaranteed to be the last patch to be executed on a module. This allows logic to be applied once all settings on a module have been calculated.
1.0.114 Apr 2016 14:37