[CMake] Secret precompiled header support?

Thu May 17 12:50:58 EDT 2012

Hey Bill,

First of all apologies if I have offended anyone, my goal wasn't to
disrespect CMake or anyone's efforts they put into it. Perhaps I made a
poor choice of words.

What I was trying to convey with my use of the word "professional" was to
say that there are areas that seem inconsistent or odd to use, and by
making those more consistent it seems more professional. Perhaps instead of
saying professional, I should just say consistent :) Normally when you
encounter "professional" software (that is, software that you pay for, that
is generally well designed and maintained by a single entity), it has a
consistent feel. Open source naturally can feel inconsistent because of the
large number of contributions, which sometimes don't follow the same
implementation patterns. I hope that clarifies what I meant. An example, as
I had stated, is general compiler flag support. For example, we have
convenience methods for includes and preprocessor definitions, but PCH and
warning levels does not have such a thing.

Outside of the mailing list, I am trying to sell the company I'm working
for on using CMake. Every day, all I do is say great things about CMake and
I even mention you and David personally to people I work with and speak
highly of Kitware. So trust me, I really do talk a lot more about the
positives than the negatives. However, it's not as useful to start a post
here on the mailing list about the great things that have already been
done. It's nice to show appreciation but such a discussion isn't as
productive as discussing what to do next or what to improve. After all, I
see the mailing list as a place to get help and to discuss future work.

The discussion has gotten quite off track. I just wanted to let everyone
know that never during the discussion was I upset or intended to come off
as hostile, that's the tricky thing about text. You can't really know what
the person is really feeling or saying :)

On a more relevant and productive note, I'd love to help add new commands
or whatever to help make supporting different compiler features more
compiler-agnostic, but there are a couple of issues:

   1. I am only a Windows developer, so I can only really provide solutions
   targeting MSVC. Such a patch would not be useful as I'd have to handle a
   wide range of compilers such as ARM and GCC.
   2. Creating a new command for every single compiler flag or feature can
   get out of control easily and quickly become unmaintainable and messy to
   use and document. I think this is where the Boost modularization discussion
   becomes useful, because they have outlined in detail some great ideas to
   creating a uniform sort of meta-language to supporting a finite number of
   compiler options without adding bloat to the commands list. If you haven't
   had a chance to look this over, it would make for a great read, especially
   for the more experienced CMake developers like you and David.

It's a tough issue to tackle but at least the majority of people here
recognize improvement is in order. The problem is, it's a tall order.

On Wed, May 16, 2012 at 8:47 PM, Bill Hoffman <bill.hoffman at kitware.com>wrote:

> On 5/16/2012 3:49 PM, Robert Dailey wrote:
>
>>  > 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.
>>
> So, I do take offense to this language.
>
> Kitware does take CMake seriously and we are always "moving" to make it
> better.  However, since it is an open source project, we do not get any
> direct revenue from CMake.  We do of course receive revenue from companies
> and agencies willing to hire us to implement features or develop CMake
> build systems for them.  If your company wants generic pre-compiled header
> support, we would love for you to hire Kitware to implement it.  If you are
> working on an open source project and you would like to contribute pch
> support that would be great as well.
>
> I think the fact that you are able to do what you need to do, even with a
> bit of extra work speaks to the "professionalism" and flexibility of CMake.
>  If you were unable to create a working build system that supported PCH and
> the other features you found missing in CMake, that would be a failure of
> CMake.  If at the moment CMake does not have an elegant way to achieve a
> particular goal, I don't think that makes it an "unprofessional" software
> tool.
>
>
>  I was using the word "serious" here as more of a verb, not an
>> adjective. I'm saying that boost considering CMake is an indication
>> of how people are taking CMake seriously. In other words, popular
>> communities are depending on CMake (or gathering interest in) which
>> makes CMake a tool taken more seriously. Understand now?
>>
>
> Not really...   KDE (one of the world's largest open source projects)
> adopted CMake in 2006, and they have been a great community to work with.
>  We have, when KDE goals have intersected with some of our paying
> customers, been able to implement features for them.  They have also
> contributed a ton of code back to the CMake.  So, I would love to see Boost
> use CMake as a build system.  I would expect the same type of community
> interaction that we have had with KDE.
>
> Over time, I am sure if PCH headers become a big enough issue for someone
> they will be implemented in CMake with a cleaner interface. CMake is far
> from a static project and has plenty of contributors inside and outside of
> Kitware.  Like any software project, there is always more to do.  I can say
> Kitware is committed to shepherding the CMake project and will be
> developing new features and fixing bugs into the foreseeable future.  If
> Boost adopts CMake, I would welcome the contributions that would come from
> that community, and I am sure both projects would be better for it in the
> future.
>
> So, I don't think it is fair to judge the CMake project on what it does
> not do elegantly, but rather to judge it on what it does well.  Which, I
> think is a great deal of very useful cross platform build features allowing
> very large open and closed source projects to build on a variety of
> platforms.
>
> I am not sure exactly what you were trying to achieve with your email, but
> it was somewhat of an insult to at least one CMake developer (myself).  I
> and the rest of the CMake team take pride in what we have achieved, and to
> say that we did not do a professional job, and don't take every user
> seriously is an insult.
>
> If you have suggestions or ideas on how PCHs or any other feature could be
> implemented in CMake, please bring the discussion to the cmake-developers
> list.  Even if it is not implemented right away, if you have the time to
> discuss what that implementation would look like, that would be a welcomed
> contribution.  However, lets try to steer this conversation back to the
> technical issues and away from non-technical issues.
>
> I suppose this is enough said, and most likely too much said...  :)
>
> -Bill
>
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/**
> opensource/opensource.html<http://www.kitware.com/opensource/opensource.html>
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/**CMake_FAQ<http://www.cmake.org/Wiki/CMake_FAQ>
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/**listinfo/cmake<http://www.cmake.org/mailman/listinfo/cmake>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120517/ff6dae15/attachment.htm>