Checking whether a certain CONFIG_* is set
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 2 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 2 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [Buildroot] [PATCH v1 0/2] Checking whether a certain CONFIG_* is set
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Yann" == Yann E MORIN <[email protected]> writes:
Hi,
Quoted 10 lines
Quoted 7 lines
Quoted 2 lines
I think the plan I'll be goign with is to add a hidden
Kconfigknob that packages that want to build a kernel module will have to select.Why not just like the kernel-module infrastructure handle it like I proposed? I don't think it is very nice that people have to remember to add the select as well (and chances are they won't notice if they forget).
Because that would not work for packages in br2-external trees, as I already explained.
Are you sure? I didn't try it, but as we only *USE* the variable when LINUX_KCONFIG_FIXUP_CMDS runs, which is after all the .mk files have been parsed I think it should work?
Quoted 4 lines
I know you are not using br2-external (and also do not really see the point of it), but a lot of people find this to be a really important feature. I also suspect some of our (corporate) users did choose Buildroot (partly) because of br2-external.
It's true that I don't personally use br2-external and don't find it such a killer feature, I *DO* acknowledge that some people do (which is why I merged the support for it in the first place) and will try to keep it working as good as possible. With that said, we have a lot of other requirements for Buildroot (like keeping it simple), so will not bend over backwards to improve br2-external support if it means making big compromises elsewhere.
br2-external stuff will always been more limited than normal packages in the tree.
Quoted 10 lines
Quoted 3 lines
Like Thomas says, we are already doing the 2nd option and I think it makes sense to keep on doing so - So I don't think there's a common need for the first.
Still, we are currently not allowing another package to set kernel options _from_ that package's .mk file. All we have is the kernel (de)activating options based on the presence of other packages, and that excludes packages from br2-external. Unless Buildroot is modified accordingly (but then br2-external looses its attractiveness for that package).
Ok, but if all of these use the kernel-module infrastructure (which linux.mk knows about), then this should work for CONFIG_MODULES, right? It naturally cannot work for random other config settings.
Signature · 2 lines
Venlig hilsen, Peter Korsgaard