Re: Putting support for precompiled headers back in

On 10/12/12 12:54, Lubos Lunak wrote:
>  The argument for PCH (MSVC2010 non-debug build):
>
> $ time make xmloff ENABLE_PCH=
> real    4m52.828s
> $ time make xmloff ENABLE_PCH=TRUE
> real    2m9.293s

that looks sufficiently convincing for me :)

>  The arguments against PCH seem to be:

> - conflicts between types/#defines - there are a couple of changes needed to 
> get things built with PCH, but it's not that many. It seems it's mostly UNO 
> vs tools (e.g. Date), and it's quite easy to handle.

the most serious problems in the past (tools types conflicting with
windows.h types, and "using namespace rtl" causing conflicts between
rtl::Reference / css::uno::Reference) should be cleaned up by now anyway.

> - lack of a tinderbox to test it - I intend to switch #6 to use it and see how 
> it works in practice

hopefully we'll get faster tinderbox turnarounds too...

>  All in all, it looks to be worth the litle trouble. Also, I modified the PCH 
> support a bit to make the extra PCH code very non-intrusive (it's just two 
> extra files in inc/pch and one line in the makefile).
>
>  It's considered experimental now, but whoever wants can indeed give it a try 
> too (MSVC or Clang are supported).

great that we have now somebody who wants to maintain this :)

these precompiled_foo.hxx used to be checked in and essentially manually
maintained, and a lot of them were actually empty - do we have some plan
how to automate maintenance of these headers?

one option would be to generated that from the generated object
dependency makefiles... but probably that isn't going to be simple
because of "special" headers that need to be included in particular
order or with particular #define before and #undef after...

another way is to grep through the cxx files... but there the problem is
#ifdefs around #include.

,,, is there some pre-existing tool to generate the PCH input headers?