[CMake] Re: Out of source build and KDevelop

[Alexander Neundorf]

Hi Bill,  
 
> Thanks, I tried the patch.  I would like to try and explain the how/why 
> of the global generator thing. 
>  
> WHY: 
>  
> It is cleaner to use the global generator because when the global 
> generator Generate is run, it knows all of the local generators.  So  
> you can remove the stuff that uses a file to talk between local  
> generators.   
 
No, I think you misunderstood this. 
It reads an already existing kdevelop project file or filelist.kdevelop 
file, so that settings the user eventually did in kdevelop to the 
cmake-generated project files don't get lost. 
The same for the filelist-file. It reads the existing one so that files 
the user added manually in kdevelop are not stripped away when cmake runs 
again. 
Slightly hackish but it works. 
 
> More Why: 
>  
> Currently your output for CMake is as follows: 
>  
> /CMake.kdevelop 
> /CMake.kdevelop.filelist 
> /Source/CMake.kdevelop   // this is a repeat of the toplevel one, why?? 
> /Source/CMake.kdevelop.filelist 
> /Source/CTest/Curl/LIBCURL.kdevelop 
> /Source/CTest/Curl/LIBCURL.kdevelop.filelist 
> /Source/CursesDialog/form/CMAKE_FORM.kdevelop 
> /Source/CursesDialog/form/CMAKE_FORM.kdevelop.filelist 
> /Source/kwsys/cmsys.kdevelop 
> /Source/kwsys/cmsys.kdevelop.filelist 
> /Utilities/CMake.kdevelop  // why is there a CMake here? 
> /Utilities/CMake.kdevelop.filelist 
> /Utilities/cmexpat/CMEXPAT.kdevelop 
> /Utilities/cmexpat/CMEXPAT.kdevelop.filelist 
 
This expression is used to decide whether to create a kdevelop project 
file or not: 
 
     switch (ti->second.GetType()) 
      { 
      case cmTarget::EXECUTABLE: 
        executable=ti->first; 
      case cmTarget::STATIC_LIBRARY: 
      case cmTarget::SHARED_LIBRARY: 
      case cmTarget::MODULE_LIBRARY: 
      case cmTarget::UTILITY: 
        containsTargets=true; 
        break; 
      case cmTarget::INSTALL_FILES: 
      case cmTarget::INSTALL_PROGRAMS: 
      default: 
        break; 
 
So I guess in /CMakeLists.txt and in /Utilities/CMakeLists.txt there must 
exist Utility targets. Otherwise no kdevelop project files should have 
been generated there. 
 
> So, there are three CMake project generated for the one CMake project. 
> I think all this would go away, if you switched to the global  
> generator. 
 
I don't think so. At least with the cmake projects I use (the ecos 
stuff), I have a big directory structure with many subprojects and many 
files. For these subprojects I really want to have separate project 
files, otherwise I would always have to build my *whole* tree with 
kdevelop (like 20 times 5 minutes per project) which would make it quite 
useless. 
 
> How: 
> See my previous post.  Basically everything gets moved into the global 
> generator 
> ::Generate method.   It works something like this: 
> 1. create a map<project name, vector<local generators> >   
> 2. for each project name in map 
>    write out a kdevelop project file called project name 
>    for the sources of that project use the targets found in the vector< 
> local generators> 
>    The first entry in the vector will be the cmMakefile for the  
> CMakeList file that contained the PROJECT command being written. 
>  
>  
> All that being said, if you don't have the time to do this, I can do it 
> when I get some free time.    
>  
> I am impressed that you were able to add on to cmake, as there 
> is not much documentation for the source code.    
 
:-) 
 
> I think this will be a good addition to cmake and kdevelop, so I don't 
> want to scare you away with seemingly picky demands. I can check in  
> what you have if you want,  
 
Yes, please :-) 
 
> but before the next release I will want to  change it over to the  
> global generator. 
 
Well, still now that I explained the two issues ? They wouldn't change 
with the global generator. 
  
> One another topic, since you have already done one patch to kdevelop, 
> how hard would it be to add one more.  kdevelop --build CMake.kdevelop, 
> this command line option would start up kdevelop without a display or  
> if that is too hard with a display, and run the build for the project, 
> then exit with the return code from the build, and sending any output  
> from the build to stdout/stderr. 
> That way we can create a dashboad that tests this stuff, and makes sure 
> it keeps working. 
 
Yes, good idea, but slightly more work than my first kdevelop patch and 
in the next weeks I'd like to concentrate on something else. 
I'll talk to the kdevelop developers. 
 
Bye 
Alex 
 

-- 
+++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl