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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-04-27 01:47:17

On Wednesday 26 April 2006 20:44, Reece Dunn wrote:

> Looking forward, I don't think that BBv2 in its current incarnation has
> the right support for pre-compiled headers. I think that PCH support
> should be at a lower level - actually built into the core functionality.

What kind of "core" support for PCH files do you think is necessary?

> There are also several things that I would like to see BBv2 or BBv3
> support. With compilers, you can get them to generate preprocessed
> output and generate the assembly instead of object code. This is not
> currently supported in BBv2. The chain would look something like:
>
>    CPP -> PreProcessed-CPP -> ASM -> OBJ

I think that supporting this would be a matter of adding new features and 
adjusting CPP->OBJ generator for compilers that support this model.

> Also, it is not possible to support different build models (e.g. Java/C#
> compile everything in one pass) 

Yes, we basically did not have anobydy work on Java/C# so even requirements 
are not written down.

> or support orthogonal toolsets. What 
> I mean by orthogonal toolsets is performing a build that uses msvc for
> C++ compilation and WiX for MSI/Installer generation.

And what is wrong with that? 

> My current thinking is to work out what is needed by all of these and
> how to make them fit into the BBv2 view of the world, but rework
> BB (for bbpy?) to add direct support *from the ground up* rather
> than providing a hack that uses several kludges to get these working
> (like is currently done with PCH). 

It's perfectly reasonable to adjust architecture to better support things like 
PCH. But without specific suggestions there's not much we can discuss ;-)

> This will be easier to do in Python 
> where we are not restricted by the action/rule model from Jam 

I think that the action/rule model from Jam is the least problematic part. Can 
you say that exactly is wrong with that?

> and 
> have a richer *native* set of types.

That's one reason of the Python port, anyway.

- Volodya

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2