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.
This change allows us to use use MOZILLA_DIR even for changes in config.mk. The
corollary is that comm-central needs to define MOZILLA_DIR before calling into
baseconfig.mk, which it already does.
The change to the test Makefile is needed since it decides to skip including
config.mk, and hence baseconfig.mk, where it would need to grab the MOZILLA_DIR
declaration.
buildlist invocations are slow and can occur in parallel since the
underlying program obtains a lock on the modified file.
Moving the XPT-related buildlist invocation from the serial libs tier to
the parallel misc tier decreased my no-op build time on OS X from 43.5s
to 37.0s.
--HG--
extra : rebase_source : 7d274024c401b1ecfbc771424a69eb487808fcbf
The installation rule for EXTRA_JS_MODULES and EXTRA_PP_JS_MODULES
became unused after b961ba8f0892 (bug 1044162). We remove the dead code.
--HG--
extra : rebase_source : 40adf7514d15ae4ba5bbfe3ac101061657aac841
This used to be necessary to avoid the conflicting names between import
libraries and static libraries, but that's now prevented by the whole
moz.build machinery.
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.
This hack has actually not been actively used since sqlite, nss and nspr are
all folded together, because no shared library is actually linked in
db/sqlite3/src.
Since essentially everything is linked to libmozglue and libmozglue takes
precedence in symbol resolution in our dynamic linker, there is no need
to wrap most symbols. PR_GetEnv/PR_SetEnv still needs wrapping because
there's no other way to actually wrap the calls from NSPR itself and NSS,
as well as the symbols wrapped because our dynamic linker can't find them
in system libraries on some devices because they're weak.
Ever since bug 969164, the js build system, when building gecko (not when
building standalone) uses a autoconf-js.mk file for its config.
One of the suboptimal ways we have to retrigger builds when the build
configuration changes (changes to e.g. configure.in can do that) is to
make most things depend on autoconf.mk. Which unfortunately doesn't
account for the fact the js/src subdirectory uses a different file.
In practice, this means that some classes of changes to the js build
system, not accompanied with toplevel build system changes may no
trigger the corresponding rebuilds in the js subtree on incremental
builds.
Currently, when there is both an expandlibs descriptor and an actual static
library, expandlibs picks the static library. This has the side effect that
if there are object files in the static library that aren't directly used,
they're dropped when linking, even when they export symbols that would be
exported in the final linked binary.
In most cases in the code base, files are not dropped that way. The most
notable counter-example is xpcomglue, where actually not dropping files
leads to link failure because of missing symbols those files reference
(yes, that would tend to say the glue is broken in some way).
On the opposite side, there is mozglue, which does have both a descriptor
and a static library (the latter being necessary for the SDK), and that
linking as a static library drops files that shouldn't be dropped (like
jemalloc). We're currently relying on -Wl,--whole-archive for those files
not to be dropped, but that won't really be possible without much hassle
in a world where mozglue dependencies live in moz.build land.
Switching expandlibs to use descriptors when they exist, even when there
is a static library (so, the opposite of the current behavior) allows to
drop -Wl,--whole-archive and prepare for a better future. However, as
mentioned, xpcomglue does still require to be linked through the static
library, so we need to make it a static library only.
To achieve that, we make NO_EXPAND_LIBS now actually mean no expandlibs
and use that to build the various different xpcomglues.
Incidentally, this makes the build fail because stdc++compat.o then appears
twice on the libxul linkage command line. This, in turn, is because
widget/xremoteclient creates both a program and an intermediate library for
libxul. The Program() template adds stdc++compat to the directory data,
which ends up being added to libxul as well. The same kind of issue arises
when linking the gtest-enabled libxul.
While eventually we'll be able to avoid those problems, it's not the case
yet, so work around the issue by making expand-libs skip .desc files that
appear multiple times.
When "speex/speex_resampler.h" was included, another exported header (in
dist/include) would find the speex/speex_resampler.h in dist/include before
dist/system_wrappers. Visibility of undefined symbols depended on the order
of includes.
This patch changes includes to <speex/speex_resampler.h> so that
WRAP_SYSTEM_INCLUDES works as expected but removes the wrapper when not using
GKMEDIAS_SHARED_LIBRARY.
--HG--
extra : rebase_source : 93ca1dbdd6b489647624326e78539f44c60d0b34
As a first step, this moves PYTHON_UNIT_TESTS to moz.build as a passthru
variable. In the future, we could hook it up to |mach test|.
The __init__.py files may not need to be in the list, but I don't want to
change the list here.
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.
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
Mike Hommey
Cykesiopka
Chuck Lee
Gregory Szorc
Steve Fink
ffxbld
Brian Smith
Brian O'Keefe
Phil Ringnalda
Ms2ger
Nicholas Nethercote
Martin Stransky
Axel Hecht
Michael Wu
Nathan Froyd
Masatoshi Kimura
awake
Joshua Cranmer
Ben Hearsum
Nick Alexander
Carsten "Tomcat" Book
Wes Kocher
Jan Beich
David Major
Ehsan Akhgari
Tooru Fujisawa
Richard Barnes
David Keeler
David Cooper
Jonathan Kew
Ed Morley
Robert Strong
Stephen Pohl
Gian-Carlo Pascutto
L. David Baron
Jacek Caban
Terrence Cole
Timothy Arceri
Jan de Mooij
Christian Holler
Chris Kitching
Garrett Robinson
Mike Shal
Steffen Michalke
Ian Neal
Karl Tomlinson
Neil Rashbrook
Mukilan Thiyagarajan
Brian R. Bondy
Ryan VanderMeulen
Wes Johnston
Randell Jesup
Anthony Jones
Robert O'Callahan
Makoto Kato
Trevor Saunders
Jan Beich
Jeff Walden
ABE Hiroki (hATrayflood)
Mozilla Release Engineering
Ted Mielczarek
Ralph Giles