emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is EDE only intended to be used with languages which /require/ a 'co


From: Eric Ludlam
Subject: Re: Is EDE only intended to be used with languages which /require/ a 'compile' step? [was: Re: IDE]
Date: Sat, 17 Oct 2015 10:09:47 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 10/16/2015 11:24 PM, Alexis wrote:

Eric Ludlam <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]