[CMake] Patch for Eclipse generator

[Pau Garcia i Quiles]

Quoting a.neundorf-work at gmx.net:

> Hi,
>
> On Sunday 21 October 2007 00:48, you wrote:
> ...
>> > Just to make sure I understand:
>> > with this patch the two eclipse project files are always created in
>> > the source tree, right ?
>>
>> Right.
>>
>> > What happens if you try to create two buildtrees for one source tree,
>> > which problems may appear ?
>>
>> With my current patch, it's not possible due to Eclipse limitations.
>>
>> The only way I can think to fix this is to create soft links to the
>> files and folders in the source tree, then create the .project and
>> .cproject in that folder. It'd be something like this:
>>
>> myhelloapp/CMakeLists.txt
>> myhelloapp/src/CMakeLists.txt
>> myhelloapp/src/hello.cpp
>> myhelloapp-build/.project
>> myhelloapp-build/.cproject
>> myhelloapp-build/src -> myhelloapp/src/hello.cpp
>> myhelloapp-build2/.project
>> myhelloapp-build2/.cproject
>> myhelloapp-build2/src -> myhelloapp/src/hello.cpp
>>
>> where "->" means that's a symlink.
>>
>> This would probably work fine on Unix platforms and probably Windows
>> 2000 and 2003 (using linkd for the symlinks). I'd have to test this,
>> though.
>
> I.e. creating a symlink for each source file and each folder ?
> Hmm, creating potentially thousands of symlinks doesn't sound too good.

Yes. I agree it does not sound too good but we would be on-track again  
to the CMake-ish way of doing 100% pure out-of-tree builds.

I have not considered it seriously but I think we may only need to  
create symlinks to the first level of files and folders, not to every  
file and folder inside every folder:

mysourcetree/CMakeLists.txt
mysourcetree/helloworld/CMakeLists.txt
mysourcetree/helloworld/hello.cpp
mysourcetree/cruelworld/CMakeLists.txt
mysourcetree/cruelworld/cruel.txt
mybuildtree/CMakeCache.txt
mybuildtree/CMakefiles
mybuildtree/cmake_install.cmake
mybuildtree/Makefile
mybuildtree/helloworld -> mysourcetree/helloworld
mybuildtree/cruelworld -> mysourcetree/cruelworld
mybuildtree/.svn -> mysourcetree/.svn
mybuildtree/helloworld/.svn -> mysouretree/helloworld/.svn
mybuildtree/cruelworld/.svn -> mysouretree/cruelworld/.svn

then we would run CMake as it were an in-tree build where the source  
files reside in mybuildtree.

However, I'd need to test if creating empty .svn/CVS dirs in  
mysourcetree, then symlinks to them from mybuildtree would work when  
the project is added to Subversion or CVS later from Eclipse. Another  
problem with this is CMake needs to be aware of the source versioning  
tools which are available (Subclipse, CVS integration for Eclipse,  
Bazaar integration for Eclipse...).


> How about that:
>
> If you run cmake in-source, everything should just work.
>
> If you run cmake out-of-source, cmake creates two eclipse projects: one
> project in the source tree, where you can't build anything, but which you
> should import in eclipse to have version control working, and the actual
> project in the build tree, where you build stuff (but don't have version
> control). The in-source version control project only would have to be created
> if it doesn't exist yet.
> What do you think about this ?

That might work but I don't see the point.

Once CMake "rapes" the source tree by writing something to it, what's  
the point in having two projects?

Could you please explain what's the benefit of having two projects,  
one for the source version control and another one for generating the  
files out-of-tree?

Please note with my current patch the built files are built  
out-of-source, so the final result is exactly the same with your  
two-projects approach and with my single-project approach: compiled  
files go out of tree, .svn and CVS folders go in-tree. The only  
difference is with my single-project approach the user does not need  
to switch projects to build the binaries, or to svn update/commit/etc,  
which I think is better.


-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)