[Enhancement] Support for out-of-tree modules

Maybe this is already possible, but I haven’t found any documentation or other statements. Coming close is issue #4533, but that developed into a different direction.

I propose to allow users to implement their own modules (inheriting ExtensionModule) and allow to import them locally.

Meson already provides a variety of modules for common tasks (i18n for example) or library-specific things (Gnome module for example). There are some issues with in-tree modules though:

• The process of getting a module upstreamed takes a long time if it happens at all (only modules useful for a broader audience are upstreamed).
• One might not be so eager to update the build system (meson itself) just to use a newly added module.

There are already ways to implement custom tasks in meson, mainly find_program() or generator(). Those generalized functions can, by design, not be as convinient to use as specialized functions. The ability to define custom methods with a speaking name and clearly defined parameters makes working with common tasks much more pleasent.

The reasoning behind this request is based on the anforemented issues, as well as companies having internal or proprietary tooling for which a module could legally not be added to meson.

[eli-schwartz]

1. We would need to keep it stable over releases.

The first one we don’t have and we don’t have resources for the latter. Not to mention that it would severely limit any internal refactoring we’d need to do to update the core.

Actually IMO this is not necessarily a problem (if it were the only argument against them) 😄 we could do like the linux kernel and say “your punishment for not upstreaming it is, there is no stable API and it might break in a point release, you’ll need to maintain ifdef soup to keep it working”.

[Flow-It]

Thanks, I didn’t know about the limitations of find_program(). That clears up the concerns @jpakkane has about UDFs.