On Thu, Feb 6, 2014 at 10:57 AM, Gregory Szorc <g...@mozilla.com> wrote:
> On 2/6/14, 9:23 AM, Dave Townsend wrote: > >> I assume the second section is actually "getcwd() not in objdir but is >> in srcdir"? >> > > Yes. > > > I'm crazy enough to want to be able to call mach when getcwd() isn't >> either the objdir or srcdir. I have many of both and use various >> environment flags to say which is active currently. Perhaps it's >> implicit, but I don't see the option to use the directory that mach is >> in to find the srcdir, that would work fine for me and solve the need >> for my current scripts to change directory just to call mach. >> > > mach needs to "bind" to a source directory because it needs to load Python > files from it. The "mach" script at the root of the checkout (which can be > symlinked or even copied to your heart's content) has a mechanism for > discovering the source directory. It then calls a routine in the source > directory which completes the bootstrap process. > > If no source directory can be found, the mach script aborts. This commonly > happens if you run |mach| outside a source directory. > > We /can/ add a facility for discovering source directories when "mach" is > not inside of one. If someone says it is a hard workflow requirement, I > reckon it will be implemented somehow. > I think perhaps I wasn't clear. I'd expect "getcwd() not in objdir nor srcdir" to have as the first option "look for the srcdir based on the location of the called mach script". So I can do "<srcdir>/mach" and have it work, or an alias to mach or something else. > >> On Wed, Feb 5, 2014 at 10:29 PM, Gavin Sharp <ga...@gavinsharp.com >> <mailto:ga...@gavinsharp.com>> wrote: >> >> Whose workflow requires calling mach not in an objdir or srcdir? That >> seems crazy and no one should do it! >> >> Similarly, it seems like all of the ambiguous cases you mention should >> be aborts, because I don't know of any reasonable cases where someone >> would be in that situation, and "picking one" just leads to >> hard-to-predict results. >> >> (Given the audience I'm sure the above must be dismissive of >> _someone_'s Important Workflow - I would love to discover whose it >> is!) >> >> Gavin >> >> On Wed, Feb 5, 2014 at 6:21 PM, Gregory Szorc <g...@mozilla.com >> <mailto:g...@mozilla.com>> wrote: >> > There are a number of people who can't use mach because of the >> way it does >> > environment detection (e.g. how it resolves object directories >> and other >> > paths). >> > >> > There are numerous bugs on the issue. We even have bug 912114 >> tracking >> > everywhere that mach and the build system is doing something wrong >> or >> > inefficient. There are many workflows and thus code paths that need >> > considered. It's a complicated problem to solve. >> > >> > I've typed up a proposal at [1] that I believe will fulfill the >> requirements >> > of most of the people who can't use mach today because it isn't >> compatible >> > with their workflow. Please leave comments on that pad or reply >> here with >> > suggestions for improvement. >> > >> > I hope to have a solution landed in the next few weeks. >> > >> > [1] https://etherpad.mozilla.org/o5igfRCiJv >> > _______________________________________________ >> > firefox-dev mailing list >> > firefox-...@mozilla.org <mailto:firefox-...@mozilla.org> >> >> > https://mail.mozilla.org/listinfo/firefox-dev >> _______________________________________________ >> firefox-dev mailing list >> firefox-...@mozilla.org <mailto:firefox-...@mozilla.org> >> https://mail.mozilla.org/listinfo/firefox-dev >> >> >> > _______________________________________________ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
