On 3/29/2013 5:32 PM, Neil wrote: > Gregory Szorc wrote: > >> * Your mozconfig contains |mk_add_options NO_AUTOCLOBBER=1| or your >> environment contains NO_AUTOCLOBBER. >> > Exactly what happens in this case, does it still fail in configure? > (The old failure mode was not detectable by client.mk so you had to > manually reconfigure.)
We moved the detection from configure to client.mk. If you run configure by hand, configure will not detect clobber is needed and the build will fail when make is finally invoked. This seems less than ideal. However, you should not run configure by hand because invoking configure is more than just running the configure script. If you must run configure, run it through |make -f client.mk configure| (There should probably be a mach command to do this as well.). > >> * The current working directory is under the topobjdir (e.g. >> objdir/browser). cwd == topobjdir will still clobber. >> > I have one tree with MOZ_OBJDIR=.. - what happens there? If MOZ_OBJDIR is literally ".." then depending on how client.mk is invoked, that '..' will be appended to the current working directory somehow. I think the exact semantics are partially undefined. I highly recommend against defining MOZ_OBJDIR in terms of relative paths. You're implicitly creating a dependency on cwd. This is handy in a few use cases but it's a giant foot gun. Instead, do something like |mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-firefox|. > >> * You invoke make or pymake directly from the objdir (you don't use >> mach or client.mk to build). >> >> > What happens to comm-central users? > I don't know! _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform