Short Question
What is the best way to create, maintain, and distribute software development tool chains?

I am trying to develop a workflow / process to create an isolated environment in install and deploy software tool chains for embedded targets. Each tool chain typically would contain an IDE, compiler, and a small set of common tools. I have looked into two solutions but the both have their limitations and I hope to find a solution that has the best of both implementations.

The rational behind a stand alone tool chain is so that all developers would be able to build the exact same code (matching CRC etc..). As well as be able to rebuild the same code after X number of years to support legacy code. A third option would be to use a central build server, which we plan on doing for nightly builds, but we still need to be able to build 'on the fly' when working on a test bench or remotely. So only using a build server will not suffice.

Ideal Goals for Deployed tool chain

  • Work on Windows XP, Vista, and 7 (excluding drivers)
  • Contain all required information to run use the tool chain (excluding drivers)

------------------ Possible Options ------------------

Option 1: Full Stand alone Virtual Machine

  • Open Source packaging via Virtual Box
  • 100% isolation
  • Guarantees the tools can interact with one another


  • Licensing multiple copies of windows
  • At best only one developer could legally use a Windows VM at a time.
  • Running the same VM on physically different lap tops (Macbook Pro, Dell 830, Dell E6500, etc...). Typically when Windows see's a new CPU or motherboard it will force a re-activation.
  • Very large files to maintain

Option 2: Virtualized Application

  • Through packagers like Cameyo, applications can run on nearly all versions of Windows. (Note that Cameyo is also free)
  • Little to no licensing issues for most tools / IDEs. Purchased compilers might have additional restrictions, all of our current compilers do support this type of usage.
  • Smaller files to maintain via a SCM, such as SVN or GIT.


  • Difficult, if even possible, to get a single file that contains the entire tool chain
  • Difficult, if even possible, to get the tools to see / work with one another. I have seen this very issue with Cameyo.

Closing Thoughts
There may not be a solution that meets all of my design goals, but I would like to find out if anyone else been successful in this type of deployment.

  • 1
    I would say, you are trying to solve several problems at once. Start with trying to solve the most important problem. Reproducible builds.
    – sylvanaar
    Commented Sep 5, 2011 at 4:34
  • another thing - VM's cant tell when they are running on different machines, sometimes the VM software tracks that though so it can update the MAC addresses on the virtual LAN adapters.
    – sylvanaar
    Commented Sep 5, 2011 at 4:36
  • @sylvanaar: A build server addresses the reproducible builds. However this is more than cumbersome while debugging / normal development. Mainly because to run / test the code it must be burned onto the target. Regarding the VM: I was not implying that the VM software tracks the machine it was on. That would be going against what it was designed for. However Windows XP in particular monitors for certain hardware changes to determine if it needs to be re-activated. This can also be seen when running Parallels 6 on OS X 10.6 and using an existing Win 7 bootcamp. It requires a 2nd activation.
    – Adam Lewis
    Commented Sep 5, 2011 at 5:11
  • 1
    I think the activate issue is more of an issue with that particular VM implementation, we have never had any issues with VMWare.
    – sylvanaar
    Commented Sep 5, 2011 at 5:56
  • 1
    @Adam - I have mostly used Windows XP in virtual development machines, the lower memory and boot drive footprint makes for more compact VM's. 512MB memory & 20GB boot drive is more than enough for a VS2008 development environment. It's also nice being able to clone a machine by copying it and then running newsid to allow both VMs to coexist on the same domain.
    – Mark Booth
    Commented Sep 5, 2011 at 13:13

2 Answers 2


I was doing exactly this a few years ago, and found the answers were either a full VM solution, or a meticulous version control system for all of you build setup. Given you appear locked into Windows, you could get an MS developer license that allows multiple copies per dev of Windows, and activation and legal issues disappear for a annual fee.

We ended up with a build server and a rule the only way to get anything onto the build server was through the revision control. A few squeals from some about binaries and size issues aside, it worked. The relaxation to that was a file containing list of clearly labeled DVD's, a file store of ISO images of those, along with full build machine setup instructions. These we randomly tested for accuracy, and although they rarely worked first time, were always able to bring up a build server from a clean VM.

Keep in mind, disk-space is very cheap, use it. Licenses can be a pain, but work with the tool provider (including MS) to find a solution.

Broken build machines, inability to build old software etc is expensive, but so is carrying around excess baggage. If the software really is past it's use by date, destroy it. Don't keep stuff lying around because you might need it one day. Only keep it around because you will need it or are legally obligated to.

In the end with an embedded system build, you should be able to bring up a clean build machine from source and a couple of install DVD's. If you need more than that, look at your tool chainan consider it may be too complex to be reliable.

My goal was always "Clean machine, Checkout, make, deploy." never got there, but got very close most times...

  • Thanks for the input. To clear up a few points, I agree disk space is cheap. It's not the physical storage that is an issue. It's really the bandwidth to pull it down / back it up. A full windows VM at a minimum is around 10Gig without doing major striping. The reason to keep it for X years is for legal reasons.
    – Adam Lewis
    Commented Sep 5, 2011 at 5:35
  • My current process is to manage all of the executables required to configure the tool chain and I have a quick setup guide to it. The largest pain with this setup is the transfer of licenses where floating licenses aren't available.
    – Adam Lewis
    Commented Sep 5, 2011 at 5:41
  • I don't thing MSDN covers you using its licenses on production machines. It pretty much says expressly that in the user agreement.
    – sylvanaar
    Commented Sep 5, 2011 at 6:08

Versioned toolchain, shared out via file servers

It's been awhile, but when I last worked with windows it was for a multi-platform product. linux-x86, linux-arm, win-ce, and win-nt. I think we managed the toolchain on all platforms by installing into a segregated directory, and then checking that into version control. We then checked them out onto a nfs server (linux), and windows share server for mounting by the developers and build machine.

We had to jump through a few hoops to make sure no writes were happening to the remotely mounted directories, but other than that it worked pretty well. I don't think we actually had to install the entire IDE in separate directories, just the compiler, linker, and standard libs.

We did updates/upgrades in place. Various versions were checked out into different directories and used by anyone who working on customer problems, bug fixes, etc.

  • I believe this solution would work for most caes, especially when using open source compilers. Sadly, the the main compiler that I use states explicitly that this type of use in not prohibited. However a VM instillation, assumed that only 1 developer is using it at a time, is acceptable.
    – Adam Lewis
    Commented Sep 5, 2011 at 6:10
  • This could be nicely coupled with Cameyo for the IDE's so the user could just pull down the standalone IDE, checkout a compiler, run a config script and the workspace is created.... +1 Thanks for the input
    – Adam Lewis
    Commented Sep 5, 2011 at 6:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.