[cmake-developers] cmake issues and KDE

Brad King brad.king at kitware.com
Tue Aug 8 11:31:02 EDT 2006


Bill Hoffman wrote:
> At 10:02 AM 8/8/2006, Andy Cedilnik wrote:
>> Hello,
>>
>> I read through those and here are my comments:
>>
>> ** CMake does not know the concept of subprojects
>>
>> *I think argument he is using is bad, but overall this one would be awesome for developers. Maybe having a way to compartmentalize sections of the code. For example in Slicer3, we have VTK, ITK, KWWidgets, Modules, etc. It would be really cool if we could designate parts as independent modules and not do dependency checking when running special targets. For example:
>>
>> make all/VTK
>> make all/KWWidgets
>>
>> So, make all/Project or something similar would only build that project.
> 
> 
> I think the idea that we have been thinking about, would be :
> 
> cd VTK
> make  // this would only build VTK and lower depends 
> cd VTK/Common  // this would only build vtkCommon and lower 
> 
> but
> make vtkCommon // this would do all the depends.

Yes, it is just a matter of moving check_build_system to be a per-target
thing and implementing a few more details in the way the makefiles are
organized.  I'd love to do this but it may take some time (== money).

>> ** make install does not start an install until compiling finishes
>>
>> *The make install thing is there. Just set the appropriate variable (CMAKE_SKIP_INSTALL_ALL_DEPENDENCY).

I love this one.  Severl users thought it was horrible that cmake did
NOT do this in the past.  Now that it does it that is horrible for other
users :)

>> ** editing CMakeFiles.txt forces an entire rebuild*
>>
>> Not sure about this one. I do know that you can mess-up cmake file so that it will always change something.
> 
> We are sort of stuck with this one, they want local generate back.

We could try some kind of save/load state of CMakeLists.txt file
processing in each directory but it could get messy.  Let's just forget
this one for now.

>> ** make install should not install files that have not changed
>>
>> *I thought we did this, but looks like we do not. Should be really easy to add.
> 
> We did, I think the entry is incorrect.  Alex, can you fix that?

Yes.  It reports that it is installing it but the file is not actually
copied if it has not changed.  Perhaps we should change the message in
the case that the file is unchanged:

-- Installing /usr/include/myproj/myproj_changed.h
-- File /usr/include/myproj/myproj_unchanged.h is unchanged

>> ** The interface to cmake is not user friendly enough
>>
>> *Brad and I talked about this one and it would not be hard to implement. Especially with some of the new command argument parsing feature. I may look at this one once I convert command line argument parsing of CMake.
> 
> A better command line interface would be good, the -D stuff is awkward at best.

Yes.

>> Anyway, good comments. Don't like the unsercmake idea... Whatever it does, we should do on the CMake level.
> 
> The post-processing is horrible, and we need to address the issues so the post processing
> is stopped.

I think Thomas's time would have been better spent patching CMake than
writing this script, but we'll get subprojects working eventually.

-Brad




More information about the cmake-developers mailing list