From: joakim@verona.se
To: Jorgen Schaefer <forcer@forcix.cx>
Cc: emacs-devel@gnu.org
Subject: Re: A unified project root interface
Date: Sun, 17 Mar 2013 09:08:37 +0100 [thread overview]
Message-ID: <m31ubea1oa.fsf@chopper.vpn.verona.se> (raw)
In-Reply-To: <87ehffuf1g.fsf@engster.org> (David Engster's message of "Sat, 16 Mar 2013 23:59:39 +0100")
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
next prev parent reply other threads:[~2013-03-17 8:08 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
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 [this message]
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=m31ubea1oa.fsf@chopper.vpn.verona.se \
--to=joakim@verona.se \
--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.