|
----- Original Message -----
Sent: Monday, August 13, 2001 11:56
AM
Subject: RE: relative paths
Hi,
Wow, calm down! I was just trying to help. I was not criticizing
JDE or anything.
Anyway, let's see:
yes on a second thought I agree that Stefan's problem is different then
mine, and I agree that creating a prj.el on the project root is a much less
"esoteric" solution. That is precisely how I use pry.el in my projects. I
should have recognized that, I apologize.
But I stand by my
assertion that using relative paths can be error prone in some scenarios. If
they start to get too big (six, seven layers) they become cumbersome and
hard to get right, and if you change any directory strutcture in your project
you have to go back changing all affected relative paths.
In my case in particular -
which may not be very common - we use ClearCase for source control on Windows
boxes. That means that I may want to work on different project trees with the
same structure but mapped to different drives (depending on which release/bug
fix/view you're working at the moment). Yes I could use relative paths, but
using defadvice I was able to use an environment variable to point to specific
points in my project tree. So instead of
../../../../../lib/proj1/jars
../../../../../out/file1.jar
I can have
$PROJ_ROOT/lib/proj1/jars
$PROJ_ROOT/out/file1.jar
Which IMHO is much
more readable and easier to maintain. If you need to change the structure of
your project you just have one place to change - not every place where you use
a relative path.
Well, I have a hard time imagining a
situation where I would want to put my jar files six directories below my
source directory. Also, on all the projects I work on, the project directory at
the root level is pretty stable (e.g., root/src, root/class/ root/lib/,
root/doc/, root/help. There is almost never a change except to add a directory
at the root level. So the problem you face has never arisen for me. Even if it
did, I'd prefer the relative path approach as it allows other developers to
use a common project file without first ensuring that the requisite environment
variable(s) are set on each developer's system.
I only used
defadvice on jde-load-project-file because there was no jde hook - and I
searched for them, in the source code - that would do what I wanted. I had to
ensure that every time a project was (re)loaded that the environment variables
would be reset based on the current path. Which hook should I use? Could a new
jde hook be created for that purpose?
I don't understand the problem you are
trying to solve with defadvice. Environment variables in paths are
evaluated by the JDE everytime the path is used, e.g., to generate a
compile command, not when the project file is loaded. Thus, if you have a
project loaded and you change the environment variable, the next time you
compile, the classpath will reflect the new value of the environment
variable.
- Paul
| 