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.
We only had this "for flexibility with other platforms", but given that
we set it to the same thing for all platforms, and nobody has tried to
change that, this flexibility isn't actually needed.
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
Back when mozalloc was a separate library, the xpcom glue code could not
use the infallible allocator API. But since bug 868814, that's not the
case anymore, so we can safely include mozalloc.h when XPCOM_GLUE is
set.
--HG--
extra : rebase_source : a8fbf8dc7020765d7287e2eb7ceaf41c99be8b18
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
These flags were added way back in bug 59454 to both the compiling and
linking rules for HOST_SIMPLE_PROGRAMS. However, the INCLUDES aren't
actually needed when linking so we can safely remove them.
MozReview-Commit-ID: 8QywO7tGPpU
--HG--
extra : rebase_source : 34870adcf73b459771413e52bc84c6c63669d0f9
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
These have been replaced by stl-headers.mozbuild and
system-headers.mozbuild
MozReview-Commit-ID: EpPasSzgiJk
--HG--
extra : source : 86302df0b38a05ce8f6f830e324631a42c1c643e
The make-system-wrappers.py invocation is largely identical to
make-stl-wrappers.py, though this script generates wrappers for both the
STL headers and every other system header that can be used.
Note that the nsprpub script didn't create multiple layers of
subdirectories properly, so for example the 'ia64/sys/inline.h' wrapper
is now generated properly. Additionally, MOZ_SYSTEM_ICU define was
incorrectly using '#ifdef' instead of '#if ... == 1', which causes those
unicode headers to have wrappers when they shouldn't. These will show up
as differences when comparing the Makefile output to the moz.build
output.
MozReview-Commit-ID: KvQAawfzXao
--HG--
extra : source : 5a967cc85e28e63c283a81e2c76444a76dfbd266
This is fairly straightforward to represent as a GENERATED_FILES, though
we have to take some care to construct the outputs tuple correctly. This
script needs to run during export, and unfortunately none of the STL
headers have proper file extensions, so the 'new' header is
special-cased in the recursive make backend to serve as a marker for
running it in the correct tier.
We can't remove the stl-headers file yet because it is still used for
the system header generation.
MozReview-Commit-ID: 3tQTOY0LAsQ
--HG--
extra : source : 828d43ec1b16edaac69c42f15561f26e209051f1
These don't actually install correctly, because 'private' is already a
system wrapper. Neither of these files are included anywhere, so there's
no harm in removing them.
MozReview-Commit-ID: 1IAFMZDvKDV
--HG--
extra : source : 8d770908a5b9a3421294c93f8a34a14265674e9b
This is no longer used in the tree, and the $ will get eaten somewhere
along the way on the path from moz.build to the python invocation by
make despite being shell_quoted.
MozReview-Commit-ID: 5mwWQYDn8Nf
--HG--
extra : source : ffe9aed0944f57e329ee279f5b14266d5c4069a2
These have been replaced by stl-headers.mozbuild and
system-headers.mozbuild
MozReview-Commit-ID: EpPasSzgiJk
--HG--
extra : rebase_source : 33bc7a5a8de794f882bd1438ac800da2150a2ce6
The make-system-wrappers.py invocation is largely identical to
make-stl-wrappers.py, though this script generates wrappers for both the
STL headers and every other system header that can be used.
Note that the nsprpub script didn't create multiple layers of
subdirectories properly, so for example the 'ia64/sys/inline.h' wrapper
is now generated properly. Additionally, MOZ_SYSTEM_ICU define was
incorrectly using '#ifdef' instead of '#if ... == 1', which causes those
unicode headers to have wrappers when they shouldn't. These will show up
as differences when comparing the Makefile output to the moz.build
output.
MozReview-Commit-ID: KvQAawfzXao
--HG--
extra : rebase_source : 758e325c6ec192d83fcfa10f8c878ba2629e45a3
This is fairly straightforward to represent as a GENERATED_FILES, though
we have to take some care to construct the outputs tuple correctly. This
script needs to run during export, and unfortunately none of the STL
headers have proper file extensions, so the 'new' header is
special-cased in the recursive make backend to serve as a marker for
running it in the correct tier.
We can't remove the stl-headers file yet because it is still used for
the system header generation.
MozReview-Commit-ID: 3tQTOY0LAsQ
--HG--
extra : rebase_source : bd9f00e45a7bce4daaa0e1c16e22b28536658e37
These don't actually install correctly, because 'private' is already a
system wrapper. Neither of these files are included anywhere, so there's
no harm in removing them.
MozReview-Commit-ID: 1IAFMZDvKDV
--HG--
extra : rebase_source : 6e153324d2add32a179d07020270db96e7ec6dd0
This is no longer used in the tree, and the $ will get eaten somewhere
along the way on the path from moz.build to the python invocation by
make despite being shell_quoted.
MozReview-Commit-ID: 5mwWQYDn8Nf
--HG--
extra : rebase_source : f2289f5f5e15529475cac6cba3fc675592c111f2
These are only set by nss' make build system, which we no longer use.
MozReview-Commit-ID: 9XRhpDmlekK
--HG--
extra : rebase_source : 5bff741863a463eca7d72f4e23c1c78e04a848de
The make backend is the only thing that is aware of PROGILE_GEN and
PROFILE_USE, so we move these ldflags to their own variable while
converting the remainder of ldflags to mozbuild.
MozReview-Commit-ID: GwbPD6Q4Oyn
--HG--
extra : rebase_source : 3c90def9ee8cd949dd135ba8fa9b192f114f6727
These flags are only relevant on OS X, and will not be necessary soon, so this
commit moves them to a separate variable while we move the remainder of the
ldflags to mozbuild.
MozReview-Commit-ID: 1NDgz3HIYpT
--HG--
extra : rebase_source : 6e9b5f5a5be5ff916db89a0b73896b9058eb040e
These targets no longer exist in client.mk. I'm not sure when they
were removed. But this is obviously dead code.
A target in rules.mk pointing back to this target in client.mk has
also been removed.
MozReview-Commit-ID: 5v1MOOTP3qq
--HG--
extra : rebase_source : b90f0788b074330b45005223f41c804589d13163
Currently mozconfig.cache overrides a few build options for sccache. This
patch moves them into toolchain.configure so that the build system will
set them properly when sccache is in use. Additionally, {CC,CXX}_WRAPPER
are set in config.mk, so just avoid setting them when sccache is in use.
MozReview-Commit-ID: FYlVKRI8OiN
--HG--
extra : rebase_source : 00715beb5fbd2c11311dec43809bd1febab56a11
extra : intermediate-source : 0f2b1b75b83737378d882a3c3e0d8dfb4efecd1f
extra : source : a8032ae9cb2ad1c4574c6ac6f5c2778863cd71e0
This also introduces C{XX}_LDFLAGS variables which contain cflags that
are meant to be passed to the linker, and adds them to various linker
command lines in place of CFLAGS.
MozReview-Commit-ID: GyKlD9nMqrt
This commit establishes a separate variable to add PROFILE_GEN and PROFILE_USE
CFLAGS to compile and link command lines. Currently the make backend
orchestrates the pgo build steps and is the only thing aware of whether
we're in the profile generate or profile use stage. The flags are separated
here to allow other flags to be moved to mozbuild, but this will not yet
sufficient to perform a PGO build independent of the make backend.
MozReview-Commit-ID: IX30l2MvvNc
Before this commit, RUSTFLAGS was derived in rules.mk by consulting
various variables set by configure. It isn't clear to me why things
are implemented this way. We don't appear to have moz.build level
overrides for Rust compiler flags. So there doesn't appear to be a
compelling reason why we can't derive these values in configure.
So, this commit ports the code for deriving default RUSTFLAGS from
rules.mk to toolchain.configure.
The port is pretty straightforward as far as the logic goes.
MozReview-Commit-ID: JhAE9Qlo8SK
--HG--
extra : rebase_source : 6186cb81cd37c516b3d645419b9461bf501d6ba2
libffi has assembly files on Windows that need to be preprocessed. Previously
this was handled by using a wrapper shell script as the assembler. This
patch handles them in GENERATED_FILES with a Python script that performs
an equivalent transformation.
MozReview-Commit-ID: 3w0HNpUb8TA
--HG--
extra : rebase_source : 284a3825cdaf2957507d60276a772f88f8c96488
extra : source : 3f422cbd4f222bc0b19f0a9e76878787652b3788
I *think* the modifications to MockedOpen are correct, but I'm not sure..
MozReview-Commit-ID: 6vTZBtdQ1dz
--HG--
extra : rebase_source : 2d2008f87640747ef831d000bf13a4b1b7fcd338
config/string-format.js was made obsolete in the removals in bug 1227388.
MozReview-Commit-ID: 1nQwlKhoC0e
--HG--
extra : rebase_source : 6b06e4d7ca2e8fc66fc2d93ade54c813d975acec
DEFFILE is currently just used as a passthrough variable. All but one of
the current uses of it use `SRCDIR + '/file.def'` to get a srcdir-relative
path anyway, and the other one wants an objdir-relative path, so using
Path makes everything clearer.
This makes it more straightforward to translate the paths for the WSL
build.
MozReview-Commit-ID: IRokABaZW2c
--HG--
extra : rebase_source : ae74c984bb2aab70211dc5974a8b052651e025dd
Incremental linking is automatically disabled when -OPT:REF or -OPT:ICF are used.
Seeing that we're disabling optimizations anyway, may as well not use those linker flags as they considerably slow down linking.
MozReview-Commit-ID: 9OXG19uxeI9
--HG--
extra : rebase_source : 4703bc4bb62af3f054ca621be7c1c51fe56cb2f3
And convert consumers to context managers because hglib requires that.
MozReview-Commit-ID: Ckf1yBYeUlm
--HG--
extra : rebase_source : 985220032bced1a7077fd9b04ca8ad6de822c887
This makes sure that:
* We don't define `MOZ_GLUE_IN_PROGRAM` so that everything in mozglue gets
defined.
* `MFBT_API`'s symbol export rules match `JS_PUBLIC_API` and `EXPORT_JS_API`.
* We add mozglue to SpiderMonkey's `USE_LIBS` when jemalloc is disabled.
This switches most tests over to use pytest as the runner instead of unittest (taking
advantage of the fact that pytest can run unittest based tests).
There were a couple tests that had failures when swithing to pytest:
config/tests/unit-expandlibs.py
xpcom/idl-parser/xpidl/runtests.py
For these tests, I added a runwith='unittest' argument so that they still run the
same way as before. Once we fix them to use pytest, the unittest logic in mozunit.py
can be deleted.
MozReview-Commit-ID: Gcsz6z8MeOi
--HG--
extra : rebase_source : 3c762422ce0af54cbbe7d9fc20085a2d1ebe7057
Similar to the existing LIB_IS_C_ONLY variable, these variables indicate
that the program in question has only C sources and so can be linked by
the C compiler rather than the C++ compiler. We need to add a little
more information to BaseProgram so we can avoid emitting periods into
Makefile variables.
As we move our compile command lines into mozbuild we want to stop using DEFINES
directly. This patch adds a variable that can be set from Makefiles to contribute
defines to a compile command line to help the transition.
MozReview-Commit-ID: 5xLB06pzpJY
--HG--
extra : rebase_source : 7ca0b9d8f5a77ec55eb751f75f58a69e64efb21d
libevent uses event.h header that is fuzzy name. Since our in-tree libevent is libevent2, we should use libevent2 headers instead of deprecated event.h
MozReview-Commit-ID: 6DjW9JEkNWL
--HG--
extra : rebase_source : b774e177b137bf7427122253a3e4c698689e08a4
To not merge the en-US language pack, the merge-% steps are in
a conditional function that disables that for en-US. Using a function
here as that's easier than a shell if in the merge rule, and
Makefile conditionals don't get evaluated late enough.
To liberate the l10n builds from settings in the automation,
we move the patch logic from LOCALE_MERGEDIR to REAL_LOCALE_MERGEDIR.
To determine strongly when we're in a repack or building a langpack,
the trick here is to
export IS_LANGUAGE_REPACK
in l10n.mk, and only set that to true in the entry-point rules.
Now, we can use that value in config.mk to define the l10n-specific
rules.
I did the same thing for langpack-%, which allows us to disable
the crashreporter files for language packs, for example.
With that,
make installers-de
just works, if you have localizations checked out.
For a while, we might run l10n-merge twice in automation, but it's really not
optional, so let's just make sure we run it.
MozReview-Commit-ID: 3nr33CKxkBQ
--HG--
extra : rebase_source : 0605a4adba018fa4b85d563cdafba80b0533bc91
cargo 1.19, and later cargo 1.20/rustc 1.19 gained support for the make
jobserver. But that doesn't work unless make passes the jobserver file
descriptors down to subprocesses, which it only does when there is a +
prefixing commands.
--HG--
extra : rebase_source : a00ffb7edb358243ac7b9469941ec6fb5ad84885
This is similar to bug 1301751, where something in rust seems to trigger errors
running dsymutil to generate debug symbols in OSX. We can set debuginfo=1 for
these builds as a temporary workaround for now, while we work on a more
permanent solution in rust and/or dsymutil. debuginfo=1 still gives us enough
info for stack traces, although without line info. debuginfo=2 would be useful
for debugging, but is irrelevant to crash reports.
MozReview-Commit-ID: DdA00GzVfWg
--HG--
extra : amend_source : 47d3573042098194a07f9b473e4a02c86a1eba7c
MOZ_REPLACE_MALLOC_LINKAGE was added back when there were problems with
getting weak references working properly for replace-malloc.
Versions of OSX < 10.6 needed flat namespace, but aren't supported
anymore.
Versions of Xcode < 4.5 required flat namespace + a dummy library in
order to produce proper weak references. There is virtually nobody still
building with such an ancient toolchain.
Keeping those around doesn't /really/ hurt, except recent versions of
Xcode don't expose dyldinfo in /usr/bin, used for the configure test.
Consequently, MOZ_REPLACE_MALLOC_LINKAGE ended up being set to use the
dummy library setup, which, by using flat namespace, now causes harm in
bug 1356701, causing bug 1378332.
--HG--
extra : rebase_source : e3edc1f2cf905943c33fafeb631f2f88fc87167e
Cargo recently introduced the `cargo check` command for shortening the
edit-compile cycle when working on large programs. Since we don't
really support invoking `cargo` directly, let's wire up this command to
`mach`. Gecko developers can then `mach cargo check` to ensure their
changes typecheck.
All the machinery we set up for `cargo build` is equally useful for
other commands, such as `cargo check`. Let's refactor things so that
it's easy to reuse said machinery for `cargo check`.
We currently only honor LIB_IS_C_ONLY for cases where we set a
LIBRARY (and, implicitly, REAL_LIBRARY) and FORCE_SHARED_LIB. For many
libraries, such as the libraries from NSS, we never set LIBRARY, which
leads to not setting REAL_LIBRARY, which leads to not honoring
LIB_IS_C_ONLY. This practice has not been harmful thus far (except
perhaps linking in more things than necessary to our NSS shared
libraries), but on some platforms, linking with the C++ compiler will
drag in more things than we would like.
Consulting LIBRARY first should not be necessary; checking
FORCE_SHARED_LIB should be enough to tell us if we're building a shared
library for the purposes of honoring LIB_IS_C_ONLY.
We can avoid the symbol visibility problem by putting
sanitizer/asan_interface.h in the config/system-headers.
--HG--
extra : rebase_source : bc81a81ef8970c3544febf06631740208583c7fa
Stable Rust currently has logic similar to the following for finding the
linker on Windows:
if VCINSTALLDIR in os.env:
search for things in PATH
if found, return, otherwise fallthrough
look for MSVC installations of various kinds
For our current MozillaBuild setup where we clear out PATH prior to
invoking Cargo, this works: even though VCINSTALLDIR is set and we
(unsuccessfully) search through an empty PATH, we'll still fallback to
looking for MSVC installations.
Beta Rust has altered this search strategy:
if VCINSTALLDIR in os.env:
search for things in PATH
return the result of the search, regardless of success
look for MSVC installations of various kinds
Note that in the above logic, if VCINSTALLDIR is set, we are only going
to try looking in PATH for an appropriate linker. Since PATH is empty
in our current MozillaBuild setup, beta Rust will therefore fail to find
the correct linker. This failure causes numerous problems.
Since Firefox is already trying to "clean" the environment that Cargo is
invoked in, we should work a little bit harder by unsetting VCINSTALLDIR
entirely, and simply force Rust to search for known MSVC installations.
Making this change makes stable and beta Rust behave identically.
(We don't have to worry about this distinction in automation, because
the "cleaning" code is only activated when we detect a MozillaBuild
shell.)