Re: progmodes/project.el and search paths

[David Engster]

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