views:

52

answers:

3

I'm trying to design an SConstruct file for an embedded system project. The compiler on my machine is at "C:\Program Files\IAR Systems\Embedded Workbench 5.4\arm\bin" I would like the build system to try to locate the toolchain even if there is another verison of Embedded Workbench installed, or if the user has chosen to install it elsewhere.

I'd also be interested in strategies used in makefiles or ant files since they are probably useful here as well.

What are some strategies for doing this? Do I have options other than searching the Windows registry or looking for "C:\Program Files\IAR Systems\Embedded Workbench *\arm\bin"?

A: 

Since different versions of toolchains may have different bugs and/or features, silently falling back onto different sets of tools is probably a bad idea. When I've supported multiple tools versions on a single project, I usually have the version number assigned via a makefile or the environment. Then you can pass -D TOOLS_VERSION=$(TOOLS_VERSION) to your compiler and use that value to key bugfixes and workarounds you need for particular versions of the tools. This system makes it clear which tools you want to support, while still making it easy for other developers to switch tool versions by making a single edit.

Carl Norum
You have a point perhaps, but if you are supporting legacy projects, it is common practice to stick with the original tool, since changing compilers may require you to revalidate the entire project from module to acceptance testing. This might be a team or project policy or a safety-critical or contractual requirement for example, or it might just be pragmatic just to avoid horrible surprises in the field. For example the codebase may have a latent bug, that happens to work with one compiler, but is exposed with another; if you don't revalidate the entire system, you may not notice.
Clifford
I think that's exactly the point I'm trying to make.
Carl Norum
+2  A: 

The simplest solution is to use an environment variable. You still have to set that up manually for each build host, but the build system need only refer to the environment variable, so can be common for all build hosts.

For example in your case you might have:

EWBARM_V0504="C:\Program Files\IAR Systems\Embedded Workbench 5.4\arm\bin"

And similar for other versions installed, and then in your build system you would use %EWBARM_V0504% in place of the path. The worse that will happen is if the variable does not exist the build will fail, which is preferable to using the wrong compiler, and easily fixed.

Clifford
A: 

The nice thing about SCons is you have all of python at your disposal. So you can use win32.winreg to look in the registry, or glob around in sets of paths, whatever works for you. And of course you can have a command-line option or an options file to override the autodetection. Then once you've found your tool of choice, you have basically two ways to make SCons use it: either prepend the tool's dir to env['ENV']['PATH'] (you can use env.PrependEnvPath for that), or just use the tool's full path as the value of your $CC (and set $LINK, $SHLINK etc. appropriately too).

I usually make a TOOL_MYCOMPILER function that takes an env and sets it all up for use with the compiler and its toolchain (cpp, linker, whatever). It keeps things cleaner in your SConstruct/SConscript.

garyo