[[ This guest blog entry is by Daniel van den Ouden of the ArduinoRCLib project. The original posting is over here. ArduinoRCLib is a library for the development of Arduino based R/C equipment. The blog post caught my eye because I’m interested both in the Arduino world, and in R/C stuff (helicopters, in particular).
Opinions here are those of the author of this piece, and don’t necessarily reflect the opinions of SourceForge, or of GeekNet. ]]
It’s official, I hate the Arduino IDE. There’s just so much wrong with it that I hardly know where to begin…
First and foremost: the build pipeline. Who came up with this anyway? I know Arduino is aimed at beginners, but that’s no excuse to make a mess of things. What happens when you hit the ‘Verify’ button (compile) is the following:
1. Create a temporary folder somewhere in your user directory, in my case (WinXP) Documents And SettingsUserLocal SettingsTempbuild-somerandomnumber. All compiled files end up here, I guess that reduces clutter in your project folder, but what’s the problem in having an obj, lib or bin folder in there anyway?
2. Do some pre-processing on the PDE file, i.e.: add an include for the Arduino header, and create forward declarations for each function in the file. Now I understand why they do this: to keep things simple for beginning programmers; no need to include a platform header and no need to have functions declared before calling them. But in my opinion educating new programmers is a much better idea, and will make life a lot easier for those of us who already know what we’re doing.
* Oh yeah, one tiny little detail: generated function declarations are placed above typedefs. So typedef struct { blah } Sometype; and then using Sometype* as a parameter in a function signature will give you some nice unexplainable compiler errors, since the function declaration will be placed above the typedef. But of course, none of this process is shown to you, you just end up with the errors.
3, Compile the pre-processed file. There’s some magic involved here as well. The pre-processor also scans for includes and tries to figure out which libraries are used. It will add all the necessary include paths to the compiler arguments. I’ll explain why this is a problem later on. In Arduino 0.22, compiler warnings are turned off, that’s right, no warnings. Seriously? Turns out I was missing a return in one of my functions, great..
4. Compile all library files that are used.
5. Link
6. Upload
If you’re like me and like to have your source tree reflect the namespaces you use then you’re out of luck. I for one like to have to use #include PPMOut.h> for my rc::PPMOut class, but that’s not going to work for multiple reasons.
First of all, using that include won’t tell the pipeline you’re using the rc library, it doesn’t look beyond the library’s root folder for files, so the library won’t be added to the include path and you’ll be presented with a nice compiler error. This can be fixed by including a file that is placed in the root of the library folder, like rc.h. So you’ll have to add another (useless) include to your source, yuck.
Now you’ve solved the include problem and fixed the compiler error, but get linker errors for unresolved references! Great, the pipeline doesn’t see the CPP file unless it’s in the root of the library, so it doesn’t compile it.
And finally, none of this is configurable in any way through the IDE, can’t set compiler flags, change warning levels, optimization levels or anything. A lot of these frustrations wouldn’t exist if there was some form of project file with compiler settings, include paths, etc. None of it would have to be very complicated.
And don’t get me started on the actual editing of code using the Arduino IDE, I’ve selected the “use external editor” option a long time ago; a few minutes after installing the IDE to be precise.
So, next challenge: rigging up a build pipeline in visual studio…