Magic-Mirror/gecko-dev
1
0
Fork 0
mirror of https://github.com/mozilla/gecko-dev.git synced 2024-10-11 20:35:50 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
18f09001d3
gecko-dev/toolkit/library/rust/Cargo.toml

46 lines
988 B
TOML
Raw Normal View History

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 04:49:26 +00:00
[package]
name = "gkrust"
version = "0.1.0"
authors = ["nobody@mozilla.org"]
license = "MPL-2.0"
description = "Rust code for libxul"
Bug 1302028 - part 5 - add bindgen feature to gecko-side Cargo.toml files for propagation to geckoservo; r=Manishearth
2017-01-20 16:33:04 +00:00
[features]
bindgen = ["gkrust-shared/bindgen"]
Bug 1322769 - Add a "servo" feature; r=manishearth MozReview-Commit-ID: A9dNTxNkl39 --HG-- extra : rebase_source : b9d115025beb00d596d34ca8d414a69b8ea2ba07 extra : source : f142ed52978bfab6407c252b7c56c53d0c3fcecd
2017-02-02 23:30:16 +00:00
servo = ["gkrust-shared/servo"]
Bug 1335525 - Update libgkrust to include webrender as an optional feature. r=froydnj MozReview-Commit-ID: 8usfSqFWkZ0
2017-02-06 16:42:52 +00:00
quantum_render = ["gkrust-shared/quantum_render"]
Bug 1346665 - P2: Import rustified cubeb_pulse.c. r=kinetik,rillian Enable by setting: media.cubeb.backend = "pulse-rust" MozReview-Commit-ID: EZXJAzN3X7c
2017-03-12 23:52:45 +00:00
cubeb_pulse_rust = ["gkrust-shared/cubeb_pulse_rust"]
Bug 1357556 - define a gecko_debug feature for gkrust*; r=emilio Servo needs to know whether C++ code is compiled with MOZ_DEBUG, and passing along an explicit feature is a better way to determine that information than relying on cfg(debug_assertions). MozReview-Commit-ID: B3XCskDQ56p --HG-- extra : rebase_source : c53cd4abb8f56701d1051c932fc9aa5cf83384f2
2017-04-20 17:54:14 +00:00
gecko_debug = ["gkrust-shared/gecko_debug"]
Bug 1261841 part 4 - Add a configuration option for enabling explicit SIMD in Rust. r=froydnj. MozReview-Commit-ID: ICifcJ9499a
2017-05-29 14:11:18 +00:00
simd-accel = ["gkrust-shared/simd-accel"]
Bug 1261841 part 2 - Use encoding_rs instead of uconv. r=emk,mystor. MozReview-Commit-ID: 15Y5GTX98bv
2017-04-27 10:27:03 +00:00
no-static-ideograph-encoder-tables = ["gkrust-shared/no-static-ideograph-encoder-tables"]
# parallel-utf8 = ["gkrust-shared/parallel-utf8"]
Bug 1302028 - part 5 - add bindgen feature to gecko-side Cargo.toml files for propagation to geckoservo; r=Manishearth
2017-01-20 16:33:04 +00:00
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 04:49:26 +00:00
[dependencies]
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 22:16:13 +00:00
gkrust-shared = { path = "shared" }
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 04:49:26 +00:00
[lib]
path = "lib.rs"
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 22:16:13 +00:00
crate-type = ["staticlib"]
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 04:49:26 +00:00
test = false
doctest = false
bench = false
doc = false
plugin = false
harness = false
# Explicitly specify what our profiles use.
[profile.dev]
opt-level = 1
rpath = false
lto = false
debug-assertions = true
Bug 1352815 - "codegen-units = 4" for Rust code in debug mode r=froydnj MozReview-Commit-ID: IIFVmijY4B3 --HG-- extra : rebase_source : 1722dba55a1759f15b82532c13f1e61affd28e9b
2017-04-02 12:17:44 +00:00
codegen-units = 4
Bug 1268727 - part 2 - compile Rust code with panic=abort; r=chmanchester
2016-08-09 22:10:19 +00:00
panic = "abort"
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 04:49:26 +00:00
[profile.release]
opt-level = 2
rpath = false
Bug 1268547 - turn on LTO support for the Rust parts of libxul; r=chmanchester
2016-08-08 22:32:34 +00:00
lto = true
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 04:49:26 +00:00
debug-assertions = false
Bug 1268727 - part 2 - compile Rust code with panic=abort; r=chmanchester
2016-08-09 22:10:19 +00:00
panic = "abort"
Reference in New Issue Copy Permalink