Re: Project systems (again)

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 18 Apr 2014 00:07:20 -0700
> From: Daniel Colascione <dancol@dancol.org>
> CC: emacs-devel@gnu.org
> 
> > FWIW, I'd prefer that you work with EDE developers to improve and
> > extend what they have;
> 
> If EIEIO can't be preloaded (or, equivalent morally, autoloaded on
> find-file), there's no point in pursuing EDE improvements. An EIEIO-less
> EDE would be an EDE rewrite anyway.

I don't know enough about this: why couldn't EIEIO be autoloaded?

> Plus, I don't think the problem space really warrants a complex
> object system: conventional elisp idioms are adequate.

Since EDE is already there, I think this is a moot point.  (I believe
Eric explained why this design was chosen a while ago.)

> > starting from scratch (or almost from scratch)
> > sounds like waste of effort, especially since some of the EDE is
> > already in Emacs. 
> 
> I really don't want to start from scratch, but I think it's the best
> option. A project system is one of those systems for which the hard part
> isn't the coding, but agreeing on having a single interface to the code.
> I think we need something much simpler than what exists.

Then how about asking the EDE developers to provide an "easy-ede"
layer which would conceal the complexity for those situations where
the corresponding power is not needed?

> I find the abstractions in EDE to be much more confusing than they are
> useful. For something that, at its core, ought to be very simple, there
> are too many concepts --- target, project, sub-project, config, project
> placeholder, too much shared state, and too few opportunities for ad-hoc
> customization. The system feels specialized for a project based on
> nested autoconf files that build C and C++, and the documentation
> reflects that. I understand that EDE started simple and grew
> functionality, but this functionality belongs in separate layers, not
> mingled into the core.

I see your point.  However, EDE was added to Emacs with the intent
that it serves as basis for developing features such as what you have
in mind.  If there's a reasonably practical way of basing your project
on EDE, I think we should explore that possibility first, even if it
requires more work on the EDE infrastructure side, because not doing
so would waste the effort of integrating EDE into Emacs.