JamPlus

Hi.

I have recently pushed a branch called 'jamplus3'. This branch contains changes for the next major evolution of JamPlus, something I've been working on over the past year. In particular, it greatly enhances the multiple toolchain support.

I have taken suggestions and some ideas of my own and made the toolchain support even better, I hope.

I open this up for discussion. What do you think of the new toolchain support? What other features, breaking, if necessary, would you like to see?

Thanks!

Josh

---

Missing rules¶

Jam now makes a good attempt to automatically find rules that have not been specifically loaded by the script via IncludeModule or include or a similar mechanism. It does this by splitting the rule name into its components (separated by periods) and then searching the disk for a file of the component name. Each component file is loaded and tested for the rule name.

If the script asks for C.Application, Jam loads modules/c.jam and looks for a C.Application rule. It finds the C.Application rule and executes it.

If the script calls CopyFile, Jam will look in modules/copyfile.jam for the CopyFile rule.

If the script wants to execute the rule Assets.Build.Something, the following happens:

1. modules/assets.jam is loaded. A test is performed for the rule Assets.Build.Something. If it is found, it is executed.
2. modules/assets/build.jam is loaded. A test is performed for the existence of the rule Assets.Build.Something.
3. modules/assets/build/something.jam is loaded. A test is performed for the existence of the rule Assets.Build.Something.
4. Assuming the search made it this far, the rule Assets.Build.Something does not exist. Now, Jam begins looking for a more generic rule called Assets.Build.Something.*.
5. If that is not found, Assets.Build.* is searched for.
6. If that is not found, Assets.* is searched for.
7. If any are found, $(__MISSING_RULE_COMPONENTS) is filled in with the string list Assets Build Something. $(__MISSING_RULE_SCAN_LIST) is filled in with the rules that were searched for and can be used for error reporting.

As a result of this new rule searching facility, a number of the rules in the provided C modules have undergone some renames:

• c/dotnet.jam
  • C.UseDotNet -> C.DotNet
  • C.ReferenceDirectories -> C.DotNet.ReferenceDirectories
  • C.StrongName -> C.DotNet
• c/mfc.jam
  • C.UseMFC -> C.MFC
• c/midl.jam
  • C.MidlFlags -> C.Midl.Flags
  • C.MidlCompiler -> C.Midl.Compiler
• c/mysql.jam
  • C.UseMySQL -> C.MySQL
• c/openssl.jam
  • C.UseOpenSSL -> C.OpenSSL
• c/qt.jam
  • C.UseQt -> C.Qt
  • $(QT_FOUND) -> C.Qt.Found
• c/win32resource.jam -> c/rc.jam
  • C.ResourceCompiler -> C.Rc
  • C.RcFlags -> C.Rc.Flags
  • C.RcDefines -> C.Rc.Defines
  • C.RcIncludeDirectories -> C.Rc.IncludeDirectories
• c/wxwidgets.jam
  • C.UseWxWidgets -> C.WxWidgets

Extended Lua Support:¶

Calling IncludeModule luasupport ; loads a small Lua script that makes Lua->Jam interop much nicer.

An example of its usage from a real world working asset build can be found in samples/assetbuild-luasupport/.

New Rule-Based Toolchain Support:¶

The Jambase.jam file will auto-launch a toolchain called (on Windows) win32/release. (I'd really like to not have the Jambase auto-launch anything in case the user is not using a C-based toolchain, but then it takes away from Jam's ease of use.) The user can override the default toolchain by passing the C.TOOLCHAIN=platform/config key/value pair. For instance, to build win64 debug for the C toolchain, you would specify C.TOOLCHAIN=win64/debug on the Jam command-line.

jam C.TOOLCHAIN=win64/debug

Additionally, as a backward compatibility feature, passing PLATFORM=abc and CONFIG=defg will result in a toolchain called abc/defg.

jam PLATFORM=abc CONFIG=defg

The rule C.Toolchain TOOLCHAIN_SPEC allows the current toolchain to be changed. The format of TOOLCHAIN_SPEC (win32/release) is slash-separated and the format is determined by the underlying Jamfiles that are executed. Additionally, at the end of the TOOLCHAIN_SPEC, you can add key=value options by preceding the option with an \@ sign. See samples/toolchains-helloworld/Jamfile.jam for usages.

C.Toolchain win32/release ;
    C.Toolchain win32/release@C.COMPILER=mingw
    C.Toolchain win32@C.COMPILER=gcc@C.CONFIG=debug

C.ToolchainSpecKeys is used as before, but it now parses a / separator to assign the same value to multiple keys. For instance, C.ToolchainSpecKeys C.PLATFORM/PLATFORM assigns the value to both C.PLATFORM and PLATFORM.

C.ToolchainSpecKeys C.PLATFORM/PLATFORM C.CONFIG/CONFIG ;

The majority of the files residing in the bin/modules/c-compilers/ directory have been moved to bin/modules/c/toolchain/'. The @bin/modules/c-compilers/ directory tree has been removed.

The order of toolchain file loads is as follows when Toolchain win32/release is called:

1. The C.Toolchain rule is requested. The rule is found missing, and Jam loads bin/modules/c.jam to find it.
2. Jam then attempts to execute a rule called C.Toolchain.win32.release. The MissingRule support kicks in and ends up executing rule C.Toolchain.win32.* from bin/modules/c/toolchain/win32.jam.
3. Toolchain spec keys are added for C.PLATFORM/PLATFORM and C.CONFIG/CONFIG. For the toolchain win32/release, the following assignments are made: C.PLATFORM=win32, PLATFORM=win32, C.CONFIG=release, CONFIG=release
4. Within C.Toolchain.win32.*, auto detection of the compiler is performed. First, the latest Visual Studio version is detected. Failing that, TDM/GCC is detected then MinGW. Assuming Visual Studio detection, C.Toolchain.vc.win32.Detect from bin/modules/c/toolchain/vc/win32.jam is called.
5. Next, C.Toolchain.vc.win32-release is called to set up some optimization flags and #defines.

samples/fakeps3/jam/c/toolchain/fakeps3.jam shows an example of handling multiple configurations and architectures within a single file.

jam C.TOOLCHAIN=fakeps3/debug/ppu

Be aware that the Jam variable called C.ACTIVE_TOOLCHAIN has been renamed to C.ACTIVE_TOOLCHAIN_GRIST.

Instead of faking 'derived' classes of compiler hierarchies within Jam (that never worked well before), settings are now added to $(C.COMPILER_SUITE_SYMBOL) with the rule names that should be called. More than one rule name can be attached per setting; the listed rules will executed in order. The names of the settings are as follows: C.ApplicationFromObjects_CleanIntermediates, C.ApplicationFromObjects_LinkFlags, C.ApplicationFromObjects_PostBuild, C.ApplicationFromObjects_Setup, C.C++Exceptions, C.LibraryFromObjects_LibFlags, C.LinkPrebuiltLibraries, C.MultiCppCompile_PreCompile, C.MultiCppCompile_PchDeps, C.MultiCppCompile_PostCompile, C.MultiCppCompile_SetupFlags, C.RuntimeTypeHelper, C.SharedLibraryFromObjects_CleanIntermediates, C.SharedLibraryFromObjects_ExportLib, C.SharedLibraryFromObjects_LinkFlags, C.SharedLibraryFromObjects_PostBuild, C.SharedLibraryFromObjects_RegServer, C.SharedLibraryFromObjects_UnRegServer.

Miscellaneous updates:¶

• For jam --workspace more than one IDE type can be specified comma separated to --gen, and all listed IDEs will have project files written.
• Visual Studio files use backslashes.
• For iOS, the minimum SDK version is handled correctly.
• iOS 8.1 support has been added.
• The workspace project hierarchy has changed around for greater clarity in the out of source build directory.
• All samples and tests have been updated with the new toolchain support.
• UseModule has been completely removed. Use IncludeModule instead.
• IncludeModule now searches $(CWD)/jam for additional modules. The search order is: $(SUBDIR) $(CWD) $(CWD)/jam $(JAM_MODULES_USER_PATH) $(JAM_MODULES_PATH)
• toolchain= is a synonym for TOOLCHAIN= on the Jam command-line.
• C.SubDirCcFlags, C.SubDirC++Flags, and C.SubDirHdrs have been removed.