[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: Tue, 4 Aug 2015 02:21:08 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0

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

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.

reply via email to

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