When we build mar, there is no reason not to build signmar as well. It
used to be optional because not all platforms were supported, but they
are now.
... except when building the newly added tools/update-packaging,
which builds the mar tool as a standalone thing, and building signmar
as well causes complications.
Differential Revision: https://phabricator.services.mozilla.com/D36992
--HG--
extra : moz-landing-system : lando
When we build mar, there is no reason not to build signmar as well. It
used to be optional because not all platforms were supported, but they
are now.
Differential Revision: https://phabricator.services.mozilla.com/D36992
--HG--
extra : moz-landing-system : lando
When we build mar, there is no reason not to build signmar as well. It
used to be optional because not all platforms were supported, but they
are now.
--disable-verify-mar is kept to still allow to disable mar verification in
the updater for debugging purpose.
Differential Revision: https://phabricator.services.mozilla.com/D36992
--HG--
extra : moz-landing-system : lando
The conditions under which verifymar is built were not aligned with what
kind of setups are actually doing something. For instance
--disable-signmar --enable-verify-mar was building the verifymar library
but not doing anything with it.
OTOH, building with --enable-signmar --disable-verify-mar did build it
but its code was eliminated at link time because it's unused.
Finally, the conditions between modules/libmar/verify/moz.build and
toolkit/mozapps/update/updater/updater-common.build weren't aligned and
broke some non-Linux tier-3 platforms. We remedy the latter by moving
the flags and libraries verifymar needs to verifymar, so that things
that link verifymar inherit them.
And while in the vicinity, replace a use of NSPR_LIBS with the
pseudo-library `nspr` which has the same effect.
Differential Revision: https://phabricator.services.mozilla.com/D34620
--HG--
extra : moz-landing-system : lando
Added defines to mar_extract.c, mar_read.c, bsdiff.c so they use the ISO C and C++ conformant name.
Ran clang format on bspatch.cpp and the files under modules/libmar except for nss_secutil.c and nss_secutil.h since they are copies of nss code.
Make CityHash64, CityHash64WithSeed, and CityHash64WithSeeds usable from C code
Remove unnecessary includes from mar_read.c as well
Add DisableStlWrapping to mar tool's moz.build to fix linkage break when
building in Windows with MSVC
Differential Revision: https://phabricator.services.mozilla.com/D10774
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
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
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.
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.
Tom Prince
Sylvestre Ledru
Mike Hommey
Bogdan Tara
Andreea Pavel
Robert Strong
June Wilde
Tom Tromey
Ted Mielczarek
Nicholas Nethercote
Bogdan Postelnicu
Chris Peterson
Brian R. Bondy
Brian Smith
Stephen Pohl
Ehsan Akhgari
Daniel Holbert