Hi Laura, [It seems I just sent a reply to /dev/null. Let's try again.] On Thu, 2016-08-25 at 12:08 -0700, Laura Abbott wrote: > On 08/25/2016 11:35 AM, Paul Bolle wrote: > > No, we don't. We try to finish the build if that's possible. We > > might > > emit warnings, but we try to keep the build going. > > > > We terminate the build for newoptions that aren't specified. I > consider > this in the same category. What is a _new_ option? For the upstream build system there are only valid or invalid options. Remember that upstream changes kconfig symbols as it sees fit (dropping symbols, adding symbols, changing symbols from 'y' to 'm', etc). > > I'm pretty sure these configuration mismatches only happen for > > rather > > obscure corner cases. Serious configuration problems will never hit > > the > > tree in the first place. > > > > I consider a case where we have an option specified as =y or =m in > our > configs and it gets generated as not enabled serious configuration > problems. What do you consider a serious configuration issue? The upstream kconfig tools are extremely liberal. You can feed them an outdated .config file and they'll always emit something. What they'll emit might not be very usefull, but they'll _never_ error out. (If they do error out that's a bug.) > > Imagine trying to rebuild the kernel package, for whatever reason, > > locally and hitting this build error for something entirely > > irrelevant. > > (Like an issue with CONFIG_PWM that is apparently not interesting > > for > > your build machine.) Why on earth should we try to make people > > unhappy > > by breaking their build for them? > > > > It's not the goal to break a build for anyone. I don't plan on > merging > or turning this on until existing issues are fixed up. The kconfig symbols are not stable and never will be stable, so issues will pop up again and again. > Ultimately > people who are making their own builds though have always been, well > on their own. I can request people test with their custom > configurations > to see if there is anything we are missing. There will be an option > similar to listnewconfig to skip the error out as well. Do you have > other suggestions about minimizing the impact? No. I'll just repeat that configuration issues should be non-fatal. (Please note that I still don't know what this patch exactly makes fatal.) Thanks, Paul Bolle _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/kernel@xxxxxxxxxxxxxxxxxxxxxxx
