Links

Share project

BuildAMation is an open source build system and project generator for Windows, Linux and macOS desktop software development in C/C++. It has a declarative markup language based on C# runtime compilation (using Mono on Linux and macOS), 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, MonoDevelop or VisualStudio for Mac. 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.1.1b416 May 2017 20:34minor bugfix:
- Race condition fix for MakeFile generation
- Added utility functions to get the compiler version and intended bitdepth during a settings patch (most useful in static patches)
- Enabled more tests to run in different build modes

1.1.0b115 Mar 2017 14:50major feature:
Added Module configuration support. A Module class can now expose an interface with properties in to allow the user (at the top-level) to change how that module is built, or exposes itself via a public interface. This is intended to allow packages to define generic modules, rather than a fixed configuration defined by the author.
Deleted deprecated TokenizedString function, removetrailingseperator.

1.0.4b125 Aug 2016 16:16minor feature:
* 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:00minor feature:
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:33minor bugfix:
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:44minor feature:
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.218 May 2016 13:15minor feature:
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:08minor feature:
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:07minor feature:
- 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.