Manfred Doudar wrote:
Reservations that come from experience - we use VTK & ITK here, and many have inherited the CMake legacy into their own projects.
CMake was written for ITK, so ITK has been using CMake for 7 years since the start of ITK. VTK started using it about a year later. So both VTK and ITK suffer from getting around CMake features that were just not there in the start. BTW, CMake can still build very old versions of ITK and VTK, so we really do try for backwards compatibility. However, Boost would be getting a fresh start with a current CMake, and the cmake files should better organized than those of ITK or VTK at the end of the day.
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.
That can happen with any program, and the support I am offering should help in avoiding that problem with Boost.
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.
Sorry to hear you had trouble. Backwards compatibility is difficult, and we try hard, but sometimes miss. CMake went through a bunch of changes for KDE, and in much better shape for adoption by a new project today than it was a year ago. Also, there is still plenty of work to do, and CMake is being actively developed. The docs on the web have most of the information in the book, and all of the commands are documented right from the source code.
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).
CMake lets developers use the tools they are most productive with. Kitware's developers are about half make based and half IDE based. There are VS 7,8, Xcode, Kdevelop, nmake and make developers, and they are all happy with CMake. As with any software, the "source code" can become complicated. However, CMake does not require "complicated", and most of the "complicated" stuff should be hidden in the c++ core of CMake that generates the build files, and not in the users cmake input files.
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.
I am not sure I follow the problem here. What dependencies do you have to list explicitly? The user just writes add_executable a few times, and it just works, there is no extra work to do by the end user.
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.
Many KDE folks would not agree with you, they say that they finally understand the build system as apposed to the one they had before. Here are some quotes: "By the KDE 3 series, there were only a select handful of elite build gurus who could understand the whole of KDE's build system." ... "Projects using CMake take less time to get started, since there is less time spent fighting with the build system. One KDE developer says, "CMake doesn't make you want to shoot yourself with a nailgun when building your project anymore." http://dot.kde.org/1172083974/
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.
For this, I would like to refer to an outside opinion: "When I started to compare my notes from the first CMake-based projects I worked on, it became apparent that the book offers the same information that I also had access to -- it is more structured, and more comfy to consume leaning back with a cup of coffee, but the same basic content." http://www.kdedevelopers.org/node/2736 Documentation is a funny thing, the more you have of it, the less people read it. We could have phone books of the stuff and people would still say it is not documented well enough. I would also say that several non-Kitware CMake users from the CMake list have offered to help as well. And after the transition, I would imagine that I would stay on this list and answer questions when needed.
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.
No problem, you bring up valid points. My obviously biased opinion is that CMake will be good for Boost, as Boost will be good for CMake. :-) If Boost does not choose CMake today, or this year, well CMake will be around next year, and will be even better then. I personally feel that CMake is up to the job today. -Bill