Home » Eclipse Projects » Eclipse Platform » Relative path for linked resources, why not?
| Relative path for linked resources, why not? [message #330304] |
Thu, 24 July 2008 19:41  |
Eclipse User |
|
|
|
Originally posted by: jim.walseth.teejet.com
Our company has a "pre-ordained layout for source files" that in part
lead to the effort to create a Flexible Project Structure:
(ref.
http://www.eclipse.org/eclipse/development/flexible-projects -proposal.html)
Ours is a three-tiered hierachical folder structure from which we
build many different applications using subsets of these source files
(C++). I can add files to the project as a linked resource due to the
solutions described in the above reference, but the paths are absolute.
Thus a significant problem remains if one wants to commit the Eclipse
project as part of the codebase, then export later to an arbitrary folder
and use the project. Generally, the paths will not be correct anymore.
At first here appears to be promise with the "path variable", but these
are also required to be absolute. And I was not successful trying to use
system variables like HOME in the resource path or path variable.
Has anyone figured this out, without going in and hacking the project
file? Can anyone explain why relative paths are not used?
FYI we are using Version: 3.4.0 (Ganymede).
[PS This was posted on CDT group and suggestion was I move it here.]
|
|
|
| Re: Relative path for linked resources, why not? [message #330308 is a reply to message #330304] |
Thu, 24 July 2008 22:12  |
| Eclipse User |
|
|
|
Originally posted by: wegener.cboenospam.com
"Jim Walseth" <jim.walseth@teejet.com> wrote in message
news:0651dd72ac9d85a49c0b3328fe15598c$1@www.eclipse.org...
> Our company has a "pre-ordained layout for source files" that in part
> lead to the effort to create a Flexible Project Structure:
> (ref.
>
http://www.eclipse.org/eclipse/development/flexible-projects -proposal.html)
>
> Ours is a three-tiered hierachical folder structure from which we
> build many different applications using subsets of these source files
> (C++). I can add files to the project as a linked resource due to the
> solutions described in the above reference, but the paths are absolute.
>
> Thus a significant problem remains if one wants to commit the Eclipse
> project as part of the codebase, then export later to an arbitrary folder
> and use the project. Generally, the paths will not be correct anymore.
> At first here appears to be promise with the "path variable", but these
> are also required to be absolute. And I was not successful trying to use
> system variables like HOME in the resource path or path variable.
>
> Has anyone figured this out, without going in and hacking the project
> file? Can anyone explain why relative paths are not used?
>
> FYI we are using Version: 3.4.0 (Ganymede).
>
> [PS This was posted on CDT group and suggestion was I move it here.]
>
>
>
When you use a Path Variable to define a resource link, the link that is
stored in the .project file is relative to the Path Variable name. The
location that the Path Variable points to is defined in each workspace.
This allows different developers to use the project on different systems.
Lets say that you want to link to a source directory in the hierarchy
C:\MyDevelopment\Project1\src and your codebase is checked into your SCM
tool at the Project1 level. You would create a Path Variable (DEV_ROOT)
which points to C:\MyDevelopment. When you create the linked folder, you
select the DEV_ROOT path variable and extend it to include Project1. This
adds a DEV_ROOT\Project1 resource link to your .project file. If you later
check the source out into C:\AlternateDevelopment\Foo\Bar\Project1\src, you
import the project into a workspace and set the DEV_ROOT Path Variable to
point to C:\AlternateDevelopment\Foo\Bar and your link is established for
you. The .project file doesn't change.
At some point, you have to have an absolute location in order to be able to
move relative to it.
|
|
|
| Re: Relative path for linked resources, why not? [message #330338 is a reply to message #330308] |
Fri, 25 July 2008 17:28 |
| Eclipse User |
|
|
|
Originally posted by: jim.walseth.teejet.com
Thanks Dave. I see the flexibility provided by the Path Variable.
However, to take advantage of it one must alter the Path Variable through
the IDE, after importing the project, also a manual step.
What this does not address is this: the project and it's settings must be
regarded as part of a build or release. In other words the correct
practice is to commit the project along with source code to a repository
and tag everything. Later, check out (to an arbitrary location)
everything and do a build. Ideally it should be possible to automate this
process. Changing things after check out sort of breaks the rules.
I agree that one must have an absolute path from which to evaluate
relative paths, but is this not provided by the absolute location of the
project file? Or the absolute location of the Workspace? These are both
known, absolute paths. Or do I not get something.
|
|
|
| Re: Relative path for linked resources, why not? [message #330340 is a reply to message #330338] |
Fri, 25 July 2008 18:29 |
| Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
Jim Walseth wrote:
> Thanks Dave. I see the flexibility provided by the Path Variable.
> However, to take advantage of it one must alter the Path Variable
> through the IDE, after importing the project, also a manual step.
Actually, if the CDT Path Variable is like the JDT Classpath Variable,
it can be set before it is used (before a project is imported or created
that uses it).
>
> What this does not address is this: the project and it's settings must
> be regarded as part of a build or release. In other words the correct
> practice is to commit the project along with source code to a repository
> and tag everything. Later, check out (to an arbitrary location)
> everything and do a build. Ideally it should be possible to automate
> this process.
How are you going to automate Eclipse to start up, import the projects,
and do its build?
In my experience, the technique you're talking about is done without
using an IDE, using Ant or make or Maven or CruiseControl, etc. So I
guess I'm missing your high-level goal here.
Anyway, because the value of the Path Variable is stored in the
workspace, you could have that be the "constant" and not have to set the
variable's value for every build, only when creating a workspace.
Hope this helps,
Eric
|
|
|
| Re: Relative path for linked resources, why not? [message #330348 is a reply to message #330340] |
Fri, 25 July 2008 21:04 |
| Eclipse User |
|
|
|
Originally posted by: jim.walseth.teejet.com
Yes I think it is the workspace that I would like to reproduce in a way
that the build can be executed without any 'intervention' like changing
Path Variables. These are some aspects that are unfamiliar coming from
other IDEs:
1) a folder becomes a workspace when you switch to that folder from
Eclipse, not like Visual Studio where Fo.dsw and Fi.dsw and Fum.dsw can be
in the same folder. In other words the workspace is not a file. How
would one commit this to the repository? Commit all the files under
metadata?
2) You don't 'open' a project you 'import' it. Meaning, one generally
works with a copy of the project? What does this mean for version control?
Right now this all feels like putting a square peg (legacy C++ projects)
in a round hole. Plus newcomer confusion. Thanks for the responses.
|
|
|
| Re: Relative path for linked resources, why not? [message #330364 is a reply to message #330348] |
Sat, 26 July 2008 17:49 |
| Eclipse User |
|
|
|
Originally posted by: wegener.cboenospam.com
Jim Walseth wrote:
> Yes I think it is the workspace that I would like to reproduce in a way
> that the build can be executed without any 'intervention' like changing
> Path Variables. These are some aspects that are unfamiliar coming from
> other IDEs:
>
> 1) a folder becomes a workspace when you switch to that folder from
> Eclipse, not like Visual Studio where Fo.dsw and Fi.dsw and Fum.dsw can
> be in the same folder. In other words the workspace is not a file. How
> would one commit this to the repository? Commit all the files under
> metadata?
>
An Eclipse workspace is not the same as a Visual Studio workspace. In
Eclipse the workspace is container to keep track of what your working on
and how you want the environment to behave. I Visual Studio, the
workspace file defines relationships between projects and how projects
are built.
The Eclipse .project file and I belive an additional .cdt??? specific
file more closely correspond to the Visual Studio workspace file. These
files define what resources make up the project, what the project
depends on, and how to build the project.
The Eclipse workspace keeps track of what perspectives (windows) and
view are opened, how you want the environment to look, where source code
repositories are located, etc.
In general, you don't want to commit your workspace to a repository.
You do want to commit the .project and .cdt???? files to a repository as
you do with the .dsw files.
> 2) You don't 'open' a project you 'import' it. Meaning, one generally
> works with a copy of the project? What does this mean for version control?
>
The Eclipse workspace allows you to maintain a project in the workspace,
but it doesn't require that the project resides in the workspace.
Import is really a way of associating a workspace with a project. The
Import dialog should have a check box for copying the project into the
workspace. If you don't check this box, the project is left where ever
it resides on the file system and your workspace just points to it.
Importing is also dependent on the SCM provider that you are using.
There are a number of providers with Eclipse plugins that allow for an
integrated SCM experience. Check with your SCM provider to see if they
supply a plugin.
> Right now this all feels like putting a square peg (legacy C++ projects)
> in a round hole. Plus newcomer confusion. Thanks for the responses.
>
>
There are some articles discussing Eclipse C++ development including one
that discusses migrating from Visual Studio. Maybe these can help you out.
http://www-128.ibm.com/developerworks/library/os-ecl-vscdt/i ndex.html
http://wiki.eclipse.org/CDT/User/FAQ
>
I know you are working on C++, but the Java tool documentation has a
tutorial about project setup. Some of the concepts including linked
resources should pertain to C++ as well.
http://help.eclipse.org/ganymede/topic/org.eclipse.jdt.doc.u ser/gettingStarted/qs-ProjectConfiguration.htm
|
|
|
Goto Forum:
Current Time: Wed Sep 18 14:20:02 GMT 2024
Powered by FUDForum. Page generated in 0.06881 seconds |
] 
Search
Help
Register
Login
Home
