search

HMIProject / open62541-sys

2 stars 2 forks source link

Only include selected files and directories to reduce packaged size #5

Closed uklotzde closed 4 months ago

uklotzde commented 4 months ago

cargo package

uklotzde commented 4 months ago

Packaged 603 files, 93.5MiB (6.1MiB compressed)

sgoll commented 4 months ago

This pull request seems to combine several things, maybe it's best to split it up;

[^1]: In favor of latest version from dtolnay/rust-toolchain

Regarding the last step, I'm not sure whether it's worth the risk. How can we make sure that we don't accidentally omit files from open62541 that are part of an optional build step? For example, open62541/deps/ua-nodeset/ may be empty. I'm not sure if there are other parts of the library that behave in this way as well.

uklotzde commented 4 months ago

How can we make sure that we don't accidentally omit files from open62541 that are part of an optional build step? For example, open62541/deps/ua-nodeset/ may be empty. I'm not sure if there are other parts of the library that behave in this way as well.

Footnotes

1. In favor of latest version from [dtolnay/rust-toolchain](https://github.com/dtolnay/rust-toolchain) [↩](#user-content-fnref-1-9348e4fad4be488632390b06ed260f23)
sgoll commented 4 months ago
  • Build options of the C library are controlled by build.rs.

Obviously.

  • The cargo package step builds the binary crate and ensures that the build succeeds for everyone, i.e. from the bundled contents.

Obviously.

I was thinking one step ahead: when at some point, we decide to upgrade the bundled open6254 version, how much risk is there that we accidentally fail to include an optional dependency because we accidentally excluded too many files from the source directory?

Can you describe how you ended up with the current selection of include/exclude paths? Is this something that would need to be reexamined every time we upgrade the bundled open62541 version?

How do you explain the huge number of files that can be excluded (seemingly safely) from the build? 3491 files versus 603 files.

sgoll commented 4 months ago

PS: My reasoning goes like this: my guess is that open62541 does not expect to find half its files missing. And we probably will not get any guarantees that it will continue to behave the way it does right now in future versions.

uklotzde commented 4 months ago

I was thinking one step ahead: when at some point, we decide to upgrade the bundled open6254 version, how much risk is there that we accidentally fail to include an optional dependency because we accidentally excluded too many files from the source directory?

Both the included sources and the build might need to be adjusted when updating the bundled C library. This is expected and not a big deal. The CI build ensures that the crate remains self-contained and nothing is missing.

Can you describe how you ended up with the current selection of include/exclude paths? Is this something that would need to be reexamined every time we upgrade the bundled open62541 version?

How do you explain the huge number of files that can be excluded (seemingly safely) from the build? 3491 files versus 603 files.

Trial and error and checking the CMakeLists.txt file. There are many features that we don't use like the experimental MQTT pubsub option, example code, tests, ...

Unfortunately the C library is not designed for redistributing a minimal subset of the repo just for building the library, e.g. the doc generator is unconditionally included even though it is not needed. The complex set of glob patterns reveals that this use case has never been considered. Should be addressed upstream, but I don't have any stake in that.

uklotzde commented 4 months ago

Packaging commonly involves pruning. Even 6 MB is still way too much for this crate.

The current limit for uploads is 10 MB.

You can inspect the generated .crate file in the target/package directory. crates.io currently has a 10MB size limit on the .crate file.