Automated Builds of Windows CE Applications

Question

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

Answer 1

Sounds like you want to play with the PATH environment that PB sucks its information from. I mean (from what I understand), you want that 2 builds will take files from 2 different locations, right? In that case you can run different batch files to setup the appropriate environment settings and then the build will be different for each batch file. The following blog has an excellent review of the build tools Platform Builder has (link).
You want to play with the INCLUDES macro to control where PB takes the headers files from and in order to link against different libs each time you will have to make the paths of the libs be comprised of a macro that you will set in the batch file, for example:
SOURCELIBS=<br> $(_MY_PREDEFINED_PATH_TO_THE_LIBS)\lib\libName.lib

Then in the batch file you will set a different _MY_PREDEFINED_PATH_TO_THE_LIBS

Answer 2

We generate the SDK, but then copy the libs/headers into a shared svn folder. This folder is updated every time we build a new SDK. The only thing we need the SDK for is to install the processor platforms into Visual Studio. Once that is done, our application pulls in the headers/libs using svn:externals.

This way, old versions of our app can still be brought up and compiled with their original SDK. Otherwise, we would have to manually uninstall/reinstall the SDK whenever we wanted to work with a different branch.

I once looked into extracting all of the files from the SDK, so that it only installs the registry entries VS needs for the platform, but I got lazy and gave up.

Answer 3

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.

Answer 4

I suggest you deal with it by using a throrough configuration (version) management strategy: just rule out the chance that you mix up versions of header files and libraries. Even if it works, it is for sure an unsupported configration, which can get you some strange quircks.

Microsoft tools make it not easy, by their love for locations like c:\program files.... but if you can guarantee that all tools are under version control, you can always roll back a version of the tools. Watch out for registry associations.

If you can make identical binary builds (i.e. no dates/build numbers embedded!) you can verifiy that you can rebuild the same binary on 2 different machines when moving to a certain version in configuration management. It will cost a lot of time, but not nearly as much time as it will cost when you'd be in an uncontrolled environment with SDK version conflicts!