On Mac developer builds, add $topsrcdir and $topobjdir paths to the application
bundle Info.plist files for the main process and plugin-container, removing the
dependency on MOZ_DEVELOPER_REPO_DIR and MOZ_DEVELOPER_OBJ_DIR environment variables.
MozReview-Commit-ID: JfFFK9sEayn
--HG--
extra : rebase_source : ab2d8dd625783326b4108eb1e4ebaf49ef8fbedb
Before bug 1348069, MS manifest tool was used to embed manifest files.[1]
The Makefile used to use EXTRA_DEPS to invoke the manifest tool when a manifest files is changed. But it is no longer effective because the manifest file namepattern is no longer $@.exe.manifest.
Now manifest files will be embedded via .res files. So we have to rebuild .res files to update embedded manifests.
[1] https://dxr.mozilla.org/mozilla-central/rev/35c7be9c2db288d1d449e3cc586c4164d642c5fd/config/rules.mk#642-655
MozReview-Commit-ID: 5QiXVeImZdY
--HG--
extra : rebase_source : 9e321e30ecd389ef0aa21e438d321e79edf0a009
The .app directory for OSX builds is created piecemeal by several
commands in browser/app/Makefile.in, however it isn't normally cleaned
by a build. If a file is removed from the tree, it's possible that an
incremental build will still have a copy in the .app dir and get
packaged up in the final dmg. It's simple to just rm -rf this directory
beforehand.
MozReview-Commit-ID: 2Zr97o9dTn8
--HG--
extra : rebase_source : 2c9995991c58ee9724464514ec8285c31ab8d062
MozReview-Commit-ID: 6G3zm2jrrMx
This patch needs to use different manifests depending on whether we are building
32-bit or 64-bit Firefox. In order to distinguish between them, I am using
checking for HAVE_64BIT_BUILD in the resource file and embedding the manifests
there.
--HG--
rename : browser/app/firefox.exe.manifest => browser/app/firefox.exe.32.manifest
rename : browser/app/firefox.exe.manifest => browser/app/firefox.exe.64.manifest
rename : ipc/app/plugin-container.exe.manifest => ipc/app/plugin-container.exe.32.manifest
rename : ipc/app/plugin-container.exe.manifest => ipc/app/plugin-container.exe.64.manifest
extra : rebase_source : 2d937f47c7b79a4f29a2c2001dec5ed8f00e54bc
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
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.
OS_LIBS for libraries that are not part of the gecko tree, EXTRA_LIBS for
libraries, such as NSPR, that are in the tree, but are not handled by
moz.build just yet. Those EXTRA_LIBS may also come from a system library.
However, in cases where the expanded variables are always empty for the
in-tree case, OS_LIBS is used (as for, e.g. MOZ_ZLIB_LIBS). OS_LDFLAGS is
used exclusively for non-library linker flags.
Always pass EXTRA_LIBS before OS_LIBS on linker command lines.
Forbid EXTRA_DSO_LDOPTS, SHARED_LIBRARY_LIBS and LIBS in Makefiles.
Haik Aftandilian
Aaron Klotz
Masatoshi Kimura
Mike Shal
Michael Kaply
Henri Sivonen
Stephen A Pohl
Mike Hommey
Nick Alexander
Ted Mielczarek
Steven Michaud
Ryan VanderMeulen
Brian O'Keefe
Joshua Cranmer
Ehsan Akhgari
Robert Strong
Nathan Froyd
Alexandre Poirot
Ehsan Akhgari
Seth Fowler