Re: IDE

[Eric Ludlam]

On 10/14/2015 07:42 AM, Dmitry Gutov wrote:
> On 10/14/2015 05:45 AM, Eric Ludlam wrote:
>
> > This is how EDE (a part of CEDET) is setup and works.  There are
> > "projects", and in projects there are "targets".  There are project
> > build commands, and target build commands.  Each project or target can
> > have language specific features for setting up CEDET's parsers.
>
> Is there a particular reason to have the notion of "target" in the 
> project API? If the need is to simply disambiguate commands with the 
> same name, the commands could be prefixed with the target name, e.g. 
> "release:compile", "release:test".

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.

> > There is a set of different base classes for projects, and many
> > specializations for various flavors of java projects such as maven and
> > ant, C++ projects, lisp projects, and more.
>
> What do you do if several different project types use the same build 
> system (and so the logic to parse the build targets is the same)?
>
> What would you do if a certain project type can be used with different 
> build systems? Create an inheriting sub-type for each of them?
>
> That approach looks worrying if we get several varying pieces of 
> behavior like that: for example, different build tools and different 
> test frameworks.
> .

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.

There are some very simple projects in EDE, such as "emacs" which just 
knows how to find emacs.c and mark that directory tree as a project, and 
it knows how to assemble some compile and debug commands.  It also knows 
how to setup C preprocessor symbols and include paths.  Other project 
types are very complex, such as those that let you configure a project 
using 'customize' and then generate Makefiles for you.   That was a bit 
of a stretch.

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.

In one of these threads someone noted that it should be easy to setup 
and transparent.  When someone's project matches a supported type, all 
you need to do is turn on EDE and it then sets up the Semantic details 
for you.  Most C/C++ projects are not as magical, and need a more hands 
on approach, and that's where things get tricky.

Eric