Hey Bill,<div><br></div><div>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.</div><div><br></div><div>
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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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 :)</div>
<div><br></div><div>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:</div>
<div><ol><li>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.</li><li>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.</li>
</ol><div>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.</div><br><div class="gmail_quote">On Wed, May 16, 2012 at 8:47 PM, Bill Hoffman <span dir="ltr"><<a href="mailto:bill.hoffman@kitware.com" target="_blank">bill.hoffman@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 5/16/2012 3:49 PM, Robert Dailey wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> involved with CMake will help push Kitware to realize how serious<br>
people are<br>
> taking their products and maybe they'll make a move to "professionalize"<br>
> them.<br>
</blockquote></div>
So, I do take offense to this language.<br>
<br>
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.<br>
<br>
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.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I was using the word "serious" here as more of a verb, not an<br>
adjective. I'm saying that boost considering CMake is an indication<br>
of how people are taking CMake seriously. In other words, popular<br>
communities are depending on CMake (or gathering interest in) which<br>
makes CMake a tool taken more seriously. Understand now?<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I suppose this is enough said, and most likely too much said... :)<span class="HOEnZb"><font color="#888888"><br>
<br>
-Bill</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/<u></u>opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/<u></u>CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/<u></u>listinfo/cmake</a><br>
</div></div></blockquote></div><br></div>