At 05:20 PM 11/10/00 +0000, Nic Ferrier wrote:
>>Again I suggest that the best way for a new contributor
>>to contribute to the JDE is to develop the contribution as
>>a stand-alone module rather than as a modification to existing
>>code. That gives me and other users a chance to evaluate
>>and try out the changes without having to commit to including
>>it in the core until JDE users are positive that it is generally
>useful,
>>robust, and consistent with the overall design of the JDE.
>
>Well... perhaps I didn't explain what I'd done very well because
>that's what I thought I'd done.
>
>I've written the file as a replacement jde-compile.el but none of the
>JDE functions is affected.
>
Imagine this scenario. A user replaces the standard jde-compile.el with
your version. I make a change to the standard jde-compile.el in the next
release. Either you or the user has to merge their version of
jde-compile.el with your version. I want to avoid this situation. The best
way for you to do this is to put all your changes into a separate file with
a different name.
>That means that you can still do C-V-C and get (jde-compile).
>
>Trouble is that if you have any relative paths set then it won't
>compile properly.
>
I can't accept changes that break existing functionality.
>So what am I supposed to do? duplicate all the jde-compile options in
>order to deliver a completly seperate module?
You don't have to duplicate them if you don't change their functionality.
You are really talking about making three distinct changes to the JDE:
1) Support for differing compiler options and syntaxes
2) Support for relative paths
3) Support for master prj.el files.
These features need to be approached each on their own merits. As I have
already said, I plan to add support for 1), taking a different approach
that I feel is more maintainable. I would be happy to offer your
alternatives implemented as a seperate module downloadable from the
Contributions page.
I am willing to add support to the JDE for relative paths based on prj.el
file location but only under the following conditions:
1) The support for relative paths must be complete, for running, debugging,
javadoc help files, etc., and must be released all at once.
2) The implementation must be completed and tested thoroughly before it is
merged into the main JDE sources.
3) The implementation should be done in such a way that the root does not
have to be the location of the prj.el file but could be based on some
other location specified by the user or determined automatically in some
other way.
I believe adding support for relative paths requires many changes in many
different JDE modules and cannot be done as a separate module. I would be
willing to do the implementation as part of the new project file system I
am developing.
If this not fast enough for you, what I suggest is that you start a
separate development branch of the JDE for relative path support. You can
make all the changes you need anywhere you need to and repackage the result
as a zip file for beta testing. I can post the zip file on the
Contributions page of the JDE website to facilitate downloading by
interested parties. When you have worked out all the kinks, I could merge
the lisp sources for your version of the JDE into the main branch which
would continue to evolve independently.
Finally, with regard to master prj.el files, I have already suggested a
soluion which is to insert a function at the end of each prj.el file that
loads a master file from a specified loactions. This master file would
contain overrides of settings in the local file, eg.
;; prj.el (local project file)
(jde-set-project-name "jmath")
(jde-set-variables
.
.
.
'(jde-which-method-format (quote (" [" jde-which-method-current "]")))
'(jde-run-classic-mode-vm t t)
.
.
.
)
(load-file "d:/master-prj.el") ;; Load overrides to the local settings.
;; master-prj.el
(jde-set-variables
'(jde-run-classic-mode-vm nil) ;; Overrides setting in local file.
)
Currently this requires editing every local project file but it would be
very simple for me to add a customization variable that would specify the
location of the master file and modify the Save->Project File command to
insert the necessary load statement at the end of the local prj.el file.
What I would suggest is that you try this approach manually and if it
works, I could make the necessary changes in the JDE to support creation
and automatic loading of master files.
- Paul
