These definitions appear to have been added to support generating Java
interfaces from xpidl interface files. Since we don't support doing
that anymore, we don't need these definitions, either.
The recursivemake backend sets IMPORT_LIBRARY to the same value as
SHARED_LIBRARY on non-Windows platforms, so we can simply use
IMPORT_LIBRARY everywhere.
NO_INSTALL_IMPORT_LIBRARY is only used in one place, and since we don't even
use $(DIST)/lib for gecko, it actually doesn't make a difference presently.
We want the ability to read data from any moz.build file without needing
a full build configuration (running configure). This will enable tools
to consume metadata by merely having a copy of the source code and
nothing more.
This commit creates the EmptyConfig object. It is a config object that -
as its name implies - is empty. It will be used for reading moz.build
files in "no config" mode.
Many moz.build files make assumptions that variables in CONFIG are
defined and that they are strings. We create the EmptyValue type that
behaves like an empty unicode string. Since moz.build files also do some
type checking, we carve an exemption for EmptyValue, just like we do for
None.
We add a test to verify that reading moz.build files in "no config" mode
works. This required some minor changes to existing moz.build files to
make them work in the new execution mode.
--HG--
extra : rebase_source : f701417f83dfa4e196e39182f8d0a6fea46c6fbb
extra : source : af07351bf2d6e85293ae3edf0fe4ae6cbc0ce246
moz.build files should execute in filesystem traversal mode. Add a test
that verifies this is true.
This test performs a brute force filesystem scan to find relevant
moz.build files. This can be a little slow. That's unfortunate. But it's
a price we need to pay in order to ensure metadata extraction mode
continues to work.
--HG--
extra : rebase_source : 7ae9be71b7cd995c0794f980c5d76f38366637c6
extra : source : 91d34d3107faa777264cdcc9c89456bf4c289466
xpt files don't have a dependency on backend files to avoid rebuilding all
of them when adding or removing new files. On incremental builds, some kind
of dependencies are required to ensure the xpt files are refreshed when
adding or removing new idls.
Generating the list of idl deps to generate an xpt from its dependency list
makes us give all _previous_ dependencies, inherited from the .deps makefiles.
This leads to removed files being listed on xpidl-process.py command line, and
the command subsequently failing.
Instead, use generated lists of idl dependencies. At the same time, lighten the
generated Makefile further by not emitting xpt dependencies on their containing
directory, and instead generating it from the $xpt_files list.
This brings down the Makefile size from 100k to 38k.
Now that the mozbuild backend knows about FINAL_TARGET, we are able to
install generated xpt files into their final location. This saves us
from copying xpt files into their final location on every build.
Original patch by gps, rebased and comments addressed by Ms2ger
--HG--
extra : transplant_source : %E2%DC%0F%E0%AD%C2%25%A1%B8%A9%FE%B0%8C%60%FF%CB%02G%25%E5
See the revisions a few steps prior for more fine-grained information. This just
needs to be relanded because our automation doesn't like non-ASCII commit
messages.
--HG--
extra : amend_source : 0ee4e0da1ea9ada815abfe989c51030db24aac56
CLOSED TREE
Backed out changeset 28abb8af2d62 (bug 1099430)
Backed out changeset 358aa39360d5 (bug 1099430)
Backed out changeset 3313e545f4f6 (bug 1099430)
With these substitutions, it is possible to have comm-central's versions of
these files merely include the mozilla-central versions and avoid having to port
small changes to these files.
win_srcdir is used as the Windows path for the srcdir, and so it needs to use
comm-central's topsrcdir to work properly. In contrast, WIN_TOP_SRC is really
only used to define BUILD_TOOLS, which refers to files in mozilla-central/build,
and so that can and should remain the mozilla-central topsrcdir.