We're planning on switching to IR-based profiling, so we can't use the
frontend-based instrumentation to collect the order in which functions
are executed...at least not during the build itself. Performance tests
indicate that not having the order information decreases performance
significantly. So we're going to check in static files for Win32 and
Win64 and use those to perform the ordering. It's OK if these files are
slightly out of date; as of this writing, builds that generate and then
use these files complain that ~1/3 of the functions can't be found (!).
We're just trying to do something slightly smarter than whatever the
linker default is.
Differential Revision: https://phabricator.services.mozilla.com/D31132
--HG--
extra : moz-landing-system : lando
Now that everything is lined up nicely, we don't need those anymore.
We can fill cargo-linker.bat with HOST_LINKER and HOST_LINKER_LIBPATHS,
which, unfortunately, can't be used as is, so we add a variant for
substitution in .bat files.
Differential Revision: https://phabricator.services.mozilla.com/D18034
--HG--
extra : moz-landing-system : lando
Now that it's automatically derived and that in-tree mozconfigs are
setting DIA_SDK_PATH, we don't need to set WIN_DIA_SDK_BIN_DIR on
automation, or elsewhere, for that matter.
Differential Revision: https://phabricator.services.mozilla.com/D17915
--HG--
extra : moz-landing-system : lando
And remove all the variables that configure will figure out for us as a
consequence. This has the side effect of making the automation builds a
little more like local builds, in that they don't rely on preset PATH,
LIB, etc. for the build to work.
Differential Revision: https://phabricator.services.mozilla.com/D17789
--HG--
extra : moz-landing-system : lando
It turns out, we don't need to `mk_add_options export` the variables
from the in-tree mozconfigs. If anything, that causes problems when
trying to simplify the mozconfigs, because it makes the variables
exported from .mozconfig.mk, overriding what configure may change and
store in autoconf.mk.
All the variables are handled by configure in a way that makes them
available in autoconf.mk, so there's no loss there, and with the
python/shell-based mozconfig loader, it turns out we don't need to go
through extra normalization via cmd.
autospider.py, being its own pseudo-mozconfig parser, still does need
it, though, but it was hooking into it already, so just inline that.
Differential Revision: https://phabricator.services.mozilla.com/D17769
--HG--
extra : moz-landing-system : lando
This happens to remove the last use of perl from configure.
Depends on D16621
Differential Revision: https://phabricator.services.mozilla.com/D16622
--HG--
extra : moz-landing-system : lando
This also requires the 64-bits rust compiler and some build system
tweaks.
And since we make the 32-bits builds cross-compiles on CI, we also need
to adjust the MSVC build mozconfigs such that the host compiler points
to the right MSVC cl. Likewise, the DIA SDK is used for host things, so
use the 64-bits version or it.
Differential Revision: https://phabricator.services.mozilla.com/D7845
--HG--
extra : moz-landing-system : lando
All but one of the current uses of DEFFILE 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.
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
The new VS package is now based on update 15.4.2, although that release didn't affect any files in our package. I'm picking up the update mostly just to make filename unique.
This patch adds a copy of vswhere.exe to build/win32, downloaded from the
current latest release (1.0.62):
https://github.com/Microsoft/vswhere/releases/download/1.0.62/vswhere.exe
It changes toolchain.configure to invoke vswhere.exe instead of reading
the registry, since that no longer works for VS2017 (but vswhere can locate
VS2015). It also removes a layer of complexity in that code by dropping
support for non-64-bit host systems, since we don't really support building
on 32-bit Windows anymore anyway.
There's a little bit of fixup in windows.configure where some LIB paths
have changed in 2017.
MozReview-Commit-ID: 5XLWjidS6W4
--HG--
extra : rebase_source : 90f79b6f4a2d8d925dd20eb0bf6ab96262c227d5
The `cd $PATH && pwd` pattern doesn't work when $PATH doesn't exist, so
move them in a block only executed when the directory exists.
--HG--
extra : rebase_source : 53bd2959dbd9825526a386b6ab5b40a7f67a5d20
