State of PCH/msvc

Philip Craig wrote:
> > Phillip Seaver <philapago.com> wrote:
> >> boost build can't be used for serious
projects in msvc++ until all of 
> >> pch and -jn (where n > 1) and pdb are
working.
> >> The performance hit for switching to boost
build is just too great 
> >> without these things.
> > Sure, it can.    I'm
currently building 9 programs (1 COM object and
> > 2 Windows GUI programs) on Windows 
> 
> Ok fair point. If you need cross platform that can
outweigh the 
> performance hit. But if you don't (and many don't)
then boost build is 
> not in the ballpark for windows only development. I
wish it was.

I know that there are many issues with the current PCH
support on the
msvc compiler with BBv2, but getting it to support *that
much* required
major effort. This is because you know how you *want* PCH
support to
work where it is "nice and simple(TM)" and then
you have how MS decided
to implement it. I am not criticising MS on their decisions,
it is just that
the two are completely different, making it very hard to get
it working
right on BBv2 as it stands.

Regarding PDB generation and copying, this is one of the
things I intend to
look into because it is something that I will find useful.

IIUC, the -jn option is parallel builds. I don't understand
how that works or
how PCHs/PDBs work in that kind of environment.

As for not being able to compile Windows GUI programs - I am
using it to
build all my home projects. That includes builds of
XPDF/Poppler, Scintilla,
HTML Tidy and a fairly large GUI app that uses all of these.
I haven't
experienced any major problems with rebuilding them,
although I haven't
done any extensive performance comparisons.

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.

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

Also, it is not possible to support different build models
(e.g. Java/C#
compile everything in one pass) 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.

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). This will be easier to do
in Python
where we are not restricted by the action/rule model from
Jam and
have a richer *native* set of types.

- Reece
____________________________________________________________
_____
Express yourself instantly with MSN Messenger! Download
today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471
ave/direct/01/
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Reece Dunn wrote:
> I know that there are many issues with the current PCH
support on the
> msvc compiler with BBv2, but getting it to support
*that much* required
> major effort. 
Yes, and I remember who did it  Thanks for
the great work!

> This is because you know how you *want* PCH support to
> work where it is "nice and simple(TM)" and
then you have how MS decided
> to implement it. I am not criticising MS on their
decisions, it is just that
> the two are completely different, making it very hard
to get it working
> right on BBv2 as it stands.
Well, MS is the fact of life and we have to deal with it :(

[snip]
> 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.
There's no need to install PCH in the core if we have a
good flexible 
design.

Current BBv2 design has too few places for custom hooks and
Jam's 
rule/action system is braindead.


> Also, it is not possible to support different build
models (e.g. Java/C#
> compile everything in one pass) 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.
Maybe we can setup a Wiki to draft the requirements for the
BBv3? I'm 
willing to take part in BBv3 development.

> 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). This will be easier
to do in Python
> where we are not restricted by the action/rule model
from Jam and
> have a richer *native* set of types.
I completely agree.

-- 
With respect,
             Alex Besogonov (cyberaxelewise.com)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

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_pru
s.blogspot.com
Boost.Build V2: http://boost.org/boost-
build2
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build