This currently works in the recursive make backend because make readjusts with
the vpath to the source directory, but for other backends (like CompileDB),
the lack of clear path hurts. In fact, CompileDB currently reports the path as
being in the objdir.
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.
With all include flags now using absolute paths, there is no need to try
to post-process them when getting them for CompileDB and codecomplete.
As a matter of fact, doing so fixes the flags in media/gmp-clearkey/0.1,
since they use literal "-include stdio.h", which was wrongly transformed
into "-include $objdir/media/gmp-clearkey/0.1/stdio.h".
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 difference between all of them is the application id they target.
Interestingly, the Fennec one is still targetting the XUL appid, instead
of the Android one, which doesn't seem right.
--HG--
rename : b2g/locales/generic/install.rdf => toolkit/locales/generic/install.rdf
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.
We want to move it to CommonBackend, so it's better to make it more
independent, which the Defines instances now attached to ContextDerived
instances allow.
Like with ChromeManifestEntries, reloop in consume_object, with the double
goal of allowing to reuse the jar manifest handler code in other backends
and avoid code duplication in the FasterMake backend itself when support
for e.g. GeneratedFiles is added.
Instead of filling the install manifests accordingly, reloop in
consume_object, so that the jar manifest handler code can eventually
be reused in other backends.
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).
Again, this is not strictly necessary but allows to confirm idempotence of
further changes. And it has the nice side effect of making chrome manifest
files more consistent.
When painting a -moz-element the root reference frame is the refered-to frame, so it can be transformed. In normal painting root reference frames are root frames which can't be transformed so this doesn't come up.
