13
\$\begingroup\$

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?

\$\endgroup\$
  • \$\begingroup\$ I think its great that your are implementing a build server. Unfortunately, I have no experience with the Keil development system so I can't really help you out. I would like to encourage you to post a solution if you when you get it worked out. \$\endgroup\$ – semaj Apr 1 '11 at 15:43
  • \$\begingroup\$ I build Keil projects via batch script without any PATH dependencies (other than to the Keil tools themselves) or __i / _ia files. Can you share any more info on this? \$\endgroup\$ – Digikata Apr 3 '11 at 23:46
  • 1
    \$\begingroup\$ @digikata I'm using the option from within the IDE to generate a batch file. This is described in Keil's documentation. There is also a command line driven method described here, but I had difficulty getting the proper console output from that command. The second method starts a new process and gives you the option to copy the output window to an output file - not a good method for a build server. \$\endgroup\$ – rmaVT Apr 4 '11 at 17:53
  • \$\begingroup\$ For future reference, this question's scope is in an area of overlap we share with other Stack Exchange sites. Questions about embedded-specific toolchains like Keil are definitely welcome here! They're also welcome on Stack Overflow, but feel free to ask in either place. \$\endgroup\$ – Kevin Vermeer May 17 '12 at 21:55
  • 1
    \$\begingroup\$ @KevinVermeer -- Yes, I was about to say the same thing myself. rmaVT, you may found browsing the questions tagged "keil" on SO just as educational as the questions tagged "keil" on EE SE. \$\endgroup\$ – davidcary May 18 '12 at 19:26
8
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ A question about this work - what operating system is your build server running? Linux, Windows 7, Windows Server 2003, Windows Server 2008? \$\endgroup\$ – CrimsonX Jan 31 '12 at 20:35
  • \$\begingroup\$ Thanks for answering the question! Looks like the arm toolchain works on Windows Server 2003 & 2008 R2 per Keil's Documentation. A follow up question regarding your edit: How do you handle changes to the uvproj file (e.g. adding a new files into the project for compilation)? Do you have to manually change the compile options in a file promoted to the build server? \$\endgroup\$ – CrimsonX Feb 1 '12 at 19:36
  • \$\begingroup\$ You have to put the .uvproj file under source control. This works pretty well, although some user preferences are still left in the file despite the .userxxxxx file that is also generated. The build server just needs to open the same "project" and build it. \$\endgroup\$ – rmaVT Feb 3 '12 at 20:09
3
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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