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

[David Engster]

Stephen Leake writes:
> David Engster <address@hidden> 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.

You can of course load another workspace/solution into Eclipse/VS
without quitting.

>> You either copy them, or you symlink them from one project into
>> another.
>
> Yuck. That totally defeats CM!

What CM? Content management? Configuration management? Cyanogenmod? ;-)

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

Not sure I understand you here. The usual way of code sharing I know is
to create libraries. Those have their own project, and if your project
depends on a library, you load its project into your workspace and
define a dependency on it. What's wrong with that? Would you prefer to
add it as some kind of sub-project into your project? That would be a
much stronger coupling.

-David