[CMake] [PATCH] kdevelop3 generator, 2nd version

[William A. Hoffman]

I really do not want to write into the source tree.
We have proved that it can work in the binary tree.
What if the source tree is on a cd rom?  There  are
many issues with writing into the source tree, and
I don't think we need to do it.

When you say it does not work now, exactly what does not
work?   The big project works fine, it has all the source
files, and you can build it from kdevelop.  The only missing
part is how to correctly handle the sub-projects.   

Perhaps I am missing something about how you want sub-projects
to work.  Visual studio works like this:

For each target (library, executable, custom) a .vcproj file is created.
For each PROJECT command a .sln file is created with all of the targets
that come in that cmakelist file or in a SUBDIR of that cmakelist file.
(except for EXECLUDE_FROM_ALL SUBDIRS. 

So, for my example you would have something like this:
(assume SubProject is a SUBDIR of TopProject and contains target3)

TopProject.sln
  target1.vcproj
  target2.vcproj
  target3.vcproj

  SubProject.sln
    target3.vcproj

Currently, in the kdevelop stuff we have this:

TopProject.kdevelop
TopProject.kdevelop.filelist  (this has the list of sources from target1,target2,target3)

And, the SubProject is completely broken.

Why can we not have:
TopProject.kdevelop
TopProject.kdevelop.filelist  (this has the list of sources from target1,target2,target3)

  SubProject.kdevelop
     SubProject.kdevelop.filelist (this has the list of sources from target3)


-Bill



>I will have a look at it. 
> 
>> I guess at the end of the day it should do something like this: 
>> TopProject.kdevelop 
>> TopProject.kdevelop.filelist 
>> SubProject/SubProject.kdevelop 
>> SubProject/SubProject.kdevelop.filelist 
> 
>I'd say 
> 
>source/Project.kdevelop.filelist 
>source/Project_sub.kdevelop.filelist 
>build/Project.kdevelop 
>build/sub/Project_sub.kdevelop 
> 
>Otherwise it won't work (see below). 
> 
>> if SubProject was in a SUBDIR(EXCLUDE_FROM_ALL SubProject) 
>> then its files should not be in TopProject.filelist. 
>>  
>> Right now if you use the kdevlop generator on CMake you get these 
>files: 
>>  
>> $ find . -name "*kdev*" 
>> ./CMake.kdevelop 
>> ./CMake.kdevelop.filelist 
>> ./Source/CMake.kdevelop 
>> ./Source/CTest/Curl/CMake.kdevelop 
>> ./Source/CursesDialog/form/CMake.kdevelop 
>> ./Source/kwsys/CMake.kdevelop 
>> ./Utilities/CMake.kdevelop 
>> ./Utilities/cmexpat/CMake.kdevelop 
>>  
>> The top level project is ok, but don't think the others work, 
>> and they have the wrong names. 
> 
>Yes, as it is now in cvs it doesn't work. 
>I tried here with kdevelop 3.0.0 and KDE 3.2.1. 
>KDevelop only shows files with relative paths and these paths may not go 
>upwards (../something/). 
>By giving the project files everywhere the same name all kdevelop 
>projects use the same foo.kdevelop.filelist file, which is not optimal 
>I'd say and more important it doesn't work. 
>So, this will only work if the foo.kdevelop.filelist file is generated in 
>the top source directory (as it did in my patch). 
> 
>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
>
>_______________________________________________
>CMake mailing list
>CMake at www.cmake.org
>http://www.cmake.org/mailman/listinfo/cmake