build: add support for the CMake build system

[JakubVanek]

Hi everyone,

this PR adds support for building the library with CMake. This way, builds without binary libev3api.a might be easier for some project structures. In particular, it is now possible to include EV3-API as a Git submodule of a project and then just include it from a parent CMake project.

A minimalistic parent project might look like this:

cmake_minimum_required(VERSION 3.10)
project("C4EV3-Project" LANGUAGES C)

add_subdirectory(EV3-API)

add_executable(program src/main.c)
target_link_libraries(program PRIVATE c4ev3::ev3api)

I have also modified the current Travis configuration to use CMake. I have also cleaned it up a little, taking https://github.com/simonedegiacomi/EV3-API/blob/master/.travis.yml as a base. From there, I've also taken the code for using the C4EV3 compiler.

Best regards,

Jakub

[a3f]

You can have a pkg-config file installed and use that from CMake. But using CMake for the library is overkill IMO.

[JakubVanek]

Hmmm, looking at it that way, the library indeed already uses Makefiles that one would then need CMake to generate. It is also not necessary to support multiple targets, as EV3 is a non-moving target with a predefined set of compilers.

I have come up with this because I've previously used a CMake-based workflow for a ev3dev-lang-cpp-based program for a local robot competition (robo2019-ss, robofat2). However ev3dev supports multiple targets and does Debian packaging and from that viewpoint it makes sense to use some abstraction on top of Makefiles there. Using a .pc file probably solves the integration with CMake programs for this library.

I see one remaining advantage - automatic project generation for some IDEs. CLion uses CMakeLists.txt natively and Qt Creator (although for this library only the code editing functionality is worth considering) can use them too.

I have modified the PR to reduce the scope of the changes a bit (no test file, no travis-ci). However I'm OK with the PR being declined; I could create a separate PR for the pkg-config integration.

Best regards,

Jakub

[a3f]

It is also not necessary to support multiple targets, as EV3 is a non-moving target with a predefined set of compilers.

Exactly.

I see one remaining advantage - automatic project generation for some IDEs.

I don't mind having an example/ project with a Hello World Application and a CMakeLists.txt, which uses the pkg-config file. I just don't want to build EV3-API with CMake.

However I'm OK with the PR being declined; I could create a separate PR for the pkg-config integration.

Sorry, closing in favor of #38.