These files have not been used since Firefox 4.0 because they were in the
omnijar while the code trying to copy them were expecting them outside the
omnijar. Fast forward a few years, and new profiles are now expected to be
empty so these files are just dead weight.
The only thing that happens there is copying two bitmaps files in
DIST/branding. Those files haven't been used since the removal of the
xpinstall-based installer code in bug 344236... 9 years ago.
The only use of BRANDING_FILES[...].source is in xulrunner/app/moz.build, for
the app.ico file.
This file has not been useful since the removal of the xpinstall-based
installer in bug 344236... 9 years ago.
This makes it clearer that really it's the same thing as FINAL_TARGET,
with preprocessing.
We still keep DIST_FILES in backend.mk because it's shorter and doesn't
really matter.
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
A new configure option --with-devtools (which sets MOZ_DEVTOOLS) is added to
control whether all DevTools, just the server, or no DevTools are included.
This defaults to just the server.
Applications should also include /devtools within their moz.build tree, so that
DIST_SUBDIR is in effect for all DevTools files if it is used by the app.
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
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.
Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.
Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.
Setting MOZ_FOLD_LIBS should stop being an opt-in for individual applications,
which also makes them responsible for doing the right thing, which happens not
to be the case for B2G Desktop Linux builds.
Enforcing MOZ_FOLD_LIBS to be set on the relevant platforms in configure ensures
everything is setup up correctly, and also allows to stop caring about supporting
now hypothetical e.g. MSVC builds without MOZ_FOLD_LIBS (which require to pass
DLLFLAGS down to the nspr build system to make nspr built against mozglue which
would now be unnecessary)
