The relative path is a great idea. We use ClearCase in NT, and every designer has the "views" mounted as different paths (different drives/path names). The result is that we can't share prj.el files. This is a wonderful change. We tried to use things like ../../../myDirectory, but it is just to error prone.
How hard would it be to extend the relative path idea to other variables that hardcode source paths, like jde-db-source, etc.?
-----Original Message-----
From: Nic Ferrier [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 09, 2000 9:43 AM
To: [EMAIL PROTECTED]
Subject: project based compilation
I've rewritten some of the JDE compilation stuff to make it a little
more modular.
I've got a version now that's much easier to plug in different
compilers. If anybody wants a copy of the source code (it's just an
altered jde-compile.el) then let me know.
*What this solves
The problem with the existing JDE compile code is that it creates a
string of options which is static across all compilers even though all
compilers don't use the same format for command lines.
For example the JDE might produce a command line:
jikes -bootclasspath dir1:dir2 -classpath ... source-files
but that doesn't make any sense to jikes.
*How it works
The user has to select a compiler function (by typing the function
name at the moment but it could be a little more clever than that).
When the new compile command is used the selected compiler function
creates the command line from an association list of all the options.
I've written basic compiler functions for jikes and javac. I imagine
that this could be done in a pluggable way using (require).
There are some other clever little things about my new stuff.
*Directory resolution
If directory variables (like classpath or destination-dir) are
specified as relative directories they are resolved against the
project files directory.
eg: if you have this setup:
/home
/nic
/project
/prj.el
/libs
/somejar.jar
then you could enter:
classpath libs/somejar.jar
and it would be resolved correctly at compile time to:
/home/nic/project/libs/somejar.jar
if you moved the project directory to:
/home/bob/project
then the classpath would automatically resolve to:
/home/bob/project/libs/somejar.jar
I guess this *may* not be what people want all the time but it seems
to me a more usefull default than we have currently. Any suggestions
on this would be appreciated.
*Compiling more than one file
Another trick is that the compiler functions can operate on lists of
files, it should be fairly easy to constuct JDE compile functions that
compile all the files opened in Emacs, or all the files that have been
opened since the Emacs session began.
I haven't done it yet but I intend to make the compiler function
understand the convention of an empty file list as "rebuild the whole
project". Some compiler functions might want to deal with that by
doing a lot of work on dependancies themselves... others might want to
just put all the project files on the compiler command line. Again any
thoughts or experiences would be appreciated.
I now intend to work on making project files work a little better as
per conversations last week.
It seems to me that a project file should have a reference to a
master project file. The master project file would then be asked to
supply all the values for the customization variables that are not
defined in the prj.el file.
When a user changes a customization value the prj.el file (not the
master should be updated).
To create a master file you would create a project file and save it
somewhere else.
To do this requires that I re-write the save/load-project functions.
After that's done I need to change the code for running Java to be as
modular as the new compile code.
Nic Ferrier
