Re: Must we rebuild all our rust code constantly?

[Simon Sapin]

On 23/08/2019 04:00, Mike Hommey wrote:

I had a similar experience on a 36-core machine earlier today. It seems
incremental is not working properly for the style crate: incremental is
supposed to have the same effect as sccache, but it still takes a long
time to compile style. I'm told mw is going to look into this in the
coming weeks.


I don’t know how much it has evolved since, but the initial versions of 
incremental compilation in rustc only cached code generation in LLVM. 
Type checking, trait resolution, etc. was still done every time rustc 
was invoked for a crate.


--
Simon Sapin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Document::ResolveWithBaseURI is just introduced to ease URL resolving

[saschanaz7]

Relevant bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1572349
Previous discussion: 
https://groups.google.com/forum/#!msg/mozilla.dev.platform/y_eEf14fLu4/ECG_Mq7hAQAJ

Based on the previous discussion, I added a helper method to ease URL resolving 
without forgetting about `document.baseURI`. This should help simplifying 
existing codes as well, so please try it whenever possible.

Thanks to Marcos Caceres for mentoring!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Must we rebuild all our rust code constantly?

[ishikawa]

On 2019/08/23 11:00, Mike Hommey wrote:
> 
> In the meanwhile, as discussed on irc, it seems fair to disable
> CARGO_INCREMENTAL when building with sccache.

So how can we disable this?
Setting environment variable as in the following?

export CARGO_INCREMENTAL=

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Must we rebuild all our rust code constantly?

[Nicholas Alexander]

On Fri, Aug 23, 2019 at 2:11 AM ishikawa  wrote:

> On 2019/08/23 11:00, Mike Hommey wrote:
> >
> > In the meanwhile, as discussed on irc, it seems fair to disable
> > CARGO_INCREMENTAL when building with sccache.
>
> So how can we disable this?
> Setting environment variable as in the following?
>
> export CARGO_INCREMENTAL=
>

`ac_add_options --disable-cargo-incremental` in your mozconfig should do
it.  See:

https://searchfox.org/mozilla-central/rev/597a69c70a5cce6f42f159eb54ad1ef6745f5432/build/moz.configure/toolchain.configure#1865

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Must we rebuild all our rust code constantly?

[Eric Rahm]

A fix for this (https://bugzilla.mozilla.org/show_bug.cgi?id=1576030)
should be on m-c shortly, no need to tweak mozconfigs.

-e

On Fri, Aug 23, 2019 at 9:45 AM Nicholas Alexander 
wrote:

> On Fri, Aug 23, 2019 at 2:11 AM ishikawa  wrote:
>
> > On 2019/08/23 11:00, Mike Hommey wrote:
> > >
> > > In the meanwhile, as discussed on irc, it seems fair to disable
> > > CARGO_INCREMENTAL when building with sccache.
> >
> > So how can we disable this?
> > Setting environment variable as in the following?
> >
> > export CARGO_INCREMENTAL=
> >
>
> `ac_add_options --disable-cargo-incremental` in your mozconfig should do
> it.  See:
>
>
> https://searchfox.org/mozilla-central/rev/597a69c70a5cce6f42f159eb54ad1ef6745f5432/build/moz.configure/toolchain.configure#1865
>
> Nick
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: `mach pastebin` ported to `paste.mozilla.org`

[Connor Sheehan]

Hey folks,


Back when `pastebin.mozilla.org` was being decomissioned, we removed `mach 
pastebin` to avoid confusing people who tried using it. Bug 1480362
tracked that work.

Now that `paste.mozilla.org` has been stood up, `mach pastebin` is back
and ported to use the new service. As with the previous implementation
you can send data to be pasted via stdin:

$ some_command | ./mach pastebin

Or by specifying a file on the command line:

$ some_command > output.txt
$ ./mach pastebin output.txt

You can use `--highlighter` to indicate what syntax highlighting should
be used for display. Passing `--list-highlighters` will display all the
known available highlighters. If you don't pass a highlighter, `mach pastebin`
will attempt to use the filename extension to determine a highlighter,
and it will also try the basename of the file if the extension doesn't
return a result.

The code is available in-tree at `tools/mach_commands.py`. File bugs against
`Firefox Build System :: General` on BMO.

Thanks to Nick Alexander and Nathan Froyd for the reviews.


Cheers,
Connor Sheehan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: Deprecated MathML style attributes

[Frédéric Wang]

Hi

In [1], I mentioned the intent to unship 's mode attribute. In bug
1548524, I'll intend to unship the remaining attributes deprecated in
MathML3: fontfamily, fontweight, fontstyle, fontsize, color and background.

Actually, these have been deprecated since MathML2 [2] (released 16
years ago) and we have been sending deprecation warnings since Mozilla
20 (released 6 years ago). The MathML CG agreed to removed them from
MathML Core [3] and Igalia does not plan to implement them in Chromium.

Contrary to the mode attribute, these attributes are also implemented in
WebKit [4] and we got bug reports about some of them in the past [5].
Hence, it makes sense to be a bit more careful. For now they will only
be disabled in nightly and use counters to determine how much they are used.

[1]
https://groups.google.com/forum/#!topic/mozilla.dev.platform/lZUF2Z9jOh4/discussion
[2] https://www.w3.org/TR/MathML2/chapter3.html#presm.deprecatt
[3] https://github.com/mathml-refresh/mathml/issues/5
[4]
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/mathml/MathMLElement.cpp#L96
[5] e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1027354

-- 
Frédéric Wang
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[ann] `mach build` now includes `mach package` for Android

[Nicholas Alexander]

Hi folks!

tl;dr: you don't need to run `mach package` for Android (GeckoView) any
more.

Bug 1550146  has
landed and stuck.  That ticket integrates producing the omnijar required
for Android into the build; and produces All The Things for Android work
during a `mach build`:
- GeckoView AAR
- GeckoView example APK
- test APKs

You shouldn't need to run `mach package` yourself any more.  And hopefully
there's less confusion about when things happen in the (Android) build
system!

If you need to produce a Fennec APK... that still requires `mach package`.

As always, thanks to reviewers and testers: Mike Hommey, Chris Manchester,
Agi Sferro, and James Willcox.

Best,
Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [ann] `mach build` now includes `mach package` for Android

[Bobby Holley]

That's great news! Many thanks to Nick and all the other folks who've
worked so hard to make our Android developer experience great.

On Fri, Aug 23, 2019 at 2:12 PM Nicholas Alexander 
wrote:

> Hi folks!
>
> tl;dr: you don't need to run `mach package` for Android (GeckoView) any
> more.
>
> Bug 1550146  has
> landed and stuck.  That ticket integrates producing the omnijar required
> for Android into the build; and produces All The Things for Android work
> during a `mach build`:
> - GeckoView AAR
> - GeckoView example APK
> - test APKs
>
> You shouldn't need to run `mach package` yourself any more.  And hopefully
> there's less confusion about when things happen in the (Android) build
> system!
>
> If you need to produce a Fennec APK... that still requires `mach package`.
>
> As always, thanks to reviewers and testers: Mike Hommey, Chris Manchester,
> Agi Sferro, and James Willcox.
>
> Best,
> Nick
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform