On Fri, Aug 16, 2013 at 2:43 AM, Andreas Gal <andreas....@gmail.com> wrote:
> I would like to propose the opposite approach: > > - Remove all conditional feature configuration from configure. WebRTC et > al are always on. Features should be disabled dynamically (prefs), if at > all. > - Reduce configure settings to choice of OS and release or developer. > - Require triple super-reviews (hand signed, in blood) for any changes to > configure. > - Make parts of the code base more modular and avoid super include files > cross modules (hello LayoutUtils.h). > I would much rather we try (a milder version of) what Andreas suggests before we start disabling shipping features by default in developer builds. If we had closer to 100% test coverage then turning things off by default might maybe make sense. But, as it is, it is important that any manual testing we do is testing something as close as possible to what we ship. I do think we could benefit from a much simpler build system with fewer options that result in us modifying configure.in and other rebuild-the-world dependencies much less often. I don't think we should completely eliminate conditionals in our build system. Like jlebar, I have found there are cases where we can eliminate a lot of dead code on a per-platform basis. However, we should be able to do said dead-code-removal conditional compilation without modifying configure.in. Maybe that is as simple as allowing support for a mozconfig-like addendum mechanism for configure.in that lets somebody enable off-by-default features in their local build without first needing to modify configure.in in a way that would affect everybody else's builds. If I think back to some of my recent changes to configure.in, they were often changes that only affected one or two modules, and that logic could have been done in a whatever.mk file or moz.build file that was included by the affected modules instead of modifying configure.in. The only reason I modified configure.in is because that's how we've always done it. For my next such change, I will try to localize the conditional logic to my module to avoid touching configure.in and whatever/confvars.sh. Perhaps others can try the same experiment. Cheers, Brian _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
