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

Reply via email to