Bug 1365859 introduced a dependency on the Visual Studio binary 'fxc'
to generate Shader bytecode. This was unavailable when compiling for
Windows on Linux as part of a MinGW build.
This commit adds a configure check for fxc, and also searches for
fxc2, which was written (https://github.com/tomrittervg/fxc2) to be
a tiny application that wraps D3DCompileFromFile and can produce
similar (but not exactly the same) output as fxc.
fxc2 is compiled using MinGW for Windows, and runs under wine, so
we need to check for wine also.
Finally, fxc outputs some include information fxc2 doesn't, so
we will just change that assert to not take effect.
MozReview-Commit-ID: 8LVxuODi6cV
--HG--
extra : rebase_source : 39acca112f4cd9e6c39f7e47e7c55b13e7606824
The libclang test wants to find a libclang library for use for rust bindgen.
But that's a host process, that needs a host libclang. However, we
currently only have the target library/object prefix/suffixes. This
works fine... except when cross-compiling.
So we need to figure out the proper ones for the host, and use those
instead. For that, we templatize library_name_info in order to get a
separate set of library/object prefix/suffixes for the host and the
target.
And we use the host set for the libclang check.
Ideally, the build system would also use the host set for host tools
builds, but we'll leave that to a followup.
--HG--
extra : rebase_source : 1970791d6d5f9b3f79fbe34b7e3d05dd4b5c3f7b
We eventually want to templatize the library_name_info function, in
order to have one for host and one for target. So we don't want 3
different dependencies for the target.
--HG--
extra : rebase_source : cc980a5da9a35e71856ef970a58b2edcd05615c6
The function as it currently is matches how things were done in
old-configure.in. However, that's just confusing and hard to follow. In
fact, the unit test failing numerous times while writing this patch
pretty much highlights the problem.
So instead of a confusing set of overrides to the prefixes and suffixes,
spell out the whole set for each set of platforms. This also happens to
make the function shorter. Win/win.
At the same time, we normalize the function output as a nested
namespace, where we get, for each of dll, lib, import_lib, etc. a
prefix/suffix pair. Further down the road, we can imagine changing those
to class instances with a method allowing to format file names based on
those prefix/suffixes.
--HG--
extra : rebase_source : c18520d4df54feeea0a7f9588bc3cf8346793aaf
SO_VERSION has only an impact on those builds. Also set the default at
the option level, instead of doing that in the library_name_info
function.
--HG--
extra : rebase_source : 29aa61beeaede7d43daec599866094b91f2e7a82
This happen to uncover the fact that mingw clang was not handled
properly after bug 1372987. This will allow us to substantially modify
the function that handles them and avoid regressions.
--HG--
extra : rebase_source : 007257caecf7917480ef6b0a834c304768f77591
For parts of configuring Stylo, we need information about the library
extensions on all of our platforms, and this change is a reasonable way
to get at that information without duplicating it in two places. Plus
moving more things to moz.configure is more better.
This involves a few changes:
- Remove the .exe from the makensis binaries. which.which will
auto-add it so Windows will keep working - and with it
present we were finding makensis.exe on Linux and trying to
run it, which isn't going to work
- Doesn't bother checking if nsis is 32bit if we're running on
Linux
- Add the -nocd option to nsis (on Linux) because it takes the
current working directory from the target of a symlink rather
than the symlink itself. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704828
MozReview-Commit-ID: CVT8LwS1t8w
--HG--
extra : rebase_source : 2a62327326ba80dfd728048d19f0ff1c90100838
For people working on Rust code, compiling in debug mode (Cargo's "dev"
profile) is convenient: debug assertions are turned on, optimization is
turned off, and parallel compilation inside of rustc itself can be
used. These things make the build faster and the debugging experience
more pleasant.
To obtain that currently, one needs to --enable-debug at the Gecko
toplevel, which turns on debug assertions for the entire browser, which
makes things run unreasonably slowly. So it would be desirable to be
able to turn *off* debug mode for the entirety of the browser, but turn
on debug mode for the Rust code only.
Hence this added switch, --enable-rust-debug, which does what it
suggests and defaults to the value of --enable-debug. For our own
sanity and because we judge it a non-existent use case, we do not
support --enable-debug --disable-rust-debug.
CLOSED TREE
Backed out changeset 158233bce738 (bug 1197325)
Backed out changeset b5ac3fa0bbe7 (bug 1197325)
Backed out changeset 55a8ad127517 (bug 1197325)
It is unfortunately not possible to include it last (or close to last,
before old.configure), but at least putting it after toolchain related
includes will be helpful.
--HG--
extra : rebase_source : bd027a87bc350c60dc1ba3308e2cc3b10782b506
This patch introduces a small change in behavior: we now unconditionally
require libffi > 3.0.9 when using system ffi, rather than accepting 3.0.9
when using GCC, as 3.0.10 was released 5 years ago, and should be widely
available.
MozReview-Commit-ID: DtSDPoZSPcx
This patch introduces a small change in behavior: we now unconditionally
require libffi > 3.0.9 when using system ffi, rather than accepting 3.0.9
when using GCC, as 3.0.10 was released 5 years ago, and should be widely
available.
MozReview-Commit-ID: DtSDPoZSPcx
This required implementing a utility function to resolve the binary
type. I used GetBinaryTypeW via ctypes because this seems the fastest.
I arbitrarily limited the function to testing 32-bit and 64-bit Windows
executables because hopefully those are the only executables we'll
ever encounter. We can expand the binary detection later, if needed.
This includes support for running on non-Windows platforms.
MozReview-Commit-ID: CYwyDWQrePc
--HG--
extra : rebase_source : 8fd7ca7f253d9e9e18d64784652a5ff934ad2272
Previously, configure found nsis on PATH, likely from MozillaBuild.
In our msys2 environment, nsis is installed under /mingw32. We
supplement moz.configure to look for nsis in this location.
MozReview-Commit-ID: 34mjoCrI7B6
--HG--
extra : rebase_source : fb50bb8870a7c3646424e69633cf83147c0f9fa7
Nothing is using MAKE in old-configure, and it was not AC_SUBST'ed, so
we don't need to set it when it's not set in the environment already.
--HG--
extra : rebase_source : 9a525517808db87add72989ab9f43a135c0cc776
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
Setting MOZ_DEBUG_SYMBOLS as a define was not moved, as this value is not
checked, and exporting MOZ_DEBUG_SYMBOLS was not moved, as this would only
impact nspr, and we're no longer using the nspr build system.
MozReview-Commit-ID: EvBTunhxcsr
--enable-build-backend was taking a list of additional backends to add
to the defaults. Changes to allow to disable some of the defaults is not
possible in a straightforward way, so introduce a new
--build-backends option that sets the exact set of wanted backends,
but also allows to add and remove from the defaults with + or -.
--build-backends=+CompileDB is equivalent to
--enable-build-backend=CompileDB.
--build-backends=-VisualStudio disables the VS backend when it's
automatically enabled.
Now that the VisualStudio backend will no-op if nothing has changed, it
should be safe to always run this backend.
On first run, backend generation takes ~3.5s on my machine. On subsequent run,
it takes ~1.5s. Wall time for a no-op config.status is now ~15.7s. We could like
make the Visual Studio backend faster by not writing so many project files.
But this would require consolidating libraries in moz.build files. And that's
out of scope for this change.
We drop the check for MSVS_VERSION because it won't always be defined on
MinGW/GCC builds. We simply default to "2015" if it isn't set.
MozReview-Commit-ID: 5W38HMGmcuV
--HG--
extra : rebase_source : 302d76277058819c115f3c2518b8cb2067971950
extra : source : 408319d87eacb28848efeab0346eb815440adade
Now that the VisualStudio backend will no-op if nothing has changed, it
should be safe to always run this backend.
On first run, backend generation takes ~3.5s on my machine. On subsequent run,
it takes ~1.5s. Wall time for a no-op config.status is now ~15.7s. We could like
make the Visual Studio backend faster by not writing so many project files.
But this would require consolidating libraries in moz.build files. And that's
out of scope for this change.
MozReview-Commit-ID: 5W38HMGmcuV
--HG--
extra : rebase_source : 1164621e00e2b917b5462d5ba310e0cc94d23bd9
At the same time, allow to enable jemalloc 4 with --enable-jemalloc=4.
MOZ_JEMALLOC4 will be deprecated later.
This also changes the semantics for freebsd, where the system jemalloc
is used, relying on MOZ_MEMORY being unset (default on freebsd) and
MOZ_JEMALLOC4 to be set. In this new setup, MOZ_JEMALLOC4 implies
--enable-jemalloc=4, which still works because of the corresponding
changes to old-configure.
While forgetting about it was warned about, having to add every new
environment option to wanted_mozconfig_variables is cumbersome. It turns
out there is a hackish way to make things work without that list, which,
all things considered, is not worse than the hacks around the
wanted_mozconfig_variables function, and are certainly an improvement as
it doesn't require an ever growing list of environment options.
For the same reasons as set_config is being moved to the global scope,
we're moving set_define to the global scope here. An additional change
is that set_define is now part of the sandbox itself instead of being
defined within the sandbox, which makes it share the implementation
details with set_config.
The way set_config is set currently makes it difficult to introspect
moz.configure files to know what configuration items are being set,
because they're hidden in the control flow of functions.
This makes some of the moz.configure more convoluted, but this is why
there are templates, and we can improve the recurring cases afterwards.
This change adds a `Version` type to moz.configure which is a small
wrapper around `distutils.version.Version`. It's suitable for wrapping
version numbers in configure checks and doing equality or greater-than
less-than comparisons in a sensible way.
MozReview-Commit-ID: BOL6yvemulG
--HG--
extra : rebase_source : 3b463eac0499086f8acffda0d01418b6ab17f3d6
extra : amend_source : aebd6e40c408d9f868623b2f53fcdf7455e2fff5
This aligns with the triplets used by clang/llvm. Technically, this
won't break iOS builds still using -darwin triplets until we move
MOZ_IOS_SDK to moz.configure and actively reject non iOS targets with
the iOS sdk.
Also allow to distinguish iOS and OSX with target.os.
Because --enable-application is the current way to do things, transpose
it to configure.py, but since --enable-application=js doesn't make
sense, make it an alias of a new --enable-project option.
This only partially moves --enable-application out of old-configure.in
because there are a lot of other things intertwined with it.
This moves all the reading mozconfig, finding autoconf, refreshing the
old configure, and running the old configure into sandboxed
moz.configure. This effectively bootstraps the sandboxed python configure.
Tom Ritter
Mike Hommey
Nathan Froyd
Ryan VanderMeulen
Chris Manchester
Justin Wood
Phil Ringnalda
Sebastian Hengst
Carsten "Tomcat" Book
Mike Shal
Gregory Szorc
Nathan Hakkakzadeh
Tom Tromey
Wes Kocher
Ms2ger
Ted Mielczarek