On Thu, Oct 15, 2015 at 6:37 PM, Nicholas Nethercote <n.netherc...@gmail.com > wrote:
> On Fri, Oct 16, 2015 at 11:37 AM, Bobby Holley <bobbyhol...@gmail.com> > wrote: > > > > |mach build binaries| is much slower for me than the present behavior, > > because I often hack on header files that are included all over the tree, > > but whose #include-ers generally don't need to be rebuilt all of the > time. > > I used to have a bunch of my own aliases for building particular > directories (and toolkit/library if necessary) and then relinking. > (Sounds like maybe I partially reimplemented dumbmake myself? Not > sure.) I stopped using them once |mach build binaries| came along > because it was better for my use cases. > > I suspect the very small number of people who are in your position can > do something similar? > This is pretty much how everyone did everything 3+ years ago: waiting 45-90s for a `make -f client.mk` to traverse all the tiers and directories when a single C++/JS file changed was just wasteful. So lots of people cobbled together shell aliases and scripts for patterns like `make -j8 services && make -j8 toolkit/components && make -j8 browser` or `make -j8 -C dom/base && make -j8 -C toolkit/library`. It was a good hack to gain build/development speed while sacrificing a little build purity. dumbmake was a formal establishment of these practices so that people didn't have to know as many inner workings of the build system and code up these aliases. The "binaries" target came along after dumbmake and made the C++ build procedure infinitely better. Now we have "fastermake," which is the rough equivalent but for frontend and JavaScript developers. But as awesome as these targets are, they can still build more than is desired (especially in the edit .h file case). This slows down iteration cycles and slows down developers. For this reason, I think dumbmake needs to remain or be replaced by something that allows Gecko developers to easily perform a partial (and probably incorrect end state) build. I /think/ this could be as simple as a "xul" target that linked libxul. This way, people could type `mach build dom/base xul` and build all binaries (including static libraries) under a source directory and link libxul. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
