I'm +1 to make ./mach build do release builds and add new --debug flags. Also I think Manish's idea of triggering a daily debug build seems like a good idea.
However, what is the current time difference between debug and release builds these days? jack. On Tue, Feb 24, 2015 at 7:21 AM, Manish Goregaokar <manishsm...@gmail.com> wrote: > Perhaps make release the default target for ./mach build, with a servobuild > thing so that devs can make the default debug again? For all other cases, > have `--release` and `--debug` as flags. > > This way people trying it out get the smooth servo experience, but devs can > continue to use fast compiling debug builds. > > I like the token builder idea. Have it build Servo and a subset of the > tests. If we can easily get more buildslaves then perhaps we can make it > more robust. > > A slightly different proposal: set up buildbot builders for debug (or > release), and have builds for those triggered daily instead of per-PR. This > way we don't double our build times or need extra buildslaves. > > -Manish Goregaokar > > On Tue, Feb 24, 2015 at 7:42 PM, Lars Bergstrom <larsb...@mozilla.com> > wrote: > >> Two questions about build flavors. >> >> 1) Should we change the default build type back from debug to release? >> >> When we made the switch to cargo, we changed to debug builds by default, >> which made for some good “reduced build times” headlines, but has gotten me >> mail from externals evaluating Servo asking why it’s so slow/choppy. It has >> also tripped up internal folks doing performance or memory profiling more >> than once. >> >> 2) Should the builders test release only or release and debug? >> >> We had release-only regressions during the last set of Rust and submodule >> upgrades, which is really bad (e.g., right now, Servo release on OSX does >> not display any content!). The only question in my mind here is whether we >> want to test everything in release+debug, just test release, or mainly test >> release but have a token debug build/test machine. >> >> _______________________________________________ >> dev-servo mailing list >> dev-servo@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-servo >> > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
