Change build infrastructure to CMake

[3cky]

Autoconf/automake build scripts used by mbusd are really old and complex to maintain, so we should switch to CMake build system https://cmake.org/

[nickma82]

What are the requirements here (for the initial transition)?

Here's what I see right now

• Automatically detect the availability of
  -- (LIB_UTIL AND tty_get_name AND uu_lock) -> HAVE_LIBUTIL
  -- logw -> LOG
  -- cfmakeraw -> HAVE_CFMAKERAW
  -- cfsetspeed -> HAVE_CFSETSPEED
  -- (time AND localtime) -> HRDATE
• Provide user options for
  -- TRXCTL
  -- DEBUG output

Functional requirements:

• classical make/make install capabilities (binary and man.file)

What else?

[nickma82]

I just made up an early functional version [1] with minimal changes to the codebase. The only real changes were in the main.c from _open/_close to open/close [2].
Does this break the OpenBSD build, could you check that?

Best

[1] https://gitlab.com/nickma/mbusd/commit/d26f68ee058edabec4209c9f191f4928d11b6e0b
[2] https://gitlab.com/nickma/mbusd/commit/d26f68ee058edabec4209c9f191f4928d11b6e0b#3a576e09615c0e19842e5f3ac31e858c9ae7fe41

[3cky]

Wow, nice to see some progress! Don't have access to any *BSD box right now, but I'll try to find some to check that.

[nickma82]

Ok, currently working on cmake and an unittest infrastructure in parallel.

What's working until now:

• I just made up the first (non mbusd dependent) tests runnable on gitlab-ci [1] using greatest [2]
• the environment infrastructure, including
  -- a modbus-serial server/instance mockup
  -- a virtual tty setup
• Artifacts downloadable from gitlab-ci [1] for the architectures ARMhf (e.g. raspberry) and x86

What's up next:

• cleanup of the automake files
• The first mbusd testcases
• maybe cmake debian package creation

Every kind of support appreciated.

[1] https://gitlab.com/nickma/mbusd/pipelines
[2] https://github.com/silentbicycle/greatest

[3cky]

Sounds great! I will look into it.

Btw, please note I've pushed into master support for read configuration from file. Also multiple systemd instances of mbusd are supported now.

[nickma82]

I've pushed into master

Awesome, I'm gonna merge asap

[nickma82]

Please review https://github.com/nickma82/mbusd/tree/unittests

[3cky]

@nickma82 great work, thanks! I've merged your changes into https://github.com/3cky/mbusd/tree/cmake branch, also made some fixes in bed0a84 (handle different PREFIXes, install example configuration file, added uninstall target).

It seem to be good enough to be merged into the master. Do you have any thoughts on this?

[nickma82]

Great, following some thoughts:

• I haven't tested the install/uninstall targets very well.
• README.md (done see this pull request)
  ** Still contains an automake corresponding section
  ** An explaining how to enable/disable the cmake options (e.g. ccmake, cmake-gui) would be nice to have
• on debian:stable there is no folder named '/usr/lib/systemd/system' leading to a disabled systemd-script installatoin

[3cky]

on debian:stable there is no folder named '/usr/lib/systemd/system' leading to a disabled systemd-script installatoin

Hmm, and there is no systemd executable in PATH on Fedora, so probably we should use both methods to detect systemd presence.

[nickma82]

Hmm, and there is no systemd executable in PATH on Fedora, so probably we should use both methods to detect systemd presence.

How about that?

[3cky]

How about that?

That's much better. :) But still have some doubts about service file install path. Arch Linux systemd user guide says:

• /usr/lib/systemd/system/: units provided by installed packages
• /etc/systemd/system/: units installed by the system administrator

Fedora Linux seem to follow the same service file location rules. Is /lib/systemd/system/ location specific to Debian?

[nickma82]

I'm having a hard time to find a good source for the systemd/sytem directory.

Is /lib/systemd/system/ location specific to Debian?

/lib/systemd/system/exists and contains a lot of *.service files

Ad /usr/lib/systemd/system/ :
-- contains the folders: boot catalog network scripts user user-generators
-- only the user folder contains *.service files (and *.target, *.socket, *.wants files)

Ad /etc/systemd/system/: Sounds good to me. Both freedesktop.org and a post at askubuntu.com are saying that this folder is for user specific file placement/overriding.
Further the following command lists that path on debian:stable

systemctl show --property=UnitPath
UnitPath=/run/systemd/transient /etc/systemd/system /run/systemd/system /run/systemd/generator /lib/systemd/system /run/systemd/generat

I'd take /etc/systemd/system/.

Best

[3cky]

I think probably we shouldn't reinvent the wheel and just borrow FindSystemd.cmake from qBittorrent guys. :)

[nickma82]

Integrated FindSystemd.cmake and changed the other install targets a bit, please review again

Another thing: do you have the fedora compile rpm-dependencies at hand?

[3cky]

Integrated FindSystemd.cmake and changed the other install targets a bit, please review again

Done, please see d8b3b24.

Another thing: do you have the fedora compile rpm-dependencies at hand?

Do you mean the dependencies required by CMake/CPack or by mbusd itself? BTW I still didn't check packaging part, will do.

[nickma82]

Do you mean the dependencies required by CMake/CPack or by mbusd itself?

For both of them - Fedora flavored.

I still didn't check packaging part, will do.

You don't have to. Wait for the gitlab-ci infrastructure, it outputs the package by itself.

[3cky]

For both of them - Fedora flavored.

Just checked it with fresh Fedora 27 install, the minimum requirements are cmake, pkgconfig and gcc-c++ packages.

[3cky]

Checked FreeBSD 11 build, merged cmake branch into master and released v0.3.0!

Thank you for your contribution @nickma82!

[nickma82]

released v0.3.0

Now with the packaging capabilities you could release (downloadable) packages.. (deb, rpm)?

Thank you for your contribution

Thank you too, your way of being into that changes kept me on track. :)