Re: progmodes/project.el and search paths

[Nix <nix@esperi.org.uk>]

On 9 Aug 2015, David Engster outgrape:

> Stephen Leake writes:
>> Nix <nix@esperi.org.uk> writes:
>>> On 3 Aug 2015, Stephen Leake told this:
>>>> I prefer to cache it in a global variable; that way, I have only one
>>>> project active at a time, for all buffers.
>>>
>>> That doesn't work very well for those of us working on multi-component
>>> projects. 
>>
>> Fine; of course this behavior should be user-configurable.
>>
>> At the same time, I work on multi-component projects all the time, and
>> one active project works for me.
>>
>>> If I'm working in the Linux kernel I do *not* want identifier
>>> search or file lookup wandering into glibc or Emacs, even though they
>>> share some identifiers (with completely divergent definitions) and even
>>> though I may have quite a lot of buffers open on those projects.
>>
>>> (I have fairly often worked on things that affect glibc, binutils, GCC,
>>> and the kernel all at once. Those are different projects with distinct
>>> roots, identifier sets, and tags tables...)
>>
>> But if you are in glibc, looking at an identifier for a function that
>> happens to be defined in the linux kernel, you want to be able to find
>> the corresponding definition; the linux kernel is a subproject of
>> glibc (which is a subproject of higher level projects like Emacs).
>
> I must say I find this to be a very unusual view.

In this specific case, I'd call it strictly incorrect. I picked those
examples for a reason: they're an example of two sorta-related projects
which define identical identifiers which relate to *different things* in
each project: the kernel is in effect a freestanding environment and
*does not* depend on glibc (indeed, the opposite is true, glibc depends
on the kernel, even though it cannot resolve any symbols in it and no
identifier lookups should ever traverse from the one to the other).

e.g. the kernel defines many of the *printf() functions, and so does
glibc -- but they define them in different places. If something inside
glibc references snprintf(), the identifier lookup should proceed within
glibc alone: if something inside the kernel references snprintf(), it
had better find the copy in the kernel's lib/vsprintf.c.

(Meanwhile, there are a lot of projects that really *do* depend on each
other and symbol resolution in one can look up symbols in the other: it
would be nice if identifier search could follow that, but it is very far
from crucial.)

>> So the Emacs project tools should reflect that. For example, file name
>> completion must handle duplicate file names. That's a problem right now
>> in Emacs for elisp files; there are both lisp/cedet/ede/dired.el and
>> lisp/dired.el in Emacs core.
>
> This is a different problem. You are within one project here; of course
> a project system should be able to handle this.

Yes indeed.

-- 
NULL && (void)