These headers were added with the initial support for hidden visibility
in bug 273336. At that time this code probably lived in libxpcom and needed to
be callable outside of that, but that's not true anymore. At this point not
linking this code into libxul seems like madness, so we
might as well stop calling them system headers so we stop exporting them
from libxul.
This commit adds an empty recipe to dependencies of .aapt.deps, which
forces the appropriate gecko-R.jar rebuild. This is because Make treats
targets with no recipe at all differently than targets with an empty
recipe, in a way that defeats our dependencies.
What appeared to be happening is the following:
Touch a resource. On the next build, .aapt.deps is stale, so aapt is
invoked, which generates R.java, and we touch .aapt.deps.
Now R.java depends on .aapt.deps, but this does not appear to force Make
to consider targets that depend on R.java to be stale. A target that
depends on R.java (such as gecko-R.jar) itself compares timestamps and
finds that gecko-R.jar is newer than R.java (from the previous build),
and this comparison appears to happen before aapt is invoked. So even
though .aapt.deps is seen to be stale, and by transitivity R.java is
stale, this does not mark gecko-R.jar as stale. The timestamp check
between R.java and gecko-R.jar appears to happen *before* aapt is
invoked.
On the second build following the update, the R.java generated in the
previous build is newer than gecko-R.jar, triggering the observed
rebuild of gecko-R.jar.
The issue is that the preprocessed files need to be referenced as
$(CURDIR)/file to have Make handle the dependencies correctly. To
allow this, this patch adds ANDROID_MANIFEST_FILE (defaulting to
AndroidManifest.xml) and uses it in the appropriate places.
It's just as easy to directly set the preprocessor macro in the moz.build
files. Using this variable doesn't really buy us anything.
This patch also removes unused code from rdf/tests/dsds.
This cleans up stale .class files, so they don't get packaged into the
.jar files that Proguard consumes.
--HG--
extra : rebase_source : a090d707579711f85b8f9f174b88bf9302be0b24
Generated sources are listed like 'generated/FILE.java'. Generated
sources are produced by PP_TARGETS, which generates the file
'$(CURDIR)/generated/FILE.java'. Because Make interprets $(CURDIR)/foo
and foo differently, this means we need to depend on $(CURDIR)/* for all
generated sources. Since R.java is both listed as a generated source,
but produced by aapt, we need any dependencies to be on
$(CURDIR)/.../R.java.
The change to java-build.mk includes $(CURDIR) in the dependencies for
generated sources. The changes to Makefile.in includes $(CURDIR) in the
produced R.java files for Make.
Before making top-level traverse js/src moz.build files, there was a need to
distinguish between top-level traversing e.g. top-level moz.build or
config/moz.build and js/src traversing them. With a single traversal of both
moz.build sets, we now only need to distinguish between js standalone builds
and gecko builds.
There is still, however, a need to distinguish between top-level vs. js/src
configure runs on gecko builds to make them subconfigure icu and libffi from
top-level instead of js/src in js standalone builds, or when choosing to make
js/src's config.status do something when run or not.
Before, we would run configure in both top-level and js/src, and both
configures would traverse their own set of moz.builds, without actual
knowledge about the other. With this change, both configures still run,
but only top-level traverses moz.build files, and uses js/src's
config.status when traversing its moz.build files. This allows a better
sharing of information between both build systems and the removal of many
hacks.
This also moves running libffi and icu configure to top-level.
Standalone js builds still have their own configure doing moz.build traversal,
as before.
--HG--
rename : config/autoconf.mk.in => config/autoconf-js.mk.in
rename : config/emptyvars.mk.in => config/emptyvars-js.mk.in
