Re: running EDE from a file that is not under a project root dir

[Stephen Leake <stephen_leake@stephe-leake.org>]

David Engster <deng@randomsample.de> writes:

> Stephen Leake writes:
>
>> But that doesn't give me the full search path, because I don't know
>> which higher level project the user is working on.
>>
>> In Emacs Ada mode, the top level project is the current project; the lower
>> level projects are present as far as gprbuild is concerned, but the
>> Emacs code doesn't need to know about them. There are still many
>> top-level Ada projects that share lower-level code, so if more than one
>> top-level project was open, there would not be a one-to-one mapping from
>> file to project.
>>
>> If Eclipse and Visual Studio are like that, so the collection of
>> projects contains only top level projects, then _if_ they have disjoint
>> file sets, you can get the project from a file. But that seems unlikely,
>> and highly use case dependent.
>
> In Eclipse, you simply cannot share files or folders between projects,
> at least not with the same path. 

Ok, so the file sets are (nominally) disjoint between projects (except
for system files, which are special). Apparently that's more
likely/common than I realized.

And if you are working on several top level projects that share core
code subprojects, you have to manually switch between the top level
projects, possibly by quitting that instance of Eclipse and starting
another.

So we still need that ability in Emacs, preferably without requiring
quiting Emacs :).

> You either copy them, or you symlink them from one project into
> another.

Yuck. That totally defeats CM!

<flame>
This all sounds like a desperate effort to pretend that we are _not_
working on projects that have an inherent hierarchical structure, with
shared code at the base. Apparently that would be too hard to
understand, or something. It does require the top level teams to
actually talk to each other to manage the core code; maybe that's the
problem (software engineers are not good at talking to each other?).

I prefer to embrace the hierarchy, and develop tools to let me manage it
efficiently.
</flame>

-- 
-- Stephe