Auto clobber is now opt in on mozilla-central.
You will need to add |mk_add_options AUTOCLOBBER=1| to your mozconfig to
enable auto clobber. The in-tree mozconfigs (used by automation and
possibly some developers) have auto clobber enabled.
Thank you for the patch, Ed Morley!
On 4/17/2013 4:12 P
On 23 April 2013 19:59:28, Chris Lord wrote:
Having just read up the replies, it seems that it's generally agreed
that this would be better as an opt-in feature. Is anyone tasked to
make it such? Is there a bug I can follow for it?
Bug 863091 (I've attached a patch, which will land soon).
Ed
_
On 18/04/2013 11:02, Ed Morley wrote:
On 17/04/2013 20:51, Ms2ger wrote:
On 04/17/2013 09:36 PM, Gregory Szorc wrote:
It /could/, sure. However, I consider auto clobbering a core build
system feature (sheriffs were very vocal about wanting it). As such, it
needs to be part of client.mk. (Please
On 4/17/2013 6:12 PM, Gregory Szorc wrote:
I agree that we should consider a compromise regarding the UI/UX of
auto clobber. I have filed bug 863091.
I would like to say that I view the object directory as a cache of the
output of the build system. Since it's a cache, cache rules apply and
da
On 17/04/2013 20:51, Ms2ger wrote:
On 04/17/2013 09:36 PM, Gregory Szorc wrote:
It /could/, sure. However, I consider auto clobbering a core build
system feature (sheriffs were very vocal about wanting it). As such, it
needs to be part of client.mk. (Please correct me if I am wrong.)
This shou
> Could the
> anti-auto-clobberers please explain where this analogy falls apart for your
> workflow?
As a simple example, I often will cd objdir and then do
dist/bin/firefox | tee out, to save stdout to a file. I could do "tee
../out", but then my log file is not associated with the objdir, whic
I agree that we should consider a compromise regarding the UI/UX of auto
clobber. I have filed bug 863091.
I would like to say that I view the object directory as a cache of the
output of the build system. Since it's a cache, cache rules apply and
data may disappear at any time. This analogy w
I think the possibility of deleting user data should be taken
seriously. Exactly who is doing the deletion (configure vs. make) is
immaterial. It's also not right to argue that since a majority of
users don't expect to lose data, it's OK to silently delete data for a
minority of them.
I think we
On 13-04-17 12:36 PM, Gregory Szorc wrote:
> It /could/, sure. However, I consider auto clobbering a core build
> system feature (sheriffs were very vocal about wanting it). As such, it
> needs to be part of client.mk. (Please correct me if I am wrong.)
Ok. A makefile deleting things is less surp
On Wed, Apr 17, 2013 at 12:36:05PM -0700, Gregory Szorc wrote:
> On 4/17/13 11:52 AM, Ralph Giles wrote:
> >On 13-04-17 10:20 AM, Gregory Szorc wrote:
> >
> >>I agree the behavior is not expected if you're coming from a traditional
> >>configure + make background. However, I believe automatic clobb
On 04/17/2013 09:36 PM, Gregory Szorc wrote:
On 4/17/13 11:52 AM, Ralph Giles wrote:
On 13-04-17 10:20 AM, Gregory Szorc wrote:
I agree the behavior is not expected if you're coming from a traditional
configure + make background. However, I believe automatic clobbering is
what the plurality of
On 4/17/13 11:52 AM, Ralph Giles wrote:
On 13-04-17 10:20 AM, Gregory Szorc wrote:
I agree the behavior is not expected if you're coming from a traditional
configure + make background. However, I believe automatic clobbering is
what the plurality of people want.
Can the mach tool do the clobb
On 13-04-17 10:20 AM, Gregory Szorc wrote:
> I agree the behavior is not expected if you're coming from a traditional
> configure + make background. However, I believe automatic clobbering is
> what the plurality of people want.
Can the mach tool do the clobbering then? If you're correct in your
On 4/17/13 6:08 AM, Chris Lord wrote:
Just my opinion on this, I don't care enough to argue it more than this;
rm -rf in response to configure, by default, is *not*
expected, or reasonable behaviour. Rather than having an environment
variable to turn this off, it should be the other way round.
Just my opinion on this, I don't care enough to argue it more than this;
rm -rf in response to configure, by default, is *not*
expected, or reasonable behaviour. Rather than having an environment
variable to turn this off, it should be the other way round. I can see
people getting caught out
On 4/1/2013 11:00 AM, Jeff Hammel wrote:
> On 03/29/2013 06:01 PM, Gregory Szorc wrote:
>
>> 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 some
On 03/29/2013 06:01 PM, Gregory Szorc wrote:
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@/
On 03/29/13 22:10, Kyle Huey wrote:
> On Fri, Mar 29, 2013 at 9:47 PM, Philip Chee wrote:
>
>> I'm running Windows7 and the mozilla-build system. We *have* to use
>> relative paths because some parts of mozilla-build (I can't remember
>> which) would choke on absolute paths.
>>
>
> Unless there'
On Fri, Mar 29, 2013 at 9:47 PM, Philip Chee wrote:
> I'm running Windows7 and the mozilla-build system. We *have* to use
> relative paths because some parts of mozilla-build (I can't remember
> which) would choke on absolute paths.
>
Unless there's some problem with comm-central specifically, t
On 30/03/2013 09:01, Gregory Szorc wrote:
> 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
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
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.)
* Th
On 3/29/2013 11:29 AM, Emanuel Hoogeveen wrote:
> How are things looking with regards to using hg purge (bug 851270)?
>
As far as I'm concerned, that's in RelEng's court. I hope they solve it
soon because not using hg purge is adding huge delays (15+ minutes for
some Windows builds) for all clobbe
How are things looking with regards to using hg purge (bug 851270)?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
The CLOBBER file landed a few months ago to help us detect and prevent
known build bustage. Since then, a lot of people (myself included) have
pushed to trees not knowing they needed to force a clobber first,
causing burnage. Others have been frustrated that |hg pull -u && mach
build| followed by a
25 matches
Mail list logo
