replace Makefile with CMakeLists.txt

[wucke13]

This PR replaces the entire Makefile build infrastructure with a CMake based one. This is how I would structure the CMakeLists.txt for the project. However, whether it is desirable at all to switch to CMake is up for debate.

What there is to like:

• Cross compilation becomes simpler, due to CMake handling different compilers easily (see the changes to pkgs/a653lib.nix), cross compiler configuration just works without further ado.
• Parallel building is no problem, compilation of the entire project in less than 2.1 seconds is feasible (time ( clear ; rm -rf build ; cmake -Bbuild && cmake --build build --parallel ) takes 2.058s on my laptop)
• Arguably the CMakeLists.txt is a bit more concise than the Makefiles
• CMake automatically neatly places the build results as a library somewhere when used with the --install command, see the following out directory layout:

  result
  ├── bin
  │   ├── a653lib_main
  │   ├── partition_a
  │   └── partition_b
  ├── include
  │   ├── a653Error.h
  │   ├── a653Init.h
  │   ├── a653Lib.h
  │   ├── a653Partition.h
  │   ├── a653Process.h
  │   ├── a653Queuing.h
  │   ├── a653Sampling.h
  │   ├── a653Semaphore.h
  │   ├── a653Time.h
  │   └── a653Type.h
  └── lib
      ├── liba653lib.a
      └── liba653lib_partition_init.a

• The fact that we use CMake is not contagious, especially with the directory layout above it is trivial to build an a653lib SDK that can be used from Makefile etc. without issue. We could even generate a pkg-config file?
• Alleviates the use of bear¹ to generate a compile_commands.json for better IDE support, CMake does it out of the box.
• I dislike the Makefile creating a files/directorys directly in my home dir (I much prefer if project build artifacts remain in the projects respective directory).

What there is to dislike:

• CMake is another (albeit only build-time) dependency of 1.17 million lines of code.
• CMake is arguably not super elegant, e.g. the recommendation to not use globs for source file listing²
• Integration with operating systems more niche than Linux might be complicated. (though VxWorks for example does support CMake builds). Also, do we actually target any other OS other than Linux intentionally?
• Building is now two commands cmake -Bbuild ; cmake --build build instead of one make (though after the first command, in the build/ dir there is a Makefile and one can iterate with just make as usual --- after all CMake generates a Makefile.
• One abstraction more between developer and compiler, making it maybe harder to inject specific compiler flags or change the compiler. (though cmake -D CMAKE_C_COMPILER=gcc-4.2 is reasonable, and CMake does take a CFLAGS³ and a LDFLAGS⁴ environment variable for this very purpose)
• Much of the pro's can also be achieved with a Makefile. (albeit with arguable more effort)

Footnotes

1. https://github.com/rizsotto/Bear ↩

2. https://cmake.org/cmake/help/latest/command/file.html#filesystem ↩

3. https://cmake.org/cmake/help/latest/envvar/CFLAGS.html ↩

4. https://cmake.org/cmake/help/latest/envvar/LDFLAGS.html ↩

[wucke13]

@nbaerair do you have feedback on this; would you like to go forward with it, or rather not?