> 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 4/17/13 2:37 PM, Robert O'Callahan wrote:
On Thu, Apr 18, 2013 at 3:40 AM, Ms2ger wrote:
On 04/17/2013 07:15 AM, Robert O'Callahan wrote:
I have a request ... can we require lists in moz.build files to be in
alphabetical order, and actually enforce with some build-system check? I'm
always
On 4/13/2013 1:28 AM, Mike Hommey wrote:
The first thing to notice in here is the 13 spikes down. The last one is
bug 860371. I wasn't aware of any of the 12 others. It might be worth
looking into them to understand why they happen. Interestingly, my
dev-tree-management archive doesn't show any n
On Thu, Apr 18, 2013 at 3:40 AM, Ms2ger wrote:
> On 04/17/2013 07:15 AM, Robert O'Callahan wrote:
>
>> I have a request ... can we require lists in moz.build files to be in
>> alphabetical order, and actually enforce with some build-system check? I'm
>> always annoyed by Makefiles where lists are
On Wed, Apr 17, 2013 at 5:09 PM, Simon Kornblith wrote:
> I want to be able to parse XML and expose the resulting document to a
> sandboxed script. I do this by first by determining the principal
> corresponding to a given URI:
>
> var secMan = Services.scriptSecurityManager;
> var uri = Services.
I want to be able to parse XML and expose the resulting document to a sandboxed
script. I do this by first by determining the principal corresponding to a
given URI:
var secMan = Services.scriptSecurityManager;
var uri = Services.io.newURI("http://www.example.com/";, "UTF-8", null);
var principa
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 Wed, Apr 17, 2013 at 07:36:40PM +0200, Robert Kaiser wrote:
> Gregory Szorc schrieb:
> >Theoretically, yes. And I do empathize with the desire to have them
> >alphabetical.
>
> As Ms2ger notes, we probably cannot have that for *DIRS, though. I
> know at least one case where this is crucial, and
On 13-04-17 8:40 AM, Ms2ger wrote:
> Fully agree, with the exception that I'm not sure this is a safe
> transformation for *DIRS.
It certainly isn't for add_tier_dir.
-r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozil
On 4/17/2013 10:50 AM, Gavin Sharp wrote:
I think Rob was talking about the case where you would call e.g.:
"mach build browser/base"
mach could know that on Mac, that also requires the equivalent of
"mach build browser/app" for those changes to actually be repackaged
into the bundle in objdir/
I think Rob was talking about the case where you would call e.g.:
"mach build browser/base"
mach could know that on Mac, that also requires the equivalent of
"mach build browser/app" for those changes to actually be repackaged
into the bundle in objdir/dist/, because the build system doesn't. Of
Gregory Szorc schrieb:
Theoretically, yes. And I do empathize with the desire to have them
alphabetical.
As Ms2ger notes, we probably cannot have that for *DIRS, though. I know
at least one case where this is crucial, and that's Mac packaging. I
added a comment for that a long time ago in Sea
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.
On 4/15/2013 11:04 AM, Rob Campbell wrote:
On Mac, does mach do the right thing when you rebuild browser, does it also
rebuild browser/app so your application bundle gets updated?
"mach build browser" is the same as "make -C $objdir/browser"
(literally, it just executes that "make" command to d
On Wednesday, April 17, 2013 3:57:58 PM UTC+2, Bobby Holley wrote:
> When you want the sandbox to die, you can do
> |Components.utils.nukeSandbox(sandbox)|, and it'll go away. Simple as that.
>
> :-)
Awesome, exactly what I was looking for! I'm not sure how I missed that (would
be good to refere
On 04/17/2013 07:15 AM, Robert O'Callahan wrote:
I have a request ... can we require lists in moz.build files to be in
alphabetical order, and actually enforce with some build-system check? I'm
always annoyed by Makefiles where lists are sometimes unordered and it's
hard to find items and know wh
On 2013-04-17, at 11:42 , Matt Brubeck wrote:
> On 4/15/2013 11:04 AM, Rob Campbell wrote:
>> On Mac, does mach do the right thing when you rebuild browser, does it also
>> rebuild browser/app so your application bundle gets updated?
> "mach build browser" is the same as "make -C $objdir/browse
On Wed, Apr 17, 2013 at 5:21 AM, Matthew Gertner wrote:
> I'm using Cu.evalInSandbox in a bootstrapped extension to run code in an
> isolated environment using a content window as the sandbox prototype. When
> the code adds expando properties to the window (e.g. jQuery), the sandbox
> predictably
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 16/04/13 12:27, Mike Hommey wrote:
> I doubt we can get a satisfactory response from MS before things blow
> out (if at all)
But if we'd asked them last time, we might have one by now. And if we
don't ask them this time, then we'll get to next time and still not have
one. :-)
Gerv
__
I'm using Cu.evalInSandbox in a bootstrapped extension to run code in an
isolated environment using a content window as the sandbox prototype. When the
code adds expando properties to the window (e.g. jQuery), the sandbox
predictably leaks when the extension is disabled.
I assume that the sandb
27 matches
Mail list logo
