On 01/15/2015 11:21 AM, Ehsan Akhgari wrote: > On 2015-01-14 8:37 PM, Steve Fink wrote: >> On 01/14/2015 11:26 AM, Ehsan Akhgari wrote: >>> From now on, the only supported build mode is unified compilation. I >>> am planning to follow-up with removing support for the >>> --disable-unified-compilation configure option altogether in bug >>> 1121000. >> >> I commented in the bug, but I guess this is probably a better forum. >> >> Why is the configure option being removed? > > Because unsupported build configurations that are *guaranteed* to not > be maintained are not worth keeping around. I am 90% sure that > --disable-unified-compilation would have been broken since yesterday. > :-)
But that's not the point. I totally agree that non-unified builds will get broken immediately and will stay broken most of the time. That's not in question. The point is how hard it is for someone who comes along and wants to fix our codebase to be valid C++, even if that fix is not permanent. Specifically, what I imagine happening is this: we start out nowish with nonunified builds working. Within a day, they're busted. After some time, somebody who gains from them being correct wants to fix them, and uses --disable-unified-builds to do so. Rinse, repeat. The amount of breakage to fix each time is determined by the time between fixes. If this hypothetical person has to go through every moz.build and change UNIFIED_SOURCES to SOURCES, or FILES_PER_UNIFIED_FILE to 1, then they're less likely to do it, and the interval between fixes will grow, and eventually the code base will be rotten enough that nobody will want to deal with it. Oh, except that people will occasionally add new files and uncover breakage that wasn't their fault because they shift around the boundaries. Which isn't awful, because you'll only have to fix a localized area, but it is guaranteed to baffle many of the people who hit it until they've been educated. More overhead to contributing, more "specialness" in our codebase. If you were saying that the --disable-unified-builds mechanism itself is likely to break, then I couldn't really argue with removing it. Is there a simpler way to accomplish the same thing? A FORCE_MAX_FILES_PER_UNIFIED_FILE_EVERYWHERE=1 setting in the toplevel moz.build or something? It doesn't need to be pretty, but it should be easier than for f in **/moz.build; do echo "FILES_PER_UNIFIED_FILE=1" >> $f; done (assuming that even works, and note that you'll need zsh for the '**' thing). > > > I understand always building >> unified in automation, but not having a straightforward way at all to >> see if your code is buggy seems... suboptimal. If someone wants to go >> through occasionally and make our codebase valid C++, how should they do >> it after this change? > > Switch the UNIFIED_SOURCES variable to SOURCES in the moz.build file. > That still works. > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
