Seeking Patterns for Reusable Build Machinery

[phillipjohnston]

What are the generally well-regarded patterns for maintaining custom reusable build machinery that is shared across projects?

Currently I'm using subdir('meson/directory_to_hold_meson.build_with_resuable_code'), which is generally fine but leads to structures of directories that exist purely to satisfy the need to have a meson.build file in a distinct subfolder.

Are there any other options, or is this still the state of the art?

(I see that the include() PR is now closed (#5209) and looking into modules, which would do the trick, it seems I have to merge them upstream, which I suspect will not happen for machinery that does not appear to be broadly useful.)

[eli-schwartz]

The include() PR was closed due to the original submitter losing interest, but I remain staunchly convinced that we want this and people deserve to have it. It just needs someone to work out all the gnarly implementation details.

Modules don't necessarily have to be extremely popular, though that does help. What kind of functionality are we talking about, anyway? Is it something useful to more than one organization's repositories?

[eli-schwartz]

So on that list, two things I can talk about right off the bat are map files and doxygen.

The first one is something that in the long term I believe meson needs to natively support and people have asked about it. Not sure what compilers other than GCC can do in terms of map files, but either way is definitely Meson's responsibility and will probably end up as a first class kwarg to build_target() and friends (or in theory it might work to recognize the file extension *.map?)

The same goes for the more targeted case of version scripts, incidentally (the fun part there is consistently handling flat lists libtool-style and deprecating the MSVC specific vs_module_defs).

The second one is an excellent example of something a module should do. It would come with some advantages like being able to detect output files as listed in Doxyfile, or automatically install them to the right location if they are specified as man page outputs. In fact, doxygen is so popular it turns out lots of people are using it, not just you :p for example I am using it and have an independent need for such a module which I have been meaning to create.

I don't currently have much thoughts on anything else you mentioned, except to note that the catch2 handling seems like the same sort of thing that has some people wanting cmake-style user defined functions, which meson probably does not want to do, and an include() snippet sounds like the best alternative. OTOH this may be frameable in terms of a module method generic enough to be broadly useful.

[dcbaker]

Could you give an example (even if it's simplified) of what you're doing with catch2?

[phillipjohnston]

Could you give an example (even if it's simplified) of what you're doing with catch2?

Happy to:

• "Module": https://github.com/embeddedartistry/meson-buildsystem/tree/master/test/catch2
• Example use:
  • Creating a dependency to pass to catch: https://github.com/embvm/embvm-core/blob/master/test/meson.build
  • Invoking the module: https://github.com/embvm/embvm-core/blob/2e3d53a03d332b83cbb746e0fc157f7c57d49262/meson.build#L223

[phillipjohnston]

In fact, doxygen is so popular it turns out lots of people are using it, not just you :p for example I am using it and have an independent need for such a module which I have been meaning to create.

Here's my doxygen "module" if it helps as a starting point in your own projects: https://github.com/embeddedartistry/meson-buildsystem/tree/master/docs/doxygen

[dcbaker]

I think about half of that could go in a module.

The other half could be handled through a test protocol. We have support for gtest and rust's native test format as test protocols. When you pass gtest, for example, we do some extra work to generate a junit file durring the test run, then after all the tests we scoop that up and produce a single, unified junit in $builddir/meson-logs/testlog.junit.xml. We do something similar with rust (though it's not as nice and we have to scrape stdout :/)