cargo: glob-expand workspace members

[sp1ritCS]

Apparently a thing

[bonzini]

Do you have an example? I would rather avoid it, especially considering that crates.io workspace are exploded anyway and therefore we control somewhat the workspace Cargo.toml files that we process.

[sp1ritCS]

glycin has it: https://gitlab.gnome.org/GNOME/glycin/-/blob/main/Cargo.toml?ref_type=heads#L28

[sp1ritCS]

Currently looking if I can somehow avoid this by writing custom meson files for it (we can just rely on get_option('loaders')), without relying on import('rust').workspace() as that attempts to parse the Cargo.toml with the glob.

Is there a mechanism that allows me to specify needed features for the synthesized dependency(xx-d-rs) subprojects from the Cargo.toml, without import('rust').workspace()?

[bonzini]

No, there isn't (other than writing your own meson.build and dropping it via packagefiles, but that's more of a side effect than a good idea).

[sp1ritCS]

Would it be possible to extend the meson.build generation to generate feature options & read them?

[bonzini]

Would it be possible to extend the meson.build generation to generate feature options & read them?

It was removed in the past, so I'd be reluctant to add it back.

Instead of globbing we could:

• add an extra_members keyword argument to workspace
• warn if glob entries are present and extra_members is absent
• error if extra_members is present and [workspace] is absent

However, this does not work well for glycin because it has a pretty complex generated meson.build, with many subdirectories.

So another possibility is to add the wrap file by hand, add an entry to the wrap file, like

[cargo]
extra_members = glycin-loaders/glycin-heif, glycin-loaders/glycin-heif, glycin-loaders/glycin-image-rs, ...

and use it to generate the extra_members argument.

[sp1ritCS]

However, this does not work well for glycin because it has a pretty complex generated meson.build, with many subdirectories.

I don't mind not relying on the generated meson.build, but instead on handwritten meson code - esp. since I'd like to just rely on get_option('loaders') as the single source of the expanded names.

So, something like that in the main glycin meson.build:

extra_members = []
foreach loader : get_options('loaders')
  extra_members += 'glycin-loaders' / loader
endforeach

cargo = import('rust').workspace(extra_members: extra_members)

[bonzini]

Yes, that's what I had in mind too. Would you like to give it a shot?

[sp1ritCS]

Yes, that's what I had in mind too. Would you like to give it a shot?

Updated, but the delayed default_member initialization is really ugly. But I'm not sure how this could be addressed, unless we define extra_members to never be part of default_members.

[bonzini]

I have another idea. What if the glob members were processed normally for their Cargo.toml but never expanded via subdir or subproject, i.e. never ever adding them to the default members? Then meson/meson.build can invoke them as needed.

In the specific case of glycin, the loaders are binaries so you need to handle them by hand anyway with something like

foreach l : get_option('loaders')
  cargo.package('glycin-' + l).executable(...)
endforeach

[sp1ritCS]

Not quite sure I understand. How would this differ from my initial attempt (3012464)?

[bonzini]

The difference would be that the Cargo.toml file is loaded but the members are not processed automatically. For glycin there would be no difference because those members are not libraries but in general there would be a difference. I will have to play a bit to formalize it more.