At 02:42 PM 11/9/00 +0000, you wrote:
>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).
>
I agree that the current compiler support for the JDE is not very flexible
and needs to be enhanced along the lines you have suggested and in fact I
intend to do it as part of the new project system. However, my plan is to
take an object-oriented approach to this problem, defining a generic eieio
compiler class and then defining subclasses for various versions of javac,
jikes, etc. This will make the code more modular and extensible than the
functional approach that you suggest.
Meanwhile, the JDE does have a workaround
jde-compile-option-command-line-args that allows you to specify any option
exactly as the compiler requires it. I realize that this does not
facilitate switching compilers but it does work.
>
>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.
>
This is a good idea but it would have to be implemented everywhere. All JDE
functions that reference a path would have to be modified to work with
relative paths. I am not adverse to doing this but I would not get to it
for a while.
>*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.
>
The JDE has two compilation commands: Compile and Build. Your proposed
change would collapse these commands into a single command. I don't think
this is a good idea. I suggest you look at the Build command as it is
currently implemented and if it does not meet your needs, suggest the
appropriate changes.
>
>
>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.
What you are proposing is to replace the current prj.el system with
something else that is superficially similar to the current system but
works much differently. My plan is to leave the current system in place for
those who like it and are comfortable with it and add a new, much more
sophisticated system for those with more demanding requirements, in
particular, for those who work in a team environment. I think most JDE
users would prefer the latter approach.
The prj.el system is a very lightweight, quick-and-dirty system that works
well for the individual/new user (e.g., me when I initially created the
JDE). I don't think it is a good foundation for building a heavy-duty,
professional-level project management system. I think it's best to build
that system from the ground up, taking advantage of new Emacs technology
that has emerged since the JDE was conceived, specifically Eric Ludlam's
object-oriented extension to elisp (eieio), parser generator (semantic),
and speedbar packages.
I am currently involved in converting the JDE documentation to XML so that
I can easily generate info, HTML, and print-ready versions from a common
source. When I am finished with this project, I intend to begin
implementation of the new project system. I plan to release the system in
pieces so that people can have access to new features quickly.
Meanwhile, if you plan to continue developing your improvements to the
prj.el system, I think you should take a cue from the approach I am
planning and implement your improvements as an alternative system that can
take its place alongside the prj.el system rather than fundamentally
altering or replacing it.
Regards,
- Paul
