Add .rs as a recognized file extension in SOURCES.
Propagate that through to the Makefile backend and add a dependency
generated and an explicit rule to call $(RUSTC) to compile them.
rustc builds static libraries, not obj files. At least, if one
asks it to output an obj file, I'm not clear how to get all the
compiler-specific runtime libraries the code will expect to link
to. Therefore we generate a static library for each rust source
file (which must be a complete crate for the time being) and link
that. Because of the extension it ends up on the LIBS line in the
the corresponding .desc file.
Note that the static library does still depend on some system
libraries, e.g. -ldl -lpthread -lm on linux. Gecko already
links to all of those, so we don't keep track of it here.
Should we need to add explicit linkage for other targets,
rustc does print a list to stderr which can be parsed.
--HG--
extra : rebase_source : 9f66101fd15a649a952d5481cf9561416204272a
Without this, invoking Make in a sub-directory will fail with an error
that libs:: cannot find target `target'.
Without this patch, the Fennec Gradle and IDE build integration fails
compiling its custom targets in mobile/android/base and
mobile/android/base/locales.
--HG--
extra : rebase_source : a105072aee28e4f7693958a175d1d8ce3188b5f4
extra : source : 3232d253cf909e38da318c3ed3c04e7b5fc6a94f
Without this, invoking Make in a sub-directory will fail with an error
that libs:: cannot find target `target'.
Without this patch, the Fennec Gradle and IDE build integration fails
compiling its custom targets in mobile/android/base and
mobile/android/base/locales.
--HG--
extra : rebase_source : be5cc6764b7c1fc7a5bdc177760a709e015e02d4
Now that moz.build can see EXTRA_*COMPONENTS and NO_JS_MANIFEST, we can
move some logic from rules.mk (executed every build) to moz.build's
emitter.py (executed only at build-backend time).
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
Ryan VanderMeulen
Liang-Heng Chen
Kelly Davis
Mike Hommey
David Major
Brian O'Keefe
Lee Salzman
Carsten "Tomcat" Book
ffxbld
Ralph Giles
Nathan Froyd
Paul Adenot
JW Wang
Nick Alexander
Richard Barnes
Kartikaya Gupta
Makoto Kato
Reuben Morais
Jim Blandy
NiLuJe
Ms2ger
Alex Henrie
Cykesiopka
Chuck Lee
Gregory Szorc