I am trying to setup an automated build of my Windows CE application. However, we are evolving our Platform at the same time as our application (adding extension cards, new services, etc). I want to be able to associate my application build with a version of the SDK and either have multiple versions of the SDK installed (less preferable option) or have the SDK versionned with my application (most preferable option). I want to be able to run parallel builds so the SDK should be local to my project and not shared between projects.
Currently what I have been able to do is install the SDK and move the headers and libraries to my project then add the relative path to my project includes and libs. My question is: there are more things than the headers and libraries that are installed with the SDK so could I run into trouble if I build an application with older header and libs and a newer SDK installed (or newer header and libs than the SDK installed)?
Another way would be to redirect Visual Studio/the command line tools to my own header/libs and Properties.xml (but I haven't figured how to do that).
Has anybody done this before?
Thanks,
Alexis
This is actually a pretty broad question covering a few area. First let's look at what an SDK actually is and what it contains.
When you create a platform, you include Catalog items. Each of those items has a set of associated header and lib files. When you roll an SDK, the roller coalesces all of those headers and libs for each catalog component, on a per-processor basis (since an SDK can support multiple processors). It also adds in any "extra" files that you define in your platform BSP (like the emulator BSP will include the emulator image) and it also includes any extra files specifically defined in the SDK definition.
So when does the contents of an SDK change? Well any time you make a change to the catalog items included in your platform, or when you explicitly choose to add or remove the extra files defined in the SDK roller.
For automation it's pretty simple. What we tend to do (and it's worked for years with many companies) is to define a very, very broad set of catlaog components. Basically throw in the kitchen sink from the catalog.
Do not add any custom files (so if you have custom headers for a driver or whatever, do not include them in the SDK). Instead publish these files manually to a common folder. Add this common folder to the applications "Additional Include Files Path".
Now you can modify the platform at will without affecting the app. The only potential problem is that you might use a header or lib that you actually end up cutting fromt he platform due to license or size restrictions.
Automating all of this is really a completely separate question, and it doesn't seem like you're actually asking how to do the build automation itself.