Re: IDE

[Eric Ludlam]

On 10/15/2015 12:21 AM, Dmitry Gutov wrote:
> It's fine for several project systems to do the same thing.  They could
> > share some implementation or not, depending the way any set of lisp
> > programs might.  Many shared behaviours are pushed up in the class
> > hierarchy.  For example, handling include paths, java classpath, etc.
> > For most things like 'compile', the similar code is about appending the
> > string "make " with some target, or whatever it might be, so it isn't
> > too deep.
>
> It's nice when things can fit into the single-inheritance hierarchy.
>
> But consider if there are several axes of customization. For example, 
> if we have Java, Scala and Groovy based projects, and each sort can 
> use Ant, Maven or, say, SBT.
>
> Will that be 9 project definitions that someone will have to type out?
>
> If we decouple the "build system" from "project", however, that would 
> be just 6 definitions, and one could add to either set without having 
> to create multiple new definitions.
>
> So, for project.el it seems appropriate to add either a variable 
> (project-build-system) or a hook similar to project-find-functions.
>
> Does a lot of code in EDE *really* need to know what build system a 
> project uses?

EDE, the high level framework, doesn't care about the build system.

Any particular project type may or may not care about the build system.  
Some do because they are the build system.  Some do because they look in 
the config files to try to extract some handy nuggets of information.  
Some do because the build system leaves a file behind that can be 
detected as the root of the project.

Several just let you configure a text string that says how to fork off 
the 'compile' command and leave it at that.

For your example above someone who is familiar with those tools would 
pick the best way to detect a project (maybe by build system like ant, 
or by some other means) and also pick the best way to extract whatever 
data is needed, such as a command to pass to 'compile', and hopefully a 
classpath.  It might be 6 independent types that share a lot of code or 
baseclasses, or maybe one hybrid. I don't think it really matters.

In the end, EDE the framework provides a common set of:
* commands a user can use to interact with the project such as compiling.
* A place to put logic that helps other tools that have project
  dependencies such as include paths, classpath, or project root detection.

The individual EDE projects then layer on bonus features, such as 
creating a specialized project (such as Android or Automake) from 
scratch, handling configurations, and a few other random things.

Eric