Re: Is EDE only intended to be used with languages which /require/ a 'compile' step? [was: Re: IDE]

[Eric Ludlam <eric@siege-engine.com>]

On 10/16/2015 11:24 PM, Alexis wrote:
>
> Eric Ludlam <ericludlam@gmail.com> writes:
>
>> EDE's framework starts with no assumptions about anything other than a
>> basic "compile", and letting the project implementation populate it.
>
> It seems to me that this assumption only holds for programming languages
> which require a distinct compile step in order to produce an executable
> program. If EDE isn't intended to be used with languages such as Python,
> JavaScript, Ruby, Lua, Perl etc., fair enough - but this should be made
> clear in this discussion and in the EDE documentation, so that
> developers/users wanting an Emacs-based software project management
> system for such languages can focus attention/efforts elsewhere (e.g.
> Projectile, project.el).

EDE's original intent was for handling compilation of compiled 
languages.  Since then, it also forms a base for anything that wants to 
organize code into a 'project' so that support code can say "what is the 
current project" and then "does that project have a language specific 
detail I can use".  It doesn't really matter if it compiles or not.

If your specific language has no need of a centralized project info, 
then sure, it won't need EDE.  If python, JS or whatever may need 
different information such as include paths, browser to connect to from 
Emacs, etc, then that could be wrapped up in EDE.

The advantage would be a consistent way to think about each step in 
using the project.  Your C++ project may have entirely different steps 
in the workflow than javascript, but users would know to look into the 
Development menu to see what that project can do.

In addition, EDE, plus other parts such as Semantic or SRecode provide 
project and language independent ways to get at basic questions, so 
tools like ECB or Speedbar can display information independent of 
language.  The more language specific the request, the harder that is of 
course, but having one place to get at the data makes writing those 
tools easier.

Eric