[CMake] Secret precompiled header support?

[Andreas Mohr]

Hi,

On Tue, May 15, 2012 at 12:00:09PM -0400, cmake-request at cmake.org wrote:
> Date: Tue, 15 May 2012 10:53:45 -0500
> From: Robert Dailey <rcdailey.lists at gmail.com>
> Subject: Re: [CMake] Secret precompiled header support?
> To: Dave Abrahams <dave at boostpro.com>

> > > Is the current implementation really satisfactory?
> >
> > For me, no.  I'm trying to make a transition to CMake in a community
> > where this is being seen as a problematic limitation.
> 
> 
> I actually was reading over the boost modularization discussion, but I
> didn't spend enough time there to understand what this whole process is
> for. I'm assuming this is being setup so users can download pieces of boost
> individually and only use the parts they want. I'm glad that Boost is
> making a real effort to use CMake. I think such an influential community
> being involved with CMake will help push Kitware to realize how serious
> people are taking their products and maybe they'll make a move to
> "professionalize" them. By that I mean, CMake is a great tool but very
> inconsistent and somewhat messy and obscure in a lot of areas. Major work
> needs to be done here to polish everything and make it feel organized and
> professional. You can claim "portability" all day but you have to do it
> right. Right now I feel CMake is 60% there. I say that because that 40% I
> had to implement via CMake scripts over the course of several months,
> resulting in a couple thousand lines of CMake code (to handle transitive
> include dependencies, compiler-agnostic features such as PCH and warning
> levels, private/public include directories, and other things).

While a 60% estimation may sound a bit harsh, I have to admit that
my own rating wouldn't be too far off either, given that only
the *current* stable version can be stated to be relatively "up to speed"
with shockingly mundane build (and more painfully, packaging) requirements.

Especially the haphazard way of variable-style configuration needs to
be reduced, in favour of more flexible property-style / helper function
APIs configuration spaces (the CMAKE_MFC_FLAG variable
or the - now improved - include_directories() thingy
would be particularly striking examples here).

OTOH implementing such a universal and flexible build system certainly
is no small feat, and every single soul out there should ask her/himself
which kind of all the critical "fringe" upstream work
(fixing exotic Find modules, etc.) they THEMSELVES failed to do recently.
Myself I certainly know of some parts where I have some upstream work
remaining to be done...
Not to mention that I'm sure that Kitware would love to be paid fairly
for certain peripheral (perhaps less so) areas to be implemented.

I also have a large number of rather "clever" (NOT! all this mostly shouldn't be
necessary given an "ideal" - whatever that means - build environment)
scripting parts to get everything packaged up the way God meant it to be.

One major part that I'm missing is some *builtin* dos2unix/unix2dos flags
of the file(COPY ...) commands (and perhaps configure_file()), BTW.
Currently all this is emulated manually in a very painful way,
whereas many major SCM tools have quite flexible d2u handling builtin...


</rant>
(had to put this tag here for my admittedly less specific reply)


BTW, I currently have an updated version of the "community-maintained"
(see related tracker item) PCH support Module within my vcproj2cmake repo
(since there are very obvious usage synergies), and I plan to keep it current.
Of course I'm fully aware that you'd like to see improved CMake-builtin
support instead...

Andreas Mohr