At 02:14 PM 11/10/00 +0000, "Nic Ferrier" <[EMAIL PROTECTED]>
wrote:
>>>> Paul Kinnucan <[EMAIL PROTECTED]> 10-Nov-00 9:31:39 AM >>>
>>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.
>
>But it doesn't work because the user has to enter the command line
>rather than have JDE generate it (or have I missed something).
>
That is the point. The user needs to know the option and then enter it.
What is wrong with that?
>There are lots of things in favour of the approach I've hacked out:
>- it will be quicker to develop than your new IDE type system
>(which you've said is going to take some time to do)
>- one compiler fn can be quickly adapted to another
>- unusual compilers can be dealt with quickly
>- it doesn't actually break anything in the current project system
>- extra/unusual compilations fn can be written by those who want
>them
>
I don't want to put temporary hacks into the core JDE distribution. You can
always put your additions in a separate package and post it to the mailing
list for others to use. I will also be happy to post your contributions on
the JDE website.
>
>>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.
>
>Sure... but could we not say "okay - compilation does this now...
>other parts of JDE will follow". I'm sure some people would volunteer
>to help add the functionality to other places.
>
No. I have to support the JDE and I don't feel like adding a partially
implemented feature that will generate a whole new slew of questions of the
form: "it works this way for compilation, how come it doesn't work for
javadoc, the online help system, or running or debugging..."
>Besides the function to do this for paths (the most complicated bit
>I'd suggest) is now done (it's an alteration of your
>jde-build-path-args btw).
>
>
>>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 have suggested changes to build before (early 99 I think). I
>submitted to you a build alternative that alllowed compilation of the
>entire project without reliance on either the Xdepend switch or on
>make (by constructing an @filelist from the project root).
>
>As far as I recall you didn't make much comment on the code. You
>certainly never put it up on the contrib page.
>
Send it again and I will post it. I am the recipient of a lot of mail, a
lot of requests, etc., I do my best to handle them all, but sometimes
things get lost in the shuffle.
>My changes to compile to allow a single compiler function to handle
>both single, multi and complete builds seemed to me sensible, given
>the desire to modularise the project system. For build I intend to
>provide a system that is similar to that which I sent to you all that
>time ago and which I've been using for all that time.
>
>
>>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.
>
>I was looking for feedback more than anything else.
>
>The changes I have just made (allowing relative paths in projects)
>work pretty well for me right now - I was kinda hoping that some
>people would ask me for the file and try it out and if they liked it
>you'd put it into the official JDE.
>
>
>>My plan is to leave the current system in place for those who like
>>it and are comfortable with it
>
>Judging by the list discussion last week most people seemed happy-ish
>with the current project system.
>
>Sure: an IDE like system would bring in new people that wouldn't
>normally use Emacs as their IDE but I personally won't use it and it
>seemed to me that most of the people taking part in last weeks
>discussion weren't keen either.
>
>To me that meant that we had to improve the current project system
>incrementally, not add something completly new.
>
>
>>The prj.el system is a very lightweight, quick-and-dirty system
>>that works well for the individual/new user
>
>Yes. And with a few changes that don't break anything we make it much
>more usefull for teams.
>
>
>>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.
>
>Yes... all that is really exciting.
>
>But I want better project management now (and I guess so do some
>others).
>
>Also the sort of project management you were talking about doesn't
>sound like what I want (and I thought that others were saying that
>too). Principally the restriction to one project at a time I see as a
>problem for me.
>
Why? All it would require is a single command to switch from one project to
another and if this is too onerous, I'm sure that the new system could have
some form of automatic switching as an option.
>That doesn't mean it's bad - I think it's great that there will be
>something which is more "normal" for users who aren't Emacs hackers.
>
>But progressive improvements to prj.el that don't break it seem a
>better upgrade for *me* (and others like me).
>
>
>>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.
>
>I didn't think the changes I have made fundamentally alter the
>current system. Nothing is broken.
>
So you say, but how am I to be certain of this? You are asking me to commit
to extensive changes to the implementation, if not the behavior, of a major
JDE subsystem, with only verbal assurances that the changes will not
destabilize the system, potentially requiring many releases to restabilize.
I can't afford to take this risk. I have too many other irons in the fire
to want to become embroiled in changes to a subsystem that I think is
basically complete and not worth extending at this point.
>The changes I'm talking about (having a master project file) to
>supply default settings don't fundamentally alter it either as far as
>I can see... It's just another config option in the project file. And
>having played with the current system (using relative paths) I'm not
>sure it's necessary anyway.
>
You say this, but I'm not convinced. What you are proposing would require a
complete rewrite of the prj.el code, potentially introducing bugs into what
has become a very stable subsystem,and would change the model of usage. For
example, prj.el files, instead of being locateable anywhere in the
directory tree, would have to be located in specific directories. I'm not
saying that you could not make the change transparently but I don't want to
take my personal time out to ensure that it is done right and to debug
problems that you introduce or wait for you to debug them in order to make
a release.
In any case, I do not think it is too onerous for you to implement your
changes as a stand-alone system. The requirement fulfilled by the current
system is to update the JDE configuration variables to project-specific
values. All you have to do is create a separate subsystem (jde-prjplus.el)
that does this with a single function that can be invoked from the JDE's
project switching and menus to do the updating. I could then provide a
config variable that the project switching code and the menus could test to
determine which update function to call. If your enhanced prj.el subsystem
turns out to be robust and preferred by users to the existing version, I
could then simply replace the existing version with yours.
>I don't understand why you're being so negative.
>
You would understand if you were in my shoes.
I am concerned about wholesale changes to a fundamental aspect of the JDE
that I then have to maintain and support. I don't know to what extent your
changes will destabilize the system, etc. I have gotten a lot of partially
or incorrectly implemented changes to the JDE that I have then had to
interrupt what I am doing to rewrite, debug, complete the implementation
of, etc. I have my own features that I am working on and it is frustrating
to have to interrupt my own projects to work on someone else's. In fact,
integrating contributions of others, some of which is buggy or
half-implemented, is beginning to consume all the time I have to devote to
the JDE.
Another problem is that a lot of JDE contributors make a contribution and
then disappear, leaving me responsible for maintaining and improving their
contributions. I have to take this into consideration when deciding to
integrate contributions into the JDE or accepting modifications to the core
JDE code. I don't want somebody starting to modify the core code who may
not be around to debug or maintain it three months from now.
I think people who want to contribute to the JDE should use David Ponce as
a model. David has contributed or taken over development of distinct
subsystems (javadoc, Classes menu, etc) that can be submitted and
maintained as a unit and that do not require widespread modifications of
the JDE code.
I don't want to discourage contributions but I can't afford to blindly
accept every contribution, regardless of its quality or its fit with the
overall design of the JDE.
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.
- Paul
