Boost logo

Boost-Build :

From: Alex Besogonov (cyberax_at_[hidden])
Date: 2006-04-27 12:20:57

On Thursday 27 April 2006 19:28, Alex Besogonov wrote:
>> BTW, I have a wild idea: rewrite JAM in C++ (after all, BBv2 is mostly
>> used on platforms able to compile Boost). Jam's codebase is about 500Kb
>> of code, it can be reduced to about 200Kb (or even less) of C++ code.
> I've no problem with that, but if V2 is ported to Python, there will be little
> from bjam left.
Yes, but I'd prefer that "little" to be written in C++ (or at least
clean C).

I'm going to try to make your Python sample work with it as a first
stage of development.

> The Jam syntax parser is good enough, and I'm sure you won't
> like to touch either variable expansion code, or build engine itself ;-) It's
> a bit scary.
Yes, it's scary :) But I think I can understand and rewrite it.

>> Is it possible? PCH+PDB support alone require bi-directional property
>> propagation.
> BTW, can you clarify? I believe that problem now is that free requiremets are
> not propagated from exes to PCH targets.
Yes, and some tricky renaming is necessary to support parallel builds.

BTW, is it possible to add propagated free properties? I needed them
badly in my wxWidgets.jam.

>> And, AFAIK, more advanced flag support is necessary. For
>> example:
>> ==========
>> flags msvc.compile PDB_CFLAG <debug-symbols>on/<debug-store>database :
>> /Fd ; # not used yet
>> ==========
>> What can I do if I need not just "/Fd" but
>> '/Fd"c:/some_dir/some_file.pdb"' ?
> Where will that values come from?
Well, the value can be:
1. A feature value.
2. Derived from some other option (from PCH, for example).
3. Derived from target path.
4. It can contain current thread number for parallel builds.

> In any case, this does not sound like radical change from the current
> model, it's just additional customization point.

With respect,
             Alex Besogonov (cyberax_at_[hidden])

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at