Version 1.0.2

The changes included in this stable release have focused on bug fixing and performance optimisations.

Highlights of v1.0.2

• 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).
• C.ConsoleApplication and C.DynamicLibrary (and C++ counterparts) now have ExtendSource and ExtendSourcePublicly functions, allowing a factored out C.CObjectFileContainer to be merged (cloned internally) into multiple modules. This is analogous to embedding a static library into a dynamic library, but without any of the platform limitations, and with the benefits of honouring patches on the factored out files.
• Xcode generation now supports identifying .tbd files, new in Xcode 7, which are text based dylib definition files.
• 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, if the project is not unloaded first. Note that Xcode project generation does not support this feature yet.
• 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 => ...);.
• Many more bug fixes.

Full changes since v1.0.1

Known issues

Bug list

Version 1.0.2 beta 3

Highlights of v1.0.2 beta 3

• 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.

All changes since v1.0.2b2

Known issues

Bug list

Version 1.0.2 beta 2

Highlights of v1.0.2 beta 2

• 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, if the project is not unloaded first. 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.

All changes since v1.0.2b1

Known issues

Bug list

Version 1.0.2 beta 1

Highlights of v1.0.2 beta 1

• Fixed performance issue with VisualStudio project generation for some larger test cases, after profiling with slimtune.
• Fixed static analysis issues raised with Coverity Scan.
• Xcode 7 project generation now supports .tbd files, which are text based dylib definition files.
• Added a function to clone an existing module, along with its private patches, Bam.Core.Module.CloneWithPrivatePatches. Public patches are subjective, depending on the use context, so are not copied. If modules need to perform custom operations during cloning, the Bam.Core.ICloneModule interface must be implemented.
• Added a new optional delegate parameter to Bam.Core.Module.Create, of type Bam.Core.Module.PostInitDelegate, which, as the name suggests is executed immediately after the new module's Init function has returned.
• C.ConsoleApplication and C.DynamicLibrary (and C++ counterparts) now have ExtendSource and ExtendSourcePublicly functions, allowing a factored out C.CObjectFileContainer to be merged (cloned internally) into multiple modules. This is analogous to embedding a static library into a dynamic library, but without any of the platform limitations, and with the benefits of honouring patches on the factored out files.
• Xcode projects linking against prebuilt static, or dynamic libraries now honour these libraries. Due to the way Xcode projects list these dependencies, the libraries must be discoverable either on the library search paths specified, or in the SDK in use.

Full changes since v1.0.1

Known issues

Bug list

Version 1.0.1

The changes included in this stable release have focused on:

• bug fixing, and clarifying and formalising the BuildAMation API,
• enabling support for a wider range of Windows Visual Studio toolchains,
• adding support for building a wider range of open source projects that currently rely on other build systems, e.g. procedurally generated headers with configuration options, such as those generated by an autoconf step, and integrating these with project generation.

Highlights of v1.0.1

• Added support for VisualStudio 2010, 2012 and 2015 (2013 was already present in v1.0.0). Note that there is a breaking change for identifying the C runtime libraries for VS2015 due to the change by Microsoft for the universal C runtime.
• Greatly improved publishing of files, directories, symlinks to create a runnable package, but also now being able to use the same API to publish API headers. Supported by all build modes.
• New wildcards for Bam.Core.TokenizedStrings to capture files recursively. Useful for multi-level directories of header files.
• C.ProceduralHeaderFile can be used to specify the content of a header file to write, and C.ProceduralHeaderFileFromToolOutput to capture the stdout of a tool built earlier into a header file.
• Clarified the valid use of CompileAgainst and derivative functions from the C package on which types of module, and what Public means to expose patches through module hierarchies. This may be a breaking change for some scripts as API functions have moved between module types, but is easily fixed. The API documentation has been updated to reflect the changes.
• Improved the identification of #includes for dependency scanning in the Native build mode, to cover more cases seen in open source software.
• Improved dependencies (both link time and order only) in generated VisualStudio, Xcode projects and MakeFiles.
• Projects containing files that shouldn't be compiled (e.g. are #include'd by another source file) can now be marked as such, so remain browsable, but not buildable.
• Projects with source files with identical leaf-names in separate source directories no longer fail the build with colliding object file names. Binary and intermediate output file paths are constructed to be as unique as possible, mirroring on the source file hierarchy, and choosing subdirectories based on generated file type.
• More compiler/linker features exposed as named settings to be used in patches.
• Updated API documentation, with additional details of both existing and new features.
• Many exception messages have been expanded upon, with hints for how to fix common errors.
• Many more bug fixes.

Full changes since v1.0.0

Known issues

Bug list

Version 1.0.1 beta 5

This is the last planned beta of v1.0.1

Highlights of v1.0.1 beta 5

• Clarified the API for inheriting public patches on C modules. For example, C.ConsoleApplication (and derived module classes) used to have CompilePubliclyAndLinkAgainst() which would both use the public patches of a dependent, but also forward them onto any dependee of the application. Applications are the end of the food chain though, so this would never happen, and confused the use of the API. This function has been moved to C.DynamicLibrary and C.CxxDynamicLibrary module classes. Note that this is a potentially breaking change to existing build scripts, depending on your use of this function. The likely use cases will be for applications using CompilePubliclyAndLinkAgainst - just change this to CompileAndLinkAgainst; and any module that accidentally benefited from the inherited patches accidentally - will likely need a CompileAndLinkAgainst added to resolve any compilation or linker errors.
• Dynamic libraries now forward any public dynamic dependencies they have. Static libraries already did this, to avoid the need to specify transient dependencies. This change should simplify build scripts.
• RTTI support in linker settings has been added, see C.ICommonLinkerSettings.EnableRunTimeTypeInfo.
• A new module, C.ProceduralHeaderFileFromToolOutput has been added with support in all build modes. While the existing C.ProceduralHeaderFile module required string input from the code, this new module takes the standard output from a built executable as the content for the generated header.
• A new evaluation reason, Bam.Core.ExecuteReasoning.EReason.DeferredEvaluation, has been added, to cover the cases as with C.ProceduralHeaderFileFromToolOutput, that does not know if its target file needs to be updated until the build has started. (All other types of evaluation reason trump deferred evaluation.) This is only applicable in the Native build mode currently.
• Many bug fixes to improve experience.

Full changes since v1.0.1 beta 4

Known issues

Bug list

Version 1.0.1 beta 4

Highlights of v1.0.1 beta 4

• Added VisualC 2012 and 2010 support, including project generation. The latter has only been tested using the Express edition, which is has limited functionality compared to the Professional edition. Specify --VisualC.version=11.0 or 10.0, respectively on the command line (assuming the relevant packages are in your definition file).
• Headers exposed in C.Prebuilt modules (e.g. Qt modules) now appear in generated projects.
• Source files that are #included into others can now be explicitly marked as don't compile (see the PerformCompilation property on C.ObjectFile), and will appear as excluded in project files.
• Windows dynamic links can now specify an existing .def file for export definitions. See the C.ICommonLinkerSettingsWin.ExportDefinitionFile property.
• If a module is a child of a collection, it now has access to string macros referring to its parent. Useful to generate unique paths. See parentmodulename and encapsulatedparentmodulename macros.
• Scanning for #include statements in source files is more flexible on use of whitespace, and searching in the same directory as the source file (since the header search path does not need to be explicitly set on the compiler).
• Shell scripts in Xcode projects will now fail the build if any command within it fails.
• Fixed circular reference issue with symbolic links created by the Publisher package on a non-clean build.
• Procedurally generated files can now be checked for updates before writing them in non-clean project generation builds. For example, modules derived from C.ProceduralHeaderFile only write to disk when their content has changed now. See Bam.Core.EvaluationRequiredAttribute. This reduces redundant compilation steps when the IDE build step is next made.
• Many bug fixes to improve experience.

Full changes since v1.0.1 beta 3

Known issues

Bug list

Version 1.0.1 beta 3

Highlights of v1.0.1 beta 3

• Improved VisualStudio 2015 support (community edition tested, on Windows 8.1 and Windows 10).
• Changed how VisualC packages can specify their redistributable runtime libraries for both C and C++. This is a breaking change from v1.0.0, but necessary to support VisualStudio 2015 dividing msvcr*.dll into two.
• API referring to C collection modules (e.g. CompileAgainst()) now enforce at compile time that at least one collection must be passed an argument (previously a runtime test).
• Clarified the licensed use of example code from the MSDN website in the Bam.Core assembly. See the command line output preamble, and the MS-PL.md file now shipped.
• Fixed 32-bit Windows support.
• Many bug fixes to improve experience.

Full changes since v1.0.1 beta 2

Version 1.0.1 beta 2

Highlights of v1.0.1 beta 2

• Can now use the Publisher.Collation starting from a prebuilt file. This is useful to reuse collation to gather sparsely distributed headers into a public API folder, for instance.
• Using the double wildcard path 'path/to/**.c' will recursively search under 'path/to' for all matching files, when adding to a C file container, e.g. for source or header files.
• Added C.ProceduralHeaderFile module class, that can be derived from to simplify generation of configuration headers.
• Bam.Core.ModuleGroup, used by VisualStudio to place modules into solution folders, can now take a directory path, e.g. path/to/somewhere, and solution folders will be created to mirror the directory hierarchy.
• Added C standard enum options for GNU89 and GNU99.
• Many bug fixes to improve experience.

Full changes since v1.0.1 beta 1

Version 1.0.1 beta 1

Highlights of v1.0.1 beta 1

• Improved Publishing package, including specifying dependencies during publishing, renaming directories during a copy, fixed MakeFile generation.
• Allow modules to specify more than one optional path.
• Fixed IDE projects for modules with custom prefix or suffix.
• Many bug fixes to improve experience.

Full changes since v1.0.0