> Nic Ferrier
> Sent: Saturday, November 11, 2000 6:10 PM
> >>> "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).
Good point - a project could require certain tools. That config needs
defining at the Package/Project level. I do not see that requirement
specified at the Environment level. I also do not see a Package level
overriding localized Environment settings.
I see the Environment level particularly for specifying the install
locations of tools, such as the JDK, and root directories, such as source
and target. The Package level can't override this, as these directories,
like the JDK install location, could vary per user.
Perhaps the Global and Package levels are mutually exclusive from the
Environment level. Meaning there are no options in common between Global &
Package levels and Environment.
In this situation, the Global and Package levels specify what is needed, and
the Environment level specifies where to find it as needed when it applies
to installed tools.
In all of the situations I can think of right now, that would work great.
My first issue in sharing .emacs, prj.el, and projects amongst a team and
different machines was isolating machine/environment differences (that was
done with environment variables). After that, the issue was differences
between projects.
Does anyone else agree/disagree with that assessment?
The "levels", what each is for, accepted options, etc. need defining, and I
am sure Paul is planning to do so and share as he plans and begins the
"brave new world" for the config and build subsystem. I look forward to
that!
> >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.
Great. I think your new stuff will be interesting and useful to try and
use, especially if you structure it separately so it is very easy to flip on
and then flip off if needed, like Paul said.
> >#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.
Where will the global emacs config go?
What is the "user stuff"...is that the environment settings you were
mentioning? And that will be in a localized file per user?
> >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.
Indeed an improvement! Isolating local environment settings (e.g. tool
install directories) to each machine is a big help.
> >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.
If I understand your point and questions correctly...
Using environment variables was the easiest solution I saw for the
environment abstraction without further development. It is not something I
want/must do, and would happily drop that practice in favor of another,
better solution.
I prefer the ability to have a separate config per user for all environment
things, as mentioned previously. That way, we can easily share project
config and individually tailor where our tools are installed, where we place
source and target files (e.g. for most of my stuff it is $DEVROOT/src/...,
$DEVROOT/target/class....), etc.
> >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.
Yes...builds must be reproducible and not depend on an IDE. My jury is
still out on build systems supplanted within the editor environment. I like
the integration - that Emacs/JDE can call out. However, I prefer the
_support_ of tools like Make, Ant, Odin, etc., vs configuring an editor tool
with the same build info too.
For example, one of the "best practices" practice is having a nightly build.
It is duplication of effort/info to setup (insert your favorite build
tool(s), e.g. makefiles) for stand alone builds, and then setup JDE,
JBuilder, Cafe, etc. to build too. Currently for build/compile, I use JDE
for compilation of the current buffer, and leave system builds to the build
environment e.g. make, etc.).
