How can I use a build server with Keil uVision4 (MDK-ARM), script a build, use a makefile?

Question

I would like run daily builds, or check-in/commit triggered builds of Keil MDK-ARM based projects. So far I've gotten things going with the batch file feature of the IDE. This does require you to build the project at least once with the IDE, then check-in the batch file and associated .__i and ._ia files created by the IDE.

Additionally, the IDE puts lots of user specific things into the batch file like the Windows PATH variable. This could become a problem with multiple developers, because the batch file for building could be changed at each commit from a different developer.

Ultimately, one just needs to keep track of the various switches for armcc, armasm, and ArmLink.

Is there a way to use a more standard makefile to build Keil uVision projects? Is there a method of translating a uVision project file into a more maintainable build script?

Answer 1

This is the best method I have come up with recently:

In the build options, select create batch file.

When you initiate a build from the IDE, a batch file along with several text files are created based on the options set in the IDE. You need to track these IDE generated files in source control:

• *.bat
• *.ini
• *.__i
• *._ia
• *.lnp
• *.sct

Then foo.bat can be launched from a build script.

While this does create extra files that need to tracked in source control if you want to build reliably from the generated batch file, it does remove the need to rely on the Keil project file (foo.uvproj) and the IDE. I find it easier to compare differences, and thus track changes, to the generated text files (*.__i) that contain compiler flags than to the .uvproj file. Additionally, the batch file calls the various tools, armasm, armcc, armlink, directly. This gives you the direct output of each of those steps as well as a seemingly better potential for migrating a project to a different tool chain in the future if necessary.

I realize this answer sounds a lot like my original question, but I genuinely don't know of a better way of running a scripted build with Keil's tools. I asked to see what might come up from others. I don't completely disagree with the answer from @digikata, but I prefer to have compiler flags and the memory map in an easier format for tracking and to use more unix-style tools for compilation rather than launching an all-in-one compilation with the IDE. I think the all-in-one compilation from the IDE works well at my workstation, but not for the build server.

EDIT: The build server runs on Windows Server 2003. I must confess that I have relented to using the IDE command line interface rather than a batch file. This just became too difficult to manage.

Answer 2

I call the Keil IDE via command line to build (not a generated batch file) from within a Makefile. Usually it works out better to lock down the project files via the scm, or take a reference build copy renaming the relevant project names when doing this.

The IDE is perfectly happy to work with read-only project files, so if you lock them down, the irritant is that you need to unlock them to change settings, save, and check them back in. If you're at a fairly stable point in the project this is pretty minor - even desirable.

If you take a reference copy, then the build tends to break as project settings change - especially as project files are added or dropped from the compilation. Explictly capturing those changes isn't necessarily bad, but is an extra step needed to maintain builds.

Either way, redirecting the output to a log file via the "-o" option lets you access the full output log. The log doesn't come out a line at a time, but it seem to all be there. (I actually parse the Keil error format to GNU fmt for integration with the eclipse CDT environment. This lets me jump directly to errors/warnings after the build)

The command-line build also generates the __i, __ia files so those don't need to go into version control for the build server either.

Hope this helps.