[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [platform-cvs-dev] Partially shared project?
- From: "Eric Noulard" <eric.noulard@xxxxxxxxx>
- Date: Wed, 8 Aug 2007 16:16:08 +0200
- Delivered-to: firstname.lastname@example.org
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Eh/pPbUvmaRzHt1duclr0XTlcIKKV/VUPSaIYW1b1yzHcdPrPAoXzARqYatDF+izMsTxxMn2kpYL/KTbHbWYsmeTRIaBIoz4Va5cwCaRkbi/UhAk+vbNWok+lnMz+ba4Gsx4vumV8Pjy7XKylfIj9ggKgqs/nZ4flkM2TY1avxY=
2007/8/7, Michael Valenta <Michael_Valenta@xxxxxxxxxx>:
> The root of the issue (if you pardon the pun) is whether you consider the project itself part of the source tree or part of the build area. Eclipse was designed with the assumption that the project directory is part of the source tree. This has some advantages in the sense that the contents of the directory (.,project and other settings files) are placed under version control as well. Hence, the senario where your build output is a link directory works very well with repository providers like CVS.
> The scenario you are describing seems to treat the project as the build area and you link in the source. Unfortunately, Eclipse just wasn't designed with this type of scenario in mind.
Ok and that was precisely what I thought when looking at some
documents. You've confirmed that point thank you for this.
> That's not to say that it couldn't support it. The only real restriction on projects is that there is a one-to-one mapping between a project and a repository provider so it would be possible to modify the CVS provider to accomodate this scenario. However, this would be a lot a of work.
I was thinking of making a wrapper repository provider which may rely on
existing providers (CVS, SVN etc...) in order to avoid making the change
to EVERY repository provider.
That was just "a thought" since I am neither an eclipse developer nor
an eclipse-plugin provider.
I do/did develop java code with eclipse JDT and
I am now trying to use eclipse CDT 4 with CMake.
(because my use of CMake is mandatory for a C/C++ cross-platform project)
The project for which I want to use Eclipse CDT are under version control
which is currently either CVS or SVN (git may be coming sooner or later).
> Before I can comment further, I would have to understand why the project folder couldn't be under source control and have the build directory be a link. Is this something that is fundamental to CMake
The "fundamental" idea of CMake out-of-source build is to separate
- the source tree which usually is under version control
- the build tree which is not
Every "generated" files usually goes to the build tree.
Generated files are directly or indirectly generated by CMake.
Since CMake generates the .project and .cproject files the first "natural"
thought was to put those files in the build tree and not in the source tree.
The separation between source and build tree is a very good
(my CMake user point of view though := ))
property since it authorizes to build different "version" of the same software
from just the same source tree.
For example I may have a build tree for Eclipse CDT/Linux/IA32,
another one for a UnixMakefile/Linux/Win32-crosscompile
which just refer to THE SAME source tree.
> or could the CMake Eclipse integration be modified to output the .project etc. into a project directory that was part of the source tree?
Yes definitely it could be modified (even if I am not the developer of
but this would be the "first" singular point regarding CMake generator.
However we may have to add those file to the content of .cvsignore
(which is CVS handled).
This is not such a 'big' deal but I think it may reveal some design issue
regarding how Eclipse Team handles "Project Sharing".
I would say honestly that if it is "a lot of work" to take this into account
it may not be worth doing it for CMake only.
However I may easily think about projects for which some parts may
be under CVS (or SVN or ...) control and some others parts that shouldn't be.
Relying on some .cvsignore kind of mechanisms to handle seems
awkward to me.
Moreover I may (actually I have done it in a near past) want to
take parts of my Eclipse-handled project from different repository providers
(even one from CVS and one from SVN).
I would think that eclipse-team should accept that
each folder may be shared separately.
The default behavior may remain to share all the project using
a unique repository provider but I think it should be possible
to only share a sub-folder of a project without sharing the entire project.
The team menu may be activated if ANY registered repository provider
recognise its "administrative files" (CVS, .svn etc...) in the concerned area
of the project.
I may be wrong but I think eclipse-team simplified a little too much the
relationship between a project and the version control system.
As of my experience there may not be a 1 to 1 relationship between those 2.
Eclipse-team seems to assume that if you have 2 version control system
which defines 2 repository providers then they MUST be linked
to 2 eclipse projects. Then those 2 projects may refers to each other,
but 1 project may not refer to 2 different repository provider.
That's why I was thinking about developing a "aggregate repository provider"
which may handles those case. without breaking the current Eclipse design.
This repository provider would be the single repository provider seen
by the project but it would call the service of each concerned provider
for each subfolder which is shared.
Those are my 2 cents thought on the subject.
I should thank you very much for your explanation/clarification
on the eclipse project point of view regarding sharing.
I will go to CMake eclipse generator developer in order to report your message.
I will keep you informed about the CMake Eclipse CDT project generator status.
If you have time I'll be glad to have your opinion regarding my thought
about project sharing and the feasibility of an aggregate repository provider.