Battle of the Arduino Makefiles

So, I’m shopping for alternatives to the official Arduino IDE that better suit the projects I’m working on. In this installment, I look at two promising Makefile implementations to see if either come through as a workable solution. One of the attractive things about a Makefile approach is that you should be able to wire it up to your favorite editor du jour.

Some of the things I’m considering are:

• Support for Arduino 1.0 and 1.5/1.6
• Support for .ino files
• Support for .c and .cpp files
• Support for libraries and easy library management
• Support for serial monitor

The two implementations I’m looking at are Tim Marston’s Arduino Makefile and the Arduino-Makefile maintained by Sudar. Testing was done on an Uno board using aptosid Linux.

Arduino Makefile (Tim Marston)

I used Rev 98 of the development version.

• Easy configuration. It works fine in a central location with a child Makefile in the project directory.
• Near complete support for conventional builds  (.ino files and several .c or .cpp files, automated library inclusion.) You’re limited to one .ino file but as many .c or .cpp files as you want.
• Supports “proper” C/C++ project structure as well (untested).
• Testcases with and without one library against both Arduino 1.0.6 and 1.6.0 worked as expected. (I didn’t test additional .c/.cpp files or “proper” C/C++ project structure.)
• Serial monitor is supported through screen, which is a pain to shut down after a test iteration. (Pres Ctrl+a then k and then a y in case you’re wondering.)
• Puts build stuff into .o and .hex files and hidden .deb and .lib build directories in the project directory.

The most important commands

• make target or make: Compiles sketch
• make upload: Uploads sketch
• make monitor: Starts serial terminal
• make clean: Deletes the stuff that making generated

Arduino-Makefile (Sudar)

I used commit d535bf5fde.

• Requires pySerial (a.k.a. python-serial) for board reset.
• Moderately easy configuration. It works fine in a central location with a child Makefile in the project directory. You need to list the project’s libraries in the child Makefile.
• Semi-supports conventional builds (.ino files and several .c or .cpp files, semi-automated library inclusion). You’re limited to one .ino file but as many .c or .cpp files as you want. In addition,
  • “Since it doesn’t do any pre processing like Arduino IDE, you have to declare all methods before you use them (issue #59)”
  • “More than one .ino or .pde file is not supported yet (issue #49)”
• Seems to support “proper” C/C++ project structure as well (untested).
• Testcases with and without one library against both Arduino 1.0.6 and 1.6.0 worked as expected. (I didn’t test additional .c/.cpp files or “proper” C/C++ project structure.)
• Serial monitor is supported through screen, which is a pain to shut down after a test iteration. (Pres Ctrl+a then k and then a y in case you’re wondering.)
• Puts build stuff into build-<boardname> directory in the project directory.

The most important commands

• make: Compiles sketch
• make upload: Compiles if needed then uploads sketch
• make monitor: Starts serial terminal
• make clean: Deletes the stuff that making generated

Screen alternative

I wrote a stupid wrapper to be used with Sudar’s makefile that takes the parameters as generated by make monitor and calls your favorite serial monitor tool instead:

#!/bin/bash

# Wrapper that launches preferred serial monitor
# via the parameters passed by Sudar's Arduino
# makefile at
# <https://github.com/sudar/Arduino-Makefile>.

gtkterm -p $1 -s $2

As you can see, my preference is gtkterm. Closing gtkterm and killing the connection is a simple Ctrl-Shift-Q.

In the project Makefile, I then set:

...
MONITOR_CMD = <path-to-script-above>
...

and it works like a champ.

You could do something similar with Tim Marston’s version, but it would involve modifying the master makefile—which would then diff it from upstream. Not a deal breaker by any means,  just tiny bit of complication when the upsteam is updated.

Conclusion

Both these makefiles seem to do what I need. Tim Marston’s major advantage over Sudar’s is the ease of configuration (specifically, no need to name libraries the project uses.) It also seems to promise better support for code that you bring over from the official IDE.

Sudar’s advantage seems to be the ease with which screen can be replaced with something requiring fewer keystrokes to kill. In addition, Sudar’s is currently actively developed, while Tim Marston’s last commit was over a year ago.

So, it’s pretty close to a tossup—but I’m giving Sudar’s the slight advantage for now. The good news is that switching between the two should be easy since they both use the same targets for the important stuff.

A big thanks to everyone involved in making these happen!