Example in
https://github.com/i3/i3/actions/runs/18260895234/job/51988635887?pr=6502
`i3-log-for-124-move.t`:
```
../libi3/font.c:332:9: runtime error: signed integer overflow: 2147483641 + 11 cannot be represented in type 'int'
#0 0x5611ce962d65 in draw_text_xcb ../libi3/font.c:332
#1 0x5611ce962d65 in draw_text ../libi3/font.c:376
#2 0x5611ce95de20 in draw_util_text ../libi3/draw_util.c:219
#3 0x5611ce947e7a in x_draw_decoration ../src/x.c:751
#4 0x5611ce94f93a in x_push_node ../src/x.c:1097
#5 0x5611ce94e9d8 in x_push_node ../src/x.c:1204
#6 0x5611ce94e9d8 in x_push_node ../src/x.c:1204
#7 0x5611ce94e9d8 in x_push_node ../src/x.c:1204
#8 0x5611ce952e9b in x_push_changes ../src/x.c:1373
#9 0x5611ce922d1f in tree_render ../src/tree.c:468
#10 0x5611ce8d1bbb in handle_run_command ../src/ipc.c:220
#11 0x5611ce8c87fe in ipc_receive_message ../src/ipc.c:1481
#12 0x7effc262b64a in ev_invoke_pending (/lib/x86_64-linux-gnu/libev.so.4+0x564a) (BuildId: cfcffb10ff16734dcc7d31d002a90940abff0323)
#13 0x7effc262f22e in ev_run (/lib/x86_64-linux-gnu/libev.so.4+0x922e) (BuildId: cfcffb10ff16734dcc7d31d002a90940abff0323)
#14 0x5611ce809d48 in ev_loop /usr/include/ev.h:841
#15 0x5611ce809d48 in main ../src/main.c:1229
#16 0x7effc1e41ca7 (/lib/x86_64-linux-gnu/libc.so.6+0x29ca7) (BuildId: def5460e3cee00bfee25b429c97bcc4853e5b3a8)
#17 0x7effc1e41d64 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29d64) (BuildId: def5460e3cee00bfee25b429c97bcc4853e5b3a8)
#18 0x5611ce80e770 in _start (/usr/src/i3/build/i3+0x230770) (BuildId: 181abde9a3dd28a8a4be68b90b9b710c8e280633)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../libi3/font.c:332:9
```
Unrelated but I fixed the build fails in `next` because of a
false-positive:
```
In file included from ../include/all.h:40,
from ../src/commands.c:10:
../src/commands.c: In function ‘cmd_floating’:
../include/log.h:30:33: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
30 | #define DLOG(fmt, ...) debuglog("%s:%s:%d - " fmt, __FILE__, __FUNCTION__, __LINE__, ##__VA_ARGS__)
| ^~~~~~~~~~~~~
../src/commands.c:1193:13: note: in expansion of macro ‘DLOG’
1193 | DLOG("should switch mode to %s\n", floating_mode);
| ^~~~
cc1: all warnings being treated as errors
ninja: build stopped: subcommand failed.
```
They are newly failing since the previous commit (upgrading to Ubuntu focal),
so instead of debugging what the issue is, let’s just remove them entirely.
Not many i386 users are left, as the world is on amd64 and arm64 these days.
Benefits:
- Faster feedback in case of error
- More checks run in parallel
- Removes stuff from Dockerfiles
- Uses newest available clang-format (in ubuntu repos)
…instead of building a release tarball over and over again.
This has become an issue as meson insists on running tests before creating a
release tarball (which is a good policy).
related to #4086
Motivation:
• faster builds (on an Intel Core i9-9900K):
( ../configure --disable-sanitizers && make -j8; )
19,47s user 2,78s system 395% cpu 5,632 total
( meson .. -Dmans=true -Ddocs=true -Dprefix=/usr && ninja; )
38,67s user 3,73s system 1095% cpu 3,871 total
• more approachable build system configuration in the
python-esque meson domain specific language instead of
the autotools m4 macro language
• built-in language server support thanks to ninja:
the required compile_commands.json is built automatically
and only needs to be linked from the source dir, e.g.:
ln -s build/compile_commands.json .
Changes:
• the embedded vcs version info format changed from e.g.
4.18-282-gabe46f69 (2020-05-16, branch "next")
to:
4.18-282-gabe46f69
I think it’s better to lose a little bit of detail for
the gained cleanliness of using meson’s vcs_tag()
• Drop unused xcb-event dependency.
• We can no longer enable sanitizers and debug options
based on whether we are in a release or non-release build,
because our new version logic runs at ninja build time,
not at meson configure time.
The new behavior is probably for the better in terms of
what people expect, and we can make the CI use address sanitizer
explicitly to ensure it is still exercised.
• We lose the AX_EXTEND_SRCDIR behavior, i.e. including the
path component of the parent of the source dir in all paths.
This was a trick we used for easier debugging, so that stack
traces would contain e.g. ../i3-4.18.1/src/main.c, instead of
just src/main.c.
The other mechanism (_i3_version symbol) that we have for including
the version number in the “backtrace full” (but not merely
“backtrace”) output of gdb still works.
• Release tarballs now use tar.xz. Why not.
Migration plan
This commit adds the meson build files to the tree, but does not remove
autotools yet. For the development phase, we will keep both build systems
functional (and built on travis).
Then, just before the i3 v4.19 release, we will remove autotools from the tree
and the release tarball will require meson to compile.
This way, we incentivize maintainers to change, while also offering them an easy
way out (if desired) by reverting the most recent commit. In practice, switching
a distribution package from autotools to meson should only be a few line change,
easier than applying the provided patch :). Take a look at the debian/ changes
in this commit for an example.
meson is broadly available everywhere that i3 is available: Both xorg-server and
systemd gained meson build files in 2017, so we can follow suit:
https://anholt.livejournal.com/52574.htmlhttps://in.waw.pl/~zbyszek/blog/systemd-meson.html
How do I?
For producing a coverage report, enable the b_coverage meson base option
and run ninja coverage-html:
% cd build
% meson .. -Db_coverage=true
% ninja
% ninja test
% ninja coverage-html
See also https://mesonbuild.com/howtox.html#producing-a-coverage-report
For using the address sanitizer, memory sanitizer or undefined behavior
sanitizer, use the b_sanitize meson base option:
% cd build
% meson .. -Db_sanitize=address
% ninja
See also https://mesonbuild.com/Builtin-options.html#base-options
related to #4086
meson only supports the top level (no subdirs), so this makes the transition
easier.
For this to work with autotools, we need to *disable* the subdir-objects option,
that autotools wants us to enable for forward-compatibility.
This results in a bunch of warnings at autoreconf-time, but we don’t care, given
that we intend to switch away from autotools. Both build systems working next to
each other (as best as they can) is more important.
related to #4086
Ubuntu’s apt started refusing to load package files from unauthenticated
repositories, but the package for which we did that (xcb-xrm) is available in
newer versions of Ubuntu, so I just removed that part altogether.
Apparently this has been broken since April, and nobody noticed :-/
mk-build-deps started using the changelog file to get the version number, but a
bug prevents it from falling back correctly to 1.0 if no changelog is
present. This has been fixed upstream in
4b15abd4f0,
but we can just ship the changelog file until that fix lands.
• The output currently contains a large number of false-positives and — AFAICT —
no actual issues.
• Upstream shows little interest in addressing the long-standing issues with the
TAILQ macros, so the false-positive situation probably won’t change soon:
https://bugs.llvm.org/show_bug.cgi?id=18222
Currently, we largely spend travis CPU cycles on this, for no additional value.
https://llvm.org/bugs/show_bug.cgi?id=30353 was filed for the unintended
line break between in e.g. “TAILQ_ENTRY(foo)\nbar;”.
Until that’s fixed or a workaround is known, we’ll live with line
breaks. To make it a bit easier for readers to see what’s going on, I
added extra line breaks around each such struct member/variable
definition, so that they at least visually are a single unit.
fixes#2174
…instead of lexicographically sorting strings, which fails for the
following situation:
4.12-96-g086276b
4.12-97-g59c070b
4.12-108-gb850cfb
This bug resulted in new packages being built and uploaded, then
immediately deleted.
Thanks to eeemsi for reporting the issue.
