CMake - Things to consider when porting AqBanking/Gwenhywfar¶

Project's peculiarities¶

• the project family contains executables, shell scripts, static convenience libs and dynamic shared libs
• Gwenhywfar uses dynamically loaded modules, those a provided by Gwenhywfar itself and by AqBanking (swift parser)
• we use typemaker2 to build source files from XML description files
• typemaker2 uses an XML file as input and creates those files:
  • .c: c-code file
  • .h: c-code header
  • _p.h: private c-code header (only to be included by the corresponding .c file)
  • TYPENAME.tm2: Short definition file used by other typemaker2 input files which use types from this XML file
  • TYPENAME_list.tm2: Same as above, but for TYPENAME_LIST type (only if the XML file states that _LIST macros are to be used)
  • TYPENAME_list2.tm2: Same as above, but for TYPENAME_LIST2 type (only if the XML file states that _LIST2 macros are to be used)
• the first step when creating files with typemaker2 is to generate the type descriptions (those *.tm2 files) using $(typemaker2_exe) --defs-only, because those are needed by other typemaker2 XML files
  • can typemaker2 be compiled standalone without requiring another instance of typemaker2 to pre-process input file? If so, this shouldn't be a problem with CMake.
    • in typemaker2 we also use typemaker2 files. Also, typemaker2 uses gwenhywfar and gwenhywfar uses typemaker2, so we have a circular dependency here. That's why generated files need to be present and current in the release tarballs. But that should not be much of a problem (at least it isn't now). But its why I would like to have a "target" to manually build the typemaker2 files like we now have with the autotools system (make typedefs; make typefiles) [mp].
• after that typemaker2 can be used to generate the c- and h- files (without the --defs-only switch)
• currently we don't always re-generate all typemaker2-built files on every run, some files are pre-built in the release-tarballs, that can be changed (in gwbuild typemaker2 source files are just handled like normal sourcefiles). However, in gwen this is necessary to avoid the hen-and-egg problem (e.g. typemaker2 output files MUST be provided in the release tarball, because the user can't rebuild them if he not already has the typemaker2 tool installed in a reasonably current version when he is compiling the new version)
• it would be nice to have non-auto targets to generate those files manually (like we now use "make typedefs; make typefiles" when needed)

Platform compatibility¶

CMake allows to build natively on all platforms, including Windows. Right now an effort is underway (https://github.com/microsoft/vcpkg/pull/26363) to compile natively on Windows with vcpkg using clang-cl (a drop-in replacement for msvc), which VS2019+ ships with. This, however, still uses the existing autotools build system, together with msys2, which vcpkg uses to abstract bash environment that autotools requires. As a result of this, compilation is quite slow.
Migrating to CMake would allow to build AqBanking with CMake only, without additional wrappers. Ideally, this should also be doable with msvc, but that would require some code changes, e.g. replacing the gcc-isms, thus making it ISO-C/C++ compliant.

Automated testing¶

We'd need some sort of automated testing, both unit testing and integration testing.

For that we need to set up a CI/CD infrastructure that would allow to create relevant pipelines. Easiest is to use GitHub Actions free plan: https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration

Steps required are:

1. Setting up a mirror sync between http://aquamaniac.de git and GitHub
2. Setting up pipelines for all systems

Unit testing¶

This should be straightforward using the pipelines

Integration testing¶

We need to be able not to only test the compilation itself, but also whether the downstream projects can compile and run just fine. At the minimum we need to test with AqBanking, but ideally also with KMyMoney/GnuCash.

What would also be worth doing is testing integration with vcpkg — i.e. rebuilding a vcpkg gwenhywfar package and its downstream dependencies (aqbanking).

Proposed order of migration¶

In the perceived order of lowest to highest complexity:

1. Libchipcard
2. AqBanking
3. Gwenhywfar
   1. Main library first
   2. Plugins
   3. typemaker2 generator (see explanations above)