> I like where you are coming from. Yay!
> However, if we know what build bustage is known, it should be codified > in the tree and the build should abort or you should see a giant > warning. If we put this information anywhere else, I fear it will become > out of date very quickly or filled with content that isn't true. It would be super cool for builds to early-abort if the configuration is known to fail! I imagine that the burden for implementing this would land on build peers (I certainly don't know enough about the build system to codify something like "vs2012 fails to build if ICU is enabled"). Editing a wiki (or a doc, as you mention below) is comparatively easy and could be accomplished by those of use who aren't fluent in the build system :) > A reason why I've been banging on the "reproducible build environments" > drum is that if we provide reproducible build environments, that's a > very quick and easy way to answer "is my build environment or my build > config the thing that's busted?" > > Unfortunately, fixing issues like these are often perceived as lower > importance than making the build faster. I would absolutely love to > spend a few months on nothing but "build UX" to help people deal with > problems like these. I totally support your efforts in either/both of the above - "build UX" and "making the build faster." I'm happy regardless of which one you're working on. > Possible compromise: have this info live in the tree as part of the > in-tree docs under build/docs. You need build peer review to update > those docs and they are versioned with the tree. That addresses my > accuracy and versioning concerns. This sounds reasonable to me! The docs would always be up to date with the code being built, anyone experiencing an issue can look it up in a known location, anyone with knowledge about a particular issue can update the doc, and build peers don't have to spend their time keeping config rules constantly up to date! Assuming people are on board with this plan, how would we go about starting that doc? _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
