On Mon, Apr 24, 2017 at 08:49:32PM +0200, Jean Delvare wrote: > On Mon, 24 Apr 2017 13:56:06 +0200, Krzysztof Kozlowski wrote: > > On Mon, Apr 24, 2017 at 1:34 PM, Jean Delvare <jdelvare@xxxxxxx> wrote: > > > On Mon, 24 Apr 2017 11:58:09 +0200, Krzysztof Kozlowski wrote: > > >> On Mon, Apr 24, 2017 at 11:48 AM, Jean Delvare <jdelvare@xxxxxxx> wrote: > > >> > On Mon, 24 Apr 2017 10:00:32 +0200, Krzysztof Kozlowski wrote: > > > You are a bit late to the party I am afraid. COMPILE_TEST was > > > introduced for this very usage 4 years ago and I count 760 occurrences > > > of it. Not as many as I would like but I think this is going in the > > > right direction. > > > > That is not the purpose of COMPILE_TEST. It serves only to allow > > compile testing of everything, not selecting "soft dependencies". > > Think again and you'll realize this is exactly the same. No, the purpose of COMPILE_TEST is to build everything whenever it is possible. Regardless if it is reasonable or not. For example without OF some drivers will not be able to bind but we can build them for build coverage (and static checkers coverage). That is the goal. However you want to limit the driver because of specific board existing in mainline (have you considered out of tree boards?). That is totally different meaning and use case. > > It > > allows you to build kernel which will not even work in certain cases. > > This is an extreme theoretical case, which has nothing to do with the > problem at hand. That is the effect of COMPILE_TEST for which it was designed... but you want to use it in different way. > > > Also it does not bring any information about wanted or unwanted links > > - like "imply". > > I have no idea what you mean here, sorry. The depends/select/imply bring an information to the user about relationship between the Kconfig symbols. COMPILE_TEST does not bring such relationship. > > > > To be honest, I have also considered the possibility of a dedicated > > > keyword to express these "intended hardware target" soft dependencies. > > > Maybe it would make things clearer. But I never had the time to look > > > into it. Feel free to propose something if you are interested. > > > > Workaround might be using default = N, unless ARCH_EXYNOS. Something like: > > default y if ARCH_EXYNOS > > Maybe this is a good idea, maybe not, I don't know as I am not familiar > with this platform nor the ARM world in general. What I am sure of is > that this has nothing to do with the problem I was originally > discussing. I want to change the visibility on non-Exynos build, you > propose to change the default on Exynos builds. That's not helping (not > me, at least.) First of all, I am not changing the defaults. Second, you asked for a hint of a better solution and now you are complaining that you do not like it... okay, as you wish. The other way is to introduce a new soft dependency called whatever you like to (e.g. "usable on"). But depends and COMPILE_TEST are not for that purpose. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
