-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kconfig Module #5031
Kconfig Module #5031
Conversation
9a227eb
to
e6fd635
Compare
To continue my question from the other thread, the reason I'd suggest a |
Yes, this version uses a dictionary (see also the first patch to enable dictionaries in |
There are also questions on how to integrate this with regeneration logic and all that. It would be optimal if we could make this work just by invoking Meson and not having to run kconfig first. That being the case let's call this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One small thing, otherwise this looks good to me as long as @jpakkane is happy with it.
looks good to me, I think this just needs a rebase and @jpakkane's sign off. |
|
||
k = import('unstable-kconfig') | ||
|
||
conf = k.load(files('config')) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have not used kconfig all that much, but shouldn't we load the output file? Specifically something that will get generated in the build dir rather than reading stuff from the source dir? Loading stuff from source dir means that you can have only one configuration per source dir, not one per build dir as is the Meson standard.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have not used kconfig all that much, but shouldn't we load the output file? Specifically something that will get generated in the build dir rather than reading stuff from the source dir? Loading stuff from source dir means that you can have only one configuration per source dir, not one per build dir as is the Meson standard.
Indeed, since Meson only supports out-of-tree build, it is somewhat unfortunate that the default for kconfig
output is .config
in the toplevel source directory. However, the output file can be overridden using an environment variable, usually specified like
$ make menuconfig KCONFIG_CONFIG=foo.config
I expect that users of this module will make the location of the configuration file a Meson option too, so that the same file can be specified both as KCONFIG_CONFIG
and when invoking Meson. I will add a note to the documentation.
Of course, having to specify the directory twice is ugly; unfortunately on one hand the build directory is not known when you invoke the kconfig frontend, and on the other hand the kconfig frontend must be invoked before Meson. One possible fix is to provide some kind of script that wraps meson setup
and invokes kconfig before Meson (removing the need to ship a Makefile
), not unlike those Meson users that are providing a simple-minded configure
script. That script can then pass a file in the build directory and pass it to both kconfig and Meson.
That said, the placement of the configuration also depends on the usecase. For example, QEMU only uses kconfig as a common format to store pre-defined configuration_data
for each binary; it does not employ any front-end, instead all processing of the configuration happens in meson.build
. In that case, the configuration files are fixed and committed, and they definitely come from the source directory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the module is unstable, we can change it later. We can merge this and change the behaviour as people test it on real world code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe something like:
k.generate_and_load(init_command: ['kconfig', 'source_file', 'output_file'])
That runs the given command if the output .config
file does not exist in the build dir and otherwise just loads it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems sensible but I would first try and see how people use this. The config frontends usually have their own make-based build system, and invoking make from Meson would be a bit weird...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe something like:
k.generate_and_load(init_command: ['kconfig', 'source_file', 'output_file'])
If you were referring to: genkconfig .config -> config.h
, then yes, I wrote a custom_target
that does just that.
If you were referring to generating the default .config
automatically with olddefconfig
then no, it's very easy but apparently considered bad practice in the (interactive) Kconfig world to automagically build the default configuration. This must be an explicit choice from the user as seen in the Linux kernel example.
This in turn allows modules to return dictionaries, since their return values is automatically passed through holderify.
Add a kconfig module to allow meson to integrate with existing projects that use kconfig.
Document best practices for per-builddir config file, and add a test covering loading a config file from the build directory. Signed-off-by: Paolo Bonzini <[email protected]>
Sharing some feedback here for the lack of knowing a better place. First, thank you @bonzini for implementing this, extremely useful! I'm also glad I found these github issues, they add a lot of useful background information to the very... concise https://mesonbuild.com/Kconfig-module.html :-)
First, "invokes kconfig" or "runs kconfig" is too vague and has lost me several times.
I'm curious if/how other projects run genconfig.py and solve this.
As a matter of fact I've run into the biggest issue with this module: the kconfig dictionary produces quoted strings, as they are in the kconfig["CONFIG_QEMU_PARAM1"] == '"some value"' You can tell Kconfig came from a C world where concatenating strings is as simple as putting them next to one another, however this seems very uncommon outside C. In this case I am (funny enough) configuring a QEMU .cfg file and there you can clearly not do that. BTW C code is most likely using config.h directly and not depending on this module. As this module is marked as "unstable", would it be acceptable to "unquote" the strings produced by it? This is my current workaround, any better suggestion welcome: double_quote = '"' # Makefile memories...
unquoted_qemu_param1 = kconfig['CONFIG_QEMU_PARAM1'].split(double_quote)[1]
kconfig += {'CONFIG_QEMU_PARAM1' : unquoted_qemu_param1 }
BTW genconfig.py can read .config in the source directory and (re-)generate the sanitized version back into a different (build) directory. For (much!) more background see the
Some other root causes and examples of meson wrappers at #6434 (comment)
Not sure I fully understand your point here but FYI https://github.com/ulfalizer/Kconfiglib is pure Python |
Yes, definitely. For example a random Linux
I would be happy to review a patch for that. |
QEMU does not support interactive Kconfig at all. It's only used to automatically compute dependencies.
I think that would be a bug in |
The main question here is this: is There is confusion because the answer is: it depends. I wouldn't call a "bug" the fact that Back to meson.build, maybe the easiest to support both cases is something like: if found source_root/.config
configure_file( copy source_root/.config to build_root/.config )
endif Thoughts? PS: for even more confusion,
[*] I started versioning Linux kernel configs after a few too many EDITED:
meson is a bit of a "wrapper" on top of ninja, meaning users need to invoke and get familiar with two different tools. I'm already using yet another wrapper on top of meson because of #3001 / #4637 but I'd really like meson not to require a 3rd layer eventually. |
It is a build input, but it's a build input that can differ for different build roots, hence the original suggestion of placing it (by default) in the build root and configurable with a build option.
(only if the build option is not set?) That can work too. At this point it's a matter of figuring out the best practices and documenting them. Fortunately none of this is affecting the code of the module itself. |
With the little knowledge I have on the matter, to me it sounds like .config is an input as far as Meson is concerned. It could be an output of wrapper tools around Meson, but then it's not Meson's issue. For example, a build script could do:
Just forget me if I completely missed the point :D |
Congratulations: everything you wrote makes sense :-) This closed PR is really not a great place, so I just filed new #6694. Appreciated if people can find the time to make it there. |
Add kconfig integration such that existing projects can use the ".config" file from a kconfig system to conditionally compile in or out features.
The code is an updated version of the original submission in pull request #1617. Compared to the original, it uses the dictionary objects that have since been introduced in meson, and it lets you pass the input as a file object. This makes for a more flexible and easier to use API.