>>> 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).
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
>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.
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.
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.
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.
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.
I don't understand why you're being so negative.
I've posted the changed file to the development list BTW should you
want to look at the code.
Nic
