Re: A unified project root interface

[joakim@verona.se]

David Engster <deng@randomsample.de> writes:

> Jorgen Schaefer writes:
>> On Sat, 16 Mar 2013 15:18:50 +0100
>> David Engster <deng@randomsample.de> wrote:
>>
>>> I think we don't need another project mechanism in Emacs. EDE and
>>> dir-locals should be enough. What we have to do however is to develop
>>> at least one very basic project type in EDE which can be used similar
>>> to project-root.el.
>>
>> Unless you create this in a way that is usable without requiring (or
>> understanding) EDE, I fear that it will not be used by many
>> other packages. And that's the issue I started this thread for.
>>
>> The issue is not that we would not have a way to define a project. We
>> do. Dozens of them, actually. Every package has their own. It's so
>> trivial to do for 90% of all use cases that most packages just write
>> their own code.
>
> I think the main issue is that every "language community" has a
> different view of what a "project" entails, so existing solutions are
> often missing something crucial, or things that should be easy to do are
> too cumbersome. It's the same reason why almost every new popular
> programming language sooner or later comes along with its own build tool
> (Rake, SCons, Maven, Ant, Leiningen, CMake, and so on). It's always
> better to have something specifically aimed at the tool-chain you're
> using. In my opinion, this is the reason why so many people develop
> their own project definitions in Emacs: they want something with
> precisely the functionality they need, nothing more or less.
>
> EDE has developed into a framework for writing such specialized projects
> in. If you want to *develop* such a specialized project type for your
> tool-chain, you indeed need to understand the inner workings of EDE,
> which mostly means to first learn EIEIO syntax, which I guess is what
> most people don't like about it. However, if you just want to *query* a
> project object for something, all you need to know is 'oref', and even
> that could be wrapped in helper functions if needed.
>
> It is entirely possible to write a project type so that it is very
> simple to use for end users. I think our C/C++ project wrapper is a good
> example for this, where you define a project like this:
>
>    (ede-cpp-root-project "NAME"
>          :file "~/myproject/Makefile"
>          :include-path '( "/include" "../include" "/c/include" )
>          :system-include-path '( "/usr/include/c++/3.2.2/" )
>          :spp-table '( ("OS_GNU_LINUX" . "1") ))
>
> I'd argue this is already similar to how projects are defined in
> project-root.el. This is all a user has to use, and every file loaded
> from that project will have a buffer local ede-object, from which you
> can easily extract those attributes. This project type was deliberately
> created for people who don't want to explicitly mess with targets,
> linkers, compilers, object files, dependency generation, 'clean' rules,
> and so on. My suggestion was to create something similar, but more
> generic and not explicitly aimed at C/C++. We already have a 'generic'
> project type, which IMO comes close.

I would just like to voice my support for EDE. It is a good base for
further facilities.

The critique is also correct though, that it has been too complicated to
setup a very simple project type. That should be something that we that
are interested in CEDET should continue to work on. It has all the
facilities one might ask for with a project base framework in
Emacs. (That doesnt mean that others can't keep on working on their own
competing solutions of course, in the time honoured tradition of
Emacs-hackers)

>
> -David
>

-- 
Joakim Verona