Improve lib template on Travis #19
Conversation
bltavares
force-pushed
the
improve-lib-template
branch
from
de36827
to
c87d830
Compare
templates/lib/before_deploy.sh
Outdated
| @@ -6,7 +6,8 @@ set -ex | |||
|
|
|||
| main() { | |||
| local src=$(pwd) \ | |||
| stage= | |||
| stage= \ | |||
| linking_args= | |||
There was a problem hiding this comment.
could we get 2 lines indentation here?
There was a problem hiding this comment.
I've updated emacs to use 2 spaces as identation, but it keeps wanting to align the variables instead of indenting it.
Should they be indented instead of aligned then?
There was a problem hiding this comment.
Yeah, I don't align any of my code; it's usually harder to have people collaborate on (unless it's enforced by something like gofmt / rustfmt).
| *) | ||
| cp target/$TARGET/release/lib$PKG_NAME.so $stage/ | ||
| ;; | ||
| esac |
There was a problem hiding this comment.
could we get 2 lines indentation here?
bltavares
force-pushed
the
improve-lib-template
branch
from
74d1d78
to
b5ada3f
Compare
|
I've used the shfmt CLI to fix indentation. Let me know if there is something else to change. |
This commit contains changes on the generated lib template to build cross-platform libs. With this changes, I was able to setup a [Travis] build with GitHub [Releases] of a cross-platform lib. It is not possible yet to build a different crate type only using command line args. It requires a modification on `Cargo.toml` to include new types of library outputs. I've already opened an issue on [cargo](rust-lang/cargo#6160) to see what should be the case here. Meanwhile, lib authors must change `Cargo.toml` and include the extra `crate-type` attribute with all the libs. Sadly, this also means that `LTO` optimisation is not available if the lib uses `lib` or `rlib` attributes. To avoid modifying the `Cargo.toml`, the sugestion would be that on a future PR we could add to the deploy script a modification on the `Cargo.toml` manifest to include the corresponding crate-type, and only such crate type for that target. This means we would be able to bring LTO and output smaller libs. Realated to: - yoshuawuyts#11 [Travis]: https://travis-ci.org/bltavares/rust-over-jna-example/builds/439439854 [Releases]: https://github.com/bltavares/rust-over-jna-example/releases/tag/initial Signed-off-by: Bruno Tavares <connect+github@bltavares.com>
bltavares
force-pushed
the
improve-lib-template
branch
from
22cf172
to
2677e11
Compare
s command `cargo` subcommand is exclusively intended to be used to help with [working arround](rust-lang/rust#51009) how crate types are defined, in order to help with cross-platform builds. It is currently [not possible](rust-lang/cargo#6160) to define a single `crate-type` override on `cargo build`, which causes libs intended to be used on other languages to compile more than one type of crate. This commit adds a dependency on this [new CLI app](https://github.com/bltavares/cargo-crate-type) to be able to workaround the limitations of Cargo. We are now able to enable the `-C lto` optimization again, as we will only compile a single type of artifact Signed-off-by: Bruno Tavares <connect+github@bltavares.com>
|
I've had the time to write a small CLI app to help to produce the correct type of lib, it being either static or dynamic. You can see the resulting run here and the artifacts here. Let me know if you would rather have this commits splits, or if there are any concerns with this extra step and dependency |
I'm not seeing any extra dependencies being pulled in; this seems all fine. I say we merge this! |
This commit contains changes on the generated lib template to build
cross-platform libs. With this changes, I was able to setup a Travis
build with GitHub Releases of a cross-platform lib.
It is not possible yet to build a different crate type only using
command line args. It requires a modification on
Cargo.tomlto includenew types of library outputs. I've already opened an issue on cargo to see what should be the case here.
Meanwhile, lib authors must change
Cargo.tomland include the extracrate-typeattribute with all the libs. Sadly, this also means thatLTOoptimisation is not available if the lib usesliborrlibattributes.
To avoid modifying the
Cargo.toml, the sugestion would be that on afuture PR we could add to the deploy script a modification on the
Cargo.tomlmanifest to include the corresponding crate-type, and onlysuch crate type for that target. This means we would be able to bring
LTO and output smaller libs.
Choose one: is this a 🐛 bug fix, a 🙋 feature, or a 🔦 documentation change?
🙋
Checklist
Context
Semver Changes