printerenumeration (nsIPrinterEnumerator)

[rvj]

.. docs say enumerateprinters() method is obsolete since 1.9 (Gecko)...

what replaces it ?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Bringing Marionette and Mochitest closer

[Neil]

Jonas Sicking wrote:


The fact that we are using gecko as the http server means a whole lot of 
complications on mobile. In short, we currently need gecko both compiled for 
android, which is the version of gecko being tested, and compiled for a desktop 
platform, which acts as host of the web server. This is currently a drain on 
our infrastructure and means that we're running tests slower than we otherwise 
could.
 

Aren't we already compiling and packaging tests for gecko for desktop? 
Is android compiling them all over again instead of using "existing" 
compiled packages?


--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Bringing Marionette and Mochitest closer

[Ted Mielczarek]

On 1/30/2013 5:56 AM, Neil wrote:
> Jonas Sicking wrote:
>
>> The fact that we are using gecko as the http server means a whole lot
>> of complications on mobile. In short, we currently need gecko both
>> compiled for android, which is the version of gecko being tested, and
>> compiled for a desktop platform, which acts as host of the web
>> server. This is currently a drain on our infrastructure and means
>> that we're running tests slower than we otherwise could.
>>  
>>
> Aren't we already compiling and packaging tests for gecko for desktop?
> Is android compiling them all over again instead of using "existing"
> compiled packages?
>

Android tests are using pre-built desktop binaries to run httpd.js, but
it's an extra hassle. Also developers who want to run Mochitests for
mobile platforms need to have a desktop build laying around, which is
one more hoop to jump through.

-Ted

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

Re: Bringing Marionette and Mochitest closer

[David Burns]

I am all for moving towards Marionette being the basis of all 
frameworks. It will allow us to share tests between other vendors 
because Marionette is based on the W3C Browser Automation Spec[1].


One of the things that this brings up is how we can share between other 
vendors. Testharness.js has become the W3 in browser standard so if we 
are going for interop between vendors then using testharness.js is what 
we will need to look at that or look at pure Marionette calls into the 
browser if we need to get out of the sandbox.


One thing to note, and might not be obvious from Marionette 
documentation, is that it is easy to switch between Browser Chrome and 
Browser Content and execute commands (including pure JS).


Opera use their equivalent of Marionette called OperaDriver[3] to load 
the browser and set the browser capabilities and visit a server that 
loads the in-browser test and runs testharness.js or calling into Chrome 
since it accesses the browser via its Scope Protocol. If I remember 
correctly, Chromium is moving to that model too but through their remote 
debugger like us.


I have also put some in line messages below for more specific things.

If you want to discuss this further via vidyo/skype/irc let me know. I 
am keep to fix any potential shortcomings in Marionette.


David Burns
AutomatedTester

[1] https://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html
[2] https://github.com/mozilla/mozbase/tree/master/mozprofile
[3] https://github.com/operasoftware/operadriver
[4] [2] https://github.com/mozilla/mozbase/tree/master/mozhttpd
[5] https://wiki.mozilla.org/Auto-tools/Projects/Mozbase

On 30/01/2013 07:13, Jonas Sicking wrote:

We'd also need to improve the web server which is started by
marionette so that we can satisfy some of the use cases that we're
currently using .sjs files to solve in mochitest.


I am sure that we update MozHTTPd[4] to have a similar feature, might be 
exact and might not be trivial to do but might be worth the effort at 
for a later stage. MozHTTPd is part of MozBase[5], the ATeam project to 
standardise tools we use in testing.




Instead we suggest that we use a simpler python based solution.


Marionette's python client will be great at this. We are already using 
this extensively.




This means that we can't immediately migrate the existing body of
mochitests to the new http server. But we only have a total of 184
.sjs files, so it seems like something that should be doable
eventually.

So for now this means that we'll have to set up a new test harness.
But I'm personally hoping that we can eventually let this harness
cover also our /mochitests which would be an all-around win.


So a quick win for this sounds like Marionette + (MozProfile[2] + 
Special Powers) to get what we want but there might be more to it.



Would very much like to hear feedback on these plans.

Something else we talked about very briefly was to improve the test
environment which we use for running mochitests on B2G such that we
enable the same "adjust test, press reload" flow that is commonly used
on desktop when writing mochitests.


Since there is a python package we can easily use the REPL for python to 
do things but I don't see how Marionette would stop this. Marionette 
just "drives" the browser. If you are just wanting to load a page then 
Marionette's navigate() method would just load that.




This will hopefully both help with
getting more tests authored for B2G-specific features (tests which can
hopefully be migrated to cross-platform as the features become
cross-platform), and help with getting the current body of mochitests
running on B2G.

/ Jonas
___
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: Bringing Marionette and Mochitest closer

[Jet Villegas]

I attended a W3C Testing Strategy meeting yesterday and the delta between our 
test frameworks and testharness.js was discussed. The W3C is very interested in 
getting our tests into their harness, and I shared some of the shortcomings 
that I gathered from Jonas:

* It requires that all code is wrapped in: test(function() { <...> })
* For asynchronous testing, you'll need the following boiler plate:
  obj = async_test(); obj.step(function() { <...> }); obj.done();
* In some cases gets even more complicated and needs additional obj.step_func 
calls.
* Exceptions thrown outside of a test/test_step function doesn't cause test 
failure
* Test functions have much longer name "assert_equals" vs. "is" and 
"assert_true" vs. "ok"
* Can't run server-side code. 

I agreed to participate in a task force to solve the issues related to bringing 
our tests to W3C (and bringing W3C tests downstream to us.) The W3C is willing 
to make changes to their test infrastructure to accommodate our tests. Let's 
make our requirements as crisp as possible: Should we be pushing for Marionette 
(vs. mochi) as the basis for the W3C framework changes? What changes do we need 
on our side to get interop between W3C tests and our frameworks and enable 
synching tests to/from our trunk and the W3C's?

--Jet

- Original Message -
From: "David Burns" 
To: "Jonas Sicking" 
Cc: "dev-platform" 
Sent: Wednesday, January 30, 2013 6:11:05 AM
Subject: Re: Bringing Marionette and Mochitest closer

I am all for moving towards Marionette being the basis of all 
frameworks. It will allow us to share tests between other vendors 
because Marionette is based on the W3C Browser Automation Spec[1].

One of the things that this brings up is how we can share between other 
vendors. Testharness.js has become the W3 in browser standard so if we 
are going for interop between vendors then using testharness.js is what 
we will need to look at that or look at pure Marionette calls into the 
browser if we need to get out of the sandbox.

One thing to note, and might not be obvious from Marionette 
documentation, is that it is easy to switch between Browser Chrome and 
Browser Content and execute commands (including pure JS).

Opera use their equivalent of Marionette called OperaDriver[3] to load 
the browser and set the browser capabilities and visit a server that 
loads the in-browser test and runs testharness.js or calling into Chrome 
since it accesses the browser via its Scope Protocol. If I remember 
correctly, Chromium is moving to that model too but through their remote 
debugger like us.

I have also put some in line messages below for more specific things.

If you want to discuss this further via vidyo/skype/irc let me know. I 
am keep to fix any potential shortcomings in Marionette.

David Burns
AutomatedTester

[1] https://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html
[2] https://github.com/mozilla/mozbase/tree/master/mozprofile
[3] https://github.com/operasoftware/operadriver
[4] [2] https://github.com/mozilla/mozbase/tree/master/mozhttpd
[5] https://wiki.mozilla.org/Auto-tools/Projects/Mozbase

On 30/01/2013 07:13, Jonas Sicking wrote:
> We'd also need to improve the web server which is started by
> marionette so that we can satisfy some of the use cases that we're
> currently using .sjs files to solve in mochitest.

I am sure that we update MozHTTPd[4] to have a similar feature, might be 
exact and might not be trivial to do but might be worth the effort at 
for a later stage. MozHTTPd is part of MozBase[5], the ATeam project to 
standardise tools we use in testing.


> Instead we suggest that we use a simpler python based solution.

Marionette's python client will be great at this. We are already using 
this extensively.


> This means that we can't immediately migrate the existing body of
> mochitests to the new http server. But we only have a total of 184
> .sjs files, so it seems like something that should be doable
> eventually.
>
> So for now this means that we'll have to set up a new test harness.
> But I'm personally hoping that we can eventually let this harness
> cover also our /mochitests which would be an all-around win.

So a quick win for this sounds like Marionette + (MozProfile[2] + 
Special Powers) to get what we want but there might be more to it.

> Would very much like to hear feedback on these plans.
>
> Something else we talked about very briefly was to improve the test
> environment which we use for running mochitests on B2G such that we
> enable the same "adjust test, press reload" flow that is commonly used
> on desktop when writing mochitests.

Since there is a python package we can easily use the REPL for python to 
do things but I don't see how Marionette would stop this. Marionette 
just "drives" the browser. If you are just wanting to load a page then 
Marionette's navigate() method would just load that.


> This will hopefully both help with
> getting more tests authored for B2G-specific features (t

Re: Removed support for global private browsing

[Kevin Brosnan]

Does this remove any of the use cases? Such as the -private or
-private-toggle command line flag or the never remember history setting.
On Jan 29, 2013 12:25 PM, "Ehsan Akhgari"  wrote:

> Hi all,
>
> Just a quick note to mention that I landed bug 817477 on mozilla-central
> earlier today, which removes support for the global private browsing mode
> implemented first in Firefox 3.5.  This means that the
> MOZ_PER_WINDOW_PRIVATE_**BROWSING does not exist any more, and all code
> that depends on mozilla-central is now built with the per-window private
> browsing APIs.
>
> If you maintain a project branch, this might cause merge conflicts for you
> as the patch touched a fair number of files in the tree.  Please do not
> hesitate to let me know if you need help with that.
>
> Cheers,
> Ehsan
> __**_
> 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: Removed support for global private browsing

[Ehsan Akhgari]

On 2013-01-30 11:38 AM, Kevin Brosnan wrote:

Does this remove any of the use cases? Such as the -private or
-private-toggle command line flag or the never remember history setting.


This is not going to change any of the features that are enabled in 
Nightly now.  I was just removing a whole bunch of dead code in a 
non-default build configuration.


Cheers,
Ehsan

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

Re: Bringing Marionette and Mochitest closer

[Benjamin Smedberg]

On 1/30/2013 2:13 AM, Jonas Sicking wrote:

A few of us got together last week and had a quick brainstorming
session about how to leverage the combined power from Mochitest and
Marionette better. The following issues were raised:
What is Marionette? From the discussion, it sounds like a W3C testing 
framework, but it's not clear whether it's something we're currently 
using, or something we're discussing using. I don't remember having seen 
it on TBPL, for example.


--BDS

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

Re: Bringing Marionette and Mochitest closer

[Josh Matthews]

On 01/30/2013 06:33 PM, Benjamin Smedberg wrote:

On 1/30/2013 2:13 AM, Jonas Sicking wrote:

A few of us got together last week and had a quick brainstorming
session about how to leverage the combined power from Mochitest and
Marionette better. The following issues were raised:

What is Marionette? From the discussion, it sounds like a W3C testing
framework, but it's not clear whether it's something we're currently
using, or something we're discussing using. I don't remember having seen
it on TBPL, for example.

--BDS



https://developer.mozilla.org/en-US/docs/Marionette

It's definitely on TBPL.

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

Re: printerenumeration (nsIPrinterEnumerator)

[Daniel Holbert]

It looks like enumeratePrinters() was replaced by an attribute
"printerNameList" in this changeset:
  https://hg.mozilla.org/mozilla-central/rev/d411716a02bc#l6.94

That attribute still exists on trunk, as shown here:
https://mxr.mozilla.org/mozilla-central/source/widget/nsIPrintOptions.idl#64


However, be warned that there are patches in bug 629500 to get rid of
nsIPrinterEnumerator entirely (though that bug seems to have stalled a
bit, so I don't know how soon that will happen).

~Daniel

On 01/30/2013 02:52 AM, rvj wrote:
> .. docs say enumerateprinters() method is obsolete since 1.9 (Gecko)...
> 
> what replaces it ?
> ___
> 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: printerenumeration (nsIPrinterEnumerator)

[Zack Weinberg]

On 2013-01-30 2:23 PM, Daniel Holbert wrote:


However, be warned that there are patches in bug 629500 to get rid of
nsIPrinterEnumerator entirely (though that bug seems to have stalled a
bit, so I don't know how soon that will happen).


It's blocked on Windows-specific fixes (bug 693230) -- it looks like 
there's a patch in there, but nobody bothered to ask for review and it's 
also not clear whether it actually works.  If anyone has low-level 
Windows GUI programming experience and spare brain cycles I could really 
use help with that part.


The intention is still to remove nsIPrinterEnumerator entirely.  All the 
tier-1 platforms nowadays discourage use of the OS-level printer 
enumeration APIs, because they have to talk to the network and may block 
the calling thread for an indefinite period.  You're supposed to just 
let the OS-supplied print dialog boxes figure it out for you.


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

Re: Bringing Marionette and Mochitest closer

[David Burns]

Marionette is one of the core frameworks for testing FirefoxOS but works 
pretty much everywhere since it is part Gecko.


You can see it on TBPL with 
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&jobname=marionette for 
example.


David

On 30/01/2013 18:33, Benjamin Smedberg wrote:

On 1/30/2013 2:13 AM, Jonas Sicking wrote:

A few of us got together last week and had a quick brainstorming
session about how to leverage the combined power from Mochitest and
Marionette better. The following issues were raised:
What is Marionette? From the discussion, it sounds like a W3C testing 
framework, but it's not clear whether it's something we're currently 
using, or something we're discussing using. I don't remember having 
seen it on TBPL, for example.


--BDS

___
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: Let's never, ever, shut down NSS -- even in debug builds

[Robert Kaiser]

Robert Relyea schrieb:

Switching to SQLite would make this a non-issue.


Is there a plan to do this? An open bug? Someone working on it?

Robert Kaiser

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

The future of PGO on Windows

[Ehsan Akhgari]

(Follow-ups to dev-platform, please)

Dear all,

This email summarizes the results of our investigation on our options 
with regard to the future of PGO optimizations on Windows.  I will first 
describe the work that happened as part of the investigation, and will 
then propose a set of options on what solutions are available to us.  If 
you're interested in the tl;dr version, please scroll to the bottom. 
For the details, see the dependencies of bug 833881.


(Note that we're only talking about PGO for libxul.  Anything outside of 
libxul, specifically the JS engine, is not going to be affected by the 
decision coming out of this thread.  And obviously, this discussion is 
only about Windows.)


The first thing that we tried to investigate was whether or not 
upgrading to Visual Studio 2012 Update 1 makes the memory usage of the 
PGO linker drop down by a significant amount.  Thanks to the 
investigation done by jimm, we know that it will actually increase the 
memory usage, and therefore is not an option.


Then, we tried to see how much breathing room we're going to have if we 
disabled PGO but not link-time code generation (LTCG), and if we disable 
them both together.  It turns out that disabling PGO but keeping LTCG 
enabled reduces the memory usage by ~200MB, which means that it's not an 
effective measure.  Disabling both LTCG and PGO brings down the linker's 
virtual memory usage to around 1GB, which means that we will not hit the 
maximum virtual memory size of 4GB for a *long* time.  (Unfortunately, 
the Microsoft toolchain cannot perform PGO builds without LTCG.) 
Therefore, for the rest of this email, I will talk about disabling both 
PGO and LTCG.


We then tried to get a sense of how much of a win the PGO optimizations 
are.  Thanks to a series of measurements by dmandelin, we know that 
disabling PGO/LTCG will result in a regression of about 10-20% on 
benchmarks which examine DOM and layout performance such as Dromaeo and 
guimark2 (and 40% in one case), but no significant regressions in the 
startup time, and gmail interactions.  Thanks to a series of telemetry 
measurements performed by Vladan on a Nightly build we did last week 
which had PGO/LTCG disabled, there are no telemetry probes which show a 
significant regression on builds without PGO/LTCG.  Vladan is going to 
try to get this data out of a Tp5 run tomorrow as well, but we don't 
have any evidence to believe that the results of that experiments will 
be any different.



Given the above, I'd like to propose the following long-term solutions:

1. Disable PGO/LTCG now.  The downsides are that we should take a hit in 
microbenchmarks, specifically Dromaeo.  But we have no reason to believe 
that is going to affect any of the performance characteristics observed 
by our users.  And it means that engineers can stop worrying about this 
problem once and for all.


2. Try to delay disabling PGO/LTCG as much as possible.  Given the 
tracking implemented in bug 710840, we can now watch those graphs so 
that we know when this problem is going to hit next, and come up with a 
mitigation strategy.  In order to effectively implement this solution, 
we're going to need:
  * A person to own watching the graphs and report back when we step 
inside "the danger zone" again.
  * A detailed plan of action on what we'll do to mitigate this problem 
the next time as opposed to acting on a firedrill.  One possible plan of 
action could be disabling PGO for everything except 
content/dom/layout/xpcom/gfx, no questions asked.

  * A group of engineers to own performing the above action.
  * Going back through the historical data over the past year, 
determine the causes behind the large spikes in the gradual memory usage 
increase, and find solutions to them to buy as much time as possible.


3. Try to delay disabling PGO/LTCG until the next time that we hit the 
limit, and disable PGO/LTCG then once and for all.  In order to 
implement this solution, we're going to need:
  * A person to own watching the graphs and report back when we step 
inside the danger zone again.
  * A build-system patch which makes it possible to disable PGO/LTCG 
for libxul by toggling a switch.
  * Clear documentation on what that switch is, so that anybody can 
toggle it when we need to take action the next time.



I think given the information that we currently have, the best course of 
action is #3, followed by #1 and #2.  I'd like to explicitly recommend 
against #2, because I don't think we have the evidence to support that 
spending that much effort will bring any noticeable gains to our users. 
 This effort is better spent elsewhere.



Please let me know if you have any questions, if I have missed anything, 
and do provide your feedback on the above proposal.  As we ultimately 
need a decision to come out of this thread, and given that it affects 
Firefox Desktop, I have asked johnath to be the person who makes the 
final call, or to delegate that to someone whom h

Re: The future of PGO on Windows

[Robert O'Callahan]

What about leaving PGO/LTCG enabled for a subset of our modules? Is that
not a possible solution?

Rob
-- 
Jesus called them together and said, “You know that the rulers of the
Gentiles lord it over them, and their high officials exercise authority
over them. Not so with you. Instead, whoever wants to become great among
you must be your servant, and whoever wants to be first must be your
slave — just
as the Son of Man did not come to be served, but to serve, and to give his
life as a ransom for many.” [Matthew 20:25-28]
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The future of PGO on Windows

[Ehsan Akhgari]

On 2013-01-30 11:11 PM, Robert O'Callahan wrote:

What about leaving PGO/LTCG enabled for a subset of our modules? Is that
not a possible solution?


I did in fact measure that by disabling PGO/LTCG on all directories 
except content, dom, layout and xpcom.  I can't seem to find the try 
push right now (and bug 836626 doesn't help), but IIRC that bought us 
600MB-700MB.  To put that number in context, we have increased the 
linker memory usage by about 1GB over the past 10 months.  Therefore, 
this will fall under option #2.


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

Re: The future of PGO on Windows

[Robert O'Callahan]

On Thu, Jan 31, 2013 at 5:34 PM, Ehsan Akhgari wrote:

> On 2013-01-30 11:11 PM, Robert O'Callahan wrote:
>
>> What about leaving PGO/LTCG enabled for a subset of our modules? Is that
>> not a possible solution?
>>
>
> I did in fact measure that by disabling PGO/LTCG on all directories except
> content, dom, layout and xpcom.  I can't seem to find the try push right
> now (and bug 836626 doesn't help), but IIRC that bought us 600MB-700MB.  To
> put that number in context, we have increased the linker memory usage by
> about 1GB over the past 10 months.  Therefore, this will fall under option
> #2.
>

Can we do it at finer granularity than that? There's a lot under content
and dom that aren't critical.

Also, reducing the number of directories that are PGO/LTCG should mean that
the rate of growth decreases proportionally. Even more than proportionally,
if we flip our default for entirely new modules to be non-PGO/LTCG, as I
assume we would.

Rob
-- 
Jesus called them together and said, “You know that the rulers of the
Gentiles lord it over them, and their high officials exercise authority
over them. Not so with you. Instead, whoever wants to become great among
you must be your servant, and whoever wants to be first must be your
slave — just
as the Son of Man did not come to be served, but to serve, and to give his
life as a ransom for many.” [Matthew 20:25-28]
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The future of PGO on Windows

[Ehsan Akhgari]

On 2013-01-30 11:40 PM, Robert O'Callahan wrote:

On Thu, Jan 31, 2013 at 5:34 PM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote:

On 2013-01-30 11:11 PM, Robert O'Callahan wrote:

What about leaving PGO/LTCG enabled for a subset of our modules?
Is that
not a possible solution?


I did in fact measure that by disabling PGO/LTCG on all directories
except content, dom, layout and xpcom.  I can't seem to find the try
push right now (and bug 836626 doesn't help), but IIRC that bought
us 600MB-700MB.  To put that number in context, we have increased
the linker memory usage by about 1GB over the past 10 months.
  Therefore, this will fall under option #2.


Can we do it at finer granularity than that? There's a lot under content
and dom that aren't critical.


Sure, that is definitely an option.  Note that I have already turned off 
PGO/LTCG for things like mathml and svg under content, dom and layout 
(see the dependencies of bug 832992).



Also, reducing the number of directories that are PGO/LTCG should mean
that the rate of growth decreases proportionally. Even more than
proportionally, if we flip our default for entirely new modules to be
non-PGO/LTCG, as I assume we would.


The decrease is unfortunately not linear, as it seems like the big 
memory eater is LTCG, and unfortunately we cannot opt out of that if we 
want to do any PGO.


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

Re: The future of PGO on Windows

[Mike Hommey]

On Wed, Jan 30, 2013 at 11:49:01PM -0500, Ehsan Akhgari wrote:
> The decrease is unfortunately not linear, as it seems like the big
> memory eater is LTCG, and unfortunately we cannot opt out of that if
> we want to do any PGO.

Well, LTCG is only going to compile objects that have been compiled
with -GL.

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