>>> "Jeff Jensen" <[EMAIL PROTECTED]> 11-Nov-00 8:42:44 PM
>>>
>1) Global: Base default configuration all projects start
>with, including across all users. Overrides JDE defaults.
>2) Package: Per package/project settings. Overrides
>anything in Global.
>3) Environment: Local user specific things for the machine's
>environment. Overrides anything in Package.
I think package/project comes last. Environment stuff should be
over-ridable on a project basis.
Eg: my default environment is to use kaffe and Sun's javac but when I
work on core Kaffe I need to use a free compiler (just to be on the
safe side).
>Only overrides are specified at each level, not everything is
>in each like today's prj.el. (tangent: an enhancement idea I
>have desired but not looked into yet is to simply have a
>customize list of JDE variables to not save in prj.el, so that
>JDE config info updates to per machine special elisp files
>aren't also needing repeated updating in the prj.el files).
I agree... This is how I've been thinking... I'm trying to build my
stuff so the global/enviornmental stuff can be specified as normal
customizations (ie: site wide and/or user specific) and the prj.el
only contains the options specific to the project. I think that *can*
be done.
>#1 is shared, placed in a globally accessible directory,
>probably typically placed at the top level in the source tree.
In my world view this would be in the global emacs config and the
user stuff goes as customizations in .emacs.
Remember we're talking about Emacs only here - we can't solve the
worlds project problems.
>I also see Package as possibly being the least used
>(at least in my setups), since #1 and #3 would cover nearly
>all. However, sometimes there are projects that do not fit
>in the "normal" source tree setup, and this would
>take care of that.
Ok. I see one prj.el being adaptable to many project where you have
similar structures. If I can take the environmental stuff out of it
then I've achieved portable project files for all similar architected
projects across all machines. That's a start I think.
>The bummer is, prj.el files still have to be individually
>generated per machine, and per project that does not
>share a proper source directory. Configuring the same
>info over & over is a drag. I have not focused on how
>to solve that yet...
My relative path stuff also has resolution of environment variables
inside JDE. Is that not what you need to do your stuff the way you
want to do it?
I mean your #3 could be solved by having "prj.el"s with entries
like:
bootclasspath $devbootcp
I don't like that personally but it is what you want right? If so -
it's working in my compile module.
>And we still need to work out configuration for debug
>vs release builds, to make it easy to flip between the two.
Paul's system will certainly be able to deal with this requirment but
I'm not sure prj.el type system will ever be able to do it (except by
using environment variables or massive duplication).
But then release builds I generally deal with in other ways.
Nic
