Re: progmodes/project.el and search paths

[Dmitry Gutov]

On 08/04/2015 12:35 AM, David Engster wrote:

> You mean like ede-compile-project?

I suppose.

And here we find out that EDE took over the project- namespace, a while 
ago. That's not nice.

> I hit a key, the project gets compiled by calling some build command
> based on the currently selected configuration.

Sounds fine to me. The respective method should probably return the 
command to compile, not perform compilation itself.

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

If the only functions that would use the information are included in 
CEDET, and there's no plans to extract them, there's no point in making 
them go through the project.el API, since they already know they're 
dealing with EDE.

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

I'm not particularly against it, just saying it's not easy to do in both 
generic and useful way.

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

Okay, the complications seem to outweigh the benefits here.

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

The API is not for a user. It's for other packages. If you're happily 
using EDE, and CEDET, and not much else, then it's unlikely to make your 
life better.

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

Yes, and that's the point. The interface definition should be clear and 
as short as possible.

> So if those features are only needed by compiled languages they don't
> count? This indeed will keep things simple...

How useful are those things for Haskell? Or ML?

Initially yet, we'll probably avoid those (if only because they're not a 
priority for me personally), but generally useful 
compiled-language-related things can be added later on.