Граф коммитов

1248 Коммитов

Автор SHA1 Сообщение Дата
Nathan Froyd 55243ce768 Bug 1300835 - enable --disable-optimize --enable-debug to DTRT for Rust code; r=ted.mielczarek 2016-11-21 17:39:39 -05:00
Gregory Szorc 389dbcf95f Bug 1315785 - Invoke cargo with --color=always when original stdout is a TTY; r=glandium
Combined with the previous patch that sets MACH_STDOUT_ISATTY, the
practical effect of this patch is that cargo is invoked with
`--color=always` when mach was attached to a TTY and colorized output
is sent to the terminal.

Note: this doesn't work with Rust/Cargo 1.10 for reasons unknown to me.
It appears there was a bug with Rust/Cargo because `--color=never` still
sent colorized output on that version! Cargo/Rust 1.12.1 works fine.

MozReview-Commit-ID: 6uXS3t3413i

--HG--
extra : rebase_source : 72df6e8248cb14c96850964f694576c7fd2f5fbb
2016-11-07 13:46:15 -08:00
Aaron Klotz a426b005cc Bug 1310841: Modify build rules to allow specification of a manifest for Windows DLLs; r=gps
MozReview-Commit-ID: EdY8Kx8irYW

--HG--
extra : histedit_source : 2c62d93279b54c30840910fb3fe54f9276a80f01
2016-10-17 16:03:11 -06:00
Cameron McCormack 4378d41370 Bug 1310939 - Pass $(CARGOFLAGS) to cargo invocations so cargo flags can be passed from a .mozconfig file. r=froydnj
MozReview-Commit-ID: A5GNTzS0BTM

--HG--
extra : amend_source : 01749f41a239949510bbc1e90a3324c934cfe86a
2016-10-18 16:04:57 +08:00
Ted Mielczarek e9130abab5 bug 1305731 - Revert workaround from bug 1301751 now that we have updated to Rust 1.12. r=froydnj
MozReview-Commit-ID: 3akbELExfKT

--HG--
extra : rebase_source : 0308214bae6eb683df65991fc91d41679acd3530
2016-10-17 10:47:30 -04:00
Nathan Froyd e818915fae Bug 1304815 - rearrange Rust crate structure for newer Rust releases; r=ted.mielczarek
In our current Rust world, we have the following dependency structure:

  xul.so --------------------------+
                                   |
  xul-gtest.so -+--> xul.a --------+-> gkrust
                |
                +--> gkrust-gtest

This structure results in link errors with multiply-defined symbols
between gkrust-gtest and gkrust with newer Rust releases when linking
xul-gtest.so.  So we have to do something different.

Our new structure is:

  xul.so --------------------------+
                                   |
  xul-gtest.so -+--> xul.a --------+-> gkrust --+-> gkrust-shared
                |                               |
                +--> gkrust-gtest --------------+

and we enforce that a given shared library can only have at most one
Rust library that it depends on.  Said Rust library is assumed to
include all significant Rust dependencies of the dependent static
libraries as well.  (In the above structure, gkrust is simply a wrapper
around gkrust-shared, so gkrust-gtest doesn't have to include gkrust as
a dependency.)
2016-10-15 18:16:13 -04:00
Andrew Halberstadt 6b48ddc0b0 Bug 1304593 - Use |mach python-test| to run python unittests from make check, r=ted
Currently make check loops over all directories and runs each test file in PYTHON_UNIT_TESTS
individually. This patch instead creates a single top-level check target that runs
|mach python-tests|. This should make automation more similar to running locally, be a bit
quicker and make it easier to pull python tests out of make check completely at a future date.

MozReview-Commit-ID: 4Hg4zdFyc61

--HG--
extra : rebase_source : 31d0c38a76c11b75d3bf569f2bf22a0666161726
2016-09-26 15:29:02 -04:00
Ted Mielczarek abdba70d60 bug 1301751 - work around llvm-dsymutil crash by building rust with debuginfo=1 instead of -g. r=froydnj
MozReview-Commit-ID: 5pK8okLw0Cl

--HG--
extra : rebase_source : f1c366ae3751bcd70272e77c7754fb4adeafdd7b
2016-09-27 06:24:24 -04:00
Chris Manchester bb8ff6012c Bug 1262155 - Always pass defines when compiling SOBJS. r=ted
This is relevant when attempting to build libffi with our build system
(libffi expects its assembly sources to be pre-processed).

MozReview-Commit-ID: J6mCUkYYjQh
2016-09-21 12:04:08 -07:00
Michael Layzell 05bd5a1076 Bug 1300208 - Allow specifying multiple rust crates to mozbuild within the same FINAL_LIBRARY, r=froydnj
MozReview-Commit-ID: IIjV4Kg7wOv
2016-09-20 11:26:43 -04:00
Nathan Froyd f7fb6722a6 Bug 1231764 - part 6 - build rust code via cargo; r=chmanchester
This patch is really two separate changes.

The first change is that rust crates are large, standalone entities that
may contain multitudes of source files.  It therefore doesn't make sense
to keep them in SOURCES, as we have been doing.  Moving to use cargo
will require a higher-level approach, which suggests that we need a
different, higher-level representation for Rust sources in the build
system.

The representation here is to have the build system refer to things
defined in Cargo.toml files as the entities dealt with in the build
system, and let Cargo deal with the details of actually building things.
This approach means that adding a new crate to an existing library just
requires editing Rust and Cargo.toml files, rather than dealing with
moz.build, which seems more natural to Rust programmers.  By having the
source files for libraries (and binaries in subsequent iterations of
this support) checked in to the tree, we can also take advantage of
Cargo.lock files.

The second is that we switch the core build system over to building via
cargo, rather than invoking rustc directly.

We also clean up a number of leftover things from the Old Way of doing
things.  A number of tests are added to confirm that we'll only permit
crates to be built that have dependencies in-tree.
2016-08-06 00:49:26 -04:00
Nathan Froyd 4fb1a7545d Bug 1231764 - part 0 - only link librul once; r=chmanchester
Through an oversight, we listed librul.a twice when linking libxul: once
as part of the "objects" we were linking, and once as a static library.
This duplication is unnecessary and would cause problems later when we
try to generate librul.a via cargo, as cargo will put it someplace
different from where we expect and the two names will conflict.  Let's
have rules.mk be the single source of truth for how librul.a is named,
and then the code to link libxul can simply refer to that name.
2016-08-06 00:49:26 -04:00
Wes Kocher 9605851be0 Backed out 7 changesets (bug 1231764) for apparently causing linux debug wpt bustage
Backed out changeset 4b71272c92cf (bug 1231764)
Backed out changeset 234d8a930afa (bug 1231764)
Backed out changeset f9b204c2f5a7 (bug 1231764)
Backed out changeset f933119e57e4 (bug 1231764)
Backed out changeset e3af0b1d3473 (bug 1231764)
Backed out changeset 643b03aae1dd (bug 1231764)
Backed out changeset a945dbf63410 (bug 1231764)

--HG--
extra : rebase_source : e71360fa4b5e3e74859c82e74e183e13e6211c4c
2016-08-03 16:27:06 -07:00
Nathan Froyd 6b2618fb44 Bug 1231764 - part 6 - build rust code via cargo; r=chmanchester
This patch is really two separate changes.

The first change is that rust crates are large, standalone entities that
may contain multitudes of source files.  It therefore doesn't make sense
to keep them in SOURCES, as we have been doing.  Moving to use cargo
will require a higher-level approach, which suggests that we need a
different, higher-level representation for Rust sources in the build
system.

The representation here is to have the build system refer to things
defined in Cargo.toml files as the entities dealt with in the build
system, and let Cargo deal with the details of actually building things.
This approach means that adding a new crate to an existing library just
requires editing Rust and Cargo.toml files, rather than dealing with
moz.build, which seems more natural to Rust programmers.  By having the
source files for libraries (and binaries in subsequent iterations of
this support) checked in to the tree, we can also take advantage of
Cargo.lock files.

The second is that we switch the core build system over to building via
cargo, rather than invoking rustc directly.

We also clean up a number of leftover things from the Old Way of doing
things.  A number of tests are added to confirm that we'll only permit
crates to be built that have dependencies in-tree.
2016-08-03 19:40:41 -04:00
Nathan Froyd a79d68b929 Bug 1231764 - part 0 - only link librul once; r=chmanchester
Through an oversight, we listed librul.a twice when linking libxul: once
as part of the "objects" we were linking, and once as a static library.
This duplication is unnecessary and would cause problems later when we
try to generate librul.a via cargo, as cargo will put it someplace
different from where we expect and the two names will conflict.  Let's
have rules.mk be the single source of truth for how librul.a is named,
and then the code to link libxul can simply refer to that name.
2016-08-03 19:40:41 -04:00
Mike Hommey 02e5baaf74 Bug 1289246 - Do not hardcode mt.exe as the Manifest Tool. r=chmanchester
Configure uses the value of the MT environment variable before falling back
to mt(.exe), but the build system was completely ignoring the MT
environment variable.

--HG--
extra : rebase_source : 8c9b43aeb08493ae5bd6d6361f4f18f097ea0553
2016-07-22 15:56:26 +09:00
Ted Mielczarek 82d77574ff bug 1266368 - move rust.m4 to configure. r=glandium
MozReview-Commit-ID: 9ol2nMYM0a0

--HG--
extra : rebase_source : 3f3feeac941791d081e09ebb096a3e052540a52c
2016-05-16 15:27:37 -04:00
Mike Shal 5ab92bb3fa Bug 1252804 - remove TARGET_LOCAL_INCLUDES; r=ted
MozReview-Commit-ID: 6s1SWINNMM9

--HG--
extra : rebase_source : 3c64cc907a41215be454ccae4230d3d216e097d9
2016-04-29 17:09:57 -04:00
Nathan Froyd 82c6f5d7a7 Bug 1163224 - add build system support for multiple Rust crates; r=glandium
Our current build system support for Rust compiles any Rust crate into a
so-called staticlib, which is a static library (.a file) that includes
the Rust runtime. That staticlib is then linked into libxul. For
supporting multiple crates, this approach breaks down, as linking
multiple copies of the Rust runtime is going to fail.

For supporting multiple crates, the approach taken here is to compile
each crate into a so-called rlib, which is essentially a staticlib
without the Rust runtime linked in. The build system takes note of
every crate destined for linking with libxul (treating them like static
libraries generated from C/C++ files), and generates a super-crate,
whimsically named "rul", that is compiled as a staticlib (so as to
include the Rust runtime) and then linked into libxul. Thus only one
copy of the Rust runtime is included, and the Rust compiler can take
care of any inter-crate dependencies.

This patch currently only supports Rust code in shared libraries, not in
binaries.
2016-04-21 09:54:01 -04:00
Sebastian Hengst 364386e3cf Backed out changeset cb4b18566f30 and 7c4d19e3376f (bug 1163224) for build bustage. r=backout on a CLOSED TREE 2016-04-11 19:43:04 +02:00
Nathan Froyd e136c9ac20 Bug 1163224 - fix typo in creating global crate dependencies; r=me
Hoping the added Rust will let us reopen this CLOSED TREE.
2016-04-11 12:42:36 -04:00
Nathan Froyd 45af5cd66c Bug 1163224 - add build system support for multiple Rust crates; r=glandium
Our current build system support for Rust compiles any Rust crate into a
so-called staticlib, which is a static library (.a file) that includes
the Rust runtime.  That staticlib is then linked into libxul.  For
supporting multiple crates, this approach breaks down, as linking
multiple copies of the Rust runtime is going to fail.

For supporting multiple crates, the approach taken here is to compile
each crate into a so-called rlib, which is essentially a staticlib
without the Rust runtime linked in.  The build system takes note of
every crate destined for linking with libxul (treating them like static
libraries generated from C/C++ files), and generates a super-crate,
whimsically named "rul", that is compiled as a staticlib (so as to
include the Rust runtime) and then linked into libxul.  Thus only one
copy of the Rust runtime is included, and the Rust compiler can take
care of any inter-crate dependencies.

This patch currently only supports Rust code in shared libraries, not in
binaries.  The handling for the rul crate is placed in the common
backend, with a special hook for derived backends to handle shared
library objects.
2016-04-11 11:05:44 -05:00
Gregory Szorc 8bec49cc68 Bug 1262569 - Do not print individual source targets being built; r=ted
Multiple people have complained that the build output of printing the
source files being built adds little value. I agree. The extra output
doesn't give really helpful progress info because sources can be built
in non-deterministic order. Furthermore, the extra output hides useful
output like compiler warnings.

This patch makes the default build system output even less verbose. We
no longer print the individual source targets when they are built. We do
still print the targets for binaries, so some sense of progress can be
inferred.

If people like verbosity, they can export the undocumented
BUILD_VERBOSE_LOG environment variable can be set to restore the old
behavior.

MozReview-Commit-ID: KeaeJJkjPJn

--HG--
extra : rebase_source : a90b4b82eeef48d9bd896b5c12907ce05a650d4d
2016-04-06 16:49:55 -04:00
Mike Hommey 2a512468b1 Bug 1260998 - Add support for HOST_CPPFLAGS for consistency. r=nalexander 2016-04-01 09:43:26 +09:00
Mike Hommey 84027af8da Bug 1256507 - Remove --enable-xterm-updates. r=gps
It's an opt-in flag that allows to display where the build is in
terminal window titles. The fact that it's opt-in and likely unknown
makes it very low-value, and the fact that it was added in an era where
builds were not very well parallelized made it have a meaning, but now
that builds are parallelized, its meaningfulness is diminished.

Let's just remove it.
2016-03-15 16:40:15 +09:00
Mike Hommey d464f29e5f Bug 1255813 - Remove build system support for Solaris, HPUX and AIX. r=ted 2016-03-15 07:34:50 +09:00
Ted Mielczarek 5c634ab869 bug 1248016 - make ASFILES rules work with .s/.asm, get rid of ASM_SUFFIX. r=mshal
MozReview-Commit-ID: 1MK0Kud51vR

--HG--
extra : rebase_source : de7a7f11bfbbac1e8eccc34de39dd2d88d803b03
extra : amend_source : d7eddb71b050e0576e783c6ce8c67f66cfd88e13
2016-03-01 13:47:19 -05:00
Mike Shal 053369e67e Bug 1253431 part 7 - Remove SDK_BINARY; r=gps
MozReview-Commit-ID: 4RmjsX966Qh

--HG--
extra : rebase_source : 0d9d94ed98ae8f1cfb9d5787edc1336ce1ee6785
2016-03-03 14:23:57 -05:00
Myk Melez db9a40ca42 Bug 1238079 - remove the desktop web runtime; r=fabrice,mossop,gps,jryans,jmaher,marco 2016-03-07 13:33:12 -08:00
Ms2ger 2351d7e46d Bug 1252093 - Move AUTOCFG_JS_EXPORTS to moz.build; r=ted 2016-03-01 09:17:29 +01:00
Nathan Froyd d75a7f55af Bug 1249103 - remove support for MOZ_POST_DSO_LIB_COMMAND; r=mshal
Nothing uses this variable.  blame suggests that it was used for HP-UX
once upon a time.  The companion variable, MOZ_POST_PROGRAM_COMMAND, is
only used by HP-UX, but as we're not wholesale removing HP-UX
support (yet), we should leave MOZ_POST_PROGRAM_COMMAND alone.
2016-02-17 15:17:21 -05:00
Mike Hommey e50a6cfd7b Bug 1239217 - Make the RecursiveMake build system create backend files generically. r=gps
The current rule is only for "backend.RecursiveMakeBackend", but, with
the current default of generating both the RecursiveMake and FasterMake
backends, the command creates/refreshes both backends. This is, in fact,
how the FasterMake backend is refreshed in most cases.

Moreover, with an hybrid backends, the generated file is not
"backend.RecursiveMakeBackend" anymore, so we need a more generic way to
handle this.

Furthermore, it's not necessarily desirable for all backends to have a
dependency file to handle the dependencies to refresh the backend, so
generate a plain list instead. This has the side effect of making `mach
build-backend --diff` more readable for changes to that file.

Finally, make the backend.* files created like any other backend file,
such that its diff appears in the `mach build-backend --diff` output.
2016-01-22 15:43:24 +09:00
Mike Hommey e9ce9ca165 Bug 1241421 - Remove jar.mn with no JAR_MANIFESTS check in config/rules.mk. r=mshal
The same check exists in the emitter code anyways.
2016-01-22 07:00:23 +09:00
Jacek Caban ea0edf0971 Bug 1239672 - Fixed symbols file support on mingw. r=glandium 2016-01-21 13:39:41 +01:00
Mike Hommey 27f3aa7c34 Bug 1241022 - Move GENERATED_FILES. r=gps
GENERATED_FILES impacts the export tier through the config/rules.mk
definitions, now moved to the backend itself, so that everything is
close to each other.
2016-01-21 13:54:03 +09:00
Mike Hommey dd60f8bf2c Backout changeset de0a7a1cdc4a from bug 1240660 for make package bustage on a CLOSED TREE 2016-01-20 08:03:58 +09:00
Mike Hommey 299b5dc832 Bug 1240660 - Move jar_maker to the misc tier, now that ordering does't matter. r=gps 2016-01-20 07:24:40 +09:00
Dan Minor 30f2bba053 bug 1237619: Record build objects in resource_usage.json r=gps
Collecting the list of object files compiled, while not ideal, will give us
some indication of how much work was involved in the build. This will help
with analyzing the data.

--HG--
extra : rebase_source : e9861ed5c0766e3ee8038dbec0b9267022c523eb
2016-01-12 14:00:24 -05:00
Mike Hommey d5c0c5233a Bug 1235733 - Use absolute paths for include paths. r=gps
Limit ourselves to include paths for now, because there are tricky things
involved in making this globally.

While here, use shell_quote instead of manual quoting for those paths.
2015-12-31 08:10:02 +09:00
Mike Hommey e0c501a1c1 Bug 1235738 - Move MOZ_DEBUG_DEFINES to build frontend. r=gps
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.
2015-12-31 07:27:23 +09:00
Mike Hommey 54704ce9a1 Bug 1235132 - Add support for a more-or-less cross-platform symbols file. r=gps
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.
2015-12-31 07:22:04 +09:00
Mike Hommey d5126527fe Bug 1235021 - Always use the % marker for preprocessed css files. r=gps
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).
2015-12-31 07:06:11 +09:00
Mike Hommey d7478b6b1e Bug 1234955 - Make TEST_DIRS a SPECIAL_VARIABLE. r=gps
Using TEST_DIRS is nothing more than a shortcut for

if CONFIG['ENABLE_TESTS']:
    DIRS += [...]

As such, we might as well remove it being a separate variable, and use some
Context magic to just fill DIRS when ENABLE_TESTS is set.

The security/manager/ssl/tests/unit/moz.build change ensures that the order
of DIRS before the change is kept, not because it matters, but because it
allows to confirm that nothing else is modified by this change.
2015-12-24 13:12:49 +09:00
Nathan Froyd bd48dbd1fc Bug 1208566 - emit proper dependencies when compiling Rust sources; r=mshal 2015-12-17 12:14:33 -08:00
Wes Kocher 5f38bdeff2 Backed out 2 changesets (bug 1208566) for breaking mulet builds
Backed out changeset a5618a5cbc7f (bug 1208566)
Backed out changeset f3fd530324ee (bug 1208566)

--HG--
extra : commitid : DaxmN4TLzwv
2015-12-17 09:34:33 -08:00
Nathan Froyd aa7ce205e6 Bug 1208566 - emit proper dependencies when compiling Rust sources; r=mshal 2015-12-17 08:25:03 -08:00
Mike Hommey 158e08c29b Bug 1230355 - Remove include_deps. r=mshal
We used to use include_deps to trigger a fast-path in pymake, but we don't
use pymake anymore, so we can use normal includes now.
2015-12-09 19:23:53 +09:00
Mike Hommey 3b9cda439c Bug 1229241 - Use FINAL_TARGET{,_PP}_FILES for JS_PREFERENCE{,_PP}_FILES. r=gps 2015-12-01 13:57:52 +09:00
Mike Hommey 861b5a242a Bug 1229241 - Redirect EXTRA{_PP}_COMPONENTS to FINAL_TARGET{,_PP}_FILES.components. r=gps 2015-12-01 13:57:52 +09:00
Mike Hommey 3a04b1f8dc Bug 1228444 - Make DIST_FILES a HierarchicalStringList, like FINAL_TARGET_FILES. r=gps 2015-12-01 08:25:22 +09:00