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

Tracking Issue for --crate-type flag #10083

Closed
Tracked by #2685
ehuss opened this issue Nov 14, 2021 · 11 comments · Fixed by #10838
Closed
Tracked by #2685

Tracking Issue for --crate-type flag #10083

ehuss opened this issue Nov 14, 2021 · 11 comments · Fixed by #10838
Assignees
@Rustin170506
Labels
C-tracking-issue Category: A tracking issue for something unstable. disposition-merge FCP with intent to merge finished-final-comment-period FCP complete T-cargo Team: Cargo to-announce

Comments

@ehuss
Copy link
Contributor

ehuss commented Nov 14, 2021 •
edited
Loading

Summary

RFC: #3180
Implementation: #10093
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#crate-type

This is the tracking issue for RFC 3180 which adds the --crate-type argument to cargo rustc to explicitly change the crate type of the crate being built.

Unresolved Issues

No response

Future Extensions

No response

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
@ehuss ehuss added the C-tracking-issue Category: A tracking issue for something unstable. label Nov 14, 2021
@ehuss ehuss mentioned this issue Nov 14, 2021
Merged
@Rustin170506
Copy link
Member

I would like to try to add it. Can I claim it?

@ehuss
Copy link
Contributor Author

ehuss commented Nov 15, 2021

Sure! I don't think anyone else has expressed interest.

Let me know if you have any questions. For handling unstable support, fail_if_stable_opt can be used to require -Z unstable-options.

I'm not sure about the best way to pass the information down to the right place. I'm thinking adding another map to BuildContext similar to extra_compiler_args might be a good option for now. Then the points where the crate-type is selected can consult that map to see if there is an override.

@seanmonstar seanmonstar mentioned this issue Nov 15, 2021
Closed
6 tasks
@AmitPr AmitPr mentioned this issue Nov 17, 2021
Open
@Rustin170506 Rustin170506 mentioned this issue Nov 17, 2021
Merged
bors added a commit that referenced this issue Nov 26, 2021
@bors
Auto merge of #10093 - hi-rustin:rustin-patch-rustc, r=ehuss
b85ad15 
Add crate type flag to rustc command

part of #10083

- Add crate type flag to rustc command
- Add tests
- Update docs
@daxpedda daxpedda mentioned this issue Jan 22, 2022
Closed
@seanmonstar seanmonstar mentioned this issue Feb 2, 2022
Closed
@seanmonstar
Copy link

I tried this out in hyper today, and hit errors. Filed #10356

@csmoe csmoe mentioned this issue Feb 14, 2022
Closed
@csmoe csmoe mentioned this issue Mar 5, 2022
Closed
@yodaldevoid
Copy link

Is making this feature stable on hold until the cargo team has additional review capacity? If not, what needs to happen to get this over the finish line?

I assume we just want to wait to see if anyone runs into more issues, but how long should we wait?

@Rustin170506
Copy link
Member

Is making this feature stable on hold until the cargo team has additional review capacity? If not, what needs to happen to get this over the finish line?

I assume we just want to wait to see if anyone runs into more issues, but how long should we wait?

Yes, I think we need to wait a little longer.

@messense messense mentioned this issue Apr 22, 2022
Closed
@memoryruins memoryruins mentioned this issue May 18, 2022
Closed
@danielhenrymantilla danielhenrymantilla mentioned this issue Jun 8, 2022
Closed
@yodaldevoid
Copy link

It's been a little over two months since I last asked so I thought I'd poke this issue once more.

I took a look at the cargo issue tracker and could find no open issues about the --crate-type flag nor any issues opened and then closed in the past two months.

I asked last time how long the team would like to wait, though I didn't get any answer. I understand if this is something that is more of a gut feeling.

I'm sorry if I'm being a bit of a bother, I know I'm just being impatient.

@Rustin170506
Copy link
Member

@ehuss What do you think? Should we stabilize it now?

I'm happy to help stabilize it if needed.

@lucifer1004 lucifer1004 mentioned this issue Jun 20, 2022
Merged
@ehuss ehuss added the T-cargo Team: Cargo label Jul 5, 2022
@ehuss
Copy link
Contributor Author

ehuss commented Jul 5, 2022

Starting the FCP to stabilize --crate-type flag for cargo rustc.
I can't think of any specific issues with this (other than adding more surface area and complexity).

@rfcbot fcp merge

Docs: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#crate-type
RFC: https://rust-lang.github.io/rfcs/3180-cargo-cli-crate-type.html

@rfcbot
Copy link
Collaborator

rfcbot commented Jul 5, 2022 •
edited by epage
Loading

Team member @ehuss has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period An FCP proposal has started, but not yet signed off. disposition-merge FCP with intent to merge final-comment-period FCP — a period for last comments before action is taken labels Jul 5, 2022
@rfcbot
Copy link
Collaborator

rfcbot commented Jul 5, 2022

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot removed the proposed-final-comment-period An FCP proposal has started, but not yet signed off. label Jul 5, 2022
@weihanglo weihanglo mentioned this issue Jul 9, 2022
Merged
@rfcbot rfcbot added finished-final-comment-period FCP complete to-announce and removed final-comment-period FCP — a period for last comments before action is taken labels Jul 15, 2022
@rfcbot
Copy link
Collaborator

rfcbot commented Jul 15, 2022

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

This was referenced Aug 16, 2022
Merged
Merged
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Aug 20, 2022
@matthiaskrgr
Rollup merge of rust-lang#100636 - cutsoy:revert-77716, r=davidtwco
c4d57f5 
Revert "Revert "Allow dynamic linking for iOS/tvOS targets.""

This reverts commit 16e10bf (PR rust-lang#77716).

The original original PR enabled `cdylib` builds for iOS. However this caused problems because:

> This new feature in Rust 1.46 added a lot of headache for iOS builds with cdylib targets. cdylib target is near impossible to build if you are using any crate with native dependencies (ex. openssl, libsodium, zmq). You can't just find .so files for all architectures to perform correct linking. Usual workflow is the following:
>
> 1. You build staticlib and rely that native dependencies will be linked as frameworks later
> 2. You setup right cocoapods in ObjectiveC/Swift wrapper.
>
> As cargo doesn't support platform-dependent crate types rust-lang#4881 as a result a lot of projects now broken on Rust 1.46

However, this will be soon a thing of the past since 1.64 brings us the long awaited much anticipated `--crate-type` flag.

> I see that this got merged recently: rust-lang/cargo#10083. The --crate-type flag will get stabilized in 1.64. In 1.64, you could still get a successful iOS staticlib with cargo build --crate-type=statclib even if the crate has cdylib targets too. If I'm not mistaken, this solves the problem too so this PR could be reverted in 1.64 with relatively little headache.

So summing up, I think this PR can be reverted in 1.64. 🤞
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Aug 20, 2022
@matthiaskrgr
Rollup merge of rust-lang#100636 - cutsoy:revert-77716, r=davidtwco
51e5b6f 
Revert "Revert "Allow dynamic linking for iOS/tvOS targets.""

This reverts commit 16e10bf (PR rust-lang#77716).

The original original PR enabled `cdylib` builds for iOS. However this caused problems because:

> This new feature in Rust 1.46 added a lot of headache for iOS builds with cdylib targets. cdylib target is near impossible to build if you are using any crate with native dependencies (ex. openssl, libsodium, zmq). You can't just find .so files for all architectures to perform correct linking. Usual workflow is the following:
>
> 1. You build staticlib and rely that native dependencies will be linked as frameworks later
> 2. You setup right cocoapods in ObjectiveC/Swift wrapper.
>
> As cargo doesn't support platform-dependent crate types rust-lang#4881 as a result a lot of projects now broken on Rust 1.46

However, this will be soon a thing of the past since 1.64 brings us the long awaited much anticipated `--crate-type` flag.

> I see that this got merged recently: rust-lang/cargo#10083. The --crate-type flag will get stabilized in 1.64. In 1.64, you could still get a successful iOS staticlib with cargo build --crate-type=statclib even if the crate has cdylib targets too. If I'm not mistaken, this solves the problem too so this PR could be reverted in 1.64 with relatively little headache.

So summing up, I think this PR can be reverted in 1.64. 🤞
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Aug 20, 2022
@matthiaskrgr
Rollup merge of rust-lang#100636 - cutsoy:revert-77716, r=davidtwco
5859af4 
Revert "Revert "Allow dynamic linking for iOS/tvOS targets.""

This reverts commit 16e10bf (PR rust-lang#77716).

The original original PR enabled `cdylib` builds for iOS. However this caused problems because:

> This new feature in Rust 1.46 added a lot of headache for iOS builds with cdylib targets. cdylib target is near impossible to build if you are using any crate with native dependencies (ex. openssl, libsodium, zmq). You can't just find .so files for all architectures to perform correct linking. Usual workflow is the following:
>
> 1. You build staticlib and rely that native dependencies will be linked as frameworks later
> 2. You setup right cocoapods in ObjectiveC/Swift wrapper.
>
> As cargo doesn't support platform-dependent crate types rust-lang#4881 as a result a lot of projects now broken on Rust 1.46

However, this will be soon a thing of the past since 1.64 brings us the long awaited much anticipated `--crate-type` flag.

> I see that this got merged recently: rust-lang/cargo#10083. The --crate-type flag will get stabilized in 1.64. In 1.64, you could still get a successful iOS staticlib with cargo build --crate-type=statclib even if the crate has cdylib targets too. If I'm not mistaken, this solves the problem too so this PR could be reverted in 1.64 with relatively little headache.

So summing up, I think this PR can be reverted in 1.64. 🤞
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Aug 20, 2022
@matthiaskrgr
Rollup merge of rust-lang#100636 - cutsoy:revert-77716, r=davidtwco
e81b994 
Revert "Revert "Allow dynamic linking for iOS/tvOS targets.""

This reverts commit 16e10bf (PR rust-lang#77716).

The original original PR enabled `cdylib` builds for iOS. However this caused problems because:

> This new feature in Rust 1.46 added a lot of headache for iOS builds with cdylib targets. cdylib target is near impossible to build if you are using any crate with native dependencies (ex. openssl, libsodium, zmq). You can't just find .so files for all architectures to perform correct linking. Usual workflow is the following:
>
> 1. You build staticlib and rely that native dependencies will be linked as frameworks later
> 2. You setup right cocoapods in ObjectiveC/Swift wrapper.
>
> As cargo doesn't support platform-dependent crate types rust-lang#4881 as a result a lot of projects now broken on Rust 1.46

However, this will be soon a thing of the past since 1.64 brings us the long awaited much anticipated `--crate-type` flag.

> I see that this got merged recently: rust-lang/cargo#10083. The --crate-type flag will get stabilized in 1.64. In 1.64, you could still get a successful iOS staticlib with cargo build --crate-type=statclib even if the crate has cdylib targets too. If I'm not mistaken, this solves the problem too so this PR could be reverted in 1.64 with relatively little headache.

So summing up, I think this PR can be reverted in 1.64. 🤞
This was referenced Sep 24, 2022
Open
Open
@vezenovm vezenovm mentioned this issue May 31, 2023
Merged
2 tasks
@jbis9051 jbis9051 mentioned this issue Jun 7, 2023
Closed
@weihanglo weihanglo mentioned this issue Jun 12, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Rustin170506 Rustin170506

Labels
C-tracking-issue Category: A tracking issue for something unstable. disposition-merge FCP with intent to merge finished-final-comment-period FCP complete T-cargo Team: Cargo to-announce
Projects
Cargo Roadmap
Status: Done
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Stabilize --crate-type flag for cargo rustc weihanglo/cargo
5 participants
@ehuss @seanmonstar @yodaldevoid @rfcbot @Rustin170506