Version 1.1.0. beta 1

Highlights of v1.1.0 beta 1

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

Full changes since v1.0.5

Known issues

Bug list

Version 1.0.5 beta 1

Highlights of v1.0.5 beta 1

• Fixed version check for newer major/minor editions.

Full changes since v1.0.4

Known issues

Bug list

Release version 1.0.4

The changes included in this stable release were aimed at building a multi-platform desktop application, Director.

Highlights of v1.0.4

• Improved Xcode support.
• Fixes to tar installer generation.
• Linux ld version script support.
• Improved dependency checking of Native builds.
• Added Assembly file support.
• Speed improvements.
• And many more changes and fixes.

Full changes since v1.0.3

Known issues

Bug list

Version 1.0.4 beta 3

Highlights of v1.0.4 beta 3

The changes below are to support the improved Python-3 build scripts in github/bam-python.

• Added API and tools to assemble .S files to object code. VisualC, clang, Gcc have been tested, as have Native, VSSolution, Xcode and MakeFile build modes.
• Fixes to incremental Native builds, to ensure that file timestamps are honoured. The tradeoff for a more accurate build is that it may take more time to run the build.
• Various fixes to Xcode project generation.

Full changes since v1.0.4b2

Known issues

Bug list

Version 1.0.4 beta 2

Highlights of v1.0.4 beta 2

This is the build that has been used to create multi-platform builds and installers for Director, a desktop application for creating CG animations.

• Performance improvements in all build modes, for packages with many interwoven dependencies, that have 'forwarded dependencies', e.g. a static library depending on a static library.
• Installer.ITarBallSettings now supports a TransformRegEx string property. This can be used so put the archived files into a directory. Note that the tar utility's --transform option is NOT supported on OSX.
• Fixes to OSX publishing of frameworks that contain 'helper' application bundles.
• Linux ld version scripts are now supported.

Full changes since v1.0.4b1

Known issues

Bug list

Version 1.0.4 beta 1

Highlights of v1.0.4 beta 1

• The new dependency sorting algorithm introduced in v1.0.2 introduced unnecessary processing of lists of modules once sorted. This has been corrected. It was observable as a stall in the progress updates.
• Configuration specific dependencies in VisualStudio are now honoured. However, this is a breaking change in the API for any custom written scripts for the VSSolution build mode; dependent projects are now associated with configurations, not their projects.
• VisualStudio and Xcode projects now specify the majority of the paths specified within them as relative to the projects. The exception are custom build steps. A new bug has been raised to fix those. The theory behind this change is to eventually make generated projects portable when distributed with the package source.
• Xcode project UUIDs are now deterministically generated, based on the data for each object (usually any dependent UUIDs, paths, names). The same UUID should be produced on incremental project generation, unless the objects change significantly.
• Incremental regeneration of Xcode projects now only writes project files if their content has changed. (VisualStudio projects already did this.)
• C.HeaderLibrarys that depend on other modules with actual code (e.g. a static library) now forward that dependency onto the eventual link step.

Full changes since v1.0.3

Known issues

Bug list

Version 1.0.3

The changes included in this stable release are aimed at improving feedback to the user during bam builds, and consistent support for module versioning across platforms.

Highlights of v1.0.3

• Cyclic dependencies between modules are now reported as errors.
• Bam command line tool displays progress updates during dependency graph construction.
• As of Mono 4.4, Bam on OSX now uses 64-bit Mono, on supporting hardware.
• C application modules can now define a working directory to use in VisualStudio and Xcode project debugging.
• All types of C binaries (applications, DLLs, plugins) now generate a resource file on Windows, containing versioning information from the module (using the same information as for dylibs and shared object symlinks; major, minor and patch versions). Exceptions are those marked with the C.Prebuilt or C.Thirdparty attributes. An optional path to an existing resource file can be passed to C.Thirdparty, for those modules representing external software that already has versioning resource files.
• Added Bam.Core.IProductDefinition, which can be implemented in a package build, providing a way of specifying additional product-wide data, such as a product version, company name, copyright etc. This information is currently only used to generate the Windows version resource files.
• And many more changes and fixes.

Full changes since v1.0.2

Known issues

Bug list

Version 1.0.3 beta 3

Highlights of v1.0.3 beta 3

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

Full changes since v1.0.3b2

Known issues

Bug list

Version 1.0.3 beta 2

Highlights of v1.0.3 beta 2

• All non-prebuilt C binaries (applications, DLLs, plugins) on Windows now automatically generate an .rc (resource) file containing versioning information for that file. If thirdparty projects are built, with their own resource file, then the C.Thirdparty attribute can be applied to the module with the path to the .rc file to use instead.
• Added Bam.Core.IProductDefinition, and an accessor on Bam.Core.Graph.ProductDefinition. At most one implementation of an IProductDefinition should be present in a package assembly. This can be used for metadata in other parts of the build to define the collection of built modules as a product, e.g. in the Windows resource file, installers, etc. Properties on the interface are
  • Name (of product)
  • MajorVersion
  • MinorVersion
  • PatchVersion (assuming semantic versioning)
  • IsPreRelease (boolean),
  • CopyrightNotice
  • CompanyName
• Add WorkingDirectory property to C.ConsoleApplication to set a Bam.Core.TokenizedString which VisualStudio and Xcode project generation uses for debug settings. Thanks to @joshmartel for the suggested fix for VS.
• Can now specify a different leafname for import libraries to that for the dynamic library. See the ImportLibraryName macro.
• Utility functions such as CompileAs now cope with the dependent module not existing, for example, if it has been filtered out of the current platform.
• Added ChangeDefaultSettings test case to exercise the Bam.Core.ISitePolicy interface.
• The Bam.Core.TokenizedString pre-function, #valid, now accepts an optional second argument. The syntax is now #valid(expr[,fallback]). Previously, if expr was not valid, an empty string was replaced. Now, if fallback is provided, this is used instead of an empty string.

Full changes since v1.0.3b1

Known issues

Bug list

Version 1.0.3 beta 1

Highlights of v1.0.3 beta 1

• If you are using Mono OSX, and have downloaded v4.4, then if you have 64-bit hardware, a 64-bit version of mono is now used. This is now consistent with the other platforms. Previously, only a 32-bit version of mono was available on OSX.
• Console output while preparing for a build is now accompanied by progress information. Module creation lists how many have been created so far (it's not known in advance how many there will be). Other operations, prior to actually executing the dependency graph, show percentage completion.
  • Note on Windows, if using the git bash shell from git for Windows 2.x, you will have to prefix any bam command with winpty for the progress output to be visible.
• Modules may now throw a Bam.Core.UnableToBuildModuleException. This indicates that the module build is fatal. The difference between this and just throwing a Bam.Core.Exception is that there are special cases in which throwing this new exception can be recoverable. One example is for a plugin build. Since plugins are runtime dynamic dependencies, in theory the primary application can run without it (just with limited features). So if the development machine does not have all the requirements to build a plugin, it can be ignored, while the rest of the build is no longer fatal. A console message is displayed when a module has been ignored.
• Simplified Bam.Core.Module.GetEncapsulatingReferencedModule(). This has not appeared in timing profiles (yet), but it is no longer recursive, and uses information that had already been gathered in the dependency graph generation.

Full changes since v1.0.2

Known issues

Bug list