Re: progmodes/project.el and search paths

[David Engster <deng@randomsample.de>]

Stephen Leake writes:
> David Engster <deng@randomsample.de> writes:
>
>> Stephen Leake writes:
>>>
>>> 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". 
>
> We are arguing about the definition of the word "subproject".
>
> The Oxford English Dictonary doesn't define it.
>
> Wiktionary says: 
>
>    A project within a larger project.
>
> I agree libc is not "within" Emacs, so apparently I'm using the word
> wrong.

Actually, EDE has support for subprojects. For instance, EDE itself is a
subproject of CEDET, just like Semantic, SRecode, and Cogre. Together,
they form CEDET. While this is nice in theory, this generates more
problems than it is worth. For instance, EDE will generate a recursive
Makefile for this, which I'm really not very fond of...

>> The only thing you need are the declarations of the API and the needed
>> type definitions, 
>
> Sometimes. There were _many_ times at NASA when I wished we had paid the
> contractor to deliver the full source code, rather than an API and user
> guide.
>
> Certainly in Emacs the doc string is often not enough, and I need to
> read the body of the function to find out what's actually going on.
>
> I often feel the need to do that in Android, but I haven't developed the
> search/cross-reference skills to be able to yet.

We are in violent agreement here. Of course you should *have* the
source. But I would not put it into a subproject. I want a flat 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. 
>
> Ok, now we are getting somewhere; this is one example of the kind of
> problems I'm trying to address.
>
>> You are within one project here; 
>
> No, 'cedet' is a library as far as I'm concerned; it has an API, I try
> to treat it as a black box. 

Sorry, but CEDET is not a library. You might think that the lisp/cedet
directory is CEDET, but that's not true (unfortunately, as it makes
merging pretty tedious). The files are scattered all over the Emacs
sources, which is also why it doesn't make sense to treat lisp/cedet as
a "subproject". The grammars are in admin/grammars, SRecode files are in
etc/srecode, documentation is in doc/misc, EIEIO is in
lisp/emacs-lisp. They are all part of CEDET (though EIEIO is now
maintained in Emacs). Originally there was even more (speedbar, for
instance).

> The fact that it is in Emacs core is just a packaging issue; it doesn't
> change the logical structure.

First and foremost, we simply have files with the same name scattered
across the Emacs source tree. dired.el, custom.el, speedbar.el,
shell.el, and many more. This is a very common thing in larger projects,
and a project system must be able to handle this.

Technically, since lisp/cedet/ede is not in load-path, those two are
different files (dired.el and ede/dired.el). Also, all the symbols
defined in those files live in different namespaces (dired- and ede-,
resp.). So really, the only issue here is when you say "give me the file
dired.el from the Emacs project", in which case the project system
should tell you that it exists twice and asks you which one to load. But
it doesn't matter when you search for symbols.

> The same problem occurs with any language library projects; if I'm
> working on top_project, and need to read the impelementation for a
> function that happens to be in library_project_1, they both need to be
> in the file completion search path.

Say I really want to see the implementation of 'foo' in glibc. I simply
load the glibc project into my workspace (to use the Eclipse lingo); it
is not a subproject, but simply another project parallel to all the
others I have loaded. I can now jump from some Emacs C source file to
the 'foo' definition.

My guess your issue is that another library might have defined a symbol
'foo' as well, and its project is also loaded in my workspace - then it
depends on the #include's in your source file. So here, a project system
must ask something like Semantic for the search path of the current
file.

-David