From: David Engster <deng@randomsample.de>
To: Jorgen Schaefer <forcer@forcix.cx>
Cc: emacs-devel@gnu.org
Subject: Re: A unified project root interface
Date: Sat, 16 Mar 2013 23:59:39 +0100 [thread overview]
Message-ID: <87ehffuf1g.fsf@engster.org> (raw)
In-Reply-To: <20130316160203.6b889aba@forcix.kollektiv-hamburg.de> (Jorgen Schaefer's message of "Sat, 16 Mar 2013 16:02:03 +0100")
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.
-David
next prev parent reply other threads:[~2013-03-16 22:59 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-09 16:44 A unified project root interface Jorgen Schaefer
2013-03-09 17:12 ` Fabian Ezequiel Gallina
2013-03-10 5:38 ` Stefan Monnier
2013-03-10 10:06 ` Jorgen Schaefer
2013-03-11 18:57 ` Lluís
2013-03-12 23:28 ` Eric M. Ludlam
2013-03-12 23:42 ` Jorgen Schaefer
2013-03-13 2:02 ` Eric M. Ludlam
2013-03-13 18:03 ` David Engster
2013-03-13 19:11 ` Sudish Joseph
2013-03-16 0:47 ` Eric M. Ludlam
2013-03-16 14:18 ` David Engster
2013-03-16 15:02 ` Jorgen Schaefer
2013-03-16 22:27 ` Phil Hagelberg
2013-03-16 22:59 ` David Engster [this message]
2013-03-16 23:16 ` Jorgen Schaefer
2013-03-17 17:40 ` David Engster
2013-03-17 18:18 ` Jorgen Schaefer
2013-03-18 22:50 ` David Engster
2013-03-19 1:57 ` John Yates
2013-03-19 7:18 ` David Engster
2013-03-19 12:23 ` Eric M. Ludlam
2013-03-19 13:06 ` Stefan Monnier
2013-03-19 19:09 ` David Engster
2013-03-20 3:21 ` Stefan Monnier
2013-03-20 4:48 ` Leo Liu
2013-03-20 7:04 ` joakim
2013-03-20 7:05 ` David Engster
2013-03-20 7:13 ` David Engster
2013-03-20 12:57 ` Stefan Monnier
2013-03-20 16:14 ` Davis Herring
2013-03-20 17:41 ` Stefan Monnier
2013-03-20 17:48 ` Stefan Monnier
2013-03-20 18:20 ` Bruce Korb
2013-03-20 22:14 ` Stefan Monnier
2013-03-20 16:34 ` David Engster
2013-03-20 17:47 ` Stefan Monnier
2013-03-21 0:55 ` Eric M. Ludlam
2013-03-21 3:27 ` Stefan Monnier
2013-03-21 4:07 ` Eric M. Ludlam
2013-03-21 14:33 ` Stefan Monnier
2013-03-22 2:12 ` Eric M. Ludlam
2013-03-23 11:04 ` EIEIO split (was: A unified project root interface) David Engster
2013-03-21 16:32 ` A unified project root interface David Engster
2013-03-22 0:47 ` Eric M. Ludlam
2013-03-22 20:30 ` David Engster
2013-03-23 17:10 ` Eric M. Ludlam
2013-03-23 17:26 ` Jorgen Schaefer
2013-03-23 18:02 ` Dmitry Gutov
2013-03-23 20:51 ` Pascal J. Bourguignon
2013-03-24 4:25 ` Dmitry Gutov
2013-03-24 10:13 ` Jorgen Schaefer
2013-04-06 13:25 ` Jorgen Schaefer
2013-04-06 17:13 ` Eric M. Ludlam
2013-04-08 19:03 ` David Engster
2013-12-31 20:12 ` Daniel Colascione
2013-03-20 17:49 ` Jorgen Schaefer
2013-03-19 7:33 ` Jorgen Schaefer
2013-03-17 8:08 ` joakim
2013-03-12 15:34 ` Sudish Joseph
2013-03-12 16:51 ` Dmitry Gutov
2013-03-12 18:23 ` Ted Zlatanov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ehffuf1g.fsf@engster.org \
--to=deng@randomsample.de \
--cc=emacs-devel@gnu.org \
--cc=forcer@forcix.cx \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.