This patch moves the logic for selecting MOZ_WINCONSOLE out of individual
Makefile.in files and into configure. It also changes config.mk to only
pass -SUBSYSTEM:CONSOLE if MOZ_WINCONSOLE=1. The MSDN docs state that
in the absence of -SUBSYSTEM, the linker will select the proper subsystem
based on whether the program contains [w]main or [w]WinMain, so let it
do that.
One program (windbgdlg) needed a tweak to add a wmain for when MOZ_WINCONSOLE
is defined.
This patch leaves one instance in security/sandbox/win/wow_helper/Makefile.in,
that Makefile has its own separate bug.
--HG--
extra : commitid : 8acDjmfKivj
extra : rebase_source : 03b4fa4c8ae077a894b08f3762ef93541e34ac1a
Dehydra/Treehydra is unmaintained, broken (iirc), and obsoleted by clang
static analysis. We've removed parts of the build system support for it, but
not all. This is meant to remove the remains.
GENERATED_FILES and accessible/xpcom/Makefile.in add to EXTRA_MDDEPEND_FILES, but for
targets that run during export. Export doesn't include EXTRA_MDDEPEND_FILES, so none
of them is ending up with correct dependencies. The EXTRA_EXPORT_MDDEPEND_FILES variable
could be used for this purpose, but given the circumstances this variable is removed,
and EXTRA_MDDEPEND_FILES is instead included unconditionally.
--HG--
extra : commitid : 7daRRnxfkS0
In bug 922912, we folded back gkmedias.dll info xul.dll, so in practice, there
is no default configuration left that exercises GKMEDIAS_SHARED_LIBRARY. And
sure enough, it's been broken for months in many different ways.
The gkmedias intermediate library is however kept for webrtc signaling tests.
The configure option has explicitly thrown an error for more than a year now,
and it happens that the remaining way to still forcefully use it has been
broken for more than 8 months.
It was added back in
5147d5c69f
for unclear reasons (and the lack of bug number doesn't help), and hasn't been
used, as far as I can see in the gecko-dev history, other than in bug 206029,
which is the only use currently in the tree.
Bug 206029 was working around the Flash player installer modifying Firefox's
prefs file and not dealing with it properly or something depending on the line
endings. 11 years later, all prefs files except channel-prefs.js are in
omni.ja, so obviously, bug 206029 doesn't actually apply anymore.
So, let's simplify it all and get rid of this.
The flags added in toolkit/locales/Makefile.in turn out not to be actually
used, so just remove that.
The remaining uses of XULPPFLAGS are to set debug flags depending on whether
MOZ_DEBUG is set or not. Just set a dedicated variable with the right value
from configure.
At the same time, make the test for libstdc++ more comprehensible.
--HG--
extra : commitid : FY4SOJob69k
extra : rebase_source : 15778a2080423666edeae78adb7a5b80925f6871
This commit is us getting out of our own way. We were specifying
-classpath twice, once in $(JAVAC) and once in java-build.mk. Only
the latter of these is active. This a problem for ANDROID_EXTRA_JARS
-- those JARs should be on the classpath and input to $(DX) -- and
JARs that should be on the classpath but *not* input to $(DX). This
commit removes the global flags to $(JAVAC) and adds
JAVA_{BOOT}CLASSPATH_JARS. This required some hijinkery moving
wildcards to moz.build files, but everything seems to work.
As well as clarifying some parts of the build, part 2 uses this work
to modify the classpath.
--HG--
extra : commitid : 25Ft0BFs88O
extra : rebase_source : 05e3d1da8d42fa89d06ef48baee17bb77df5bd59
extra : histedit_source : 95b82309aca15c5a3c5f5a0eafbdcf75c5e8dfc0
Use |nm -A| instead of |nm -l| to avoid depending on imprecise debug
information in optimized builds. (And to get the 100x faster
performance.)
Fix a problem with the filename regex so we can also detect symbol
references in from source files with a hyphen in their name.
When bad allocation references are detected, display results from |nm -l|
so we still get the useful line number information.
It was necessary to allow warnings here I introduced ALLOW_COMPILER_WARNINGS in
bug 1198334, but something must have changed subsequently because it no longer
is necessary.
--HG--
extra : rebase_source : 292bd070928b2a0f8f943b8f5dabf31db30244b4
Its only purpose is to disable PGO. Where that was not already explicitly done,
or irrelevant (because the directory only contains python), I disabled it in
moz.build.
As part of this move, HOST_NSPR_MDCPUCFG needed to be changed to get the quoting right.
--HG--
extra : commitid : J26MhSiPq9g
extra : rebase_source : 81c5b98371042803741ddace8d01b0097757dff3
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973
This moves a little bit more of mobile/android/base/Makefile.in into
moz.build, and gets closer to moving that aapt invocation into
java-build.mk.
There are no other extra package consumers in the tree. (There should
be a new one shortly: b2gdroid.)
--HG--
extra : commitid : AaYqXYReOSX
extra : rebase_source : d41368ff0bd0736221fdc04ed8299b70c2488c8b
extra : histedit_source : 845efd5ba9f99f4e186c3a5c66affe69eac7fec7
This paves the way for defining additional Android packages in
moz.build, which is a step toward moving the special
mobile/android/base/Makefile.in aapt invocations into the generic
java-build.mk framework.
The new variables are both passthru variables for now: in the future,
we'll roll them into some aggregate Android APK definition.
It's worth noting that references to the variables in Makefile.in
files are only defined after including rules.mk (and thereby
backend.mk). This only required a few changes in the tree but it
confused me for some time.
--HG--
extra : commitid : G5mEvm8Ng4F
extra : rebase_source : 7ba05f2e53554549ffb5cefe270925e3e2025b6a
extra : histedit_source : eacd22f4b7edddab67147c413fea45a3ba292c0c
Now that we have moz.build, we can be guaranteed that any flags we add
in moz.build will be added after everything else has been setup. So any
uses of MODULE_OPTIMIZE_FLAGS can be moved to moz.build's
CFLAGS/CXXFLAGS without any unusual repercussions. We do have to verify
that MOZ_OPTIMIZE is in effect, though.
We have had singular ANDROID_ASSETS_DIR in Makefile.in for a while.
Fennec itself does not use the existing Makefile.in Android code, for
complicated historical reasons.
This makes the existing variable moz.build-only; generalizes the
existing variable to an ordered list; and adds the equivalent use of
the new list to the Fennec build, with a simple example asset.
This patch also updates the packager to include assets packed into the
gecko.ap_. Without the packager change, the assets/ directory in the
ap_ gets left out of the final apk. This whole approach is totally
non-standard but is more or less required to support our single-locale
repack scheme.
--HG--
extra : commitid : 4EAh1UNGNWT
extra : rebase_source : 5e5b4c4a120c3b4cc776c9f9380ddd2f9b63587e
extra : source : 0ddce3eb833e6d6180a19928a9b45d5d12f1d7fa
Optimised Rust compilation is enabled on passing --enable-optimize to
the configure script. This sets the RUSTFLAGS output variable that gets
picked up by the compile targets RSOBJS and RSSRCS and passed to rustc.
r=glandium
--HG--
extra : commitid : 8thSkfLFXSY
extra : rebase_source : 5ec79b76a187bcbb0f09ad374cf9f763f0adb0d7
There are several parts to this ticket:
1) Produce javaaddons-1.0.jar, a standalone JAR defining a (versioned)
Java interface suitable for consumption by third-party Java addon
implementations.
2) Support the new V1 interface in the JavaAddonManager.
3) Add Robocop JavascriptTests testing the JavaScript message passing
interface to and from Java.
This patch can be read as "not in tests/" and "everything in tests/".
--HG--
rename : mobile/android/base/JavaAddonManager.java => mobile/android/base/javaaddons/JavaAddonManager.java
extra : commitid : ApOd0Iz9BrZ
extra : rebase_source : 9808487ec3b233f31524e3694d1e997af78a0c84
extra : histedit_source : c8883a01805d7ed39ffb58e8523103260aa72d0b
Add .rs as a recognized file extension in SOURCES.
Propagate that through to the Makefile backend and add a dependency
generated and an explicit rule to call $(RUSTC) to compile them.
rustc builds static libraries, not obj files. At least, if one
asks it to output an obj file, I'm not clear how to get all the
compiler-specific runtime libraries the code will expect to link
to. Therefore we generate a static library for each rust source
file (which must be a complete crate for the time being) and link
that. Because of the extension it ends up on the LIBS line in the
the corresponding .desc file.
Note that the static library does still depend on some system
libraries, e.g. -ldl -lpthread -lm on linux. Gecko already
links to all of those, so we don't keep track of it here.
Should we need to add explicit linkage for other targets,
rustc does print a list to stderr which can be parsed.
--HG--
extra : rebase_source : 9f66101fd15a649a952d5481cf9561416204272a
Without this, invoking Make in a sub-directory will fail with an error
that libs:: cannot find target `target'.
Without this patch, the Fennec Gradle and IDE build integration fails
compiling its custom targets in mobile/android/base and
mobile/android/base/locales.
--HG--
extra : rebase_source : a105072aee28e4f7693958a175d1d8ce3188b5f4
extra : source : 3232d253cf909e38da318c3ed3c04e7b5fc6a94f
Without this, invoking Make in a sub-directory will fail with an error
that libs:: cannot find target `target'.
Without this patch, the Fennec Gradle and IDE build integration fails
compiling its custom targets in mobile/android/base and
mobile/android/base/locales.
--HG--
extra : rebase_source : be5cc6764b7c1fc7a5bdc177760a709e015e02d4
Now that moz.build can see EXTRA_*COMPONENTS and NO_JS_MANIFEST, we can
move some logic from rules.mk (executed every build) to moz.build's
emitter.py (executed only at build-backend time).
These definitions appear to have been added to support generating Java
interfaces from xpidl interface files. Since we don't support doing
that anymore, we don't need these definitions, either.