Eclipse/Carbide workspaces.

[svdwal]

I am having a problem understanding the Eclipse/Carbide workspace concept, in terms how they are related to Eclipse/Carbide projects. I have looked in the usual places but the only thing worth mention about it was that it is a place to store projects.

This would be fine in itself, weren't it for the problems that I have using Carbide C++ express on my existing projects. It just doesn't work, I get incomprehensible error messages. Creating new projects works fine but that is not the point here.

Let me elaborate.

My projects are stored in a folder structure like this (i'll only mention the mmp files )

/shared/mbrain/prj1/prj1_s60/rel_x_yy/prj1_s60/group/prj1_s60.mmp
/shared/mbrain/prj1/prj1_s80/rel_x_yy/prj1_s80/group/prj1_s80.mmp
/shared/mbrain/prj1/prj1lib/rel_x_yy/prj1lib/group/prj1lib.mmp

The idea is having a shared library prj1lib being used by the two UI-dependent S60 and S80 apps.

Using MS C++ and CW the projects are easily identified, by the parent folders of the mmp files. As both CW and MS C++ do not have a workspace concept, you do not have to mention this.

With Eclipse, there are a number of possible workspace candidates:

/shared/mbrain/
or
/shared/mbrain/prj1
or
/shared/mbrain/prj1/prj1_s60/rel_x_yy/
/shared/mbrain/prj1/prj1_s80/rel_x_yy/
/shared/mbrain/prj1/prj1lib/rel_x_yy/

The third one seems a bit silly, but whether the first or the second one is the best? I don't know, and the documentation doesn't tell me enough to make a sound decision.

[timm-ah]

Hi - You typically just want to have one workspace, e.g. "/shared/mbrain/" and when you import your projects either from MMP or INF file you just keep this workspace as the location of your (Carbide) project files. This is assuming you import without copying source files to the workspace.

How you set this up also may depend on whether you are working with version control and if you plan on checking in any of the Carbide generated project files.


Tim

[svdwal]

Hi - You typically just want to have one workspace, e.g. "/shared/mbrain/" and when you import your projects either from MMP or INF file you just keep this workspace as the location of your (Carbide) project files. This is assuming you import without copying source files to the workspace.

Ok, when I use /shared/mbrain/ as the workspace path, and I then import a mmp file in /shared/mbrain/prj1/prj1lib/rel_x_yy/prj1lib/group, Eclipse/Carbide creates it metadata folders in /mbrain/shared/prj1lib and not in /mbrain/shared/prj1/prj1lib/rel_x_yy/prj1lib, as I would expect it to as that is the project path for a Symbian OS project.

This makes Eclipse/Carbide in it's current state a very dangerous tool to use. Key behaviour is not properly documented so the effects on an existing codebase can only be assessed by time-consuming experimentation

How you set this up also may depend on whether you are working with version control and if you plan on checking in any of the Carbide generated project files.

Tim

This makes the tool even more dangerous. I would like to know what is possible regarding version control before plaiing a project folder structure, and not run into all kinds or trouble after designing it.

I would say that it this moment using Eclipse/Carbide for existing projects is simply too dangerous as it is not known what it does to the project. Forking out for the Developer version is therefore out of the question.

If I might make a suggestion, I think that there should be an example project consisting of a engine dll with at least two different UI on top of it (lets say S60 and UIQ, or S60 and S80). The code itself can be trivial, an edwin to enter some text in, something like that. What should be clear is the folder structure of the project. Further it must be possible to use proper version control. By this I mean that it must be possible to have at least two different releases of the entiere project checked out and being edited. This mimics the situation of doing new developments on the trunk, while fixing bugs on a release branch.

[timm-ah]

[QUOTE=svdwal]
I would say that it this moment using Eclipse/Carbide for existing projects is simply too dangerous as it is not known what it does to the project. Forking out for the Developer version is therefore out of the question.

QUOTE]

I agree that it's confusing knowing all the different behaviours and ways to manage projects. It seems to me that your concern is keeping Carbide.c++ projects synchronized with the MMP file. Is this correct? Are you wanting clearer info on what files Carbide generates (eg .project, cdtproject) and what files Carbide synchronizes (e.g. MMP/INF) and how the project interacts with the file system?

I think in your case, the best way to work is to import your project (not copying files to the workspace) and just use version control for your sources and don't keep the Carbide project files around.

And the suggestion for a cross-ui example is a good one. I'd like to see more mulit-module examples/templates as well which we'll be able to support better in the next release (currently wizard projects only support one MMP file.)

Thanks,
Tim

[svdwal]

I agree that it's confusing knowing all the different behaviours and ways to manage projects. It seems to me that your concern is keeping Carbide.c++ projects synchronized with the MMP file. Is this correct? Are you wanting clearer info on what files Carbide generates (eg .project, cdtproject) and what files Carbide synchronizes (e.g. MMP/INF) and how the project interacts with the file system?

I am not concerned about the mmp file being automatically updated when I do something to a carbide project after importing. Neither MS VC++ nor CW do this and reimporting an mmp file is no big deal. Building from the command line must be possible anyway as that's the only way one can do automated builds. So the mmp file is the main file and any IDE project file is a derivate of it. I am also not interested in the exact contents and meanings of these files, and neither was I in the exact structure of the MS VC++ or CW project files.

That way I stay independent of an IDE, which is good as we get a new one each year.

No, my problem lies with the concept of an Eclipse workspace. It appears that it can only support project folder structures like this

/shared/mbrain/prj1/prj1lib/group

with /shared/mbrain/prj1lib both the workspace and the project.

When one creates
/shared/mbrain/prj1/prj1lib/group
/shared/mbrain/prj1/prj1_s60/group
/shared/mbrain/prj1/prj1_s80/group

to build a s60 and a s80 variant, it won't work, I think. There are three different projects here, prj1lib to be compiled for both S60 and S80 SDK's, prj1_s60 compilable with a S60 sdk and prj1_s80 compilable with a S80 sdk.
There are also three different workspaces here. The prj1lib workspace would then only consist ot prj1lib itself, the prj1_s60 workspace would consist of prj1lib and prj1_s60 and the prj1lib_s80 workspace would consist of prj1_s80 and prj1lib. Both the prj1_s60 and the Prj1_s809 workspace would be rooted in /shared/mbrian/prj1, and I think this is going to be a problem because I think that the eclipse project files of workspace prj_s60 will clash with the files of prj1_s80.

It appears natural to have both the engine project and the UI project in a single workspace, because yoyu can then easily debug problems when you don't know if the defect is in the engine or the UI.

But because Eclipse stores its project files in the workspace itself, you cannot have two workspaces in a single folder. Neither CW not MS VC++ has this problem. MS VC++ 6.0 can only open one project at a time, and CD doesn't have workspaces, only projects.

The only solution I see is to puit the prj1lib files in the prj1_s60 and S80 folders too like this:

/shared/mbrain/prj1/prj1lib/group

/shared/mbrain/prj1/prj1_s60/group
/shared/mbrain/prj1/prj1_s60/prj1lib/group

/shared/mbrain/prj1/prj1_s80/group
/shared/mbrain/prj1/prj1_s80/prj1lib/group

There are now theree projects and workspaces. First is prj1lib, with prj1lib both the project and the workspace. The second is prj1_s60, with prj1_s60 the workspace and prj1_s60 and prj1_s6p/prj1lib the projects, and the third is the same , but the using the S80 folder. This is essentially the folder structure one would use for the CVS trick of using a vendor library source folder.

Fixing a defect in prj1lib then involves lots of extra checkins and checkouts of prj1lib in the diverse prj1 folders.

I think in your case, the best way to work is to import your project (not copying files to the workspace) and just use version control for your sources and don't keep the Carbide project files around.

And the suggestion for a cross-ui example is a good one. I'd like to see more mulit-module examples/templates as well which we'll be able to support better in the next release (currently wizard projects only support one MMP file.)

Thanks,
Tim

[wapawapa]

I think there's some confusion about what the workspace really is. Eclipse has the concept of a workspace as the "default" place to store things. It will always create the .metadata folder there which stores prefs and such. You can optionally create projects in it as well. This is the default location when you create new projects.

When working with existing Symbian projects (bld.inf, 1 or more mmps), you can copy the project into the workspace, or create a "link" to it in the filesystem. The former is really only useful for importing examples and such so you get a local copy that you can make your own and change without affecting the original copy in the SDK.


The linked approach is recommened for existing projects. It leaves your source code where it lives in the filesystem. The .project files are created in the workspace though, so your project's file structure is not contaminated by these files.

That's really all there is to it. You can leave the workspace as the default, or just C:\Carbide_workspace or whatever. Then import your 3 projects using links. Now you can work on all three at once, or all 6 (if you have two branches of the source checked out).

I hope that helps. Let me know if you have any other questions.

Thanks,
Warren

[svdwal]

I think there's some confusion about what the workspace really is. Eclipse has the concept of a workspace as the "default" place to store things. It will always create the .metadata folder there which stores prefs and such. You can optionally create projects in it as well. This is the default location when you create new projects.

When working with existing Symbian projects (bld.inf, 1 or more mmps), you can copy the project into the workspace, or create a "link" to it in the filesystem. The former is really only useful for importing examples and such so you get a local copy that you can make your own and change without affecting the original copy in the SDK.


The linked approach is recommened for existing projects. It leaves your source code where it lives in the filesystem. The .project files are created in the workspace though, so your project's file structure is not contaminated by these files.

That's really all there is to it. You can leave the workspace as the default, or just C:\Carbide_workspace or whatever. Then import your 3 projects using links. Now you can work on all three at once, or all 6 (if you have two branches of the source checked out).

I hope that helps. Let me know if you have any other questions.

Thanks,
Warren

Thanks, this certainly does help a lot. In fact, I would suggest adding this text to the carbide C++ helptext.

The helptext on workspaces suggest that all projects are in the workspace itself, which I understand as that all project folders are folders inside the workspace folder. But from answer it appears this is not the norm and that all project folders live outside the workspace. Therefore I think there should be a section in the carbide helptext on how to set up Carbide for existing projects with a given folder structure, and in particular how to set up projects with shared engines and separate UI's as that is most likely to be the situation for ISV's.

[wapawapa]

Thanks, this certainly does help a lot. In fact, I would suggest adding this text to the carbide C++ helptext.

The helptext on workspaces suggest that all projects are in the workspace itself, which I understand as that all project folders are folders inside the workspace folder. But from answer it appears this is not the norm and that all project folders live outside the workspace. Therefore I think there should be a section in the carbide helptext on how to set up Carbide for existing projects with a given folder structure, and in particular how to set up projects with shared engines and separate UI's as that is most likely to be the situation for ISV's.

We'll definitely work on beefing up the docs around this area.

Thanks,
Warren