Re: [CEDET-devel] ede-expand-filename and multiple files

[Eric M. L. <er...@si...>]

On 03/24/2014 10:40 PM, Daniel Colascione wrote:
> On 03/24/2014 07:13 PM, Eric M. Ludlam wrote:
>> On 03/24/2014 09:49 PM, Daniel Colascione wrote:
>> You're question doesn't make much sense to me, so let me summarize what
>> ede-expand-filename is for.
>
> We have a project that lives under /proj/foo. It has
> /proj/foo/comp1/comp.cpp and /proj/foo/comp2/comp.cpp. There is a
> project object for /proj/foo. ede-expand-filename, called for that
> project object and comp.cpp, should return *which* comp.cpp?
>
> The whole ede-expand-filename interface seems to embed the assumption
> that file short names are unique in a project, and that's not true in
> the general case. The abstraction seems wrong: it assumes that a project
> is the same as a directory. I want to use project object for a project
> in thousands of directories. Which of those directories should host a
> file that's "force into existence" using ede-expand-filename?

Hi Daniel,

A high level answer to most of your questions in this thread and the 
other is that EDE was originally designed so that there was one 
'project' object for each directory, and it was targeted squarely at 
automake and its features circa 1996 or so.  As you suggest, this is not 
true for all projects, so EDE was adapted to help make that happen, and 
after that, it was optimized heavily for performance.

For your specific question, ede-expand-file-name was designed in a 
system where all the files were known so it could find files if they 
happened to be unique.  There are other similar tools, like ffap that 
try to do the same thing.  Also, I don't think it forces anything into 
existence.  It just expands a file name.

>> It is used in two ways.
>>
>>  From a user perspective, you can ask EDE to bring up a file foo.cpp, and
>> if EDE can find it, it will show you the buffer.  If it can't, it wont.
>
> So if it's implemented only for header files, as you suggest below,
> users will be able to use file-finding functionality only for header files?

After EDE was built, the most common use case ended up being the finding 
of header files, so the new top-level-only projects which had no master 
list of all the files all implemented only the bits needed to find 
header files.

> If there needs to be a function for locating C++ include paths, why not
> put all that logic there instead of adding this function to the core?
> EDE's abstractions are very confusing, maybe because I want to write a
> simple object for a project having nothing to do with C++. I wish EDE's
> base classes were a lot simpler.

I agree it probably makes sense to have a "find header files" type 
function if we can come up with a good abstract way to represent the 
concept.  That would separate the concerns between generic file finding 
or not such that includes paths could specify priority in the case where 
there are multiple matches separate from the global search.

I'm not sure what you mean by "in the core".  ede-expand-file-name is 
just an interface and happens to have a set of helpers in the locate 
package.

Eric