[sldev] [VWR] Switch to cmake?

[Bill Hoffman]

Paul Oppenheim (Poppy) wrote:
> Phoenix wrote:
>> I believe there is a fair amount of support for cmake here at linden 
>> primarily because it would simplify adding files/libraries and 
>> simplify the changes necessary during a source export.
> 
> I admit to being somewhat of a rabble rouser.
> 
>> If someone has cmake proficiency and can make a project definition 
>> which builds linux and makes project files for xcode and dev studio, I 
>> would take responsibility for putting it into the release trunk.
> 
> This is on my Someday Maybe list, but is suddenly more relevant.
> 
>> On 2007-10-11, at 23:19, Callum Lerwick wrote:
>>> This came up at the meeting, but I haven't seen any threads for it.
>>> There was talk of switching from scons to cmake. Personally I'm for
>>> it. :) The advantages would be all platforms can share the same build
>>> system, yet people can continue using MSVC and XCode the way they're
>>> used to.
> 
> So, kind of.
> 
> NOTE: my last experience with CMake is from 2004. Feel free to flame me 
> if what I am saying is either not true anymore, or false from the get-go.
> 
> UNIX Workflow:
> 1. write cmake file
> 2. build cmake file into makefile
> 3. make
> 4. debug / test / etc
> 5. change cmake file
> 6. goto 2
> 

Actually, you don't have to go to 2 here at all.  If you change a cmake 
file, the makefile will re-run cmake automatically for you.

> seems a lot like automake, so cool there.
> 
> XCode / MSVS / other IDE Workflow:
> 1. write cmake file
> 2. build cmake file into IDE project file
> 3. open project, build
> 3. make
> 4. debug / test / etc
> 5. change cmake file   <--- PROBLEM
> 6. goto 2
> 

Same thing goes here.  However, there are issues with VS not working 
perfectly when the files changes out from under it.  It will reload the 
files, and this works "most" of the time.  I think Xcode handles the 
reload better.  However, cmake does put rules in the ide to re-run 
itself when cmake input files change.


> Why is step 5 a problem? Because no IDE-using coder is going to want to 
> have to go through this mess EVERY time they want to make a change to 
> the project file.
> 
> This could be less of a problem because the gain from cross-platform 
> consistency is high. However, we don't seem to suck TOO bad at that now 
> (hopefully!). This also may not be a problem if good plugins have been 
> written for the corresponding IDEs that change the cmake file whenever 
> you change the project.

I don't think there are any plugins that move the changes from the IDE 
into the cmake files.  If you want to change the build, you have to 
change the cmake files by hand.  In practice, the build/debug cycle is 
not heavy on adding files to the build, or changing compile flags.  It 
is mostly working on one or more source files, and doing lots of 
edit/compile/run/debug sort of stuff.
> 
> That's where I'm at with it. Does anyone know if the workflow is less of 
> an intrusion for IDE developers these days than it has been? It's gonna 
> be a *real* hard sell unless that's not how I wrote it.

I can only say it works well at Kitware.  There are plenty of IDE users, 
and they have few problems with the work flow.


-Bill