Re: progmodes/project.el and search paths

[Stephen Leake]

David Engster <address@hidden> writes:

> Dmitry Gutov writes:
>> On 08/03/2015 04:49 PM, David Engster wrote:
>>
>>>  From what I see in project.el, this is an API for defining a set of
>>> directories. I'm not saying that Emacs does not need such an API, but I
>>> would not call this a "project API".
>>
>> These are the traits common to most projects that we've identified so
>> far. Ones that a third-party package will almost always be able to
>> use.
>
> As I've said: I'm not saying it's not useful.
>
>>> What about things like setting up
>>> toolchains (compiler, linker, debugger), configurations (debug/release),
>>> support for external build systems, setting up environment variables and
>>> pre-processor symbols, and so on?
>>
>> 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?

It depends on whether there are really common features across several
toolchains.

I guess the top-level API for these things in EDE is common across
several toolchains, but I'm not clear; you've talked about some things
are in EDE 'only for Java', or only for some other backend.

I agree the core API should allow all possible backends, but there's a
trade-off. If the core includes stuff that only one or a few backends
need, then that imposes extra overhead (if only by overloading the
implementer understanding of the 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.

gud does that, but if a new debugger needs to be added, perhaps gud
should consult the project system first, rather than having a separate
way to add a debugger.

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

Right. I do that by editing Makefiles directly; M-x compile is always
"make -r <target>" for me. I've always felt that anything else just gets
in the way. Clearly I'm in the minority on this one :(>.

Although I've recently started working on JDEE, and it doesn't have a
Makefile, just an ant build.xml. So I'm trying to force myself to not
add a Makefile. We'll see. So far it's very frustrating trying to track
down exactly what ant is doing; must easier with a makefile.

>> Do you need help setting up environment variables?
>
> 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.

These seem very backend specific. How much of this is really in the EDE
core, and how much in some "make/gcc backend"?

-- 
-- Stephe