queezythegreat:
are boilerplate code, which gets repeated over and over in large projects. So my build sytem style eliminates all of which is redundant. When you have 50 targets in you build system you will understand how much redundancy that is (especially when working with QT)
The beauty of the boilerplate code is its boilerplate-ness! Any macro/function I or someone else already have works with little change. I'm not suggesting your approach is wrong for you or your projects; rather, make the expected work and then provide whatever macros/functions you are accustomed to. (Of course, those should already exist in your cmake modules path so that they need not be rewritten...)
Remember, I said I'm not a CMake guru. 50 targets does not impress me. 
And Qt is an absolute dream from CMake regardless of project complexity. I kinda think it's because it follows the same rules everything else does.
And you haven't done away with redundant code, you've only changed the way it looks. From this:
set(ARDUINO_PLATFORM uno)
find_package(Arduino)
include_directories(${ARDUINO_INCLUDE_DIR})
add_executable(proj file.cpp)
target_link_libraries(proj ${ARDUINO_LIBS})
generate_arduino_flash(proj PORT /dev/USB0)
To this:
find_package(Arduino)
set(proj_BOARD mega2560)
set(proj_SRCS wire_master_reader.cpp)
set(proj_PORT /dev/ttyUSB0)
generate_arduino_firmware(proj)
5 lines or 6 lines? (And only because I think it's wrong to put the include_directories into the FindArduino.cmake file.) Furthermore, you've made it hard for me to add the EXCLUDE_FROM_ALL property to my target! (This will be worse if CMake adds more properties like EXCLUDE_FROM_ALL in the future...
Another reason for using this style is extending it to support more options (and being backwards compatible) is much easier using this style.
I am not convinced. I think this is easily done by the user in their own project specific macro/function. But I'm willing to be wrong... Convince me.
I do agree with you that this is a little bit non standard when it comes to CMake, but this style has been used with great success on big projects for over 2 years.
Essentially I'm arguing familiar is good! If everything looks and acts the same, then for the most part I can update my CMake files without going to documentation. I can use my common.cmake file with expected results.
For example, Boost and Qt generally look the same from a CMake perspective. It's easy to combine them. If either of them went a non-standard route, I might have a problem using them together on a project.
Another example: Lets say I wanted to create 10 executables that all use my loc library. I can, with the boilerplate approach, compile my loc library once, and link 10 times. Show me how to do this your way. (Really, it's such a non-issue for Arduino because of the limited resources of the system. But it is an issue for the bigger picture.)
Again, your way isn't wrong, I just want the familiar. Because it will work with my current cmake module files!