mirrors/rust-lightning
1
0
Fork 0
mirror of https://github.com/lightningdevkit/rust-lightning.git synced 2025-01-19 14:44:01 +01:00
Code Issues Packages Projects Releases Wiki Activity
5c5d691425
rust-lightning/Cargo.toml

41 lines
1.0 KiB
TOML
Raw Normal View History

Use workspaces to separate crates
2019-11-15 03:44:30 +01:00
[workspace]
Bump MSRV to rustc 1.63.0 and edition to 2021 .. which is a reasonable common ground, also supported by Debian stable.
2023-10-24 15:16:38 +02:00
resolver = "2"
initial checkin
2017-12-25 07:05:27 +01:00
Use workspaces to separate crates
2019-11-15 03:44:30 +01:00
members = [
"lightning",
Add lightning-block-sync package and library Defines an interface and related types for fetching block headers and data from a block source (e.g., Bitcoin Core). Used to keep lightning in sync with chain activity.
2021-01-11 19:50:54 +01:00
"lightning-block-sync",
Clean up lightning-invoice CI, license, and add to workspaces
2021-04-07 19:04:04 +02:00
"lightning-invoice",
Use workspaces to separate crates
2019-11-15 03:44:30 +01:00
"lightning-net-tokio",
Add a sample module FilesystemPersister. Intended to be a cross-platform implementation of the channelmonitor::Persist trait. This adds a new lightning-persister crate, that uses the newly exposed lightning crate's test utilities. Notably, this crate is pretty small right now. However, due to future plans to add more data persistence (e.g. persisting the ChannelManager, etc) and a desire to avoid pulling in filesystem usage into the core lightning package, it is best for it to be separated out. Note: Windows necessitates the use of OpenOptions with the `write` permission enabled to `sync_all` on a newly opened channel's data file.
2020-09-16 23:46:11 +02:00
"lightning-persister",
Rename background-processor to lightning-... to match other crates
2021-04-14 01:39:32 +02:00
"lightning-background-processor",
Move `lightning-custom-message` to main workspace Since we now have a consistent MSRV and edition, we can move `lightning-custom-message` to the main workspace.
2023-11-06 11:50:19 +01:00
"lightning-rapid-gossip-sync",
"lightning-custom-message",
Use workspaces to separate crates
2019-11-15 03:44:30 +01:00
]
Move test profile to crate root, so it has effect again
2019-11-28 07:19:54 +01:00
Check for no-std compatibility across dependencies To ensure no-std is honored across dependencies, add a crate depending on lightning crates supporting no-std. This should ensure any regressions are caught. Otherwise, cargo doesn't seem to catch some incompatibilities (e.g., f64::log10 unavailable in core) and seemingly across other dependencies as describe here: https://blog.dbrgn.ch/2019/12/24/testing-for-no-std-compatibility/
2022-03-04 08:59:44 +01:00
exclude = [
Move `lightning-transaction-sync` out of the main workspace Because `lightning-transaction-sync` does not have an MSRV (and because its dev-dependencies are huge), we can't build it by default when devs run `cargo test`, so it is moved out of the top-level workspace.
2023-02-27 18:32:07 +01:00
"lightning-transaction-sync",
Check for no-std compatibility across dependencies To ensure no-std is honored across dependencies, add a crate depending on lightning crates supporting no-std. This should ensure any regressions are caught. Otherwise, cargo doesn't seem to catch some incompatibilities (e.g., f64::log10 unavailable in core) and seemingly across other dependencies as describe here: https://blog.dbrgn.ch/2019/12/24/testing-for-no-std-compatibility/
2022-03-04 08:59:44 +01:00
"no-std-check",
Test MSRV builds (without dev-dependencies) in CI
2023-07-17 23:53:07 +02:00
"msrv-no-dev-deps-check",
Replace std's unmaintained bench with criterion Rather than using the std benchmark framework (which isn't maintained and is unlikely to get any further maintenance), we swap for criterion, which at least gets us a variable number of test runs so our benchmarks don't take forever. We also fix the RGS benchmark to pass now that the file in use is stale compared to today's date.
2023-05-11 08:03:57 +02:00
"bench",
Check for no-std compatibility across dependencies To ensure no-std is honored across dependencies, add a crate depending on lightning crates supporting no-std. This should ensure any regressions are caught. Otherwise, cargo doesn't seem to catch some incompatibilities (e.g., f64::log10 unavailable in core) and seemingly across other dependencies as describe here: https://blog.dbrgn.ch/2019/12/24/testing-for-no-std-compatibility/
2022-03-04 08:59:44 +01:00
]
Disable LTO builds in tests (and bump deps to -O2) For some reason rustc, at some point, decided that our optimization of dependencies implies we want to also build with LTO. This causes our test builds to take substantially longer to compile, even with only a trivial change. By hard-disabling this (even keeping the optimization of the test and in-tree libraries enabled) the time required to build with only a trivial change to `functional_tests.rs` goes from 0m25.635s wall clock/1m14.220s CPU time to 0m17.841s wall clock/0m17.828s CPU time on my i7-13700K on rustc 1.63. The changes in test execution time appear to be within noise. While we're at it, we also bump dependencies to build with -O2 because their build time is now substantially reduced cost.
2023-02-24 23:15:00 +01:00
# Our tests do actual crypto and lots of work, the tradeoff for -O2 is well
# worth it. Note that we only apply optimizations to dependencies, not workspace
# crates themselves.
Fix passing -O1 to build from `cargo test` In 9e03087d6acbc876a5ad1c9b9d8746bf18d5ca86 we started setting `opt-level` only on profile.test and not profile.dev. When that commit was authored I tested only that rustc was being called with opt-level set in its flags, not that the resulted run ran at the speed I expected. It seems profile.test isn't applied properly to dependencies or so, resulting in tests running much slower than they do at profile.dev.opt-level=1.
2020-10-05 18:47:08 +02:00
# https://doc.rust-lang.org/cargo/reference/profiles.html#profile-selection
Disable LTO builds in tests (and bump deps to -O2) For some reason rustc, at some point, decided that our optimization of dependencies implies we want to also build with LTO. This causes our test builds to take substantially longer to compile, even with only a trivial change. By hard-disabling this (even keeping the optimization of the test and in-tree libraries enabled) the time required to build with only a trivial change to `functional_tests.rs` goes from 0m25.635s wall clock/1m14.220s CPU time to 0m17.841s wall clock/0m17.828s CPU time on my i7-13700K on rustc 1.63. The changes in test execution time appear to be within noise. While we're at it, we also bump dependencies to build with -O2 because their build time is now substantially reduced cost.
2023-02-24 23:15:00 +01:00
[profile.dev.package."*"]
opt-level = 2
# It appears some minimal optimizations are required to inline many std methods
# and reduce the otherwise-substantial time spent in std self-checks. We do so
# here but ensure we keep LTO disabled as otherwise we're re-optimizing all our
# dependencies every time we make any local changes.
Specify panic = abort in profiles for lightning-c-bindings
2020-09-01 22:11:39 +02:00
[profile.dev]
Fix passing -O1 to build from `cargo test` In 9e03087d6acbc876a5ad1c9b9d8746bf18d5ca86 we started setting `opt-level` only on profile.test and not profile.dev. When that commit was authored I tested only that rustc was being called with opt-level set in its flags, not that the resulted run ran at the speed I expected. It seems profile.test isn't applied properly to dependencies or so, resulting in tests running much slower than they do at profile.dev.opt-level=1.
2020-10-05 18:47:08 +02:00
opt-level = 1
Disable LTO builds in tests (and bump deps to -O2) For some reason rustc, at some point, decided that our optimization of dependencies implies we want to also build with LTO. This causes our test builds to take substantially longer to compile, even with only a trivial change. By hard-disabling this (even keeping the optimization of the test and in-tree libraries enabled) the time required to build with only a trivial change to `functional_tests.rs` goes from 0m25.635s wall clock/1m14.220s CPU time to 0m17.841s wall clock/0m17.828s CPU time on my i7-13700K on rustc 1.63. The changes in test execution time appear to be within noise. While we're at it, we also bump dependencies to build with -O2 because their build time is now substantially reduced cost.
2023-02-24 23:15:00 +01:00
lto = "off"
Specify panic = abort in profiles for lightning-c-bindings
2020-09-01 22:11:39 +02:00
LTO in release mode by default, which is really critical for C libs
2020-05-16 03:27:51 +02:00
[profile.release]
opt-level = 3
lto = true
Specify panic = abort in profiles for lightning-c-bindings
2020-09-01 22:11:39 +02:00
panic = "abort"
Reference in New Issue Copy Permalink