Re: progmodes/project.el and search paths

[Dmitry Gutov]

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
> 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.

> 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
> set ARCH and CROSS_COMPILE.

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.