Since ./mach bootstrap installs Android SDK into ~/.mozbuild, we should detect
this location as default SDK install path.
Also, --with-android-max-sdk and --with-android-min-sdk are still in android.m4
because confvars.sh sets MOZ_ANDROID_MIN_SDK_VERSION.
Differential Revision: https://phabricator.services.mozilla.com/D15463
--HG--
extra : moz-landing-system : lando
We default to -Zi for Windows debug flags, which is for generating debug info
into a PDB file, but clang-cl doesn't actually implement that so -Zi is
an alias for -Z7 in clang-cl:
http://clang.llvm.org/docs/UsersManual.html#id9
sccache has special handling for -Zi because multiple compiles writing
to the same PDB file is not cacheable, so we've always overridden -Zi with -Z7
in CI when using sccache.
Given that everyone should be using clang-cl nowadays and MSVC will no longer
be supported soon, this patch changes the default and removes some PDB
file name flag setting from rules.mk, as well as the no-longer-necessary
overrides from mozconfig.cache.
Differential Revision: https://phabricator.services.mozilla.com/D18264
--HG--
extra : moz-landing-system : lando
Also use armv7a as the default when no target is given at all.
Also change bootstrap to create a simpler mozconfig. The downside is
that the resulting mozconfig would not work when building older
revisions.
Add unit tests for this as well as the simplications added in bug
1523341.
Differential Revision: https://phabricator.services.mozilla.com/D17906
--HG--
extra : moz-landing-system : lando
While not related, it turns out this test was opted in by ourselves,
while it's practically useless. Recent autoconf documentation says it's
obsolescent, and even autoconf 2.13 documentation said with "recent
versions of the GNU C compiler", the issue it's detecting "is becoming
a less prevalent problem". Recent as of 20 years ago.
Differential Revision: https://phabricator.services.mozilla.com/D18054
--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
Clang 8 seems to generate destructor decls from different source
locations which breaks an assertion in the code. This patch updates the
code to remove the assertion and more robustly handle the new
declarations.
Differential Revision: https://phabricator.services.mozilla.com/D17902
--HG--
extra : moz-landing-system : lando
We reject MSVC compilers < 2017 already, there's no point checking for
smaller versions after that.
Differential Revision: https://phabricator.services.mozilla.com/D17770
--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
We currently rely on WIN_DIA_SDK_BIN_DIR being passed, but we can
actually derive it from the DIA SDK directory. So we now do that, except
when it's given explicitly.
While in the vicinity, move the dia2.h check to python configure.
With WIN_DIA_SDK_BIN_DIR being derived and not set when dia2.h is not
found, we don't really need MSVC_HAS_DIA_SDK anymore, so we just check
for WIN_DIA_SDK_BIN_DIR to determine whether to build dump_syms or not.
One exception to the above is when WIN_DIA_SDK_BIN_DIR is passed in,
which we only keep for the in-tree mozconfigs for now. We'll remove that
possibility after bug 1523201.
Depends on D17892
Differential Revision: https://phabricator.services.mozilla.com/D17893
--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
Previously, we hardcoded HostX64 because configure would autodetect a
x86 host on x64 machines, but the x86 MSVC compiler wouldn't be
suitable.
While the x86 MSVC compiler might still not be suitable, now that
configure detects x64 hosts properly, when the configure host is
detected as x86, we can't even execute the x64 compiler, so we can at
least try with the x86 one correctly.
Differential Revision: https://phabricator.services.mozilla.com/D17788
--HG--
extra : moz-landing-system : lando
The combination of bug 1515579 and bug 1520394 made things harder for
old-configure, because it doesn't necessarily have a complete view of
the search PATH that has been used. This doesn't actually cause problems
on non-Windows builds because things work out fine, but on Windows,
some of the executions of clang-cl in old-configure insist on being able
to find a MSVC install. That, again, doesn't currently cause problems in
general on local builds because clang-cl finds it through the registry
(presumably), and on automation, because it's in the `mk_add_options
export`'ed PATH, but the latter is due to change.
Depends on D17772
Differential Revision: https://phabricator.services.mozilla.com/D17783
--HG--
extra : moz-landing-system : lando
Also, while here, replace subprocess.check_output with check_cmd_output.
Depends on D17771
Differential Revision: https://phabricator.services.mozilla.com/D17772
--HG--
extra : moz-landing-system : lando
Bug 1520394 changed things such that the configure sandbox is using a
copy of os.environ. So when mozconfig injects environment changes, they
only affect the sandbox. Which means when the which module uses
os.environ to get PATH, it gets the original unmodified environment.
So instead of relying on the which module getting PATH itself, we feed
it with it. It's worth noting that the which module adds `.` on Windows,
but we don't copy this behavior, because in the context of configure,
it's actually not important (`.` would be the topobjdir).
Differential Revision: https://phabricator.services.mozilla.com/D17771
--HG--
extra : moz-landing-system : lando
And use it as an alternative to vswhere, instead of the current late
check. This allows to use VC_PATH when using a MSVC archive that is not
installed through the VS installer, and not have to care about PATH.
Depends on D17786
Differential Revision: https://phabricator.services.mozilla.com/D17787
--HG--
extra : moz-landing-system : lando
- Only expose it as well as --with-visual-studio-version when the host
system is Windows.
- Don't run vswhere twice (once for host and once for target).
Depends on D17785
Differential Revision: https://phabricator.services.mozilla.com/D17786
--HG--
extra : moz-landing-system : lando
config.guess doesn't actually figure out the real host system on
Windows. All it does is end up finding the CPU for which the msys used
for the shell is built for. Which has the unfortunate effect that if you
build on a 64-bits host, configure pretends the host is 32-bits.
So instead, rely on some environment variables that should be set
mostly everywhere, and derive the corresponding triplet.
This has two effects:
- configure now knows that the host is 64-bits when it is.
- consequently, configure will build a 64-bits Firefox on 64-bits hosts
by default (since by default, the target is derived from the host), and
that's actually a desired side effect.
Depends on D17620
Differential Revision: https://phabricator.services.mozilla.com/D17621
--HG--
extra : moz-landing-system : lando
- We assume the output from config.guess is sufficiently normalized for
our needs.
- If we partially derive the target from the host (with only the cpu
given for --target), we assume the derived value doesn't need
canonicalization.
Differential Revision: https://phabricator.services.mozilla.com/D17620
--HG--
extra : moz-landing-system : lando
In fact, "simply" use whatever python configure does to find a shell to
execute config.guess and config.sub, and get both the mozconfig content
and the real, canonicalized target alias. This has the side effect of
making builds with --target=$cpu use a complete obj-$cpu-$os default
objdir instead of obj-$cpu. This will also allow to change the
host-guessing logic without having to duplicate code.
Differential Revision: https://phabricator.services.mozilla.com/D17618
--HG--
extra : moz-landing-system : lando
Sylvestre Ledru
Makoto Kato
Ted Mielczarek
Mike Hommey
Gurzau Raul
Tom Ritter
Alex Chronopoulos
shindli
Mark Banner
Cosmin Sabou
Sebastian Hengst
Tom Prince
Kartikaya Gupta
David Major
Ryan VanderMeulen
Jan Henning