WIP: meson build

[Larhzu]

The following is relevant only when other things have already been finished. I'm writing it here so that it won't be forgotten.

The tuklib files are a bit similar to Gnulib in sense that a subset of the files is meant to be reusable in other projects somewhat easily. With Autotools and CMake, one can copy the relevant m4/tuklib_*.m4 or cmake/tuklib_*.cmake files along with the .h and .c files.

Meson's language is intentionally more restrictive so it's OK that the first iterations put all tuklib checks into a single meson.build. This is not ideal in the long term though as it makes it difficult to reuse a subset of the modules.

One method would be to have a separate repository for the tuklib modules, each module having a meson.build snippet file. Then a script would take a list of modules to use and generate a single meson.build from the snippets (in the right order, handling possible dependencies). The downside is that each project using a different subset of the modules would end up with a different generated build system file in the source package (simpler than configure but still).

Another idea could be to have a variable, for example, tuklib_modules which would contain a list of modules to use. Top-level meson.build would set that variable and then do subdir(src/common/tuklib_meson) which would further do subdir(modulename123) for each module name that was found in tuklib_modules (in dependency order).

This way the checks of each module would be in their own meson.build files. In the parent directory the meson.build file would list all modules, including those that a specific project doesn't need. It would be just a boring chain of if-subdir-endif lines in the correct order to satisfy possible cross-module dependencies. This way no generated files would be needed to use a subset of the modules in another project.

(The if-subdir-endif file might still be a generated file in the module repository. However, it would be the same for all projects that use the modules, thus there wouldn't be as many versions of the generated file, making reviews easier.)

The set of tuklib modules is tiny so in this sense this is silly overthinking. But I'm curious how this would have to be done with bigger number of reusable modules (like Gnulib). It seems essential to split the per-module checks into separate files if there are tens of modules and different projects use a different set of modules. A per-project generated meson.build that contains checks for tens of modules sounds too similar to a generated configure. Avoiding such per-project generated files is a big reason why this Meson discussion in XZ Utils is happening in the first place.

---

Edited to add:

Modules may add build options too. Currently unaligned-access is listed in the top-level meson_options.txt which is OK for now but, like with meson.build files, it's not ideal in the long run as it would require project-specific generated files.

Or perhaps the solution to generated files is to have a mesongen.py which would generate the meson.build files and meson_options.txt. This would mean no muon support though as Python would be a hard dependency. But this way the package wouldn't ship with any generated build system files, and one would only need Python (which is already needed for Meson) to genete the files needed by Meson. The idea of a build system generator doesn't sound great though but if pure Meson solutions are inconvenient, it might be an option too.

[Larhzu]

(which generates #undef WORDS_BIGENDIAN on little endian) good for you ?

Yes. Thanks!

[Larhzu]

I see no '.' at the beginning of a line in toplevel meson.build.

True and I didn't mean to imply that. In case you missed my point, see the commit f9cf4c05edd14dedfe63833f8ccbe41b55823b00.

[vtorri]

(which generates #undef WORDS_BIGENDIAN on little endian) good for you ? Yes. Thanks!

done