Re: IDE

[Dmitry Gutov]

On 10/15/2015 03:14 AM, Eric Ludlam wrote:

> Historically, the 'targets' matched the makefile targets, and was used
> to generate a Makefile from a configuration.
>
> For the other projects, the targets simply group source code together so
> if you use the 'compile' key sequence, you get something appropriate for
> that group of source files.  Sometime it is very simple so that .texi or
> .cpp execute different compile steps. Sometimes there is no difference.

That doesn't sound portable: with flexibly scriptable build tools (e.g. 
Rake, and Ant, I imagine), an external tool reading the build file won't 
be able to determine, in general, which files or groups of files a task 
is related to (unless it executes the task and watches the disk for 
changes, which is not tenable).

> 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?

> Some are in between, such as the 'android' project type that finds the
> AndroidManifest.xml file, tags that tree, and queries your android SDK
> for build tools and paths to set everything up for you.

That's one of the easier cases, conceptually, because there are no 
alternative choices for build tools.