This patch disables the stdcxx-compat check for the sm-fuzzing build which
requires patching autospider as well. Furthermore, it switches the build
to linux64-clang-6-pre because the older clang 3.9 does not support trace-pc
instrumentation. Finally, it excludes fuzzing parts from the vanilla allocation
check.
MozReview-Commit-ID: FdhCIFdUore
--HG--
extra : rebase_source : c41bda01cb42f2ef0cd5a1675d88bdb55d9dc8c9
The MSVC linker winds up generating import libraries when linking some of
our executables, presumably because they contain functions that are
__declspec(dllexport). By default the import libraries get written
alongside the exe, so we force them to be written to the objdir so they don't
clutter up dist/bin.
MozReview-Commit-ID: 7DTfCo3OdDQ
--HG--
extra : rebase_source : fea69e8f60633b824726269c2296af9fe812d3ed
Historically we built all our binaries in directories in the objdir, then
symlinked them into dist/bin. Some binaries needed to be copied instead
so that certain relative path lookups work properly, so we resorted to
sprinkling `NSDISTMODE=copy` around Makefiles.
This change makes it so we build PROGRAMs (not any other sort of targets)
directly in dist/bin instead. We could do the same for our other targets
with a little more work.
There were several places in the tree that were copying built binaries to
some other place and needed fixup to match the new location of binaries.
On Windows pdb files are left in the objdir where the program was
originally linked. symbolstore.py needs to locate the pdb file both to
determine whether it should dump symbols for a binary and also to copy
the pdb file into the symbol package. We fix this by simply looking for
the pdb file in the current working directory if it isn't present next
to the binary, which matches how we invoke symbolstore.py.
MozReview-Commit-ID: 8TOD1uTXD5e
--HG--
extra : rebase_source : 9140be949b206bb595d9188ce7e8357347ecd9a9
Work around excessive command-line length issues by
disabling incremental rust compilation, which is enabled
by default outside `cargo --release` starting with Rust 1.24.
Incremental rust builds shouldn't help much in automation,
where sccache provides the only continuity between build
environments. In the meantime, they add a lot of object
files to the link line.
See https://github.com/rust-lang/rust/pull/47507 about addressing
the underlying issue upstream.
MozReview-Commit-ID: LRwUj3fhiaO
--HG--
extra : rebase_source : 1739a7570b2e7fe40ead3b301ea20c2fe79f0431
The pytest cache plugin writes its cache in the srcdir, which means that it
shows up in `hg status`, which is annoying. Writing files to the srcdir is
generally bad practice anyway, so we disable this plugin to stop this
from happening.
MozReview-Commit-ID: HytLLMUtKlc
--HG--
extra : rebase_source : f6acbf3650881312cef051126387220a0f78597f
Back when I filed this bug, $appname-$version was already useless, but
there actually were multiple supported versions (e.g. 3.5/3.6). So it
made sense to have e.g. firefox-3.5 and firefox-3.6, but not
firefox-3.5.12 and firefox-3.5.13.
Fast forward 10 years, and we change "major" versions every 6 to 8
weeks, have multiple chemspills every other week, and installing to
firefox-57.0, firefox-57.0.1, firefox-57.0.2, firefox-57.0.3 doesn't
make any kind of sense. Even firefox-56, firefox-57 is pretty much
useless.
There /kind/ of was some usefulness to the version in the SDK
directories, but those are gone.
I'm pretty sure no downstream is actually using versioned directories
anyways.
At this point, it seems better to just use the application name, without
the version. A case could be made about ESR, but that would be better
handled with a separate application name (e.g. firefox-esr).
--HG--
extra : rebase_source : 333e10ea1316714bf0008ec772b35093edfc45ff
Some of the variants are multi-platforms, and having
--enable-stdcxx-compat in their definition will break when the option is
moved over to python configure.
While here, prepare for --enable-stdcxx-compat actually doing something
(it currently doesn't), by adding an exception for it in
check_vanilla_allocations.py.
--HG--
extra : rebase_source : ee1647421542209cf0137db703c4f7e7f06cbc91
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
Christian Holler
Gurzau Raul
Ted Mielczarek
Simon Fraser
Ralph Giles
Csoregi Natalia
Sylvestre Ledru
Dragana Damjanovic
André Bargull
Tom Prince
Mike Hommey
David Major
Ting-Yu Chou
Nathan Froyd
Andreea Pavel
Mike Shal
Alfredo.Yang
Brindusan Cristian
Chris Manchester
Ryan VanderMeulen
Phil Ringnalda
Sebastian Hengst
Jonathan Watt
Narcis Beleuzu
Randall Barker
Jon Coppeard
Masatoshi Kimura
Gregory Szorc
Dragana Damjanovic dd.mozilla@gmail.com
Jan Beich
Dustin J. Mitchell
Gian-Carlo Pascutto
Zibi Braniecki
Robert Helmer
Mark Banner
Henri Sivonen
Wes Kocher
ffxbld
Jean-Yves Avenard
Nick Fitzgerald
Petr Sumbera
Andrew Halberstadt
Eric Rahm
Matt Brubeck
Kartikaya Gupta
Makoto Kato
Axel Hecht
Robert Strong