Re: Help needed testing EDE branch

Daniel Colascione writes:

> On 06/25/2014 01:43 PM, Lluís wrote:
>> Eric M Ludlam writes:
>> 
>>> On 06/22/2014 03:30 PM, Lluís wrote:
>>>> I also tried to run "customize-project" on a
>>>> linux project, and it looks like no file is saved with the project
>>>> customizations. I guess that's still not possible (to somehow "overlay" local
>>>> customizations on auto-detected projects).
>> 
>>> Hi Lluis,
>> 
>>> There are definitely two camps on these project types.  Some generate 
>>> your build system have save files to remember your configuration (such 
>>> as the the 'proj' type that supports creating both Makefiles and 
>>> Automake files.
>> 
>>> The other types such as Linux, Emacs, cpp-root, arduino, and the other 
>>> automake project type which all detect existing projects, and if you 
>>> want to customize them, you need to edit some file related to that 
>>> project which Emacs would read in later.
>> 
>> That makes all the sense in the world.
>> 
>> 
>>> The generic project is different in that it just tries to find some of 
>>> your code in project form, and then has a configuration that sits on top 
>>> that saves itself between sessions.   This system is nice in that the 
>>> code to make the project is simple, but you still get at the key pieces 
>>> needed for Semantic smart completion parsing, etc.
>> 
>>> I think your observation is that some of the project types such as Linux 
>>> and Emacs don't have enough automatically configured such that you want 
>>> to add some extra on top and save it away.   Perhaps the right thing is 
>>> to update 'linux' as a subclass of 'generic' but with some of the extra 
>>> goodness from ede/linux kept around for pre-configuring the system.
>> 
>> I don't have any specific use-case. I was just wondering if it would be possible
>> to, for example, customize something like cpp-root's spp-table in
>> ede-linux-project, or, for example, set some project-local variables or the
>> build command.
>> 
>> In fact, I think that saving the project-local variables across sessions would
>> be the most useful feature at this point. To me it makes sense to implement this
>> functionality in EDE, but many other tools try to do the same, and emacs also
>> has the directory-local variables.
>> 
>> I know it would be a huge effort, but do you think it would make sense to
>> refactor the project class hierarchy? For example:
>> 
>> * There could be the current ede-project as a base.
>> 
>> * Per-language subclasses, (e.g., ede-lang-c, ede-lang-c++, ede-lang-java,
>> etc.), which only care about language-specific things like include
>> directories and preprocessor macros.

> I don't think language should have anything to do with the project
> system. Plenty of projects (like Emacs!) are written in a mixture of
> languages. Projects should opportunistically define facilities that
> language modes can use, e.g., header file disambiguation, but there
> should be no such thing as a "C++ project".

Right. Why I meant is that projects can then use multiple-inheritance to enable
the language-specific features of all the languages in the project.


Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Cedet-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cedet-devel