[Top][All Lists]

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

Re: progmodes/project.el and search paths

From: Dmitry Gutov
Subject: Re: progmodes/project.el and search paths
Date: Mon, 3 Aug 2015 18:13:38 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0

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. Or different "types" of projects the consumer will have to "cast" the project object to.

In any case, you'll need to present a use case first. 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.

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

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.

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?

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

So, the API would not only list the variables, but also somehow describe the possible values.

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.

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.

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.

reply via email to

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