From: David Engster <deng@randomsample.de>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: Eric Ludlam <eric@siege-engine.com>,
Emacs Development <emacs-devel@gnu.org>
Subject: Re: progmodes/project.el and search paths
Date: Mon, 03 Aug 2015 23:35:20 +0200 [thread overview]
Message-ID: <87lhdsys13.fsf@isaac.fritz.box> (raw)
In-Reply-To: <55BF8522.4010009@yandex.ru> (Dmitry Gutov's message of "Mon, 3 Aug 2015 18:13:38 +0300")
Dmitry Gutov writes:
> On 08/03/2015 05:27 PM, David Engster wrote:
>
>>> What linker and pre-processor? Seriously, you're talking to a Ruby
>>> developer here.
>>
>> Just because Ruby does not have them, project.el should not have support
>> for different toolchains?
>
> I'm not sure yet how to fit the toolchain-specialized aspects
> best. Maybe we'll have a set of methods that are optional to
> implement.
You mean like ede-compile-project?
> In any case, you'll need to present a use case first.
I hit a key, the project gets compiled by calling some build command
based on the currently selected configuration.
> If that information will only be consumed by functions inside EDE
> itself, there's not much use in making it a part of the general API.
I don't understand this.
>>> What aspects of "setting up a debugger" would you consider
>>> generalizable over different project systems?
>>
>> A debugger needs to know where the executable is and how it should be
>> called.
>
> Just for your reference, the ways I tend to use the debugger in Ruby
> projects are quite different from calling it with a path to the
> executable.
>
> Or consider some Java web application project. To launch it in debug
> mode, you pass an argument to the application launcher, and then an
> application (maybe the IDE itself) connects to it via a socket.
Yes, the notion of "debugging the project" varies wildly; same goes for
"running the executable". You can also add remote debugging on a target
platform through a debug server. Why not try to support it all?
>> If you say "compile this project", you will usually not call the
>> compiler directly but run some external build systems. Depending on the
>> current configuration (debug/release), it must be called differently.
>
> Is there something there to be automated in Emacs, that will save the
> user a lot of effort, compared to 'make env=DEBUG' in the console?
Every switch away from Emacs is a distraction. These are things I have
to do *many* times a day. Besides, I need the Make output in a
compilation buffer, so that I can jump to errors, etc.
>> Yes. I might need to set things like CFLAGS dependend on the current
>> configuration. Or I might want to cross-compile, in which case I need to
>> set ARCH and CROSS_COMPILE.
>
> So, the API would not only list the variables, but also somehow
> describe the possible values.
The user can switch between different configurations, and dependend on
the current configuration a certain set of environment variables is used
when the build system is called.
>>> If people such as yourself help identify more pieces of knowledge that
>>> apply to most projects out there, I'd be happy to add them.
>>
>> I've mentioned a few.
>
> I hope you can see that there's more design work to be done that just
> mentioning them.
Of course, but since I'm quite happy with EDE, that's not an itch I need
to scratch. You volunteered to create a project API, and I simply state
what I would expect from such an API to be usable for me, as an EDE
user. I don't want to sound so negative, and I surely don't want to
discourage your efforts. A simple API that defines a certain set of
directories based on the current buffer could cover a lot of what users
need. While I still think that EDE could support this, it has the huge
drawback that it cannot be automatically loaded at startup because of
EIEIO.
>> If you add support for this, your simple API will
>> grow, and I wouldn't be surprised if in the end it looks a bit like EDE.
>
> I guess we'll have to see. But for now, compare the 140-line long
> project.el and 12000 lines in ede.el and ede/*.el combined.
You are comparing what is essentially an interface definition, covering
a tiny amount of the EDE API, against the whole EDE suite. That factor
is hardly surprising.
I'm the first to say that EDE needs a serious overhaul. I also wouldn't
object to simply require that the user already has a working build
through whatever build system she chooses (make, ninja, ant, gradle,
rake, you name it), which would mean we could drop a lot of stuff like
the automatic Makefile generation.
>>> Aside from that, EDE is a project system obviously geared towards
>>> C/C++ development.
>>
>> It can (and does) support other languages.
>
> It contains a lot of stuff that's useless from a Ruby developer's
> standpoint (or Python, or Elisp, or R), and it doesn't compensate that
> with a lot of features.
So if those features are only needed by compiled languages they don't
count? This indeed will keep things simple...
-David
next prev parent reply other threads:[~2015-08-03 21:35 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-02 13:52 progmodes/project.el and search paths Eric Ludlam
2015-08-02 17:17 ` Dmitry Gutov
2015-08-03 1:19 ` Eric Ludlam
2015-08-03 16:16 ` Stephen Leake
2015-08-03 22:56 ` Dmitry Gutov
2015-08-08 13:07 ` Nix
2015-08-09 5:18 ` Stephen Leake
2015-08-09 12:17 ` David Engster
2015-08-09 15:55 ` Stephen Leake
2015-08-10 11:29 ` David Engster
2015-08-10 16:43 ` Stephen Leake
2015-08-12 10:10 ` David Engster
2015-08-12 13:49 ` Stephen Leake
2015-08-12 15:36 ` David Engster
2015-08-13 11:53 ` Nix
2015-08-13 12:05 ` Dmitry Gutov
2015-08-14 11:52 ` Eric Ludlam
2015-08-14 22:30 ` Dmitry Gutov
2015-08-15 0:48 ` Eric Ludlam
2015-08-15 7:05 ` Eli Zaretskii
2015-08-10 17:12 ` Nix
2015-08-03 22:47 ` Dmitry Gutov
2015-08-04 11:52 ` Eric Ludlam
2015-08-04 16:09 ` Dmitry Gutov
2015-08-03 13:49 ` David Engster
2015-08-03 14:09 ` Dmitry Gutov
2015-08-03 14:27 ` David Engster
2015-08-03 15:13 ` Dmitry Gutov
2015-08-03 21:35 ` David Engster [this message]
2015-08-03 23:21 ` Dmitry Gutov
2015-08-04 8:15 ` David Engster
2015-08-04 13:43 ` Eli Zaretskii
2015-08-04 18:05 ` Dmitry Gutov
2015-08-04 18:16 ` Eli Zaretskii
2015-08-04 18:41 ` Dmitry Gutov
2015-08-04 19:23 ` Eli Zaretskii
2015-08-04 19:40 ` João Távora
2015-08-05 2:52 ` Eli Zaretskii
2015-08-04 20:15 ` Dmitry Gutov
2015-08-05 2:49 ` Eli Zaretskii
2015-08-05 6:18 ` Stephen Leake
2015-08-05 15:08 ` Eli Zaretskii
2015-08-05 15:36 ` Dmitry Gutov
2015-08-05 16:31 ` Eli Zaretskii
2015-08-05 16:45 ` David Engster
2015-08-05 22:17 ` Dmitry Gutov
2015-08-06 7:56 ` Stephen Leake
2015-08-06 7:54 ` Stephen Leake
2015-08-05 9:42 ` Dmitry Gutov
2015-08-05 15:23 ` Eli Zaretskii
2015-08-05 15:31 ` Dmitry Gutov
2015-08-05 16:16 ` Eli Zaretskii
2015-08-06 6:44 ` Dmitry Gutov
2015-08-06 7:43 ` Stephen Leake
2015-08-06 10:25 ` Dmitry Gutov
2015-08-06 14:27 ` Stephen Leake
2015-08-06 23:16 ` Dmitry Gutov
2015-08-07 14:10 ` Stephen Leake
2015-08-07 14:44 ` Dmitry Gutov
2015-08-03 16:35 ` Stephen Leake
2015-08-03 16:45 ` Eli Zaretskii
2015-08-03 21:07 ` Stephen Leake
2015-08-03 21:33 ` David Engster
2015-08-04 2:35 ` Eli Zaretskii
2015-08-03 15:09 ` Eli Zaretskii
2015-08-03 15:16 ` Dmitry Gutov
2015-08-03 15:29 ` Eli Zaretskii
2015-08-03 19:01 ` Dmitry Gutov
2015-08-03 19:19 ` Eli Zaretskii
2015-08-03 21:05 ` Dmitry Gutov
2015-08-04 11:48 ` Eric Ludlam
2015-08-04 16:20 ` Dmitry Gutov
2015-08-03 16:25 ` Stephen Leake
2015-08-03 21:33 ` Stefan Monnier
2015-08-03 22:15 ` David Engster
2015-08-03 22:50 ` Dmitry Gutov
2015-08-04 7:13 ` Stefan Monnier
2015-08-04 8:13 ` David Engster
2015-08-05 13:42 ` Stefan Monnier
2015-08-06 11:27 ` {Spam?} " Eric Ludlam
2015-08-06 23:10 ` Stefan Monnier
2015-08-07 11:18 ` Eric Ludlam
2015-08-07 11:43 ` David Engster
2015-08-07 12:17 ` Dmitry Gutov
2015-08-07 12:40 ` David Engster
2015-08-07 12:54 ` Dmitry Gutov
2015-08-07 12:08 ` Alexis
2015-08-04 9:40 ` Stephen Leake
2015-08-04 17:43 ` Dmitry Gutov
2015-08-04 19:49 ` Stephen Leake
2015-08-04 20:03 ` Dmitry Gutov
2015-08-05 6:02 ` Stephen Leake
2015-08-05 9:59 ` Dmitry Gutov
2015-08-06 7:25 ` Stephen Leake
2015-08-07 14:21 ` Dmitry Gutov
2015-08-05 1:29 ` Eric Ludlam
2015-08-11 20:01 ` Dmitry Gutov
2015-08-12 0:49 ` Eric Ludlam
2015-08-12 7:25 ` project terminology Stephen Leake
2015-08-12 9:28 ` progmodes/project.el and search paths Dmitry Gutov
2015-12-29 2:00 ` Dmitry Gutov
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lhdsys13.fsf@isaac.fritz.box \
--to=deng@randomsample.de \
--cc=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=eric@siege-engine.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).