[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Managed builder questions
|
First of all, I'm not talking about CDT 2.0 implementation. There is a
plan, deadline is not so far, and we shouldn't change it if the issues
are not really critical.
I starts from two browse buttons:-))
Of course, we are not obliged to show user all internal stuff, for
example., how we are storing elements in manifest files. I'll try to
clarify my point below.
Imagine there are two users A a B working on one and the same project.
Let user A keeps workspace in C:\workspace folder , and user B keeps
workspace in D:\workspace folder. The project they are working now (say
proj1) uses additional includes from another project (say proj2). It's
easy to solve, just if path you are going to store in manifest starts
from $(WORKSPACE_ROOT) . IDE before storing can transform it to some
more generic format. In this example if user A is going to store
C:\workspace\proj2, IDE can replace C:\workspace and transform it to
something like $(WORKSPACE_ROOT)\proj2, and then when user B opens the
same project, IDE can re-transform it to D:\workspace\proj2. The things
are getting worse if proj2 is located out of workspace. In my example,
for A it could be C:\proj2, and for B - D:\proj2. For IDE user there is
no difference between projects that are located in or out workspace. But
I have no idea (opposite to the first example) how to store this path
but to use something like $(PROJ2_ROOT). In any particular session IDE
can resolve this paths. But in this case I don't see any way besides the
user's hint (second Browse button :-))) how IDE can understand that.
Maybe I over complicate the issue, but many customers for different
reasons like the ability to keep their projects out of workspace. .