Otherwise, each time we start a nagbar, a cleanup handler is created.
However, each of these handlers tries to kill the same process (->data
is a pointer to config_error_nagbar_pid / command_error_nagbar_pid).
With this commit, both potential nagbar processes are killed once.
Other changes in nagbar_exited:
- Remove ERROR from ELOG as it shows up as "ERROR: ERROR:"
- Make sure to reset the PID even when the process did not exit
normally.
- Use ELOG when exitcode != 0
- Remove the not found error: if nagbar is not in $PATH, exec_i3_utility
prints an error as well.
For the record, I also implemented a more complicated approach with a
new watcher data structure:
bd3aaf3a33
While writing the commit message, it occurred to me to compare
watcher->pid with *watcher->data, which fixes the problems mentioned in
that patch.
Fixes#4104
…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
This works better with meson, where .h files can be declared as being part of an
executable easily, but I couldn’t find a way to declare
e.g. include/atoms.xmacro as a dependency.
related to #4086
This is another regression from #4014: multiple arrows in a row mean
optional values. Re-introduce new states to force matching & proper
parser errors.
- Split cmd_bar into 2 functions, improving errors and reducing strcmps
- Only update barconfig when something has changed
- Only update barconfig for the specific bar that has changed
Fixes#3958
- Includes updated bigpicture.png from dump-asy.pl script
- The X11 root window is not a container
- Adds some extra information
bigpicture.png is created by converting the .asy to an .eps with `asy
bigpicture .eps` and then using the following gs command:
gs -dSAFER -dBATCH -dNOPAUSE -dEPSCrop -r600 -sDEVICE=pngalpha -sOutputFile=bigpicture.png bigpicture.eps
Instead of sorting alphanumerically, use a more opinionated order,
listing more "important" files towards the beginning.
Info in this section was a bit outdated. First of all, i3 contains many
more files that were not mentioned. Instead of trying to include
everything, I deleted some files with very obvious descriptions. We can
always re-add something if we want to add more details to it.
This still had some leftovers from the patch era. Since git and
specifically GitHub-like developing is much more mainstream now we don't
need to link introductions or even mention the idea of "patching".
The deleted "them" was referencing an old sentence referring to patches,
generated by the git cli. As emailing patches is not common at all for
GitHub repos, I removed the sentence altogether.
Also simplifies the 'branches' subsection a bit. Asking people to verify
their patch on master seems too much preliminary work and I doubt that
anyone does it anyway.
