initial meson move

[sewnie]

Currently, this has no support for the following features that already existed within Makefile:

• Valgrind https://mesonbuild.com/Unit-tests.html#other-test-options
• Test program ninja -C build test
• Documentation (Move to scdoc #1225)
• Doxygen

Fixes #1224

[sewnie]

I had underestimated how big this project is, which is why i initially thought this would be quite easy, as i had figured dunst is this simple notification daemon program.

[fwsmit]

What is difficult about the test binary? It just needs to be compiled and run with valgrind. Meson probably has some way to run binaries

[sewnie]

Thankfully, Meson comes with coverage reports, so i hope we can drop the coverage reporting all together and only have valgrind tests and run the test program.

https://mesonbuild.com/howtox.html#producing-a-coverage-report

sound good to you?

(this is still somewhat very difficult due to the complexity of Dunst, its website, documentation, testing suite and such... i still really expected dunst to be a simple project)

[fwsmit]

Yeah, seems good to me. Maybe @bebehei has a stronger opinion about this, since he set up most of our testing infrastructure.

[bebehei]

Nice!

Meson was on my "fancy things I might implement" list.

Need to try it with some spare time at the evening.

[sewnie]

If you are a bit more experienced with Meson, I'd suggest you give it a shot rather than me :D

[bebehei]

Sorry for giving false hints, but I do not have any experience with meson.

[sewnie]

I'll be dropping coverage tests for the time being.

[sewnie]

@fwsmit tests program is failing here as well.

[sewnie]

Notable changes:

• GitHub CI workflow is Ubuntu only, due to dependency constraints, and how it shouldn't realistically fail to run on musl or other distributions, the source is their problem typically.

[sewnie]

Can main.c be moved into src?

[bebehei]

Can main.c be moved into src?

Probably yes.

[sewnie]

I am rather concerned over the fact that 'main.c' isnt simply just the dunst_main function from dunst.c, seems complicated for no good reason that i know of currently..

[bynect]

I am rather concerned over the fact that 'main.c' isnt simply just the dunst_main function from dunst.c, seems complicated for no good reason that i know of currently..

I was also wondering why that is.(some leftover?)

Probably main.c could be removed altogether by putting main in dunst.c?

[sewnie]

Probably main.c could be removed altogether by putting main in dunst.c?

Other code in the test suites depend on code from dunst.c. I've tried to move dunst_main to main.c myself but unsure what to do about the setup_done variable.

[bynect]

Probably main.c could be removed altogether by putting main in dunst.c?

Other code in the test suites depend on code from dunst.c. I've tried to move dunst_main to main.c myself but unsure what to do about the setup_done variable.

Well, since the main function is heavily tied to everything in dunst.c probably moving main there would be better.

[sewnie]

Moving main.c to dunst.c, while dunst.c is required by the test suite causes problems, as the test suite depends on dunst's code too.

[bynect]

Moving main.c to dunst.c, while dunst.c is required by the test suite causes problems, as the test suite depends on dunst's code too.

Some simple meta programming can fix that honestly.

#ifndef TESTING

int main(int argc, char **argv) {
    return dunst_main(argc, argv);
}
#endif

[sewnie]

• Need to implement debug buildtype

[sewnie]

anything missing from the makefile so far?

[bynect]

I was wondering, why remove outright the makefile when they can coexist afaik? Shouldn't the option to use meson be added alongside of makefiles?

Then, after some time (to get feedback from the users), removing the latter can be thought of in another pr.

[sewnie]

It doesn't make sense to keep both build systems, it will be messy.

[bynect]

Yes, but it is still an additional dependency that is really not that required. I mean, it doesn't seem to add any value to what the makefiles can already do. So people would have to install and learn meson instead of just using make (installed by default everywhere) just for the sake of using meson.

Well, that is my idea. @fwsmit or @bebehei should decide a reasonable compromise.

Note: I am not saying that meson is useless, just that removing the makefiles point blank is probably not the best way

[bynect]

For now meson is the secondary build system, however I am positive we can move totally to meson in the future.
I would like to leave a couple of release before removing the makefile.
also to move to meson we have to make the ci work like the makefile.

[bynect]

anyway, thanks for your work ❤️

[bynect]

It now occurs to me that the prefix is not handled correctly, as pointed out by Narrat in #1462.

When the prefix is set to something the bindir is not actually used as prefix+bin.
I supposed that meson automatically managed the appending but I guess not.

Is there an idiomatic way to solve this? @apprehensions @eli-schwartz

[eli-schwartz]

When the prefix is set to something the bindir is not actually used as prefix+bin.
I supposed that meson automatically managed the appending but I guess not.

There are valid use cases for knowing both a relative and an absolute bindir.

Given:

--prefix=/usr --bindir=/usr/bin

--prefix=/usr --bindir=bin

the value of get_option('bindir') is "bin" and the absolute path can be gotten with

abs_bindir = get_option('prefix') / get_option('bindir')

For something like this:

install_data('dunstctl', install_dir: get_option('bindir'))

Meson knows to install dunstctl in the directory sigified as bindir, and to find that relative to the prefix. The ambiguity comes when you want to render the string representation of that directory inside a configuration file, such as a systemd service.

[eli-schwartz]

We can see for example this was already done here.

[eli-schwartz]

... but forgotten here.