We currently use a 32-bit Rust toolchain for win32 builds, but this can lead
to OOM situations. This patch makes win32 builds use a 64-bit Rust toolchain,
which requires a little bit of extra configuration because rustc needs to
be able to find a link.exe that produces 64-bit binaries for building
things like build scripts, which are host binaries.
We will now generate a batch file that sets LIB to the paths to 64-bit
libraries and invokes the x64-targeting link.exe, and add a section to the
.cargo/config file to instruct cargo to use that batch file as the linker
when producing 64-bit binaries.
MozReview-Commit-ID: 9vKBbm7Gvra
--HG--
extra : rebase_source : 599b3b661c7a8a5db1f32a2a9732fc202fb55e1e
- Add node as a dependency on Linux and Mac
- Add python3 for Mac only (linux generally has it installed already).
MozReview-Commit-ID: EpNWFTI9UXc
--HG--
extra : rebase_source : 755e8575e6e6c261c1ccaf9e5fe08e66502a4c3c
Sometimes, one just wants to run a one-off script with access to all
(or most) the libraries available like mozbuild, etc. but without
the weight of the whole virtualenv, which implies having an objdir
setup, etc.
One of my use cases is to run our preprocessor before the objdir is even
setup, and I'd rather not have one automatically created.
--HG--
extra : rebase_source : a6ad30a47ea8e497b274845caf7a9504b9f13282
This makes sure the mozterm module is available to the testers. The
setup.py was needed to it could be installed from requirements.txt.
This module does not yet live on pypi.
MozReview-Commit-ID: 9AL0EZ1uVgL
--HG--
extra : rebase_source : 882d4ec5ec9b80f20ca63e5c7303752427b390d2
This makes sure the mozterm module is available to the testers. The
setup.py was needed to it could be installed from requirements.txt.
This module does not yet live on pypi.
MozReview-Commit-ID: 9AL0EZ1uVgL
--HG--
extra : rebase_source : 4052f60e5e793d912045a9bd420d70c59e8a69fb
mesa is not necessary as of bug 938489 (there was even a bootstrap patch
that never landed)
libiw is not necessary as of bug 799391.
libnotify is not necessary as of bug 783765.
--HG--
extra : rebase_source : f6ecc18e50f8f92cb02ed16c87a6192800ea250d
We no longer support Android/armv6 and we requires NEON for Android/arm, so
we can remove armv6 support for Android.
MozReview-Commit-ID: Hh17BTyE0wR
--HG--
extra : rebase_source : 57e043ecb1bb57a026c0b656b82768b899ddae78
At the same time, we make it actually do something on spidermonkey
builds. We also add an environment variable alternative, that we use
in mozconfig.stdcxx, allowing for mozconfig.no-compile to override it
and avoid configure failures on e.g. artifact builds.
--HG--
extra : rebase_source : b68d362025e0c99f9184a03391c652ec2c9357ad
Bug 1325632 added some facility to add target compiler flags. This
change extends it to add allow adding host compiler flags as well.
--HG--
extra : rebase_source : 424b405a1d8f9a4778ff75c3308c9622f050e194
We currently use a 32-bit Rust toolchain for win32 builds, but this can lead
to OOM situations. This patch makes win32 builds use a 64-bit Rust toolchain,
which requires a little bit of extra configuration because rustc needs to
be able to find a link.exe that produces 64-bit binaries for building
things like build scripts, which are host binaries.
We will now generate a batch file that sets LIB to the paths to 64-bit
libraries and invokes the x64-targeting link.exe, and add a section to the
.cargo/config file to instruct cargo to use that batch file as the linker
when producing 64-bit binaries.
MozReview-Commit-ID: 9vKBbm7Gvra
--HG--
extra : rebase_source : 366dd966cafe4f07b8e59fc170d2db2dada32627
Prior to bug 1224450, CompileDB used data from the Makefiles to generate
the compilation command-lines. Now that the data is derived entirely
from moz.build, we don't need to check that the Makefile is present.
This enables a simple "ac_add_options --build-backends=CompileDB"
mozconfig to work without building a make backend first.
MozReview-Commit-ID: 9tYumyUyg5Y
--HG--
extra : rebase_source : 979f729076b3ab4fd719924877b7ef195e34bfd7
For cases like BackendMakefile where we don't have access to
BuildBackend._write_file(), we need to make sure that FileAvoidWrite
uses the dry-run flag in order to avoid writing out files during a
config.status --dry-run.
MozReview-Commit-ID: ApsSQPySImt
--HG--
extra : rebase_source : 70775f48b7bbea82ce94b0cd9467815c2abe8e8c
This commit adds a frontend construct, `GN_DIRS`, to facilitate building
gn projects with moz.build. Directories added to `GN_DIRS` get particular
treatment by two build backends added here as well, `GnConfigGen` and
`GnMozbuildWriter`.
The `GnConfigGen` backend runs `gn gen` for a gn project specified in
`GN_DIRS` and dumps this configuration as json, which is filtered to include
only those elements that will be needed by mozbuild. `gn gen` is run in
the context of a single build's configuration, so when adding or updating
a gn project it will be necessary to run this step with each supported
configuration.
The `GnMozbuildWriter` aggregates the config files generated by the
`GnConfigGen` backend, which it expects to find in the `gn-configs` directory
under the directory specified to `GN_DIRS`. The result is written to a set of
moz.build files suitable for building the project that are intended to be
checked in to the tree.
Once these moz.build files are checked in to the tree the project can be built
as any other directory: when using a general purpose build backend such as
RecursiveMake or FasterMake to build, entries in `GN_DIRS` will be treated as a
normal entries in `DIRS`.
MozReview-Commit-ID: KlHuP4DY2R4
--HG--
extra : rebase_source : b16079b3417bee3e58b0ecc8724b54c1b9d87d98
This has the virtue of not executing python three times during configure
just to read the same value of milestone.txt and munge it. We can also
remove milestone.py as a happy side effect, so all the milestone
computations can be done in init.configure.
Bug 1416891 introduced a line in moz.build that uses
LOCALIZED_FILES['..'], which ended up created a BackendTupfile object
for 'dist/bin/browser/../Tupfile' separate from the BackendTupfile
object for 'dist/bin/Tupfile'. Since both objects write to the same
file, the one with a '..' in the path ended up clobbering the original
one.
This patch makes two small changes, either of which would be sufficient
to fix the problem. First, we only get the backend file in
_process_final_target_files() when we actually use it (the
LOCALIZED_FILES in this case goes through the else case). Second, we now
call normpath in _get_backend_file() to ensure things like '..' are
resolved so that any future cases of 'Tupfile' and 'foo/../Tupfile'
end up pointing to the same object.
MozReview-Commit-ID: KDGBdtQ18lK
--HG--
extra : rebase_source : 8322e6bfccf2db8ee303e1ecf6ae954380b1ebc7
These files fail to build in the tup backend because the --locale
argument is missing and scripts like generate_update_locale.py require a
locale. Since the tup backend currently only supports en-US, we can just
hardcode this argument for now.
MozReview-Commit-ID: 7Js1yd9QB01
--HG--
extra : rebase_source : 387b5cfd0379ae3fd857e8c58722cfbca189e058
Bug 1256642 introduced magic at the emitter level to determine whether a
binary contains C++ sources and should be linked with the C compiler or
the C++ compiler.
Unfortunately, the Binary() moz.build template always adds C++ OS
libraries on Android (through STLPORT_LIBS), and C++ libraries on Linux
(stdc++compat).
The latter only ends up forcing every Binary() to be linked with the C++
linker, which is unfortunate, but doesn't cause much problems. The
former, however, involving OS libraries, the magic from bug 1256642
doesn't kick in, so we end up trying to link C++ OS libraries with the C
linker. Which ends up failing, because the libraries in STLPORT_LIBS
require -lm, which, while it's added by the C++ compiler when linking,
is not when the linkage is driven by the C compiler.
Because the fallible library, linked to all GeckoBinary()s is a C++
library, we still ended up linking with the C++ compiler on Android, so
this wasn't actually causing any problem... until I tried to remove that
fallible library in bug 1423803.
Anyways, the core problem is that moz.build evaluation is happening too
early to know whether any C++ sources are being linked together, so
there is no way the Binary() template can do the right thing. So this
change moves the logic to the emitter.
This also changes the type of STLPORT_LIBS to a list.
--HG--
extra : rebase_source : a70ddf7a132f94dc10e7e1db94ae80fb8d7a269f
Since bug 1421097, rust 1.22.0 is required to build, but
mozboot was still considering 1.21.0 sufficiently new.
bumpt the version there as well so `./mach bootstap`
will update to the required version.
MozReview-Commit-ID: moYo0KSsU
--HG--
extra : rebase_source : 900a962f5742b24ccd6ce3decc0242ff4fe36456
The process_define_files action uses the PartialConfigEnvironment to
query buildconfig values, but it should only be doing it for 'define'
and 'undef' statements. It was incorrectly also querying the
PartialConfigEnvironment with other preprocessor statements like 'if'
and 'include', which caused bogus entries to appear in the generated
dependency file.
MozReview-Commit-ID: IJptyXGluC7
--HG--
extra : rebase_source : a30aed7a37ec8d9c993cad22dc7f4bef1064edef
The name 'relativedir' is ambiguous - it is unclear whether it is a
relative srcdir or objdir. Rename it to 'relsrcdir' in the
ContextDerived() object to match the naming used in Context() so it is
obvious that it is a relative srcdir.
Most of these are a straight text replacement from relativedir to
relsrcdir, except for tup.py:_get_backend_file(), which was supposed to
be using an objdir in the first place.
MozReview-Commit-ID: 9eFHOCMofq5
--HG--
extra : rebase_source : bcd981953fcd72a8c049de02eca9cf31c04dff3c
exe_7z_archive.py runs during the MinGW build L10N check step, and
hardcodes 7z as the 7zip executable. This works on Windows, but not
Linux. We need to pass it the correct executable for 7zip, which is
located during configure.
However, repacks (repackage-winXX-nightly) don't do configure, and
don't have the tools to do configure. So we leave the default
command in the python script if one is not supplied.
MozReview-Commit-ID: B7GEKRYEJTD
--HG--
extra : rebase_source : 10ec7e688d53341625217306e88f2e647195ce8d
The script behind GENERATED_FILES currently opens output files in text mode,
which means that they wind up with CRLF line endings on Windows. With
switching updater.ini to use LOCALIZED_GENERATED_FILES, this means that it
will wind up with different line endings than it currently has.
Changing this to use binary format means that we'll have LF line endings
everywhere, which shouldn't harm anything on Windows as most of our generated
files are source files anyway.
MozReview-Commit-ID: 7rTUDtVGL82
--HG--
extra : rebase_source : 53a604c225477ad02e439b7b9ace587aefd0785a
The moz.build files that specify USE_YASM = True will get the value of
AS_DASH_C_FLAG and AS overwritten in PassthruVariables. We can save
those in the BackendTupfile and use them in place of the configure or
default settings as appropriate. This enables compilation of those .s
files that are built with yasm.
MozReview-Commit-ID: J66q8nKQ0an
--HG--
extra : rebase_source : 0ee97ef7a2122b42f1d21c473539a2e6352bd9ab
This accounts for LOCAL_INCLUDES in the moz.build files, as well as the
default INCLUDES specified in config.mk that are used for host
compilation. Since some of the HOST_CFLAGS were also used for linking,
those flags are split off into HOST_C{XX}_LDFLAGS so that
the linker-only flags can be placed in those variables.
MozReview-Commit-ID: J1LxIZVeFJ
--HG--
extra : rebase_source : ed7293604e5428e3124f1ecfb2b706e087436b72
