Overhaul of the make file structure

[fredizzimo]

@algernon mentioned the need for an overhaul of the make files here #582.

Coincidentally, that's also what I have had in mind. But my requirements comes from integrating the unit tests into the build system. While I already have a very first draft integration here, I'm not happy with the solution, and it would be hard to integrate properly with the rest of the build system. Let alone adding targets that run all the unit tests.

Also from being a complete makefile beginner, at the start of the year, when I for the first time, had to touch any makefile, I have grown a quite good understanding how they work. That's from reading a lot, and also having to make a lot of changes to do what I want. So I'm quite confident that I can make the following changes.

1. Get rid of the quick targets - I don't like the fact that by default everything is always rebuilt. I understand the reason for it, especially since a lot of inexperienced programmers make changes that would require a re-build. Quick was added as a shortcut to disable that action, but I still consider it a hack. It also makes our make files work in a non-standard way, where you always do make clean, followed by a make, if you really want to re-build.

   In order to to properly fix this, we need to add the compiler and linker options as dependencies, so as soon as an option changes, the affected files would be re-built. The basic technique is described here

2. Make proper clean targets - Currently the clean targets clean too much. This should be changed so that it only really cleans what's required for the specific base target.

3. Get rid of the /keyboards/keyboard targets - Those targets doesn't really make sense, they look like file system paths, but violates both rule number 2. (but not completely since they are phonies), and rule 6. on Paul D. Smith's "Rules of Makefiles"

   This targets are also very verbose to type, and are not consistent with the rest of the targets that we have.

4. Consistent and fast to type rule names - I would like to change the keyboard rules to all have this format keyboardname-keymapname-subproject-realtarget, where realtarget can be quick, hex, dfu-util and so on, and if left out all

   For these there would be shortcuts, so if you type just keyboardname, you actually get keyboardname-default-default. There's also automatic shortcuts, so if you run make inside a keymap, you get keyboardname-keymapname-default, and of course if you run make infinity, inside an ergodox keymap, you get ergodox-keymapname-infinity So in that sense it would like before.

   This would also deprecate the use of the keyboard=, keymap=, subproject= flags. But I might still be able to retain their behaviour.

   Of course you can still run make all-keyboards, which expands to all-keyboards-all-keymaps-all-subprojects, all-keyboards-defaults might be changed into all-keyboards-default (not the missing s), which expands to all-keyboards-default-all-subprojects, this of course lets you run all-keyboards-default-default.

   For unit tests there would be similar targets as well.

   The advantage of this model, is that it would now be possible to specify two targtes, so of you want compile two keymaps, inside the keyboard folder you could run make keymap1 keymap2

5. Split the make files into two parts, - top-level targets, and actual compilation - The top-level targets would do nothing else, than process the targets that I described in 4. They would not include the actual rules for compiling. Instead they call those recursively. But with only one level of recursion, for better speed and to fix the problem which @algernon described in Makefile: Keep going when building with make -k #582.

   The actual compilation would also build one target, also completely without any recursion.

   I have been considering a completely non-recursive solution, but there's three reasons why I decided against that.

   1. We would lose the nicely ordered output, with OK, ERROR and WARNING.
   2. It would be very error prone, if the wrong types of make file variables are used inside a keyboard specific make file it could start affecting the other keyboards
   3. It would be considerably more difficult to implement.

6. Put all files belonging to a feature in their own variables, instead of directly adding them to the source - This is way more flexible, at least from the point of unit tests, which might want to build only parts of the actual source.

7. Perhaps split the make files into several files, which are included - For better organization

8. Split keyboard and keymap specific makefiles into two parts - Makefile and rules.mk, The makefile would contain nothing more than including the master Makefile, while the rules.mk contains all the specialization.

   This would ensure that everything is included in the right order, since now it matters if you include things at the bottom or at the top of the makefile.

   This is a thing that I would like to do, however it's a breaking change, so maybe this has to be skipped.

9. Use one .build directory in the root - Right now .build directories are created both at the root level and in the keyboards. I would like that everything is always inside a root level .build directory, which contains subfolders for all keyboards and keymaps.

I'm already working on 1. I have partly done 6. and 7. in my [unit test branch(]https://github.com/fredizzimo/qmk_firmware/tree/unit_test)

Edit: Added 9.