Re: [Boost-build] [PING] State of PCH/msvc

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])