How can I specify an Eclipse .classpath entry for specific O/S platform?

Question

I am working on an SWT project as part of a team. We are constantly breaking each others build environment because Eclipses .classpath file is checked into version control and we include different SWT libraries for our machines.

Depending on who committed last, the .classpath entry can be:

<classpathentry kind="lib" path="lib/swt/swt-win32.jar"/>

or

<classpathentry kind="lib" path="lib/swt/swt-carbon.jar"/>

or

<classpathentry kind="lib" path="lib/swt/swt-gtk.jar"/>

It appears that the libraries are mutually exclusive, i.e. you cannot include them all at once and let SWT work it out. So we need to filter them for each platform somehow...

Does anyone have any ideas on how to do this? My initial idea was to split this into its own ".classpath-swt" file (ignored by the VCS), auto-generate it using Ant and include it in the main .classpath, but it seems Eclipse doesn't support splitting up the .classpath file.

Our current work-around is to avoid committing the .classpath unless we have actually changed the dependencies, however this still means that a number of people have to fix their development environments each time the .classpath is changed.

Any suggestions will be much appreciated, as long as it's not "don't use Eclipse" as this is not an option for this project :)

Answer 1

Eclipse will let you define classpath variables so you can keep the .classpath the same, but each developer would configure her Eclipse according to platform. You could at least then version the .classpath file. You will have to alter the directory structure of where you store your SWT jars to something where the jar name doesn't change per platform. This menu can be found in: "Window->Preferences->Java->Build Path"

SWTJARDIRECTORY/
    WIN32/
        SWT.JAR
    CARBON/
        SWT.JAR
    GTK/
        SWT.JAR

Ex.

    SWT_PLATFORM="SWTJARDIRECTORY/GTK", set by developer in Eclipse

.classpath

    SWT_PLATFORM/SWT.JAR

Answer 2

How about simply configuring your own instances and for this one component of your environment you don't keep it in your source control?

Alternatively you could store a classpath file for each environment, perhaps in another directory and in an ant file i.e. build-setup-env.xml file you could simply have one target for each environment that copies the correct one across. As for keeping a copy of this in source control you'd have to be sure to copy it back when it is updated.

Answer 3

You should have these libraries in a separate, easily identifiable project instead of placed in each and every project.

E.g. create a project named "00-swt-provider" (so it goes on top) and let it reference one of "00-swt-provider-carbon", "00-swt-provider-win32" or "00-swt-provider-gtk".

Either of these export the appropriate native libraries for the given platform and the only link is in 00-swt-provider. The actual project only references this meta project.

We use a variant of this internally - it works well for us.

Answer 4

SWT does this by not versioning the .classpath file, but by versions multiple separate .classpath_* files with the operating system and window system appended, e.g. .classpath_win32_win32. Thus when you check out the sources from the repository you are expected to copy the appropriate classpath file to .classpath and recompile your project.