On Wed, Jan 15, 2020 at 3:01 AM Gregory Nutt <spudan...@gmail.com> wrote: > > > > Haitao is preparing the jenkins job to run all possible config, but > > the config number is huge, we need to donate several powerful severs > > to ensure the precheck can finish in half hour. > > I am repeating myself, but it is worth remembering. > > There might not be any configuration in the repository that builds the > code that is changed by a PR! The code could be totally broken and > could fail the first time you compile it, but if there is no > configuration in the repository that has the configuration settings > needed to build all options for the changed code, you will never know it. > > It is for this reason that have been arguing that we need a smarter test > than just building a set of configurations. The smaller the set the > more likely that they will not build the affected code at all! Then > the build test is completely useless. >
Yes, it's great that we develop a tool to generate all possible combination of affected options smartly. > I very typical example is when someone develops a new driver for some > "FooBar" hardware. It is enabled by CONFIG_DRIVER_FOOBAR. But there is > no defconfig file under boards that includes CONFIG_DRIVER_FOOBAR=y. As > a result, any kind of canned build test is a waste of time and will not > prove or disprove the syntactic correctness of the file -- since it > never builds it. > Like Nanthan suggestion, we can create a special config to enable all non-execlusive options, actually kconfig support --allyesconfig to simplify this task. > I have suggested that we ask the contributor to provide a list of every > configuration option that needs to be set/unset to verify all > combinations of the changed code. Then we use those configuration > options to select all relevant configurations. > > Perhaps we could grep the modified files to get those options? > > In the case that there is no configuration in the repository that select > those configuration options, we would need to ask the contributor to > provide a test configuration. > > Anything that is random, hit or miss would be, most likely, a waste of time. > > Greg > > > >
