Compiler weirdness with include files in ino file

How bizarre. The library author decided to put everything in the .h file, but knowing that if you included the file in two different .cpp files you'd get duplicate symbols, he placed all the C++ definition code in #ifndef LIBCALL_OOPINCHANGEINT barriers. So in one file you include it normally. And in all other .cpp files, you have to #define LIBCALL_OOPINCHANGEINT.

This is a style of C++ I have never seen before. Please library authors, do not do this! Just stick your implementation code in a .cpp file. It will be much easier to debug, less prone to conflicts, and will just work when someone uses your .h file in a usual fashion. I'm not sure where this trend to put everything in the .h file is coming from (I see on stackexchange it's becoming common), but it's not a good idea. For one it breaks make systems. If a method call's implementation is tweaked, if you stick to a separate .cpp file then a rebuild is a matter of compiling one cpp file and a re-link. If you keep the code in the .h file (even if it is inside of #define implementation barriers), build systems will rebuild possibly all your cpp files. Obviously build time isn't an issue here in Arduino, but in the real world, that could be hours! Rant finished now.