[WIP] Use cargo workspace. Move gfx_app in its own crate #1250
Conversation
ama0
changed the title
kvark
changed the title
|
☔ The latest upstream changes (presumably #1251) made this pull request unmergeable. Please resolve the merge conflicts. |
|
@ama0 Since I presumably created lots of conflicts with my formatting PR, may I try to do this workspace-PR? Or would you prefer to do it yourself? |
|
@torkleyy Sure, go on 👍 Just remember that there's still this blocking issue |
|
@ama0 Maybe we could just do a |
|
@torkleyy I don't know what |
|
@ama0 From |
|
@torkleyy I'm not sure how this would solve the |
|
Well, I'm just working on the cargo issue, but you have to be patient - not a cargo expert 😄 |
|
My PR is in this week's TWIR. IIRC the next release should be in 2 weeks. |
|
@torkleyy Congratulations 👍 I've updated this PR so it stays closer to current master. Currently it looks like this:
There are still some issues I'm not sure how to solve since I'm not that deep into gfx internals.
|
They shouldn't depend on |
|
I removed the changes to |
|
☔ The latest upstream changes (presumably 50f6715) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Okay, the flag landed on stable. |
|
@ama0 would you be able to rebase this? |
|
Thanks for the heads up. I'll try to look into it in a few days. |
1417: Move examples to explicit gfx_support crate/module. Also move to virtual cargo workspace. r=kvark I noticed [this issue about gfx_app](#922) has pretty much stopped, when I was just looking, and realized the exact same thing had been confusing me trying to learn gfx. In the thread, it was brought up maybe it was a good idea to move gfx_app to it's own module, to help users with learning the API (whom are reading the example code). Since progress has slowed down in [the PR for cargo workspaces](#1250) I thought I would submit this as *some* progress. I thought it was good timing since the last commit to the gfx repository just accepted a [pull-request doing a similar rename](d1e99ce), it seems smart to do another rename pull-request like this (since others maintaining branches will already need to rebase). I could be wrong about this, but the alternative would for me to sit back and wait until another point in the future to do this. I think renaming gfx_app to gfx_support, and more importantly moving the code out of gfx's root (and under examples/) will help users understand what is "gfx library code" vs "gfx support library code". The distinction is subtle but important, I believe. It certainty wasn't clear to me until quite a while of digging by myself. I have a few things I'd like to discuss moving forward, this pull request certainly isn't ready as is. 1. I'd like to gather consensus that this is the right direction to move gfx. Are there any objections to the direction of this pull-request? 2. Is gfx_project a good name for the "root project"? 3. I'm not sure that duplicating the Cargo.toml file is the right way to express what I'm intending. Right now I'm duplicating the dependencies section in both Cargo.toml files. Apart from going through each dependency one-by-one, and seeing whether examples/ or gfx/ requires the dependency, is there a way to not duplicate the dependencies your aware of? Is duplicating them a problem? 4. In the other thread glium was brought up as an example, in glium's example code, the helper code lives in the [examples/support/](https://github.com/glium/glium/tree/master/examples/support) directory, causing all examples to have to add [explicitly mod support it](https://github.com/glium/glium/blob/master/examples/deferred.rs#L10). I tried emulating the same setup, but I wasn't able to get it to compile. I would need to spend more time comparing with the glium project to emulate that setup. 5. I need to try using the support code from another package, to make sure it's visible the way I think it should be. This is a TODO. Anyways, I stole this list from the other thread. Here is what is working: cargo build cargo run --example (they all seem to work) What is not working: cargo test -- this isn't working for me on master/, not completely sure abouit this one. cargo build --all (error: native frameworks are only available on macOS targets) cargo test --all (error: Could not compile `core-foundation-sys`) Pretty tired now when writing this up, so posting this looking to get some direction/guidance to move forward with this change. edit: Resolves: * #1248 * #1424
|
Guess this can be closed now that another PR implemented it. |
|
anyone in the future: #1417 |
|
Thanks everyone, this is done! |
1258: Lint all the things r=kvark a=kvark **Connections** Fixes gfx-rs#1250 **Description** Refactors the code to satisfy the linter, configures it, and enables on CI. **Testing** `cargo clippy` saves the dau Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
This is a first prototype on using cargo workspace for the whole project. (#1248)
gfx_app is no longer the 'main crate'. It is moved into src/gfx_app
I left the old dependencies in the main
Cargo.tomlto make it easier to compare and see what may be a cause of error.What is working:
What is not working:
Both throw a bunch of errors because the platform is wrong. See Provide a way to run cargo subcommands on all crates in the workspace #2878 This seems to be the blocker right now.