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
The filenames that these objects generate are passed into the _handle_*
methods instead of with a Sources object, so they need to be added to
the BackendTupfile's list of sources separately.
MozReview-Commit-ID: GoqhiJ3Ismm
--HG--
extra : rebase_source : 60e53c2c28a93c543a99bff0463b2935b2826e09
Both SFLAGS and ASFLAGS are used to compile assembly, but SFLAGS include
DEFINES and LOCAL_INCLUDES whereas ASFLAGS do not. It seems easiest to
just separate them into two different ComputedFlags values so that the
backend can distinguish between the two types.
MozReview-Commit-ID: Bkm3621ImJG
--HG--
extra : rebase_source : 420204e37d591512f700d77b780939d20c2feeb0
In most cases, relobjdir is the same as relativedir. However they are
different for some objects, notably with nss gyp handling. We need to
output files in relobjdir, so use that when getting the BackendTupfile.
This puts generated files like certdata.c in the directory that
moz.build is expecting.
MozReview-Commit-ID: DG29OulOKAz
--HG--
extra : rebase_source : 76dbaeb92fb4112b664768653548caf57242d90d
The srcdir does not necessarily directly correspond to the objdir, so it
doesn't make sense to tie them together in BackendTupfile. Since the
srcdir was only used for the IPDL sources, we can just replace that
usage with a local variable.
MozReview-Commit-ID: By0N30VTKhh
--HG--
extra : rebase_source : 5cc35da4fadcc53132d459173bcc29ac5b0a57bc
This change makes the recursive make backend emit slightly different rules
when handling LOCALIZED_GENERATED_FILES vs. GENERATED_FILES.
First, localized file generation is always done in the libs tier.
Second, inputs are allowed to be locale-dependent, which is determined by
the path starting with `en-US/`. These inputs will be run through MERGE_FILE
to determine the actual file path to pass to the script.
Third, the file_generate action now accepts a `--locale` option, and it
gets passed the value of `$(AB_CD)` when generating localized files. If this
option is passed it is also passed as a keyword argument `locale` to the
generation function.
Fourth, the make rules for localized files include an additional dependency
on FORCE when running l10n repacks, so that the targets will always be
rebuilt in that situation.
MozReview-Commit-ID: BfgR8MxxJXZ
--HG--
rename : python/mozbuild/mozbuild/test/backend/data/generated-files/foo-data => python/mozbuild/mozbuild/test/backend/data/localized-generated-files/foo-data
rename : python/mozbuild/mozbuild/test/backend/data/generated-files/generate-foo.py => python/mozbuild/mozbuild/test/backend/data/localized-generated-files/generate-foo.py
rename : python/mozbuild/mozbuild/test/backend/data/generated-files/moz.build => python/mozbuild/mozbuild/test/backend/data/localized-generated-files/moz.build
extra : rebase_source : 1d123afbad4f3d949a2f13f1685f30b1e3069e97
LOCALIZED_FILES and LOCALIZED_GENERATED_FILES are analogs of FINAL_TARGET_FILES
and GENERATED_FILES, but they receive special handling in the recursive
make backend so that l10n repacks work properly. To this end, we support
using the output of LOCALIZED_GENERATED_FILES in LOCALIZED_FILES, but not
mixing localized with non-localized targets.
MozReview-Commit-ID: GCJAUfUG8OZ
--HG--
rename : python/mozbuild/mozbuild/test/frontend/data/localized-generated-files/moz.build => python/mozbuild/mozbuild/test/frontend/data/localized-files-from-generated/moz.build
rename : python/mozbuild/mozbuild/test/frontend/data/localized-generated-files/moz.build => python/mozbuild/mozbuild/test/frontend/data/localized-files-not-localized-generated/moz.build
extra : rebase_source : c67f87782a5992734948da79c0cdbe64e23ed437
This change adds LOCALIZED_GENERATED_FILES, which emits GeneratedFile objects
just like GENERATED_FILES. It also adds a `localized` field to GeneratedFile
which will be `True` for objects emitted from LOCALIZED_GENERATED_FILES.
MozReview-Commit-ID: 3iWGLMkbF2C
--HG--
rename : python/mozbuild/mozbuild/test/frontend/data/generated-files/moz.build => python/mozbuild/mozbuild/test/frontend/data/localized-generated-files/moz.build
extra : rebase_source : 36446da5d367925655e7adfa3e4133be843f99d3
This makes it a bit easier to share with other parts of the tree,
like test and linting.
MozReview-Commit-ID: 8Gzk8uOF5zK
--HG--
extra : rebase_source : 9354614c78481ca4cbe0327501018a95792e9351
This is a new module that will provide a place to store some common
abstractions around the 'blessings' module. The main entrypoint is:
from mozterm import Terminal
term = Terminal()
If blessings is available, this will return a blessings.Terminal()
object. If it isn't available, or something went wrong on import,
this will return a NullTerminal() object, which is a drop-in
replacement that does no formatting.
MozReview-Commit-ID: 6c63svm4tM5
--HG--
extra : rebase_source : 9ab221774d92a418d9b098d79bb2c88f75d937f8
- aarch64 has GNU-free toolchain thus /usr/bin/as is N/A by default
but GNU as is required to build bundled ICU.
- Downstream Python splits sqlite3 C module into a separate package
to reduce optional dependencies but _sqlite3 is used by mozprofile.
MozReview-Commit-ID: Lh2ktcqh16f
--HG--
extra : rebase_source : bbcbe437132ecfce0f3e6e7b2005d0e8eac65836
I believe all backends will need to know which GeneratedFiles are needed
before compilation can start, so we should make that an attribute of the
object. Each backend can then make its own decision about what to do
with the different types of GeneratedFiles.
MozReview-Commit-ID: ByburRx540b
--HG--
extra : rebase_source : ccfee5b569da432cb61882f2f6ea518f1ccbfa07
This makes things slightly more inconvenient (having to set two
environment variables instead of one for the simplest case) until a few
patches down the line, when DMD is statically linked, at which point it
will get down to one environment variable every time.
--HG--
extra : rebase_source : 08dc3c05318b572ae1026227d0369fa8bf21b20f
Andreea Pavel
Mike Hommey
Csoregi Natalia
Ted Mielczarek
Mike Shal
Chris Manchester
Cosmin Sabou
Nathan Froyd
Marco Castelluccio
Daniel Holbert
Ralph Giles
Tom Ritter
Emilio Cobos Álvarez
Masatoshi Kimura
Narcis Beleuzu
Seinlin
Andrew Halberstadt
Jan Beich