Ideally, the code would handle things in a more general way that doesn't
require manually dealing with these lists, but this would require more
testing than there is time left before 102 releases.
While here, remove HOST_CPU_ARCH, which is always the same and thus
never appears in a condition.
This changes none of the generated moz.builds for the current
configuration (but changes the outcome when adding new configurations)
Differential Revision: https://phabricator.services.mozilla.com/D149850
The way the processor works currently is that it relies on two different
build backends, one of which produces json files for specific
configurations, and the other which produces moz.build files from the
aggregate of all those configs.
Each of these json files is huge, and we actually don't have enough to
support all the platforms we're supposed to be supporting. Adding more
files is not enticing.
Now that we've made the first step described above work in a single pass
on a single machine (as opposed to multiple passes on multiple machines
previously), we can actually merge both steps and avoid producing the
intermediate json files altogether. This will allow to add more
configurations without having to worry about the weight of those files.
And because this all doesn't need to depend on having the first step
hooked up in the build system, we make the whole an independent script
rather than a build backend.
Differential Revision: https://phabricator.services.mozilla.com/D149210
The way the processor works currently is that it relies on two different
build backends, one of which produces json files for specific
configurations, and the other which produces moz.build files from the
aggregate of all those configs.
Each of these json files is huge, and we actually don't have enough to
support all the platforms we're supposed to be supporting. Adding more
files is not enticing.
Now that we've made the first step described above work in a single pass
on a single machine (as opposed to multiple passes on multiple machines
previously), we can actually merge both steps and avoid producing the
intermediate json files altogether. This will allow to add more
configurations without having to worry about the weight of those files.
And because this all doesn't need to depend on having the first step
hooked up in the build system, we make the whole an independent script
rather than a build backend.
Differential Revision: https://phabricator.services.mozilla.com/D149210
As we're shortly going to stop producing the intermediate json files,
we want the fixups to happen in the GN processor.
Ideally, we'd move them all, but cleaning up -isysroot is more involved,
while we won't need it once we don't use intermediate json files, so we
leave the -isysroot cleanup in fixup_json.py for now.
While here, `gn_out["targets"][target_fullname]` doesn't need to be set
on every iteration of the loop.
Differential Revision: https://phabricator.services.mozilla.com/D149209
The current script requires to be run on 4 different host platforms each
of which would handle a subset of a total of 32 mozconfigs. That is not
sustainable, and there are already missing configs that break tier-3
platforms.
This replaces the current setup with one that handles all platforms in
one go, although we still keep the internal sequence of GcConfigGen ->
fixup_json -> GnMozbuildWriter.
The downside is that because this relies on the upstream webrtc build
system supporting cross-compilation, and that it actively rejects some
configurations, we need some local hacks to make it work on Linux and
Mac, but for now, we have to leave out Windows, which requires more
work.
For some reason, that removes some duplicated include directories in the
json files, which moves things a little in one moz.build file.
We also remove the mozconfigs we don't use anymore.
Differential Revision: https://phabricator.services.mozilla.com/D149205
The way the processor works currently is that it relies on two different
build backends, one of which produces json files for specific
configurations, and the other which produces moz.build files from the
aggregate of all those configs.
Each of these json files is huge, and we actually don't have enough to
support all the platforms we're supposed to be supporting. Adding more
files is not enticing.
Now that we've made the first step described above work in a single pass
on a single machine (as opposed to multiple passes on multiple machines
previously), we can actually merge both steps and avoid producing the
intermediate json files altogether. This will allow to add more
configurations without having to worry about the weight of those files.
And because this all doesn't need to depend on having the first step
hooked up in the build system, we make the whole an independent script
rather than a build backend.
Differential Revision: https://phabricator.services.mozilla.com/D149210
As we're shortly going to stop producing the intermediate json files,
we want the fixups to happen in the GN processor.
Ideally, we'd move them all, but cleaning up -isysroot is more involved,
while we won't need it once we don't use intermediate json files, so we
leave the -isysroot cleanup in fixup_json.py for now.
While here, `gn_out["targets"][target_fullname]` doesn't need to be set
on every iteration of the loop.
Differential Revision: https://phabricator.services.mozilla.com/D149209
The current script requires to be run on 4 different host platforms each
of which would handle a subset of a total of 32 mozconfigs. That is not
sustainable, and there are already missing configs that break tier-3
platforms.
This replaces the current setup with one that handles all platforms in
one go, although we still keep the internal sequence of GcConfigGen ->
fixup_json -> GnMozbuildWriter.
The downside is that because this relies on the upstream webrtc build
system supporting cross-compilation, and that it actively rejects some
configurations, we need some local hacks to make it work on Linux and
Mac, but for now, we have to leave out Windows, which requires more
work.
For some reason, that removes some duplicated include directories in the
json files, which moves things a little in one moz.build file.
We also remove the mozconfigs we don't use anymore.
Differential Revision: https://phabricator.services.mozilla.com/D149205
A week ago we received a notification that we had a test that the WPT chrome tests were perma failing on [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1773621 | bugzilla ]]
After going through the fail logs I realized it was because of website "panda.tv" directing to a unable to connect page message, after some digging it was not returning proper data because panda.tv has not been a company since March 2019(bankruptcy filing), why this only is causing an issue now I believe is because of some kind of update from WPT as I can see a noticeable UI difference on the test results page from before and after the failures started.
My resolution was to remove Panda.tv from our test list and that seems to have resolved the issue.
I also updated the error message to display which website is causing the issue so that if this happens again I don't need to go through each and every webpagetest result to know which of the 40 websites are having an issue.
Differential Revision: https://phabricator.services.mozilla.com/D149642
Including glean_parser 6.1.1
Two important things in there:
* glean_parser: [data-review] Include extra keys' names and descriptions in data review template
* Glean: Derive `serde::{Deserialize, Serialize}` on `Lifetime` and `CommonMetricData`
Differential Revision: https://phabricator.services.mozilla.com/D149381
I also added `%USERPROFILE%/.mozbuild` to the exclusion list and updated the windows_build docs to reflect the changes made.
Differential Revision: https://phabricator.services.mozilla.com/D149199
When `./mach bootstrap` is called with the default mozconfig file,
verify the content matches the selected build target, and if not,
show a warning and ask whether to overwrite or not.
Differential Revision: https://phabricator.services.mozilla.com/D146384
