From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-10-20 02:42:10
> It seems that few people are interesting in the
> and the changes I made to Bjam tool. But I still
> attach a copy here.
> Hope it will be helpful to someone.
sorry that I did not reply to your previous email. As it sometimes happens, it
has falled thought the cracks.
> I have already made a contribution but don't know how to send to
That's simple. The "hacking.txt" document tells how to send a patch.
> Therefor I introduce first what changes and new features
> I made. I hope they would be helpful.
> ps. The code is base on "boost-build-2.0-m7".
> 1. The PROFILE Rule
> rule PROFILE ( key_path : data ? )
> Added only on win32 platform. It reads the registry of Windows.
> 'key_path' is the location of information, and 'data' is
> the name of value which we want to get. If 'data' is omitted,
> the default value of 'key_path' will be returned.
I recall Matt Armstrong has implemented something similiar for this patched
version of Perforce Jam. Is it primarily used for detecting where msvc is
I'm +/- 0 on this change, since we did not seen any complains from msvc users.
Anybody has an opinion?
> 2. The PREBUILD and POSTBUILD global variables
> Two predefined global variables with lists of commands executed
> just before or after the build process. Not like commands
> in actions which depend on some targets marked to update.
> The commands in the two lists will be always executed.
> They might be useful to cooperate with other console tools,
> like CVS, doxygen, codegen tools, or e-mail auto-sender...etc.
> For example, we can schedule daily-build at midnight,
> and send a report to us when it is finished.
> I only test the function in Windows, I don't know if it works
> on other platform.
You know, I think this is a bit out of jam's scope. For example, I have
nightly build script written in bash. I think separate script is more
powerfull that PREBUILD/POSTBUILD could be, for example, it can checkout the
project first --- where no Jamfile exists, or it can check return code, or do
conditional logic, and so on.
> 3. The HOST_OS and WIN32 global variables
> Besides 'NT' variable, it also define 'WIN32' now.
> In the past, Jam can only run in Windows NT platform,
> but it isn't exact today.
> The HOST_OS variable will be set to actual OS in run-time.
> Currently valid values are 'WIN95', 'WIN98', 'WINME', 'WINNY4',
> 'WIN2K', 'WINXP', 'WIN2003', 'NT'.
> I intend for cross-compilation, but the information
> might be useless. So I consider not to add it now,
> and added it later when we need it.
> 4. JAMSHELL setting of "%", indicating that the command should be
> invoked directly. But I found the code in "Bjam" only deal with it
> in execnt.c. I don't know if it works well in execunix.c.
> So I move the code from execnt.c to execunix.c. Of course,
> I refactor them a little. If it's ok in original way,
> I should move the snippet back. Would somebody help me to verify
> this? Because I have no Linux or Unix platform to test, and
> I am not familiar with them myself. Thank you.
I am not sure that "%" is needed for linux. The shell there has no command
line limit other than the limit enforced by the kernel.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk