On 10/21/07, Pau Garcia i Quiles wrote: > Quoting Alex Neundorf: > > 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.
Exactly, a limitation we should remove in Eclipse. > >> 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: <snip> > >> 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. Which is the right way, of course. > 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: <snip> > 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...). I think this won't work, and if it does... we are bending over backwards to fix something that is not a CMake issue. More below. > > 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. Well, I definitely see the point, and I think it is a much better route than putting the build projects in the source tree... But I still disagree that this route to go... last time I checked it was trivial to create a version control project in Eclipse (very few clicks). For CMake to generate them it would need to be an option, since I might not want Eclipse to handle that. Also, CMake would need to know what type of version control it is and how to generate the project for it... All of this isn't too hard, but it isn't harder creating it manually. > 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. The problem here, Pau, is that CMake exists for a reason that goes beyond the specific needs of one user. I thought long and hard about Mike's comments when I was building the generator, but for a CMake generator to be implemented it has to work in a general way. Otherwise, it is not much use for people in general. People using CMake expect to be able to do out-of-source builds without a single shred of evidence in the source tree. If we were to violate that principal by putting the .project/.cproject files in the source tree, which of course I think is wrong, then still people using CMake expect to be able to have multiple build trees from the same source tree. If you can work around these issues in the CMake code, then fine. But if it is going to limit the use of CMake then maybe it is time to consider submitting a patch to Eclipse... I don't have the time to consider this at the moment, but it is the way to go. Just my other 2 cents, --Miguel _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
