[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[platform-core-dev] RE: [cdt-dev] First gotcha with add/exclude children of FFS
|
Title: Re: [cdt-dev] First gotcha with add/exclude children of FFS
Copying the platform-core-dev folks too. Is there someone
from the Platform who could attend a meeting at EclipseCon about flexible file
systems. John A, will you be there? John is Mr. EFS and we can use his
guidance.
Thanks,
Doug.
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.
Im 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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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
