Re: Must we rebuild all our rust code constantly?

2019-08-24 Thread ISHIKAWA,chiaki

Here is my own answer to clean up the mess of version mismatches, etc.

I did the following.

1. I removed ~/.mozbuild and ~/.cargo directory and
re-ran |make bootstrap|.
(I am not sure if removing ~/.cargo directory was a good idea.)

2. I revered my local changes before I update the M-C and C-C (./comm).

3. Then I noticed mozilla/Cargo.lock has been modified when I tried to 
reapply my local changes.

This file was presumably changed when I did my own sccache installation.

So I reverted the change to Cargo.lock, and now it seems that the 
compilation is proceeding... (Not sure if the result is OK.)



4. When I did this, I noticed there is sccache 0.2.11-Alpha.0 under 
~/.mozbuild/sccache directory.
Obviously, I was using my own installed older version of sccache which I 
installed many months ago.
So I added the path to this sccache in my script for building TB and it 
seems to be compiling TB.


I added the following in my mozconfig for TB, but I am not sure if this 
is the right way to disable incremental compilation.


mk_add_options "export CARGO_INCREMENTAL=0"

TIA

On 2019/08/22 11:22, ISHIKAWA,chiaki wrote:
Well, I have a problem now after trying to update sccache just in case 
I need a new version in the future.


I did the following:

cargo install --force sccache

(I was not so sure of what the proper update procedure of already 
installed package. sccache 2.0.8-alpha-something was already installed.)


Then when I try to compile TB using the command script which worked 
for more than a few years suddenly printed the following and failed. I 
think I have messed up my cargo metadata somehow by the above command.


I have run |mach bootstrap| to see if it fixes the issue. It did not.

ERROR: Couldn't execute `cargo metadata` with manifest 
"/NREF-COMM-CENTRAL/mozilla/toolkit/library/rust/Cargo.toml": 
Metadata(Output { status: ExitStatus(ExitStatus(25856)), stdout: "", 
stderr: "error: failed to select a version for the requirement `libc = 
\"= 0.2.62\"`\n  candidate versions found which didn\'t match: 
0.2.60\n  location searched: directory source 
`/NREF-COMM-CENTRAL/mozilla/third_party/rust` (which is replacing 
registry `https://github.com/rust-lang/crates.io-index`)\nrequired by 
package `mozjs_sys v0.0.0 
(/NREF-COMM-CENTRAL/mozilla/js/src)`\nperhaps a crate was updated and 
forgotten to be re-vendored?\n" })
ERROR: Couldn't generate bindings for 
/NREF-COMM-CENTRAL/mozilla/toolkit/library/rust.

make[4]: *** [backend.mk:72: .deps/ServoStyleConsts.h.stub] Error 1
make[3]: *** [/NREF-COMM-CENTRAL/mozilla/config/recurse.mk:101: 
layout/style/export] Error 2

make[3]: *** Waiting for unfinished jobs
ERROR: Couldn't execute `cargo metadata` with manifest 
"/NREF-COMM-CENTRAL/mozilla/toolkit/library/rust/Cargo.toml": 
Metadata(Output { status: ExitStatus(ExitStatus(25856)), stdout: "", 
stderr: "    Blocking waiting for file lock on package cache 
lock\nerror: failed to select a version for the requirement `libc = 
\"= 0.2.62\"`\n  candidate versions found which didn\'t match: 
0.2.60\n  location searched: directory source 
`/NREF-COMM-CENTRAL/mozilla/third_party/rust` (which is replacing 
registry `https://github.com/rust-lang/crates.io-index`)\nrequired by 
package `mozjs_sys v0.0.0 
(/NREF-COMM-CENTRAL/mozilla/js/src)`\nperhaps a crate was updated and 
forgotten to be re-vendored?\n" })
ERROR: Couldn't generate bindings for 
/NREF-COMM-CENTRAL/mozilla/toolkit/library/rust.
make[4]: *** [backend.mk:11: .deps/webrender_ffi_generated.h.stub] 
Error 1
make[3]: *** [/NREF-COMM-CENTRAL/mozilla/config/recurse.mk:101: 
gfx/webrender_bindings/export] Error 2


Does anyone have a clue how to restore order here?

TIA

Chiaki


On 2019/08/21 4:33, Markus Stange wrote:

On 2019-08-19 8:11 p.m., Dave Townsend wrote:
Thanks to a tip I've tracked this down. This seems to only be the 
case when
I have sccache enabled. Disabling it gives me nice quick incremental 
builds

again.


What's your sccache version? I think you may be hitting the following 
sccache bug which has been fixed already:

https://github.com/mozilla/sccache/issues/436

I'm using sccache 0.2.9 and I don't see rust code rebuilding constantly.

Markus
___
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


Re: Intend to deprecate: XLink attributes on MathML elements

2019-08-24 Thread Cameron McCormack
On Sat, Aug 24, 2019, at 8:31 PM, Frédéric Wang wrote:
> In bug 1548524, I intend to deprecate XLink attributes (“href”, “type”,
> “show” and “actuate”) on MathML elements. This has never been supported
> by other browsers and AFAIK there is not any plan to do so. Gecko
> actually only has partial support for XLink and there is no plan to
> implement full support [1].
>
> [...]
>
> For now these attributes
> will only be disabled in nightly and a use counter will be introduced to
> determine how much this feature is used.

Thank you for cleaning this up, Frédéric.  What are the use counter thresholds 
you are looking for with these MathML deprecations?  A certain percentage of 
all pages, or of pages with any MathML?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Intend to deprecate: XLink attributes on MathML elements

2019-08-24 Thread Frédéric Wang
Hi,

In bug 1548524, I intend to deprecate XLink attributes (“href”, “type”,
“show” and “actuate”) on MathML elements. This has never been supported
by other browsers and AFAIK there is not any plan to do so. Gecko
actually only has partial support for XLink and there is no plan to
implement full support [1].

MathML3 (released 5 years ago) introduced a href attribute as a
replacement for xlink:href [2]:

"Note that MathML 2 had no direct support for linking, and instead
followed the W3C Recommendation 'XML Linking Language' [XLink] in
defining links using the xlink:href attribute. This has changed, and
MathML 3 now uses an href attribute. However, particular compound
document formats may specify the use of XML linking with MathML
elements, so user agents that support XML linking should continue to
support the use of the xlink:href attribute with MathML 3 as well. "

Although MathML 3 still says xlink:href should be supported in user
agents supporting XML linking, there is an open item regarding what to
do in future versions [3].

We have been sending deprecation for xlink:href on MathML elements for 7
years [4] however users have reported bugs for xlink:href in the past
[5] so it is sensible to be a bit more careful. For now these attributes
will only be disabled in nightly and a use counter will be introduced to
determine how much this feature is used.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=61664
[2] https://www.w3.org/Math/draft-spec/chapter2.html#fund.globatt
[3] https://github.com/mathml-refresh/mathml/issues/127
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=553917
[5] e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=427990

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