mirrors/rust-lightning
1
0
Fork 0
mirror of https://github.com/lightningdevkit/rust-lightning.git synced 2025-02-24 23:08:36 +01:00
Code Issues Projects Releases Packages Wiki Activity
rust-lightning/Cargo.toml

40 lines
1 KiB
TOML
Raw Normal View History

Use workspaces to separate crates
2019-11-15 02:44:30 +00:00
[workspace]
initial checkin
2017-12-25 01:05:27 -05:00
Use workspaces to separate crates
2019-11-15 02:44:30 +00: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 10:50:54 -08:00
"lightning-block-sync",
Clean up lightning-invoice CI, license, and add to workspaces
2021-04-07 13:04:04 -04:00
"lightning-invoice",
Use workspaces to separate crates
2019-11-15 02:44:30 +00: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 17:46:11 -04:00
"lightning-persister",
Rename background-processor to lightning-... to match other crates
2021-04-13 19:39:32 -04:00
"lightning-background-processor",
Introduce graph sync crate for fast-forwarding through gossip data downloaded from a server.
2021-11-03 10:50:08 -07:00
"lightning-rapid-gossip-sync"
Use workspaces to separate crates
2019-11-15 02:44:30 +00:00
]
Move test profile to crate root, so it has effect again
2019-11-28 01:19:54 -05: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-03 23:59:44 -08:00
exclude = [
Macro for composing custom message handlers BOLT 1 specifies a custom message type range for use with experimental or application-specific messages. While a `CustomMessageHandler` can be defined to support more than one message type, defining such a handler requires a significant amount of boilerplate and can be error prone. Add a crate exporting a `composite_custom_message_handler` macro for easily composing pre-defined custom message handlers. The resulting handler can be further composed with other custom message handlers using the same macro. This requires a separate crate since the macro needs to support "or" patterns in macro_rules, which is only available in edition 2021. https://doc.rust-lang.org/edition-guide/rust-2021/or-patterns-macro-rules.html Otherwise, a crate defining a handler for a set of custom messages could not easily be reused with another custom message handler. Doing so would require explicitly duplicating the reused handlers type ids, but those may change when the crate is updated.
2023-01-03 11:24:30 -06:00
"lightning-custom-message",
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 17:32:07 +00: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-03 23:59:44 -08:00
"no-std-check",
Test MSRV builds (without dev-dependencies) in CI
2023-07-17 21:53:07 +00: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 06:03:57 +00: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-03 23:59:44 -08: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 22:15:00 +00: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 12:47:08 -04: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 22:15:00 +00: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 16:11:39 -04: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 12:47:08 -04: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 22:15:00 +00:00
lto = "off"
Specify panic = abort in profiles for lightning-c-bindings
2020-09-01 16:11:39 -04:00
LTO in release mode by default, which is really critical for C libs
2020-05-15 21:27:51 -04:00
[profile.release]
opt-level = 3
lto = true
Specify panic = abort in profiles for lightning-c-bindings
2020-09-01 16:11:39 -04:00
panic = "abort"
Reference in a new issue Copy permalink