-Zi is already set through MOZ_DEBUG_FLAGS, which is set from
--enable-debug-symbols, which is the default, and if someone goes all
the way to explicitly disable them, we might as well not silently
override their decision.
-Od disables optimization, and the given reason was for sane stack
traces, but the fact is we're currently building debug builds, which
have been optimized by default for a while, and are the only ones with
DMD enabled by default, without overriding with -Od and are apparently
happy with it.
-DNDEBUG is already set through MOZ_DEBUG_DEFINES, and -UDEBUG is not
doing anything useful, since nothing is setting DEBUG on the command
line, nor does the compiler by default.
The flag is used to create .sbr files, which bscmake subsequently uses to
create .bsc files. These files and related tools are, aiui, the ancestors
of Intellisense.
The -FR C*FLAGS are added to the build if MOZ_BROWSE_INFO or MOZ_BSCFILE
are set in the recursive make backend. While the former has an AC_SUBST,
the latter does not, so in practice, only the former can be set by
supported methods, and would need to be set in a mozconfig. At that
rate, people who do want those flags can add them in the C*FLAGS on
their own.
Developers are probably better served by the VisualStudio backend
anyways.
We don't really care to set those in js/src/configure because the JS
engine doesn't use ObjC. We also don't care to preserve the += behavior
because there were no AC_SUBST in the first place, so it's unlikely
anyone has an override in their mozconfig and expects it to work.
FasterMake needs some RecursiveMake install manifests to have been
processed before doing its work, so we can actually end up processing
them twice because of the going back and forth from FasterMake in the
hybrid build system.
Set the dependency at the RecursiveMake level when doing an hybrid
build.
--HG--
extra : commitid : 7nD60DTsoHz
extra : rebase_source : 61b5803732b0ecdff421e4e15a2086d4eae7a937
extra : amend_source : c0ae62708b2019888ea320c3793d4ea3f6d6d460
Recent changes in bug 1239217 added the faster backend to the default
build mechanism for artifact builds. This seems to have uncovered a
difference in behavior between GNU Make 3.81 and newer. Starting with
GNU Make 3.82, pattern rules are selected according to shortest stem.
Before, they are used in definition order.
So, we change the order of the pattern rules so the longest prefixes are
first. This should result in the same behavior on various GNU Make
implementations.
--HG--
extra : commitid : GVAzwgjaChF
extra : rebase_source : e0765bcf80ad93b7b193f8d4218f4c6f90dbb843
extra : amend_source : d06092dde64d22be476ef1f9e0232eda87d48325
The current rule is only for "backend.RecursiveMakeBackend", but, with
the current default of generating both the RecursiveMake and FasterMake
backends, the command creates/refreshes both backends. This is, in fact,
how the FasterMake backend is refreshed in most cases.
Moreover, with an hybrid backends, the generated file is not
"backend.RecursiveMakeBackend" anymore, so we need a more generic way to
handle this.
Furthermore, it's not necessarily desirable for all backends to have a
dependency file to handle the dependencies to refresh the backend, so
generate a plain list instead. This has the side effect of making `mach
build-backend --diff` more readable for changes to that file.
Finally, make the backend.* files created like any other backend file,
such that its diff appears in the `mach build-backend --diff` output.
The FasterMake build system is meant to be invoked through `mach build
faster`, which does it already, or, in the near future, as part of an
hybrid build system, which will deal with it as well. People doing
`make -C objdir/faster` won't have the backend automatically refreshed,
but that's not a supported way to use it anyways.
While it would be possible to move those things in the export tier, it
is still interesting to have reporting for them separately, especially
considering I expect things to gradually move from the other tiers to
this new one.
While not entirely obvious, the recurse_pre-export target doesn't imply
actual recursion as long as the RecursiveMake backend doesn't emit
traversal information for it, so nothing will actually happen on this
target, but the interesting part is that it runs, per the generic
config/recurse.mk rules for tiers, between BUILDSTATUS TIER_START and
BUILDSTATUS TIER_FINISH, so that all its dependencies are accounted
as being part of the pre-export tier.
GENERATED_FILES impacts the export tier through the config/rules.mk
definitions, now moved to the backend itself, so that everything is
close to each other.
Turns out the claim in bug 1234439 that the FasterMake backend knows
about all the chrome manifest entries is wrong, and there's still one
that is added "manually" with buildlist.py, and during mach build
faster, that can happen before or after the corresponding chrome
manifests are written out by install manifest processing.
While the real fix here would be to make the build system totally
aware of those "manifest interfaces.manifest" entries, for now, it's
simpler to add dependencies to work around the race condition.
Collecting the list of object files compiled, while not ideal, will give us
some indication of how much work was involved in the build. This will help
with analyzing the data.
--HG--
extra : rebase_source : e9861ed5c0766e3ee8038dbec0b9267022c523eb
Limit ourselves to include paths for now, because there are tricky things
involved in making this globally.
While here, use shell_quote instead of manual quoting for those paths.
This might seem like going in the opposite direction of what we tend to do
to move to moz.build land, but those flags are irrelevant in many situations
and are better separated out.
MOZ_DEBUG_DEFINES are essentially defines used everywhere. So treat them as
feeding the initial value for DEFINES in each moz.build sandbox. This allows
the kind overrides that was done in the past by resetting MOZ_DEBUG_DEFINES
in Makefiles.
The only affected symbols are
_PR_<architecture>_Atomic{Decrement,Set,Add,Increment}, they are not exposed in
public headers, have a different name on each architecture, and have a public
API: PR_Atomic{Decrement,Set,Add,Increment}.
Currently, one needs to define DEFFILE or LD_VERSION_SCRIPT appropriately,
and somehow deal with the fact that their input format is different, which
currently relies on manual invocations of the convert_def_file script, with
awkward aggregations.
This simplifies the problem by using a simple list of symbols, with
preprocessing, allowing #includes.
Currently, only css files added through jar manifests are treated this way.
There is really no reason for the discrepancy, but there are actually no css
files added directly through moz.build, so this was never a problem.
On the other hand, it makes things simpler in a world where jar manifests are
treated as if they were entirely described in moz.build (which is where the
FasterMake backend is heading).
Using TEST_DIRS is nothing more than a shortcut for
if CONFIG['ENABLE_TESTS']:
DIRS += [...]
As such, we might as well remove it being a separate variable, and use some
Context magic to just fill DIRS when ENABLE_TESTS is set.
The security/manager/ssl/tests/unit/moz.build change ensures that the order
of DIRS before the change is kept, not because it matters, but because it
allows to confirm that nothing else is modified by this change.
