1.1.1b416 May 2017 20:34
- 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.1b313 May 2017 13:12
- Fixes for Mingw assembler
- Fixes for examples
1.1.1b211 May 2017 10:17
- VS2017 assembler tool
- General assembler support improvements on all platforms.
- Generate Xcode project fixes when Pedantic warnings are used per file
- More bug fixes
1.1.1b121 Apr 2017 11:18
- More C++ language specifications exposed in enums
- Default to supporting 10.6 as the oldest macOS version for maximum compatibility
1.1.0b325 Mar 2017 11:33
Build scripts can now be conditional against tool versions.
1.1.0b219 Mar 2017 23:51
-VisualStudio 2017 support
-Xcode 8 support
-Gcc 5.4 support
1.1.0b115 Mar 2017 14:50
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.5b115 Mar 2017 14:49
Fixed version check for newer major/minor editions.
1.0.401 Mar 2017 12:55
See https://github.com/markfinal/BuildAMation/releases/tag/v1.0.4 for details
1.0.4b316 Feb 2017 15:12
Primarily including support to include assembler files (.S) into projects, as well as other bug fixes
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