At 09:39 PM 3/29/00 +0100, you wrote:
>
>
>>>>>> "Paul" == Paul Kinnucan <[EMAIL PROTECTED]> writes:
>
> Paul> At 02:24 PM 3/29/00 -0500, you wrote:
> >> We've been handling the classpath by setting the following in
> >> prj.el file:
> >>
> >> '(jde-compile-option-classpath (list (getenv "CLASSPATH")
> >> "c:/sourcepath"))
>
>
> Paul> Actually, it wouldn't be too hard to do expand environment
> Paul> variables in classpaths, using getenv, when constructing the
> Paul> compile, run, and debug command lines.
>
> If I can be so bold as to make a suggestion here I would
>do it in the defcustom, so that you have a value menu which allows
>"Use environment variable value" and then "any other value". I would
>not want my environment variables accidentally overriding the custom
>values.
What I had in mind is that you could enter paths with environment variables
for jde-global-classpath, e.g.,
Jde Global Classpath: [Hide]
[INS] [DEL] Path: %classpath%
[INS] [DEL] Path: %myprojhome%/pkg1
[INS]
[State]: you have edited the value as text, but you have not set the option.
When you execute a compile (or run, or debug) command, the JDE constructs a
-classpath argument by concatenating the paths in the list that is the
value of jde-global-classpath. I am proposing that when the JDE constructs
the classpath argument, it scans each path for environment variables, e.g.,
strings between % characters on Windows, and replaces them with the result
of applying getenv, e.g., getenv("classpath").
>I also think that it would be confusing if the command line
>were made up of values which were not actually what the custom buffer
>said.
The JDE could insert the unexpanded version of the classpath in the compile
buffer while passing the expanded value to the create-process function,
e.g., in the above example, the compile buffer would contain:
cd c:/myproj/pkg1
javaw -classpath %classpath%;%myprojhome%/pkg1 Foo.java
>(For instance I know many people who have got a little confused
>by the jde-global-class-path which is over-ridden by
>jde-compile-class-path, and sit there changing the global class path
>going "why isnt it changing". Possibly it should be mentioned in the
>global class path that other variables can silently over ride it?).
>
Possibly people should read the doc.
The fact that jde-global-classpath can be overridden by
jde-compile-option-classpath, etc. is mentioned both in the JDE User's
Guide and in the docstrings for the variables in question.
> The only thing that I do not understand is why javac is not
>using the environment var automatically which it should do by
>itself. Is it because emacs is using a different internal shell (bash
>for instance) to launch javac than used to launch emacs dos in this
>case I would have thought? Has the CLASSPATH been set in your
>.bash_profile?
>
The JDE uses the current implicit shell to run the compiler executable. It
launches the vm and the debugger directly as subprocesses of Emacs. I don't
know whether a shell expands environment variables embedded in arguments
that are passed to it programmatically rather than interactively. You could
easily find out by trying to compile a java source file with
jde-global-classpath set to a path that includes an environment variable.
If you decide to try, let me know the resulg.
> Paul> I'll put this on my list of things to do.
>
> Just out of curiosity Paul, how long is this list?
I haven't bothered to count. I know I'm not likely to run out of things to
do for a long time.
------------------------------------------------------------
ASKING FOR TECHNICAL SUPPORT ON THE JDE LIST
Please use the JDE->Help->Submit Problem Report command when reporting a
bug or seeking help. This command generates a complete snapshot of your
system. Submitting such a snapshot increases the chances that your request
will get a swift response.
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
JDE website: http://sunsite.auc.dk/jde/
JDE mailing list archive:
http://www.mail-archive.com/[email protected]/maillist.html
