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
