Skip to content

Conversation

@slowsage
Copy link

Will help in ci environments to know which system dependency to install based on feature.

@slowsage slowsage marked this pull request as draft November 26, 2025 17:41
@slowsage slowsage force-pushed the metadata branch 3 times, most recently from fbf5646 to 39c9bd8 Compare November 26, 2025 18:02
cc = "1.0"
cfg-if = "1.0"
pkg-config = "0.3.17"
system-deps = "7.0"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Distro packager hat on here. How exactly does the system-deps crate go about determining if the appropriate headers and sources are installed on a host system? If this isn't using pkg-config under the hood somewhere (it may be) then this feels like a regression. If it's just an ergonomic wrapper around the same tooling that's probably fine, but it it is some bespoke hand rolled detection system this would be a huge red flag.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are two separate changes - adding metadata for parsing by any tool (easier than going through code) and one to use the added metadata for pkg-config's probe() calls:

  1. First commit: Specifying dependencies in Cargo.toml in a way that can be parsed. This is for any bespoke tools - no code change, only metadata added to Cargo.toml. Figured the format from system-deps can be reused (as in the second commit, described below). This commit is enough for ci tools to parse and figure out which pkgs to install.
  2. Second commit: Once we specify in Cargo.toml, we might as well switch to system-deps in mlua-sys itself. Cargo.toml of system-deps crate uses pkg-config.
    It explicitly uses pkg-config under the hood here.

For my use case, the first commit is enough but system-deps can use it to call pkg-config's probe() and we can avoid repeating the same info in the code, hence the second commit.

Please let me know if I missed something.

@slowsage slowsage marked this pull request as ready for review November 26, 2025 22:44
@slowsage
Copy link
Author

slowsage commented Nov 26, 2025

Its ready now. Removed optional = true and changed fallback_names order to match original behavior (fail when no feature is picked and keep old order of fallbacks).

Can make it one commit instead if that is better.
Edit: Not sure about the 1 failure in typos. Did my commits break it?

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