RE: [cdt-dev] 'exporting' a workspace

[Thomas Fletcher <ThomasF@xxxxxxx>]

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of dmsubs
> Sent: January 20, 2006 10:31 AM
> To: kesselhaus@xxxxxxx; 'CDT General developers list.'
> Subject: RE: [cdt-dev] 'exporting' a workspace
> 
> Please remember, I am trying to obtain an excellent 'out of 
> box' experience for my users. They are experienced embedded 
> application developers who have used other IDE's before, but 
> this is very likely their first exposure to Eclipse. I want 
> to get them up and running quickly with Eclipse and leave 
> them with a 'warm and fuzzy' feeling about Eclipse.

See my comments below, but in order to achieve this, you are 
almost always going to have to do some additional configuration
and customization to automate a few things that a normal Eclipse
import/export would just "do manually".  

> Bearing this in mind, there are several problems with the 
> project export/import mechanism.
> 
> 1. It doesn't import/export items that are defined in the 
> workspace. For my projects, I also need to define the debug 
> and run launch configurations.
> This needs to be set up for each project. For example, I need 
> to set up the the debugger name ('xx-elf-gdb' instead of 
> 'gdb'), define a gdb ini file, define the application 
> arguments etc etc. Also, in my embedded environment, I also 
> need to start a GDB-server before I can debug/run. For my 
> users convenience, I have defined an External Tool to do 
> this. None of this is exportable (from what I can see).

You can use an external launch configuration (see the option to
save the launch configuration in the workspace) to do this.  It
doesn't help if you have custom gdb files, but then at least you
could set the options to be sourced from a file local to the 
project and run some pre-processing on it.
 
> 2. Import doesn't (easily) recreate a project containing what 
> I exported. I tried 2 things:
> A) Export every project individually. When I came to import, 
> I had to create each project of the appropriate type (managed 
> vs standard make, C vs C++) before I could import. This also 
> lost any project dependencies.
> B) export every project in the workspace. When I came to 
> import, I had to create an empty project and each imported 
> project was then a sub-project of that 'empty' project. 
> Again, dependencies were lost.

The problem is that dependancies are a workspace concept.  If 
you don't have a workspace, then it is difficult to describe
a dependancy.  Again, if you write your own custom import wizard
then you can pick through and re-assemble the dependancies as you
see fit, but ultimately the management of dependancy relationships
lies in the workspace.
 
> With my company's products, we are trying to expand the 
> number of developers using Eclipse, and probably bringing a 
> new type of user. Some are prepared to investigate and bear a 
> little bit of pain, but the majority are not. We are trying 
> to address that majority. 

That is great.  If you want to defer the specialized users' pain
then that means that you have to take on the burden of enhancing the
experience (often programatically) yourself to fit a custom model
of what you think your users' workflow will be.

Thomas