just a meta note -- there are 181 bugs open in the mach component, of which only 3 are mentored and none marked "good first bug" (which the resolution to this discussion sounds like)
changing any of that should improve the scratchability of the itch On Thu, Apr 7, 2016 at 8:39 PM, Gregory Szorc <g...@mozilla.com> wrote: > On Thu, Apr 7, 2016 at 11:26 PM, Mike Hommey <m...@glandium.org> wrote: > >> Random related thoughts: >> >> Most people who run mach bootstrap already have a clone of >> mozilla-central. Which means they could run any other mach command as >> well. With thing moving off autoconf into our shiny new stuff that can >> do whatever we decide to put into it, we could have a `mach configure >> --bootstrap` that, instead of, e.g. failing when the Android NDK can't >> be found, downloads it. >> >> Also, now that it's possible to pass configure options to `mach >> configure`, >> we could, e.g. save a .mozconfig corresponding to the options passed to >> mach configure if there is .mozconfig already. >> > > These are great ideas/observations! I think it would rad for configure to > auto-download missing dependencies (if requested). After all, requiring a > manual step to invoke tooling is overhead and wasted time. > > Quick history lesson: the original intent of the bootstrapper was the "one > line bootstrap" to go from fresh OS (read: no clone) to something capable > of building Firefox (basically automate the commands people were copying > from a wiki/docs). `mach bootstrap` was added (at the same time IIRC) > because dependencies can change over time and we wanted to make it easy for > people to ensure their system dependencies were up to date at any given > time (configure checks could advise people to run `mach bootstrap` to > recover). The bootstrapping code didn't gain Fennec support until later > when IIRC nalexander implemented it. The bootstrapping code has effectively > been slowly iterated on since and hasn't really received any major new > features other than support for Fennec and various distros. I've been kinda > hoping someone would scratch an itch and add the missing transition from > system dependencies to build/source config. > > >> >> On Thu, Apr 07, 2016 at 11:07:37PM -0400, Gregory Szorc wrote: >> > The current reason we separate is to install the minimum set of required >> > dependencies for developing any particular product. >> > >> > We've always wanted bootstrap to more seamlessly transition into "and >> > configure VCS, clone the repository, configure the build, and perform >> the >> > build" but we haven't executed on that due to lack of interest/priority. >> > >> > Fennec's bootstrap does print a list of mozconfig lines that are needed >> to >> > perform a Fennec build. That's just to help users transition from >> bootstrap >> > to build (although that transition can be a bit rocky for first-time >> > developers since they don't even have a clone yet). We also don't want >> to >> > require a mozconfig file for first-timers because requiring a mozconfig >> > increases the barrier to contribution. No mozconfig defaults to building >> > Firefox for desktop. This is a simple reflection of history (Firefox >> came >> > first) and popularity. >> > >> > If you want to change the wording on the menu prompt, patches welcome. >> > >> > I'd prefer we not make the bootstrap code too complicated to support >> > multiple products simultaneously. I think people start off thinking >> they'll >> > contribute to a specific product and it makes sense to guide people >> towards >> > a well-defined outcome by making a decision early in bootstrap (as is >> > currently implemented). I would rather see us focus energy on completing >> > the transition from bootstrap to build. If we do this, someone could run >> > `mach bootstrap` any time to switch products and install new >> dependencies >> > and a mozconfig (if necessary). I think this would be more valuable >> than an >> > omnibus bootstrap. >> > >> > On Wed, Mar 30, 2016 at 2:50 PM, Brad Lassey <blas...@mozilla.com> >> wrote: >> > >> > > bah.. fat fingers. >> > > >> > > Nick and Benjamin just gave two different reasons for this menu. If >> it is >> > > just to download the tools needed to build, let's give that context. >> > > Including an option for both would be good as well. If the intention >> is to >> > > set a mozconfing, I'm note sure that belongs here, maybe do that when >> there >> > > isn't a MOZCONFIG set and someone tries to build. >> > > >> > > >> > > >> > > On Wed, Mar 30, 2016 at 2:46 PM, Brad Lassey <blas...@mozilla.com> >> wrote: >> > > >> > >> Nick and Benjamin just gave two different reasons >> > >> >> > >> -Brad >> > >> >> > >> On Wed, Mar 30, 2016 at 2:16 PM, Benjamin Smedberg < >> benja...@smedbergs.us >> > >> > wrote: >> > >> >> > >>> >> > >>> >> > >>> On 3/30/2016 1:06 PM, Brad Lassey wrote: >> > >>> >> > >>>> I'm setting up a new linux machine and just ran mach for the first >> > >>>> time. The first thing I'm presented with is: >> > >>>> >> > >>>> Please choose the version of Firefox you want to build >> > >>>> 1. Firefox for Desktop >> > >>>> 2. Firefox for Android Artifact Mode >> > >>>> 3. Firefox for Android >> > >>>> >> > >>>> We have a general problem with developers not building for Android >> and >> > >>>> I think this isn't helping. It sets the mindset that your tree is >> either >> > >>>> configured to build for Android or Desktop, when in fact you can >> build for >> > >>>> either in the same tree. >> > >>>> >> > >>>> What are we trying to accomplish here? >> > >>>> >> > >>> >> > >>> I believe that the goal is to get you started without huge wait >> times >> > >>> for dependencies. Building for Android requires Java compilers and >> Android >> > >>> SDKs and things. Building for desktop requires its own set of dev >> libraries >> > >>> and such. >> > >>> >> > >>> Would it resolve your concern to have a "both" option, and/or >> > >>> explanation that you can set them both up in the same source tree? >> > >>> >> > >>> --BDS >> > >>> >> > >>> >> > >> >> > > >> > > _______________________________________________ >> > > dev-builds mailing list >> > > dev-builds@lists.mozilla.org >> > > https://lists.mozilla.org/listinfo/dev-builds >> > > >> > > >> >> > _______________________________________________ >> > dev-builds mailing list >> > dev-builds@lists.mozilla.org >> > https://lists.mozilla.org/listinfo/dev-builds >> >> > > _______________________________________________ > dev-builds mailing list > dev-builds@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-builds > >
_______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
