Putting a xTIME composer workspace under version control Topic is solved

[Guest]

I am preparing the work environment for several developers who will work on the same projects and am trying to figure out how to place the code and build configuration under version control (we're using Subversion).
So far I've encountered these issues:
- After build and cleanup the workspace contains changed files (i.e. .metadata/.plugins/org.eclipse.ui.workbench/workbench.xml or .metadata/.plugins/org.eclipse.core.resources/.safetable/org.eclipse.core.resources). Which files can I safely ignore and which files need to be present to build the project?
- The workspace contains absolute paths. When I try to check out a workspace from the repository, I'm unable to build it since the referenced files to not exist.

It is even possible/supported to place a workspace under version control?

I need a to be able to tell a new developer: "Check out repository "x" into your local work folder and run "tool Y"; then click on "button Z" to build."
In the near future, I plan on building the checked-in code on our Jenkins build server, I was assuming that it is possible to place a complete and authoritative setup under Subversion in order to have reproducible binaries.

How do other projects do this?

UPDATE:
After some research regarding Eclipse I've realized that I'm supposed to only place the actual project under version control and have the individual developer import from Subversion into their individual workspaces.
That works and solves my "How to explain to the developers what to do" problem.
The "How do I build the workspace with Jenkins" is still a problem, any hints appreciated.
Again, I'd like to be able to place everything required for a flashable binary into Subversion.

[Andy]

Hi CLO,

The "How do I build the workspace with Jenkins" is still a problem, any hints appreciated.

Eclipse simply invokes the XMOS command line GNU Make based build system. Jenkins should just be able to call make and build the application provided that the XMOS tools environment is correctly setup and your Makefiles are correct. We use this method for building everything internally at XMOS using Buildbot.

See Section 10 of the tools user guide for some details about using XMOS Makefiles: http://www.xmos.com/download/public/xTI ... 66A%29.pdf

[Guest]

Eclipse simply invokes the XMOS command line GNU Make based build system. Jenkins should just be able to call make and build the application provided that the XMOS tools environment is correctly setup and your Makefiles are correct. We use this method for building everything internally at XMOS using Buildbot.

Thanks,that means that once the workspace is set up I can use the Makefile to build the project.

My issue is that the workspace itself if not under version control and that I need the xTIMEcomposer to create the workspace and import the projects from subversion.
I'd like to be able to have a workspace that is reproducible from a version-controlled file set.
My first idea was to use the xtimecomposer.exe command line and org.eclipse.cdt.managedbuilder.core.headlessbuild to build and I've seen com.xmos.cdt.test.TestProjectCheckerImport and com.xmos.cdt.test.TestGenerateProject are existing in the underlying Eclipse.

Are these documented somewhere I haven't found yet?
Would it be possible to create the workspace and import a project from the command line?

My current goal is to write a script (which I can then check into SVN) to start in an empty directory and create the workspace, import my project(s) and their dependencies and then build the binary.

Maybe I'm too used to CMake (which we use for our other projects), but I assume there is a way to build a project without having to use Remote Desktop to connect to the build server...

[kris]

Hi CLO,

If you are setting up a continuous integration server in order to validate your target code then maybe you could just checkout the projects from subversion, source the SetEnv (to set up the environment for running the xmos tools), then as Andy says, just call xmake from the command line? That way you will not need a workspace at all.

It is possible to use the org.eclipse.cdt.managedbuilder.core.headlessbuild eclipse application to create a workspace (use the -data option), and you can use the -import and -build options to import a project into the new workspace and build it. However, the com.xmos.cdt.test.Test* applications are really just used internally for testing the tools, and are not really useful in any other context (thus are not documented).

Hope this helps,
Kris.

[Guest]

It is possible to use the org.eclipse.cdt.managedbuilder.core.headlessbuild eclipse application to create a workspace (use the -data option), and you can use the -import and -build options to import a project into the new workspace and build it.

That solves it.
My solution (to match the XMOS build with the way our other projects are build) is:
- clean and update the repositories and remove the old workspace
- run "C:\Program Files (x86)\XMOS\xTIMEcomposer\12.2.0\xtimecomposer_bin\xtimecomposer.exe" -noSplash -data C:\projects\xmos_workspace_jenkins\ -application org.eclipse.cdt.managedbuilder.core.headlessbuild -import C:\projects\subversion\HelloWorld\module_uart_rx -import C:\projects\subversion\HelloWorld\module_uart_tx -import C:\projects\subversion\HelloWorld\module_i2c_master -import C:\projects\subversion\HelloWorld\HelloWorld -build HelloWorld
- wait for the build results (C:\projects\subversion\HelloWorld\HelloWorld\bin\Debug\HelloWorld_Debug.xe and C:\projects\subversion\HelloWorld\HelloWorld\bin\Release\HelloWorld.xe) to exist (with adjustable timeout)
- run xmake clean all from where my HelloWorld's Makefile is and redirect the output

This way I have checked that the project is buildable from the IDE and have a parsable build output to test for errors/warnings/explicit build messages.
While this is a rather baroque way of doing things, it works well, is traceable (the build script is under version control) and should scale to the number and complexity of the projects we're expecting.

Thanks to the both of you for your help.