initial meson move

[apprehensions]

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 meson setup -Dtest=true
• Documentation (Move to scdoc #1225)
• Doxygen

Fixes #1224

[apprehensions]

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

[apprehensions]

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.

[apprehensions]

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.

[apprehensions]

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

[apprehensions]

@fwsmit tests program is failing here as well.

[apprehensions]

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.

[apprehensions]

Can main.c be moved into src?

[bebehei]

Can main.c be moved into src?

Probably yes.

[apprehensions]

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?

[apprehensions]

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.

[apprehensions]

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

[apprehensions]

• Need to implement debug buildtype

[apprehensions]

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.

[apprehensions]

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

[apprehensions]

But since you already add that to the whole project

Where?

[bynect]

But since you already add that to the whole project

Where?

I updated the comment. I thought I saw it but checking it back there wasn't 🤦‍♂️

[bynect]

I tried building with meson build and ninja -C build and everything worked well. I also tried with the x11 and wayland options. (nitpick question, is it possible to move dunst directly in the build dir?)

But when I tried to run the tests with meson test -C build the runner segfaults. When I read the log a lot of test failed, supposedly because the files in test/data where not found by the runner.

testlog.txt

Also, I didn't get any warnings about the test (with gcc) so I think it is somehow compiler specific.

[apprehensions]

Congrats you found #1228 on your own, which I can replicate without Meson.

[alebastr]

But when I tried to run the tests with meson test -C build the runner segfaults. When I read the log a lot of test failed, supposedly because the files in test/data where not found by the runner.

WARNING: Cannot open '/home/nect/dev/dunst/build/test/data/dunstrc.default': 'No such file or directory'

I'm just going to point to #1226 (review), because it's most certainly a meson port issue.

[bynect]

Congrats you found #1228 on your own, which I can replicate without Meson.

It actually is not the same thing, because I tried commenting the notification test suite (which is what causes the problem there) and it still is being problematic. Also a lot (and I mean it) of tests fail, so there is something else going on. Obviously I tried make and it works for the tests.

But when I tried to run the tests with meson test -C build the runner segfaults. When I read the log a lot of test failed, supposedly because the files in test/data where not found by the runner.

WARNING: Cannot open '/home/nect/dev/dunst/build/test/data/dunstrc.default': 'No such file or directory'

I'm just going to point to #1226 (review), because it's most certainly a meson port issue.

Thanks for pointing that out. I thought that a way to fix this problem was added already.

Also I noticed that the test runner is built/run with the debug verbosity which is not ideal since it clutters all the output

[apprehensions]

...What is that status on this?

[bynect]

if i remember correctly the only problem was with the test runner?

[apprehensions]

Why is there an installation section in the wiki? shouldn't it be in the README?

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 65.34%. Comparing base (d2faa87) to head (6232e71).

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1226   +/-   ##
=======================================
  Coverage   65.34%   65.34%           
=======================================
  Files          50       50           
  Lines        8326     8326           
  Branches     1001     1001           
=======================================
  Hits         5441     5441           
  Misses       2885     2885           

Flag	Coverage Δ
unittests	65.34% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[bynect]

Why is there an installation section in the wiki? shouldn't it be in the README?

I guess it should be in both. the wiki is still documentation

[hholst80]

I had underestimated how big this project is,

That is how any project get started. If we knew up front how much work it would be, nobody would ever start anything. ;-)

Looking forward to the final result, I have packaged up 150+ source packages and the stinkers are those who does not follow a strict autoconf / meson or cmake build.

The best most pleasant packages to work with are those build on Meson.