i3/RELEASE-NOTES-next

46 lines
2.4 KiB
Plaintext
Raw Normal View History

┌──────────────────────────────┐
│ Release notes for i3 v4.19 │
└──────────────────────────────┘
This is i3 v4.19. This version is considered stable. All users of i3 are
strongly encouraged to upgrade.
add meson build files (#4094) 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.html https://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
2020-05-19 15:45:06 +03:00
In this release, we switched from the autotools build system to the meson build
system (https://mesonbuild.com/). Check https://github.com/i3/i3/issues/4086 for
details. If this causes problems for you, you can revert the commit which
removed autotools from the tree: we tried our best to keep both build systems
working. Please reach out to us in that case!
┌────────────────────────────┐
│ Changes in i3 v4.19 │
└────────────────────────────┘
• configure: respect --program-suffix
• use exec to avoid leaving useless shell process
• ipc: always include the marks property (even if empty)
• introduce “tiling_from” and ”floating_from” criteria
• make dock client order deterministic (sorted by class/instance) as a
side effect, i3bars without an explicit bar-id will be sorted according
to their definition order in the config file
• update i3bar config when necessary (reduces redraws on bar mode changes)
• mention rofi in default config file
┌────────────────────────────┐
│ Bugfixes │
└────────────────────────────┘
• ensure client windows have a size of at least 1px after resize
• correctly handle overlapping decorations
• limit workspace numbers within 0..INT32_MAX
• fix a bug with tiling resize inside floating container
• i3-nagbar: Use _PATH_BSHELL to ensure using a bourne shell
• do not propagate $mod+right click to fullscreen clients
• do not try to resize fullscreen and non-fullscreen windows
• do not focus floating windows changing workspace with ConfigureNotify
• i3-dmenu-desktop: Support symlinks in search path
• build: correctly provide auxiliary functions when needed
Makefile.am: Use BUILT_SOURCES for GENERATED headers (#4068) The previous fix when using _DEPENDENCIES was wrong because that dependency is only created for the final executable. However, the build fails when building the object file. The manual explicitly mentions that using _DEPENDENCIES is wrong for source files: > In rare cases you may need to add other kinds of files such as linker > scripts, but listing a source file in _DEPENDENCIES is wrong. If some > source file needs to be built before all the components of a program > are built, consider using the BUILT_SOURCES variable instead (see > Sources). https://www.gnu.org/software/automake/manual/automake.html#Linking Instead, using BUILT_SOURCES works, as mentioned in the manual. https://www.gnu.org/software/automake/manual/automake.html#Sources I have also removed the dependencies from i3_SOURCES since AFAIK dependencies to header files don't do anything. I have verified that modifying the header correctly re-triggers the build for i3 & i3-config-wizard. > Header files listed in a _SOURCES definition will be included in the > distribution but otherwise ignored. In case it isn’t obvious, you > should not include the header file generated by configure in a > _SOURCES variable; this file should not be distributed. Lex (.l) and > Yacc (.y) files can also be listed; see Yacc and Lex. https://www.gnu.org/software/automake/manual/automake.html#Program-Sources An alternative instead of BUILT_SOURCES that should also work in our case is found in this section: https://www.gnu.org/software/automake/manual/automake.html#Built-Sources-Example see "Recording Dependencies manually". The syntax would be: foo.$(OBJEXT): $(config_parser_SOURCES) $(command_parser_SOURCES) The benefit of this over BUILT_SOURCES is that it will work for targets other than 'all', 'check' and 'install'. However, since we don't really have such targets we don't need to do this right now. Tested extensively using this script: #!/bin/bash set -x autoreconf -fi while mkdir build && cd build && ../configure && make -j; do cd .. rm -rf build done Fixes #3670
2020-05-05 19:13:19 +03:00
• build: fix issues with parallel build
• set _NET_DESKTOP_VIEWPORT after randr changes
• fix a bug with i3-nagbar not starting after it has already started once