Hello Bill, On Wed, 09 May 2007 09:05:30 -0400 Bill Hoffman <bill.hoffman@kitware.com> wrote:
Hi,
I noticed the "boost development process / scope" thread on your list. A CMake user posted a link to your discussion. There is significant interest in the CMake community to help boost transition to CMake. Several people on the CMake list have volunteered to help, and Kitware is willing to put about 2 man weeks of effort into the conversion. I think that CMake has all the features to do what you need at this point, but if any bugs or issues are discovered during the process, we can fix them and/or provide work-arounds for the issues.
I don't ever mean to look a gift-horse in the mouth so to speak, but I have reservations. Reservations that come from experience - we use VTK & ITK here, and many have inherited the CMake legacy into their own projects. I observe many just copy & paste slabs from CMakeLists.txt files, not really understanding what they are doing and getting it to work with trial & error. The recent backend changes to CMake posed a severe problem for some projects here, and the transition did not prove easy, with limited support on the web. Furthermore, in my experience I've found CMake to be overly complex. I've used & written build tools myself - multi-platform, using standard "standard" make, that are imminently more maintainable (, of course, it never did create vcproj files, but all our builds are done on the commandline - our windows users just use nmake instead with the build system, though admittedly windows users who liked the VC debugger were out of luck). Part of the problem with CMake I've found is that it allows you to build multiple executables in the one directory - this means having to specifically list dependencies, and with many executables for the one build file, it becomes a nightmare to maintain the primary CMake makefile. It doesn't encourage a clean separation of dependencies. If it didn't have this feature, it would be far simpler a tool. In short, CMake I have found tries to do too much, and as consequence (while it achieves its aims), obfuscates. With CMake you get multi-platform, but you also buy complexity - which shouldn't be part of the equation IMO.
I realize you have not yet decided on moving to CMake, but I thought I would put out this offer so that you could consider "free" support as one of the benefits you will receive from the port to CMake.
What does "free" mean here? Aide Boost in the transition to CMake, and after that we'd need to purchase the CMake manual - or log into some web forum on the kitware site to have our questions answered? The online information is at best useful for beginners, and the manual honestly doesn't fare much better.
I can see this happening in two ways. One would be for a CMake developer to create initial cmake files for boost, and get the basics working. Then, the work would be turned over to the Boost community. The other way would be to have a boost developer create the build files with help and support from the CMake community. Either way works for me. Of course, no one will want to do anything unless there is a commitment to actually use CMake.
I will stay on this list while you decide, and answer any questions about CMake that may come up.
Thanks, and I look forward to working with the boost community in the future.
I hope whatever way the wind blows, that if CMake is adopted by the Boost community, that my experiences and reservations will count amont the minority - ultimately we all want the best tools for Boost. This being said, I'd like to see BBv2 given a chance too. I sincerely apologize if I have come across as too negative, that's not the intention - it's more so perceptions bourne out of prior frustrations in using CMake. Cheers, -- Manfred Doudar - Research Engineer National ICT Australia - Canberra Research Lab | www.nicta.com.au Research School of Information Sciences and Engineering (RSISE) The Australian National University - Canberra, ACT 0200 AUSTRALIA