[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-core-dev] RE: [cdt-dev] First gotchawith add/excludechildren of FFS
|
OK, let's start by meeting at the CDT lunch table on Wednesday.
Thanks - Ken
> From: ext Szymon Brandys <Szymon.Brandys@xxxxxxxxxx>
> Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
> Date: Fri, 14 Mar 2008 17:19:00 +0100
> To: <cdt-dev@xxxxxxxxxxx>
> Subject: Fw: [platform-core-dev] RE: [cdt-dev] First gotchawith
> add/excludechildren of FFS
>
>
> We can use both BOF and lunch time on Wednesday for the discussion. I would
> prefer
> to make it earlier. 9 pm is quite late for clear thinking ;-)
> --
> Szymon Brandys
>
>
>
>
> "Schaefer, Doug"
> <Doug.Schaefer@wi
> ndriver.com> To
> Sent by: "Eclipse Platform Core component
> platform-core-dev developers list."
> -bounces@eclipse. <platform-core-dev@xxxxxxxxxxx>,
> org "CDT General developers list."
> <cdt-dev@xxxxxxxxxxx>
> cc
> 2008-03-13 18:06
> Subject
> FW: [platform-core-dev] RE:
> Please respond to [cdt-dev] First gotchawith
> "Eclipse Platform add/excludechildren of FFS
> Core component
> developers list."
> <platform-core-de
> v@xxxxxxxxxxx>
>
>
>
>
>
>
> Well I'll be there and I want to talk about flexible file systems. Szymon
> can you make this time?
>
> We can also use lunch times, I guess.
>
> Doug.
>
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Chris Recoskie
> Sent: Thursday, March 13, 2008 12:55 PM
> To: CDT General developers list.
> Subject: RE: [platform-core-dev] RE: [cdt-dev] First gotchawith
> add/excludechildren of FFS
>
> I guess it depends?
>
> We really have no idea who is showing up to the BOF or what they want to
> talk about. Do we know if Szymon can make that time?
>
> ===========================
>
> Chris Recoskie
> Team Lead, IBM CDT Team
> IBM Toronto
> http://www.eclipse.org/cdt
>
>
>
>
> "Schaefer, Doug"
> <Doug.Schaefer@wi
> ndriver.com> To
> Sent by: "CDT General developers list."
> cdt-dev-bounces@e <cdt-dev@xxxxxxxxxxx>
> clipse.org cc
>
> Subject
> 03/13/2008 12:50 RE: [platform-core-dev] RE:
> PM [cdt-dev] First gotcha with
> add/excludechildren of FFS
>
> Please respond to
> "CDT General
> developers list."
> <cdt-dev@eclipse.
> org>
>
>
>
>
>
>
> Did we just want to do this at the CDT BOF? I don't see much room in the
> schedule. The CDT BOF is 8:45 on Wed. Thoughts?
>
> Doug
>
> -----Original Message-----
> From: platform-core-dev-bounces@xxxxxxxxxxx
> [mailto:platform-core-dev-bounces@xxxxxxxxxxx] On Behalf Of Chris Recoskie
> Sent: Wednesday, March 12, 2008 9:41 AM
> To: CDT General developers list.
> Cc: platform-core-dev@xxxxxxxxxxx
> Subject: [platform-core-dev] RE: [cdt-dev] First gotcha with
> add/excludechildren of FFS
>
> Please count me in for such a meeting.
>
> ===========================
>
> Chris Recoskie
> Team Lead, IBM CDT Team
> IBM Toronto
> http://www.eclipse.org/cdt
>
>
>
>
> "Schaefer, Doug"
> <Doug.Schaefer@wi
> ndriver.com> To
> Sent by: "CDT General developers list."
> cdt-dev-bounces@e <cdt-dev@xxxxxxxxxxx>,
> clipse.org <platform-core-dev@xxxxxxxxxxx>
> cc
>
> 03/10/2008 10:27 Subject
> AM RE: [cdt-dev] First gotcha with
> add/exclude children of FFS
>
> Please respond to
> "CDT General
> developers list."
> <cdt-dev@eclipse.
> org>
>
>
>
>
>
>
> 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.
>
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Ken Ryall
> Sent: Saturday, March 08, 2008 5:08 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] First gotcha with add/exclude children of FFS
>
> 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] 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
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
> _______________________________________________
> platform-core-dev mailing list
> platform-core-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-core-dev
> _______________________________________________
> 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
> _______________________________________________
> platform-core-dev mailing list
> platform-core-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-core-dev
>
>
> _______________________________________________
> platform-core-dev mailing list
> platform-core-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-core-dev
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
