Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Generate library templates using --lib #11

Open
yoshuawuyts opened this issue Sep 13, 2018 · 6 comments
Open

Generate library templates using --lib #11

yoshuawuyts opened this issue Sep 13, 2018 · 6 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@yoshuawuyts
Copy link
Owner

Feature Request

Summary

In addition to building binaries, we should be able to build libraries too.

Motivation

This is useful for targeting non-cargo targets such as Android, iOS, and WASM. An example use case for this was brought up in datrs/hypercore#36 (comment), where we're trying to build .so files targeting Android.

Guide-level explanation

When someone wants to use crossgen to build libraries, they can run:

$ crossgen --lib

And it'll setup a base version of crossgen, targeting most common platforms.

Reference-level explanation

  1. We should add a lib: bool flag to the CLI.
  2. We should create separate travis templates for CLI
  3. We should create a separate generator method for lib; giving us a choice of gen_bin() and gen_lib() from the lib.rs interface.
  4. main.rs should choose between the gen_bin() and gen_lib() based on the lib: bool flag.

Drawbacks

None.

Rationale and alternatives

  • crossgen --lib was chosen to be compatible with cargo init --lib and cargo init, which target binaries by default, and libraries with a flag.
  • a separate subcommand could be chosen too, but that would be less consistent with cargo, and possibly the wider rust ecosystem.

Unresolved Questions

This does not address setting up individual targets. For example there is currently no way to indicate you want Android support, but not WASM. This must be removed manually after crossgen has run.
@yoshuawuyts yoshuawuyts added enhancement New feature or request help wanted Extra attention is needed labels Sep 13, 2018
@yoshuawuyts yoshuawuyts mentioned this issue Sep 13, 2018
Open
@bltavares
Copy link
Contributor

I'll have some time next week to investigate what would be an ideal lib template and work a bit on helping with this issue.

@yoshuawuyts
Copy link
Owner Author

@bltavares that would be fantastic! 🎉

@spacekookie spacekookie mentioned this issue Sep 13, 2018
Merged
3 tasks
@spacekookie
Copy link
Contributor

Hey there, ah dang! I saw this issue before my flight left and worked on it on the plane 😏

@bltavares bltavares mentioned this issue Oct 10, 2018
Closed
bltavares added a commit to bltavares/crossgen that referenced this issue Oct 10, 2018
@bltavares
Improve lib template on Travis
de36827 
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
@bltavares bltavares mentioned this issue Oct 10, 2018
Merged
3 tasks
bltavares added a commit to bltavares/crossgen that referenced this issue Oct 10, 2018
@bltavares
Improve lib template on Travis
c87d830 
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
Copy link
Contributor

After learning more about the --crate-type argument on Rust, I've discovered it will not be possible to override it to only produce a single type of artifact.

I'm going to try out with this quick CLI tool I've wrote to see if I would be able to specify a single type of crate when compiling libraries and report back.

bltavares added a commit to bltavares/crossgen that referenced this issue Nov 17, 2018
@bltavares
Improve lib template on Travis
2677e11 
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>
yoshuawuyts pushed a commit that referenced this issue Dec 18, 2018
@bltavares @yoshuawuyts
Improve lib template on Travis (#19)
a0b25ce 
* Improve lib template on Travis

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:
- #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>

* Define the type of artifact to be produced by cargo.

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>
@stale
Copy link

stale bot commented Feb 15, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix This will not be worked on label Feb 15, 2019
@yoshuawuyts
Copy link
Owner Author

This is definitely still relevant.

@stale stale bot removed the wontfix This will not be worked on label Feb 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@bltavares @yoshuawuyts @spacekookie