Re: progmodes/project.el and search paths

[David Engster <deng@randomsample.de>]

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. Just because a program
depends on libc, the libc is not a "subproject". Instead, you have a
dependency on a library which has a fixed API. The only thing you need
are the declarations of the API and the needed type definitions, which
are given through the system headers, but those hardly qualify as a
"subproject"; they simply state how libc functions must be called. I
don't care how printf is implemented; in fact, I might have to switch to
musl or ulibc if my target system can't handle glibc's size. You can of
course have the full glibc and Emacs sources loaded as projects at the
same time, but they are separate projects on the same level in the
project hierarchy.

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

-David