relative paths in project files?
Allan Hessenflow
under $WIND_BASE to tornado2, it stores the filename using a path relative
to $WIND_BASE. Files that are not in that tree are stored using absolute
paths. I'd like to add another environment variable, say SOURCE_DIR
(assuming it doesn't already have provision for something like this that
I don't know about), and have it store paths to files under that directory
as relative paths. So I was hoping the code that makes that decision for
WIND_BASE is in tcl so I could just find it and add my changes. But a
quick scan hasn't turned anything up; maybe someone here can point me in
the right direction.
The reason for doing this is that we have a source tree that we used to
store in tornado2\target\src\..., so the project files had relative paths
and therefore were portable between development systems which may not have
everything installed in the same locations. But now we're using more than
one version of tornado2, which cannot share a common WIND_BASE, so I've
moved our source tree outside of the tornado2 tree. Of course that has
resulted in absolute paths being stored in the project files so they are
no longer portable.
allan
--
Allan N. Hessenflow all...@kallisti.com
Bill Pringlemeir
[snip]
> which cannot share a common WIND_BASE, so I've moved our source tree
> outside of the tornado2 tree. Of course that has resulted in
> absolute paths being stored in the project files so they are no
> longer portable.
Well, I won't answer your question directly. However, I might change
your goal a little bit and suggest a common mount point on Unix (or
symbolic links). Alternatively on Windows, you can use the "subst"
command to map a directory to a common drive. These solutions will
solve the problem. It would be nice to use relative paths, but this
seemed the most painless when I came across this problem.
fwiw,
Bill Pringlemeir.
--
Keep an open mind. But not so open your brains fall out. - Kallis'
Law
Wiki - "http://www.bluedonkey.org/cgi-bin/twiki/bin/view/Books/WebHome"
FAQ - "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"
Denis Perelyubskiy
>
> I've noticed that when I add a source file to a project
> that is located under $WIND_BASE to tornado2, it stores
> the filename using a path relative to $WIND_BASE. Files
> that are not in that tree are stored using absolute
> paths. I'd like to add another environment variable, say
> SOURCE_DIR (assuming it doesn't already have provision
> for something like this that I don't know about), and
> have it store paths to files under that directory as
> relative paths. So I was hoping the code that makes that
> decision for WIND_BASE is in tcl so I could just find it
> and add my changes. But a quick scan hasn't turned
> anything up; maybe someone here can point me in the right
> direction.
If you keep all the files that belong to your project under
a the same project tree the paths are stored using the
PRJ_DIR directory, and are relative. I can't be 100%
certain, but it seems to be true for us.
For example:
c:\project\proj1\proj1.wpj (other project files are in the
same folder)
c:\project\proj1\src\... (this is where all your source is)
then proj1.wpj will store everything using PRJ_DIR variable,
and you'll be a happy camper again.
I've seen some weird behavior recently, however. it seems to
be related to having files (in our case its prjParam.h) be
above the .wpj file for the project. For example, if you had
another project as part of the same workspace, and it was in
c:\project\proj1\proj2\proj2.wpj, then the two would share
prjParam.h, which would be located in
c:\project\proj1\prjParams.h (which is above project2's .wpj
file), and then c:\project\proj1 would show up as absolute
path. This path, however, would be changed every time you
re-generate dependencies, so sharing is still possible, but
annoying.
To make the long story short, just make sure all your
sources (and project files) are at the same level (or below)
as your .wpj (as in example I outlined above)
denis
ps. why could not they just stick to makefiles!?!?!? :)
--
'From' email address is used as a sink. Not read. Ever.
Instead, send to [p-o-s-t-i-n-g|o-v-e-r-w-h-e-l-m|n-e-t]
(remove dashes, replace the first vertical bar with @,
and second with a dot). Sorry for any inconvenience.
Allan Hessenflow
Denis Perelyubskiy <kie...@dslextreme.com> wrote:
>If you keep all the files that belong to your project under
>a the same project tree the paths are stored using the
>PRJ_DIR directory, and are relative. I can't be 100%
>certain, but it seems to be true for us.
Thanks, I'll try moving the project files into a common tree
with the source to see if that works...
>I've seen some weird behavior recently, however. it seems to
>be related to having files (in our case its prjParam.h) be
>above the .wpj file for the project. For example, if you had
>another project as part of the same workspace, and it was in
>c:\project\proj1\proj2\proj2.wpj, then the two would share
>prjParam.h, which would be located in
>c:\project\proj1\prjParams.h (which is above project2's .wpj
>file), and then c:\project\proj1 would show up as absolute
>path. This path, however, would be changed every time you
>re-generate dependencies, so sharing is still possible, but
>annoying.
That sounds pretty strange, but shouldn't effect us as all of
our projects are at the same level (.../proj/proj1/proj1.wpj,
.../proj/proj2/proj2.wpj, etc.).
>ps. why could not they just stick to makefiles!?!?!? :)
If it was up to me we would. And the development machines would be
*nix boxes, where among other things we could use symlinks to easily
solve these sorts of problems. And version countrol would use CVS
instead of sourcesafe. But I don't get to decide any of these
things...
Allan Hessenflow
Bill Pringlemeir <spam_a...@sympatico.ca> wrote:
>Well, I won't answer your question directly. However, I might change
>your goal a little bit and suggest a common mount point on Unix (or
>symbolic links). Alternatively on Windows, you can use the "subst"
>command to map a directory to a common drive. These solutions will
>solve the problem. It would be nice to use relative paths, but this
>seemed the most painless when I came across this problem.
Another poster suggested putting the project files in the same tree
as the source, causing everything to become relative to PRJ_DIR.
That sounds like a workable solution for us. But "subst" would be
my next choice; not using dos/windows much except for this one company,
I hadn't thought of that... I had tried to create symlinks in various
ways, but Windows idea of symlinks seems pretty limited.
Allan Hessenflow
>same folder)
>c:\project\proj1\src\... (this is where all your source is)
>
>then proj1.wpj will store everything using PRJ_DIR variable,
>and you'll be a happy camper again.
When I first read this I was thinking I could get PRJJ_DIR to
point a level above the directory where the .wpj file is. But
that is not the case, at least not easily. So this isn't going
to work because we have multiple projects referring to the same
source tree. So I think I'll have to try 'subst', as another
poster suggested...