On 30/01/19 11:02, Thomas Huth wrote: >> I think the two approaches are more or less equivalent, but >> "#CONFIG_FOO=n" has a small advantage when the feature has a build-time >> dependency, such as CONFIG_MILKYMIST_TMU2's dependency on OpenGL. In >> that case, >> >> CONFIG_MILKYMIST_TMU2=y >> >> would report a contradiction if OpenGL is not available at build time, while >> >> default y >> ... >> #CONFIG_MILKYMIST_TMU2=n >> >> would not. > I somehow dislike the idea of adding lines that are commented out by > default. For example, if someone later renames or removes the config > switch in the Kconfig files, the comment could stay there without being > noticed, while a CONFIG_XXX=y would cause a clean build failure if the > option is not available anymore.
I agree. On the other hand I don't see another solution for the MILKYMIST_TMU2 and QXL cases, and consistency is a plus too. How often are config switches renamed or removed, especially user-visible optional devices though? I see CONFIG_MEM_DEVICE, CONFIG_PCI_APB, CONFIG_LIBDECNUMBER, CONFIG_XEN_I386, CONFIG_MIPS_BOSTON, CONFIG_PIIX_PCI, CONFIG_ISA_MMIO, CONFIG_ICC_BUS over the last few years but none probably would have been optional devices in default-configs/ but rather in Kconfig files. (Long term default-configs/ should probably be built automatically, possibly by adding a description field to the Kconfig files, and that would also ameliorate the issue you describe). Paolo
