[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Engster
Subject: Re: running EDE from a file that is not under a project root dir
Date: Fri, 07 Aug 2015 16:53:59 +0200
User-agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.4 (gnu/linux)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]