On 8/2/07, Eric Noulard <[EMAIL PROTECTED]> wrote: > 2007/8/2, Alexander Neundorf <[EMAIL PROTECTED]>: > > On Thursday 02 August 2007 05:34, Eric Noulard wrote: > > > Moreover I think in-source built should be supported by the CDT Generator > > > in order to be consistent with other generator. > > > > Yes, in-source builds should work and having Eclipse support that only part > > of
This was an oversight due to the fact that I think it is an *evil* practice to do in-source builds ;) I'll put code around the linked resource creation code and the pathentry to detect if SOURCE_DIR == BINARY_DIR and handle it approapriately. > > Somebody feels like looking into the Eclipse/CDT sources ? > > I may have a look at this. At some point I might look into the source deeper... What I really have been thinking about is to send the cdt-dev list a message trying to sell them cmake. Then with their help/guidance I wouldn't mind contributing to the Eclipse/CDT to enhance the cdt/cmake integration. The reason I think they might be interested is that I've been reading in the docs and archives that they are interested in supporting a copule of things that cmake does already. Among them, 1. integration with the Microsoft tools. Bill mentioned that we can compile with the VS Express (or any VS version) compiler and debug with cygwin gdb, right? Can somebody point me in the direction on how to do this? I seem to recall that it wasn't with the NMake generator, but setting the compiler to VS's cl and using "Unix Makefiles". If that is the case are there more settings needed to provide the correct environment for cl? If I can do this then they would have a shortcut way to provide MS Toolchain support in the cdt, which they allegedly are working on but haven't had the time and resources to complete. 2. cppunit testing support. I'd venture to sell them on ctest and while I'm at it try to promote cpack, the dashboard concept, etc. However, does anyone use cppunit set up with cmake/ctest. What is the basic setup? > Nevertheless I think the issue may not be "only" in Eclipse/CDT > but more in the Eclipse Platform Team, > "http://www.eclipse.org/eclipse/platform-team/";. > > Doc says > (http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/team.htm) > > "A repository provider (RepositoryProvider) is the central class in > the implementation of your repository. This class is responsible for > configuring a project for repository management and providing the > necessary hooks for resource modification. " > > It seems that repository provider is really "project-oriented" > we may be able to write an "aggregate repository provider" which may > implements the feature we (may) need which is having a project > refering to different folders (at least 1 in the current test case) > under possibly different source management system. > > I will have a look and ask questions on eclipse.org concerned > subpart and tell you what I can do. <start rambling> I'm not sure where the problem is, but I'm certainly developing a love/hate relationship with eclipse ;) On the one hand it is a great tool, although a memory hog, that has quite a nice interface and great flexibility. I even used the refactoring "rename" tool to change the enum EclipseToolchainType naming!! I wish C++ was more refactoring friendly, just this one refactoring... On the other hand it seems that the most commonly used things are not supported yet... for example, nested projects and hierarchichal design to allow the source root to be placed anywhere. </start rambling> My current work around to this problem (and this should make it into the wiki page) is to have a CVS project created to check out the source. The location of this project seems to be required to be in the workspace. Then create an out-of-source build using the "Eclipse CDT4" generator, which will have the links to the source as usual. Use the CVS project to manage cvs/team interaction and the out-of-source project for development. You would have: workspace - ~/eclipse | -- CMake - cvs source checkout, ~/eclipse/CMake | -- cmake_bin - out-of-source build in ~/eclipse/cmake_bin that links to ~/eclipse/CMake sources | -- cmake_bin2 - another out-of-source build (debug or other tool set maybe) in ~/eclipse/cmake_bin2 with links to the same source so changes during development will make it to the CMake source dir and the regular commit, update, etc interactions are supported through the CVS project. Note that if you are not interested in using Eclipse CVS to manage the team interaction (e.g., you use the command line cvs or the sources are local) then there is no need for the cvs project above and the sources can be installed anywhere. You'd have the following layout instead: workspace - ~/eclipse | -- cmake_bin - out-of-source build in ~/eclipse/cmake_bin that links to sources | -- cmake_bin2 - another out-of-source build (debug or other tool set maybe) in ~/eclipse/cmake_bin2 with links to the same source Hope this helps, --Miguel _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
