Re: [boost] Boost building with CMake

From: Bill Hoffman (bill.hoffman_at_[hidden])
Date: 2007-05-09 23:58:01

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