This one doesn't have simple answers, just tossing it out there for discussion purposes.
It's pretty clear there are a lot of options that affect building, and the combinatorial possibilities are kind of scary. Maybe I'm overthinking it? The motivation for putting together the wiki page on the jenkins builds was to be able to tell if a combination I'm interested in is built for by Jenkins. We have certainly seen cases where code which breaks builds snuck through despite Jenkins verification, not clear if that is due to (a) someone manually marking verified, or ignoring jenkins result, (b) jenkins not always correctly reporting an error or (c) "the case was missed" by jenkins. I suspect we've had some of all three. It would be great to have less conditionally compiled code. For development use, at least, might be it possible to build the maximal image that is possible for that host/target combination. and then have a runtime way to configure in/out optional stuff, instead of doing compile-time configuration? I know for production use, especially if the intent is to certify, that it's important to lock down an exact configuration which matches what is tested, so that's a different case; but at least if developers always had "all the code is built" we'd be more likely to have things built and exercised, and to catch unseen interactions like "I never saw that, because I didn't build with those flags while I was developing my feature". Some flags aren't amenable to this - I wouldn't want to figure out how to turn security on/off at runtime (one that should be 100% impossible to do in a production build, of course) but I suspect at least some are...
