emacs-devel
[Top][All Lists]
Advanced

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

Re: A unified project root interface


From: David Engster
Subject: Re: A unified project root interface
Date: Sat, 16 Mar 2013 23:59:39 +0100
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2.93 (gnu/linux)

Jorgen Schaefer writes:
> On Sat, 16 Mar 2013 15:18:50 +0100
> David Engster <address@hidden> 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.

-David



reply via email to

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