Comparison with Jam/MR
KJam is modelled closely on Jam. It shares most of its language primitives, and functions in a similar manner. However, KJam is different than Jam in many important respects. Jamfiles written for Jam/MR will not run under KJam and vice-versa, though it is straight forward to adapt most files written for Jam to run under KJam.
Differences:
For large projects KJam is much faster than Jam. KJam can compute dependencies for many thousands of targets in just a few seconds.
KJam has greatly expanded and more powerful variable expansion. KJam's variable expansion includes several primitives which allow for file system searches and full support for regular expression matching, eliminating the need for special builtin rules like MATCH and GLOB, and for the action modifier bind.
In Jam modifiers can only be applied to variable expansions. KJam allows you to apply modifiers directly to literals. Variable expansions and literal expansions can be nested within one another to make extremely powerful expressions.
KJam has better support for build actions which collect multiple sources and targets and build them together in a single build action. Jam/MR supports this usage as well but has trouble managing dependencies in this case. KJam works correctly in this case. When building sources together KJam also supports cutting the list of sources into batches of a given size. This is useful for load balancing in build environments where multiple processors are available.
KJam has better support for text output. KJam can be configured to autowrap all output text, so that lines which are longer than the shell width can wrap neatly and readably in user configured paragraphs. KJam supports an additional built-in rule called print, which is similar to echo, but concatenates its output and prints it without quote marks. In KJam, print is useful for printing formatted messages. echo is useful for printing an accurate representation of the contents of a given variable.
KJam has named arguments for actions as well as rules. In Jam, only rules may have named arguments and actions arguments must be referred to using numbered arguments, which are error prone and hard to read. In KJam actions have named argument lists, just like rules, which improves the readability and consistency the Jam language.
KJam's support for the switch statement uses full regular expressions, and supports a default label. In Jam, the patterns in the case statements use a much simplified approximation of regular expressions. In KJam the case patterns are full regular expressions. In Jam if no case statement matches, then no associated statements are run. In KJam, the user may provide a default label, whose associated statements are run if none of the case patterns match.
KJam's parser is more powerful and also stricter about accepting sensible input.
KJam supports comments starting with #, and //, as well as c-style multi-line comments /* */. c-style escape characters are supported in variable names and inside strings. Numbers may be expressed as in decimal or hexadecimal throughout. All the assignment operators ( = += ?= -=) can have lists of more than one as a left hand side, even when scoped with local or on.
In many places where a lists are accepted, Jam accepts empty lists even when an empty list would make no sense. KJam will catch those cases and report a parsing error. The expression part of if, switch, while and for statements must be surronded by () like in most programming languages.
The scripts attached to KJam actions must be delimited by {% %}. In Jam only { } is required. Requiring {% %} delimiters for scripts allows the user greater flexibility in the content of their scripts.
KJam's built-in rules are different from those in Jam. The jambase file used by KJam takes advantage of many of KJam's many improvemnets. Therefore the built-in jambase file's rules are different - and easier to use, more robust and more flexible than the jambase used in Jam.
KJam's built-in rules can be easily modified by the user. In Jam, changing the built-in rules requires re-compiling the program. In KJam the built in rule files can be extracted from the binary, modified and re-imported into the binary. Jam uses a single jambase file. KJam's built-in rules can consist of multiple files, allowing users to integrate complex multi-file build system into the KJam binary.
KJam supports many new built-in variables: JAM_CWD, JAM_IS_NET_CLIENT, JAM_NAME, JAM_USER, JAM_PLATFORM, JAM_CMD_OPTIONS, JAM_CMD_TARGETS, JAM_CMD_FILES, JAM_TARGETS, JAM_BUILDABLES, and JAM_WRAP.
When running in a multi-threaded mode, in Jam/MR the output of commands from different threads is interspersed making it extremely difficult to determine which output comes from which thread. In KJam, in all multi-threaded modes, output from each thread is saved and presented to the user together for greater readability.
The Jam keyword actions has been changed to action. This seemed more appropriate given that rule is singular. When talking about the contents of a jamfile, it also makes it less ambiguous when referring to multiple action definitions.
The [] operator for variable expansion uses indexes which start at 0, in keeping with the way indexes are treated in most modern programming languages. For example in Jam the $(LIST[1]) refers to the first element of a list. In KJam $(LIST[0]) refers to the first element of a list.
In Jam users can get information about the current operating system by inspecting the built-in variables OS and OSPLAT. In KJam users can get more detailed platform information by inspecting the built-in JAM_PLATFORM and JAM_UNAME variables.
Added features:
KJam can be run in a multi-system client server network mode.
KJam servers can be started on networked machines. By default if the machines are on the same subnet and all the servers are listening on the standard KJam server port, the servers will find each other and create a peer to peer distributed build network. KJam can then be run as a networked build client which will spawn its build jobs on this distributed network. For certain types of resource intensive build applications this can radically speed up build times.
KJam by default uses a built-in sh-like shell. In Jam, all build commands must be run using an external shell. The shells available on different systems may have different capabilities requiring users in a cross platform environment to write actions for different shells. In particular on Windows the only shell commonly available is the extremely primitive cmd.exe.
By using KJam's built-in shell:
- Users can expect a base level of shell functionality on any platform. In situations where a users needs outstrip the capabilities of the built-in shell KJam, like Jam, allows users to specify an external shell by defining JAM_SHELL.
- Execution can be significantly faster in situations requiring the build system to run a large number of simple actions because an external shell is not spawned repeatedly.
- Most basic file system operations use built-in implementations. In situations where most build commands involve file system operations this can be significantly faster than spawning many calls to external commands.
- Execution errors are reported with file and line numbers which reference location of build error in the jamfile.
KJam has more extensive debugging and reporting features than Jam. KJam can report is internal operations more clearly and in greater detail than using Jam, making it easier for users to find problems in their ajamfiles. KJam has more flexible output rules, allowing users to make better, more readable build output.
KJam has the -= operator, which removes any elements of the variable on the right hand side from the variable on the left.
Missing features:
Legacy symbol names for rule and action arguments. KJam does support numbered arguments for rules and actions or the legacy $(<) and $(>) arguments. Because KJam supports named arguments for both rules and actions, numbered naming schemes seem inferior and redundant. Since KJam does not have to support numbered arguments, rules and actions are no longer limited to 9 arguments.
Jam has many built in rules with upper case, lower case and mixed case versions. In some cases not all options are available. This can cause confusion, because in Jam there are multiple keywords with the same function. In KJam all the built-in rules use lowercased names.
The GLOB and MATCH built-in rules are not implemented. With KJam's more powerful variable expansion syntax these rules are no longer necessary.
The action modifier bind is not implemented. With KJam's more powerful variable expansion syntax this modifier is no longer necessary.
In Jam it is possible to use archive elements as targets. This is not supported in KJam as it would require building into KJam application and platform specific dependencies.
Jam is supported on a large number of platforms. KJam only supports Windows and Linux. A port to Apple OSX is planned.