Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] First gotcha with add/exclude children of FFS

This is just "off the top of my head", so it just an idea...

What if, a CDT project had the concept of source "locations"?  Source
file locations would be relative to the source locations.  Source
locations would be "logical" and could be mapped to physical locations
on a per-user basis. 

The project directory is the obvious and default location.  That
currently works quite well throughout CDT and the platform.

The local file system is another default location.  That currently works
with linked resources (to some extent, at least).  As Chris mentioned,
he made it work with makefile generation and I don't remember having any
problems in CDT with linked resources in my MBS testing.

We also want to support "remote" locations and I think that remote files
should be relative to remote locations.  That is, the location of every
remote file should not be stored as a full URI, but instead as relative
to a location that has a full URI and can be mapped to a different URI
by the user if desired.

If that is the "model" then the CDT UI has to change:
1.  Add the ability to define and map source locations.
2.  Create a new "Add existing file to project" UI that works with
locations and treats source files in the workspace and outside the
workspace in the same manner - i.e., not the obscure treatment that
linked resources get today.
3.  Maybe CDT has to go back to having its own "project explorer" if the
generic explorer can't handle this.

Leo

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Chris Recoskie
Sent: Monday, January 14, 2008 7:26 AM
To: CDT General developers list.
Subject: RE: [cdt-dev] First gotcha with add/exclude children of FFS

Linked resources should work.  I haven't tried it lately with the new
build
system, but about 2 years ago I made the concerted effort to get it
working
in the MBS, so I'm hoping that's still true.

===========================

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 
             01/14/2008 10:13          RE: [cdt-dev] First gotcha with

             AM                        add/exclude children of FFS

 

 

             Please respond to

               "CDT General

             developers list."

             <cdt-dev@eclipse.

                   org>

 

 





I think that's true today. We do support projects with linked resources
and generate makefiles with the real physical paths. That's how I
discovered linked resources worked where my added resources did not.

Doug Schaefer
Engineering Manager, Wind River Systems
and Eclipse CDT Project Lead


> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of subs
> Sent: Saturday, January 12, 2008 4:45 AM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] First gotcha with add/exclude children of FFS
>
> One question I would have with linked resources is - would it
> work outside of Eclipse? That is, we use CDT to create a
> project using linked resource, and it generates a makefile.
> Can I then run that makefile from the command line?
>
> I think this functionality is essential for whatever you do.
>
> Thanks
> --
> Derek
>
> Treggiari, Leo wrote:
> > "linked resources" are handy, but I don't think they are
> well exposed
> > and explained in the Eclipse platform.  Learning about linked
> > resources is kind of a conversion with an Eclipse expert
> like: "gee, I
> > wish I could do this", and the expert saying: "well you can..." and
> > she shows me some non-intuitive example of how to use
> linked resources.
> >
> > Using linked resources "under the covers" would be great,
> but it would
> > be nice to present a CDT "concept"/"model" that is easier
> to work with.
> > Doug, I'm sure you are familiar with the Visual Studio concepts of
> > "reference" vs "directory" projects - maybe something there
> could help.
> >
> > Leo
> >
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> > On Behalf Of Schaefer, Doug
> > Sent: Friday, January 11, 2008 11:49 AM
> > To: CDT General developers list.
> > Subject: RE: [cdt-dev] First gotcha with add/exclude children of FFS
> >
> > Yes. In a lot of ways, the adds are the same as linked
> resources, just
> > done at the file system level.
> >
> > Having said that, I'm starting to rethink that strategy.
> Why not just
> > use linked resources? This bug with managed build doesn't happen in
> > that case (I remember the team working on fixing that). Any
> opinions?
> > I'll give it some thought over the weekend. Things would be
> simpler if
> > I was only had to worry about exclusions.
> >
> > Doug Schaefer
> > Engineering Manager, Wind River Systems and Eclipse CDT Project Lead
> >
> >
> >> -----Original Message-----
> >> From: cdt-dev-bounces@xxxxxxxxxxx
> >> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Chris Recoskie
> >> Sent: Friday, January 11, 2008 2:40 PM
> >> To: CDT General developers list.
> >> Subject: Re: [cdt-dev] First gotcha with add/exclude
> children of FFS
> >>
> >> This was something I was going to ask... so the FFS hierarchy is
> >> virtual then?  I.e. it's not strictly a filter that hides
> files, you
> >> can also add files in arbritary folders in the hiearchy,
> even if the
> >> folder is not the actual parent of the file with respect to the
> >> operating system's view of the filesystem?
> >>
> >> ===========================
> >>
> >> 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
> >>              01/11/2008 02:08          [cdt-dev] First gotcha
> >> with
> >>              PM                        add/exclude children
> >> of FFS
> >>
> >>
> >>
> >>
> >>              Please respond to
> >>
> >>                "CDT General
> >>
> >>              developers list."
> >>
> >>              <cdt-dev@eclipse.
> >>
> >>                    org>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> **** Build of configuration Debug for project Test ****
> >> **** Internal Builder is used for build ****
> >> g++ -O0 -g3 -Wall -c -fmessage-length=0 -otestdir\test.o
> >> ..\testdir\test.cpp
> >> g++: ..\testdir\test.cpp: No such file or directory
> >> g++: no input files
> >> Build error occurred, build is stopped Time consumed: 158 ms.
> >>
> >> Sigh.
> >>
> >> Of course, I've added the testdir directory from somewhere
> outside my
> >> project. Managed build obviously is assuming that the
> physical tree
> >> looks like the IResource tree. As Chris mentioned on the call
> >> yesterday, we're going to find a lot of these...
> >>
> >> Doug Schaefer
> >> Engineering Manager, Wind River Systems and Eclipse CDT
> Project Lead
> >> _______________________________________________
> >> 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
> >>
> > _______________________________________________
> > 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
> >
> _______________________________________________
> 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


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top