Skip to content

Cargo workspace2 #14681

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.

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

Draft
wants to merge 9 commits into
base: master
Choose a base branch
from
Draft

Conversation

xclaesse
Copy link
Member

@xclaesse xclaesse commented Jun 5, 2025

No description provided.

@xclaesse
Copy link
Member Author

xclaesse commented Jun 5, 2025

@bonzini This is my very, very WIP for workspace support. The code is a total mess right now, but it finally passed configuration of the whole gst-plugins-rs tree! Over 400 subprojects generated.... https://paste.centos.org/view/6920dc55

@bonzini
Copy link
Collaborator

bonzini commented Jun 5, 2025

Thanks, I can try to integrate workspace parsing in my PR (just based on unit tests) and the interpreter code should be the same.

@xclaesse
Copy link
Member Author

xclaesse commented Jun 5, 2025

It doesnt't have unit tests yet, my test case is simple:

project('rs')
subproject('gst-plugins-rs')
[wrap-git]
url=https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs.git
revision=main
method=cargo

@bonzini
Copy link
Collaborator

bonzini commented Jun 6, 2025

I can add some ;)

@bonzini
Copy link
Collaborator

bonzini commented Jun 6, 2025

Ok, I added workspace inheritance to #14672 and this diff is the rebase of your wip patch on top of it.

@xclaesse xclaesse force-pushed the cargo-workspace2 branch 2 times, most recently from a2d2035 to 596dae8 Compare June 8, 2025 16:54
@xclaesse
Copy link
Member Author

xclaesse commented Jun 8, 2025

@bonzini I started to clean this PR commits and integrate some of your ideas I liked. I'm not yet totally satisfied with the result, but it's starting to look good IMHO. Now all dataclasses are created using _raw_to_dataclass() that can validate/convert attributes from raw to dataclasses.

@bonzini
Copy link
Collaborator

bonzini commented Jun 8, 2025

Ok I will also do the same and apply some of your commits, so that the WIP parts are up to date and conflicts are not a problem. Hopefully we start getting some review soon. :)

@xclaesse xclaesse force-pushed the cargo-workspace2 branch from 596dae8 to 9cb6cc8 Compare June 8, 2025 21:30
@bonzini
Copy link
Collaborator

bonzini commented Jun 9, 2025

Updated my branch(es). Among other things I renamed the conversion function to _raw_to_dataclass, switched the computed Meson version to lazy property.

I also added release notes for "cargo: Use -rs suffix only for rust ABI".

I would also like to reinforce that without unit tests for the dataclass conversion, this is not going anywhere. Some bugs that you have in your tree:

  • changing the default feature to use default_factory is wrong, because you're dropping the feature if any other feature is defined

  • as mentioned earlier, the version of the Cargo.lock file is an integer and not a string

Without tests it's also unclear what changes will need release notes. For example I suspect that "cargo: When loading wraps multiple packages can have the same URL" does require them, but I am not sure.

I really would prefer it if you switched to https://github.com/bonzini/meson/commits/cargo-workspace2-for-xclaesse, since it also takes into account more of the review comments that you got for #12983. In any case I am very interested in moving this work forward, so I'll keep rebasing my branches and making them follow what you do as closely as possible.

@xclaesse xclaesse force-pushed the cargo-workspace2 branch from 9cb6cc8 to 6cc3636 Compare June 9, 2025 14:07
@xclaesse
Copy link
Member Author

xclaesse commented Jun 9, 2025

I would also like to reinforce that without unit tests for the dataclass conversion, this is not going anywhere.

We do have tests cases already, but I agree not enough.

  • changing the default feature to use default_factory is wrong, because you're dropping the feature if any other feature is defined

Thanks, reverted that change.

  • as mentioned earlier, the version of the Cargo.lock file is an integer and not a string

I missed that you mentioned that before, fixed.

cargo: When loading wraps multiple packages can have the same URL

AFAIK, that's specific to workspace. Without workspace 1 subproject is 1 crate. For release notes, that's part of adding support for workspace.

I really would prefer it if you switched to https://github.com/bonzini/meson/commits/cargo-workspace2-for-xclaesse

Could you rebase that branch on top of mine so I can more easily see what you're adding? I'm still very strongly against bringing back TypedDict.

@bonzini
Copy link
Collaborator

bonzini commented Jun 9, 2025

Could you rebase that branch on top of mine so I can more easily see what you're adding? I'm still very strongly against bringing back TypedDict.

I am adding nothing except rebasing on top of #14672 (which I am keeping green). I understand you don't want to bring back TypedDict but you already got pushback from 2.5 people (I am the 0.5).

xclaesse added 9 commits June 15, 2025 11:59
If main project finds a directory subprojects/foo with no corresponding
foo.wrap, it creates a dummy PackageDefinition for it. If we later find
a subproject that has foo.wrap, replace the dummy wrap with it.

This happens for example when wrap-redirect have been deleted. It also
happens for subprojects downloaded from some Cargo.lock which does not
create a wrap-redirect.

Avoid loading the same location twice, which can happen when preparing
cargo subprojects.
This eliminate the double definition of every Cargo types. Only from_raw
constructors opperate on untyped values, which is what we get from toml
parser.
This avoids cloning the same repo multiple times, instead a single wrap
can provide multiple cargo dependencies.
A cargo package can build multiple crate types for the same library.
Using the same name in meson.override_dependency() fails.
Cargo workspaces will use this to have a single subproject defining
multiuple crates.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants