I think there is a third "level" needed, in both the new configuration
scheme Paul is creating, and the changes Nic is doing to the current.
The three "levels" of configuration needs form a hierarchy/inheritance:
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.
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).
The three levels allow an organization to setup core defaults that differ
from JDE defaults (#1), a team to setup per package needs that differ from
Global (#2), and a developer to setup specific items for a machine
configuration that differ from Package (#3).
Some incomplete thoughts on "placement" implementation:
#1 is shared, placed in a globally accessible directory, probably
typically placed at the top level in the source tree.
#2 is shared, placed in a globally accessible directory, probably
typically placed in the package directory it is for (or perhaps a level
above to share across packages if that feature is desired).
#3 is not shared, placed in a local/private/personal directory, probably
in $HOME, or possibly in .emacs.
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.
JDE customize settings are needed to state where the Global file is, and
possibly something for telling it how to find other files (e.g. one per
package, etc. options).
Interestingly, this could work with the prj.el of today, if it was made to:
- process multiple prj.el's, from the specified starting directory
continuing to the directory root
- only store config overrides, not all variables
So far, I have been doing:
#1 in .emacs
#3 via environment variables; since .emacs files are shared among
machines, I change JDE customize settings in .emacs to use things like
(getenv "JDK_HOME"), for example,
'(jde-db-source-directories (\` ((\, (getenv "JDK_SRC_HOME")))))
[I can see Paul frowning now!! ;-) ]
#2 in prj.el file settings (automatically includes items from #1 and #3
when written out, plus the added settings like per project db-source
directories)
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...
And we still need to work out configuration for debug vs release builds, to
make it easy to flip between the two.
How does this thinking compare with others' thoughts? Does anyone see this
similarly, or not?
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of Paul Kinnucan
Sent: Friday, November 10, 2000 4:03 PM
To: Nic Ferrier; [EMAIL PROTECTED]
Subject: Re: project based compilation
At 09:58 PM 11/10/00 +0000, Nic Ferrier wrote:
>>>> Paul Kinnucan <[EMAIL PROTECTED]> 10-Nov-00 9:14:11 PM >>>
>
>>With my proposal, the master file gets loaded last
>>and thus has the final say on the settings of the
>>variables that it specifies. I don't think you can get
>>any more "superior" than that.
>
>I think you've misunderstood me... what I was trying to say was that
>the "master" file should define the things that the machine deals with
>but the project file should be about per-project things.
>
>So the master has things like:
>
>- vm
>- bootclasspath
>
>and the project has things like:
>
>- global-classpath
>- extdirs
>
Okay, I am confused. I thought the master was to be used by teams to
specify any settings that they wanted all projects to have. A problem with
what I have proposed is that it does not let the local project file
override the master. Thus, the team might want to define
jde-global-classpath to be a default value but let the local project file
override it. My proposal does not really permit this. So maybe it is not
really a good solution.
- Paul
