Is there a way to identify if this module/file should be compiled or not

[sandy-2018]

I'm asking help to seek an approach to cover the scenarios we used quite often before with Makefile or some other building system.

The intention is to use some macro definition handled by config files to identify if this module would be compiled or not. e.g. CONFIG_MODULE_A = y to compile this module_a in and CONFIG_MODULE_A = n to have this module not compiled in, for sure a meson.build is always under the directory of this module_a.

there could be quite some modules like module_a to be handled in this case by config file, or just like the config files in Linux kernel or _defconfig in u-boot.

I'm wondering how to handle this scenario with Meson, I tried with configuration_data, configure_file, and was intended to use a variable to identify if the subdir should be included or not, but didn't get the solution based on my knowledge of Meson.

Please help to advise if it's feasible with Meson to support this scenario, thanks.

[phillipjohnston]

Please check this meson build file for CMocka's patch, which shows how to read variables from a config data object: https://github.com/mesonbuild/cmocka/blob/1.1.5/meson.build#L171 .

Define the module as a dependency [what follows is wrong, see below] ~either supply the proper dependency or a disabler object depending on the config value: https://mesonbuild.com/Disabler.html~

[phillipjohnston]

Well, actually, that would disable your build completely :). Another approach that I've used in my builds is to create an empty list variable. This can be unique for each module, or a list of all modules.

E.g.:

optional_deps = []

If the config value matches what is expected to enable a module, then you add your dependency to that list. Then you reference the optional_deps variable in the appropriate build target(s). Even if it's empty, your build will work.

[sandy-2018]

@phillipjohnston Thanks for your comments & suggestions, I'm really appreciated it! I realized I didin't describe my scenarios/issues clearly, so I made a screenshot with comments to express what I need. Not sure if it's feasible to cover my scenario with Meson.

So basically I'd like to extract some marcos from user's input to identify if some folder or even file(.c) should be included into the build output generated by Meson to be used by Ninja.

Thanks a lot!

[phillipjohnston]

Ah, I do understand what you mean now. For some reason I was thinking configuration_data could take in a file, but that was a misunderstanding on my pat.

The other path I see that allows you to use the existing infrastructure isn't one that I like to propose, hopefully someone involved with the project has a better suggestion.

You could read the header using run_command, and use string parsing to split up the output into an array that you can operate on. It would probably be best to have a shell script that stripped out everything except key value pairs, being the definition name + the value.

If you're looking to meson-ify your build system, it seems like moving these module-based options into meson_options.txt would be the right approach. This can also drive the particular settings for configuration headers. But, not knowing how complex the build setup is given there are multiple input files, maybe that is not desirable for your needs.

[sandy-2018]

@phillipjohnston Thanks a lot for your comments and sharing such info. Seems no other suggestions from other people:-(, I'll try to figure out a solution for my case, thanks again.

[eli-schwartz]

It looks like the objective here is to

there could be quite some modules like module_a to be handled in this case by config file, or just like the config files in Linux kernel or _defconfig in u-boot.

Considering the kernel comparison, you may be interested in https://mesonbuild.com/Keyval-module.html which is literally "take a kernel-like .config file and load it as a meson dictionary".

The workflow would look something like, use kconfig in your project, then, after that, invoke meson -- have meson parse the generated config and use that to implement meson rules for building the targets which have been selected.

Does this do what you wanted?