From: Manfred Doudar (manfred.doudar_at_[hidden])
Date: 2007-05-09 20:10:42
On Wed, 09 May 2007 09:05:30 -0400
Bill Hoffman <bill.hoffman_at_[hidden]> wrote:
> 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
I don't ever mean to look a gift-horse in the mouth so to speak, but I
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.
-- 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk