Doug,
Can we get together at EclipseCon to discuss this issue specifically?
Do you know the right platform people to invite to the meeting? We
really need to piece together a plan.
I’m sure you have enough to do so if you can tell me who to recruit I
can help organize the meeting.
Thanks - Ken
------------------------------------------------------------------------
*From: *"ext Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx>
*Reply-To: *"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
*Date: *Wed, 20 Feb 2008 18:44:57 -0800
*To: *"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
*Subject: *RE: [cdt-dev] First gotcha with add/exclude children of FFS
So, you know. The more I think about what you guys are saying, I'm
realizing that the EFS solution probably is the right one. The
objective should be to turn the IResource tree into a logical project
view and to remove all notions that it represents physical file
layout. That unfortunately starts with the .project and .cproject
files, but I think there are tricks we can do there. The .settings may
be harder but let me sleep on that.
At any rate, this has piqued my interest again and I'll work on
reviving it and see where it goes. I'll try to get a prototype working
by EclipseCon so we can talk about it more concretely.
Cheers,
Doug
------------------------------------------------------------------------
*From:* cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx]
<mailto:cdt-dev-bounces@xxxxxxxxxxx%5D> *On Behalf Of *Brunauer, Walter
*Sent:* Monday, February 18, 2008 8:53 AM
*To:* CDT General developers list.
*Subject:* RE: [cdt-dev] First gotcha with add/exclude children of FFS
Hi Warren,
well, the confusion my origin from the different meanings of what
project setup is: for me, project setup is not equal to build setup.
I.e., on our projects, the build setup is an independent step from the
project setup. We intentionally separated this to overcome all kind of
issues you obviously experienced as well. And this is how we see it:
1. Create a project at the desired location (everything beneath this
root location is part of the project, but it can be an empty project
just as well with linked resources added to it later). By default, the
build setup is identical to the project content (there is one build
target, linking/archiving everything together).
2. If (a) specific build setup(s) are needed, it is possible to
specify as many build targets with arbitrary contents as desired. This
approach separates the physical file system layout from logical build
layouts, and it even works beyond project boundaries. IOW, no matter
from where source files are pulled in (the same projects, nested
projects, outer projects, sibling projects), one is able to specify
any build setup exactly are needed, as long as all source files are
known to Eclipse (as resources).
HTH,
Walter
------------------------------------------------------------------------
*From:* cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx]
<mailto:cdt-dev-bounces@xxxxxxxxxxx%5D> *On Behalf Of
*Warren.Paul@xxxxxxxxx
*Sent:* Freitag, 15. Februar 2008 14:51
*To:* cdt-dev@xxxxxxxxxxx
*Subject:* RE: [cdt-dev] First gotcha with add/exclude children of FFS
Hi Walter,
I forgot all about the absolute paths issue with linked resources.
I'll update the wiki.
I'm a bit confused about your comment about this not being a
project setup issue. We have our own builder as well, and it will
happily build whatever the build description says, whether those
files are under the project root or not. We even have our own
project explorer view which shows a logical representation of the
project rather than the physical file system layout. But we still
run into a lot of issues when files are not under the project root
- that is, when you can't get an IFile for them.
We have a wide range of user types from small application
developers to large system developers. In many cases, a users code
base consists of hundreds of directories with thousands of source
files. In such a source base, there are many hundreds of build
artifacts and almost as many "logical projects". It is a huge
problem for these users to be able to create projects currently.
They will typically have a few projects going at a time, but many
times the natural project root for all of them will be the same.
We've found ways to work around some of the other issues, but not
this one. It sounds like perhaps you guys have found a way. Could
you elaborate on how you setup your projects?
Thanks,
Warren
------------------------------------------------------------------------
*From:* cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx]
<mailto:cdt-dev-bounces@xxxxxxxxxxx%5D> *On Behalf Of *ext
Brunauer, Walter
*Sent:* Friday, February 15, 2008 1:56 AM
*To:* CDT General developers list.
*Subject:* RE: [cdt-dev] First gotcha with add/exclude children of FFS
Hi Warren,
FWIW, you did not mention anything about linked resources and
absolute paths these persist in the .project file by default.
Again a big issue around linked resources in combination with
sharing project within a team (even without team support), and one
more reason why they appear to be so cumbersome to handle. To me
it seems many times one has to unsell linked resources to users:
Whereas linked resources are (kind of!) nice for evaluation
purposes (because, yes, in this case you might not want to pollute
your sources), as soon as you start serious development, you run
into all kind of troubles. The hurdle to get everything right from
the beginning is overwhelming for novices (e.g. its not possible
to change a linked resource to use a variable later). Sorry, I
don't know how to add this to the Wiki page...
Having said that, the scenario you describe is really about having
the flexibility around build and indexer setup, not around project
setup, IMO.
It's rather classic: users have common code they want to reuse in
multiple applications - so they create one or a set of libraries
out of it, within one or a set of projects. Of course, indexing
should be able to handle only code going into these libraries, and
optionally ignore the rest. Then, they create their application
projects, which use the binary artifacts of the library
project(s). Now it would be great if they would have automatic
support for application linkage specification, i.e. some nice
wizard or UI allowing to select the library binaries of other
projects to be linked in, without the need to specify it manually
in the linker options. And probably also desired: during
application code development, the public API's of all used library
projects should be the only thing they see WRT code completion,
etc. I guess, some UI would be needed for this as well.
And now think of all developers in the world. Wouldn't it be great
to give as many of them the freedom to choose how to achieve this?
Either everything in one project, or one project per build
artifact, or one project per module/application/product, or with
nested projects... its possible. Our commercial IDE based on CDT
supports all this, and we did not have to provide some EFS or work
with linked resources. Well, we had to override the build system,
and this is IMO the place to solve this in CDT as well.
Again, I don't see anything specific to project setup. The issue
around having the source tree polluted with project files - I
don't think this is the big thing. I would not leave the Eclipse
path in this area at all and allow to separate the project file
from the project location. Its a very general paradigm of Eclipse,
and I am pretty sure doing everything differently will generate
lots and lots of problems in all kind of areas (probably much more
than you already identified), unless you make it a new Eclipse way
(add/change this in the platform, not in CDT, that is).
Just my 2 or 3 cents again,
Walter
------------------------------------------------------------------------
*From:* cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx]
<mailto:cdt-dev-bounces@xxxxxxxxxxx%5D> *On Behalf Of
*Warren.Paul@xxxxxxxxx
*Sent:* Donnerstag, 14. Februar 2008 23:35
*To:* cdt-dev@xxxxxxxxxxx
*Subject:* RE: [cdt-dev] First gotcha with add/exclude
children of FFS
I've updated the Wiki page
http://wiki.eclipse.org/CDT:Flexible_Project_Structure with
some more thoughts on the issue. It would be great to get
feedback from other CDT users - both those shipping C/C++
IDE's and end users. You'll see that I'm not convinced that
the linked resources route is a viable option. Maybe we can
get the platform team involved in the discussion to help find
the best route forward.
Thanks,
Warren
------------------------------------------------------------------------
*From:* cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx]
<mailto:cdt-dev-bounces@xxxxxxxxxxx%5D> *On Behalf Of *ext
Schaefer, Doug
*Sent:* Friday, January 25, 2008 11:15 AM
*To:* CDT General developers list.
*Subject:* RE: [cdt-dev] First gotcha with add/exclude
children of FFS
I guess what my investigation has shown me that the EFS
solution and linked resources are pretty much identical. I
really noticed this when trying to figure out how to persist
the adds and found myself wishing I could add that to the
.project file just like linked resource are. And they are....
I think all the issues that we have with linked resources
would be equally as bad with the EFS solution, possibly worse
because the EFS adds are hidden. The CVS one is a great
example. I really doubt CVS would work with the EFS solution
either. And I don't want us to think EFS would be better since
it's not in the platform where we'll have a battle getting
changes. Any platform changes required to make linked resource
work correctly would also need to be done for EFS.
So my hope is to save the effort at implementing the
add/remove functionality since I believe that's already there
with linked/hidden resources. We can then focus on making
linked resources work where we need them and improving the
workflows. But this really needs to start now.
So, Warren, you've somewhat started a list of workflows that
we'd like to support with this solution. This is a great place
to start. I've created a Wiki page to start capturing these.
Please feel free to add more information, especially to the
workflow section. When we have that we may get a better idea
of which of the two solutions will work best.
http://wiki.eclipse.org/CDT:Flexible_Project_Structure
Thanks,
Doug
------------------------------------------------------------------------
*From:* cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx]
<mailto:cdt-dev-bounces@xxxxxxxxxxx%5D> *On Behalf Of
*Warren.Paul@xxxxxxxxx
*Sent:* Friday, January 25, 2008 11:22 AM
*To:* cdt-dev@xxxxxxxxxxx
*Subject:* RE: [cdt-dev] First gotcha with add/exclude
children of FFS
We've been working on Eclipse/CDT based products for about
three years now. I'm sorry to say that the project model is
still not satisfactory for our purposes. We've tried many
angles, but are still stuck with some pretty serious
limitations. I've volunteered to investigate the EFS route to
see if it will help at all. Based on this thread I'm assuming
it won't.
Let me give you a brief overview of how our users work, and
then discuss the problem we've run into. I don't think any of
this is specific to our users BTW.
Most of our users have existing code bases. They simply want
to "import" it into the IDE. Others will create new projects
from our templates. The new projects are created in the
workspace. Imported projects could be anywhere in the file
system. Often times they will import several projects from the
same source tree. This is where our biggest problem is. Let's
say the source base looks like this:
C:\MyProjects\Project1\...
C:\MyProjects\Project2\...
C:\MyProjects\Common\...
Because both projects share code in the Common directory, the
logical root project directory for both Project1 and Project 2
is C:\MyProjects\. But in Eclipse you can't have two projects
with the same root. This is where the .project and .cproject
files are created. So currently our users would import
Project1 with the natural root (C:\MyProjects\), but Project2
has to be rooted at C:\MyProjects\Project2\. This means that
any source/headers from the common directory are not under
Project2. This means those files are not in the project
explorer for that project, are not indexed, etc.. We logged
this against the platform -
https://bugs.eclipse.org/bugs/show_bug.cgi?id=78438. Basically
if you put the .project file anywhere, but have a project root
attribute, this would cease to be a problem.
Our first product actually always created the .project in the
workspace, and for imported projects, would create links to
files and folders. We ran into so many issues with this that
we had to change the model. I don't recall all of the issues,
but here's a list of some:
- Version control simply didn't work at all
- You can't make file system changes with links. For example,
if you want to rename a file or folder, or move a file around,
you can't do this with linked resources. It only changes the
link itself, not the underlying resource.
- Creating new resources in a project with links is confusing
at best. Let's say you have a project with a linked folder and
file at the root. If you create a new file or folder at the
root, it is created in the workspace, not where the other
folder/file are in the file system. But if you create a new
file under the linked folder, it gets created where you'd expect.
- The location of the .project/.cproject files are
problematic. Some users will want to keep these in version
control, while others won't. Those that do want them created
in the source tree, but those that don't want them elsewhere,
like the workspace. I forget now why this was a problem with
linked resources, but there was something weird going on there.
I suppose it's worth noting that the last time we really
looked at this was in Eclipse 3.2, so some of this may have
been fixed by now. But I doubt it. In general linked resources
are second class citizens. Some IResource API's just don't
work for linked resources. Just search for references to
IResource#isLinked for "special handling". I suspect that
we'll run into similar issues with EFS though - see
getLocation vs getLocationURI.
We also have the same issue that Doug is trying to address
(hiding some branches in a source tree). This is much less of
an issue for us though. You can already reduce the scope of
the indexer and the build. The only real issue for us is for a
very large source tree, you're going to get IResource's for
everything, which slows things down quite a bit. There is
actually somewhat of a problem in reducing the indexer scope -
see https://bugs.eclipse.org/bugs/show_bug.cgi?id=178159.
The hidden attribute addition sounds promising for hiding
resources under the project root, but doesn't really do
anything to add flexibility to the contents of a project. EFS
sounds like it would though. What I mean by that is, having
resources under a project that are real resources, not linked,
but that don't live under the project root in the file system.
I've just started looking into EFS, so maybe it's a bit of
wishful thinking at this point, but I'm hoping we could create
a project anywhere, and when we create it we pass the URI
location from our own EFS. Then when asked for the children,
we could return URI's for files from anywhere in the file
system, or on other machines even. This would seem to hold the
potential for working around the issues listed above. We'd
basically have an EFS map from what we want under a project to
the actual file system.
So hopefully some of the experts can chime in here. Is my hope
for EFS unrealistic? Is there a different approach we should
look at?
Thanks,
Warren
------------------------------------------------------------------------
*From:* cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx]
<mailto:cdt-dev-bounces@xxxxxxxxxxx%5D> *On Behalf Of *ext
Brunauer, Walter
*Sent:* Friday, January 25, 2008 1:47 AM
*To:* CDT General developers list.
*Subject:* RE: [cdt-dev] First gotcha with add/exclude
children of FFS
Hi,
after reading this rather long thread, I'll decided to throw
in my personal opinion.
I consider this approach to work against one of the most
general Eclipse platform paradigms, where a project is defined
to be a root directory and everything in it. IMO, the more
workarounds are introduced against this paradigm, the more
problems will be faced, and the more incompatibilities (or at
least unawarenesses) created.
Isn't the whole problem you try to solve here rather about
what files should go into the build (and probably into the
indexer) than what files are part of a project? I understand
that CDT has no separation of what a project and what the
build input is (well, IIRC one can exclude specific files from
the build, but in general, the project content defines the
build input, right?).
In our commercial IDE, we separated this. This not only
introduced much more powerful build setup capabilities in
general, but especially enabled users to setup build artifacts
with arbitrary contents (think of sources being compilable
with different compiler flags for different build artifacts,
build input exclusion patterns, build input from all over the
workspace, multiple build artifacts within the same project,
reusable build artifacts accross project boundaries, etc.,
etc., etc.). BTW, we call this build system flexible managed
build - because that's what it is:-)
Of course, one can setup CDT projects as of today to exactly
contain what is desired (with the help of linked resources).
However, I find linked resources to be cumbersome and error
prone, though many of our customers start out with them during
evaluation as well, mostly because they are looking for a way
to achieve what they did in the past with other non-Eclipse
based IDEs, but sooner or later I know of lots of them
realizing its much easier to use the features of our flexible
build system instead, especially if projects need to be shared
in a team. And now think of virtual file systems, the
potential complexity of these, hidden assumptions,
restrictions, etc. Sounds worse than linked resources to me.
I guess, the point I am trying to make is: whatever you decide
to do, make it understandable and transparent (and of course
as simple as possible to use) for the user.
As said, just my 2 cents,
Walter
------------------------------------------------------------------------
*From:* cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx]
<mailto:cdt-dev-bounces@xxxxxxxxxxx%5D> *On Behalf Of
*Schaefer, Doug
*Sent:* Donnerstag, 24. Jänner 2008 23:17
*To:* CDT General developers list.
*Subject:* RE: [cdt-dev] First gotcha with add/exclude
children of FFS
Jogging through the code, it really looks like the HIDDEN
feature is what I was looking for. What I haven't found
yet is UI to make a resource hidden or a navigator filter
to show hidden resources (in case you want to bring them
back). Is this planned?
Assuming we have the core features available to link in
and hide resource, I think we still have workflow issues
that need to be addressed. I like Ken's idea of a file
that controls the linking/hiding. We could have an
import/export mechanism for setting up projects based on
this file. A nice wizard for creating the file would also
be good, similar to the way the way the export file system
wizard works.
Given this, we may be further along than we thought (BTW,
the hidden stuff seems to have been added in 3.4 M4).
Cheers,
Doug
------------------------------------------------------------------------
*From:* cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx]
<mailto:cdt-dev-bounces@xxxxxxxxxxx%5D> *On Behalf Of
*Schaefer, Doug
*Sent:* Thursday, January 24, 2008 2:51 PM
*To:* CDT General developers list.
*Subject:* RE: [cdt-dev] First gotcha with add/exclude
children of FFS
Thanks Michael/Szymon,
Is there a bug describing the isHidden feature?
Doug
------------------------------------------------------------------------
*From:* cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx]
<mailto:cdt-dev-bounces@xxxxxxxxxxx%5D> *On Behalf Of
*Michael Valenta
*Sent:* Thursday, January 24, 2008 11:37 AM
*To:* cdt-dev@xxxxxxxxxxx
*Subject:* RE: [cdt-dev] First gotcha with add/exclude
children of FFS
Doug et al,
Szymon is really the person you want to bug on this but
I'll throw in my 2 cents ;-) First, I have to say that a
solution at the IResource level (e.g. using linked
resources and the new hidden folder support) is infinitely
better from a repository provider perspective than an EFS
based solution. You may not get all the Team support you
want at the IResource level but a solution at the EFS
level would certainly break the existing CVS client since
the CVS client isn't EFS aware to any great extent. For
instance, if you tried to hide a folder using EFS, the CVS
client would probably try and recreate it the next time
you performed a Team>Update. It is also important to note
that the Platform does not provide all the hooks required
by repository providers and I know of at least one
provider that has resorted to using it's own EFS
implementation under projects that are mapped to that
provider to get the capabilities it requires. I think it
is important that tooling in Eclipse stick to using the
IResource layer as the layer they operate on and let the
repository provider (or any other tooling whose
responsibility it is to manage the available files)
control the underlying file system. If there are
shortcomings or enhancements required then you should push
to get them in at the IResource level.
As for the current state of Team support for linked
resources, I think the best approach is to enumerate some
specific scenarios of how you see linked resources and
exclusions working with descriptions of what you need to
do today to get Team support and what you would like to
see. It is also important to know if you expect all the
links to come from the same repository (or at least
repository type) or whether a project could contain
content from different repository types (obviously the
later would be more difficult to accommodate than the
former).
Hope this helps,
Michael
------------------------------------------------------------------------
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
------------------------------------------------------------------------
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
