question: Meson

[Tachi107]

Hi! First of all, I'm impressed with your work, great job :D

As you know systemd upstream uses Meson. Why did you choose to replace it with CMake instead? Does it have some issues that make it a bad choice for cross-Unix development? Could you please be specific?

I really like Meson, and I think its simplistic approach ensures a nice development experience. But nothing is perfect! If you'd share your concerns I might be able to work on fixing them (I'm not a Meson dev). Thanks :)

And again, your work is quite impressive, hope someone starts integrating it in some cool BSD project!

[netbsduser]

Thanks for your kind words, glad to hear InitWare is appealing to you. InitWare's inception was some time ago, forking from a version of systemd which still used the GNU Autotools for a build-system. I would not necessarily be opposed to moving towards a Meson-based system, however, especially now that there is an alternative implementation of Meson written in C under the name Mumeson or Boson or something like that, which should clear up any old portability issues relating to Python quite nicely.

One thing I like about modern CMake is that in place of the old approach of dealing with compositions of string CFLAGS, LDFLAGS, etc., it's now encouraged to deal instead with logical targets; one defines for example a library target, adds relevant public include directories and suchlike to that target, and then with one line, you declare that some other target will link to that target, and all the relevant things (include directories etc; the actual library itself) are added automatically to the underlying CFLAGS etc of the target which will link in that other target. I am not sure if Meson follows this approach; does it? It wouldn't mean a 'no' to Meson if it does not; it would however feel like a clear regression to lose that abstract notion of targets.

[Tachi107]

there is an alternative implementation of Meson written in C under the name Mumeson or Boson or something like that

muon is in good shape, especially compared to the alternatives listed on Meson's FAQ. I regularly use it to build one of my projects.

I am not sure if Meson follows this approach; does it?

Yep, it does. It's a bit different though. In Meson, when you want to define a target you can call the executable() or library() function and you pass in all its properties at the same time; once you define a target, it is immutable. For example:

syslogctl = executable(
	'syslogctl',
	'syslogctl.c',
	c_args: ['-DMY_DEFINE', '-DSOMETHING'],
	install: true,
	dependencies: [
		internal_library_dep,
		dependency('system-or-subproject-dep')
	]
)

creates a syslogctl target, and the return value of the function, i.e. the target object, is saved in a syslogctl variable, in case it needs to be referenced later. One nice thing about the Meson DSL, compared to CMake's, is that return values of functions are actually returned as values like in C, and do not implicitly create global variables. It also has types, like strings (enclosed in '), arrays ([value, other_value]), integers, dictionaries, etc, as opposed to CMake's "everything is a string" approach.

One other notable difference is that Meson targets do not have the concept of private and public flags. All the properties of a target are private, but if you want to create an object that other targets want to "link to", or better, depend on, you have to create a dependency object. In the previous example, syslogctl depends on internal_library_dep, an object created like this:

internal_library = library('internal', 'internal.c')

internal_library_dep = declare_dependency(
	compile_args: '-DPUBLIC_DEFINE',
	include_directories: '.',
	link_with: 'internal_library'
)

This way the syslogctl target will inherit all the properties defined in the declare_dependency() call.

Some other things about the first example: install: true tells Meson that we want to install that target when running meson install, while in dependencies: [ ... ] we list all the dependencies of the target; they can be dependency objects created internally with declare_dependency() or external dependencies obtained with a dependency() call. dependency() is similar to CMake's find_package(), except that it searches for dependencies in pkg-config files, CMake config files, and in some cases it does custom lookups for some well known, hard to find system dependencies, and if it doesn't find it it can even fall back to using a bundled version stored in the subprojects/ directory (it can be stored as a git submodule, a Meson wrap, or a simple directory tree).