Change build infrastructure to CMake about mbusd HOT 20 CLOSED

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.

from mbusd.

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

from mbusd.

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.

from mbusd.

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

Thank you for your contribution @nickma82!

from mbusd.

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?

from mbusd.

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

from mbusd.

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.

from mbusd.

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

from mbusd.

I've pushed into master

Awesome, I'm gonna merge asap

from mbusd.

@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?

from mbusd.

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

from mbusd.

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.

from mbusd.

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?

from mbusd.

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?

from mbusd.

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

from mbusd.

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

from mbusd.

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?

from mbusd.

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.

from mbusd.

For both of them - Fedora flavored.

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

from mbusd.

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. :)

from mbusd.