Add the metadata needed by cargo-c

[lu-zero]

Fixes #174

It does not install any header, uses libz_rs as name in pkg-config and z_rs as library name.

The default cargo cinstall --destdir=/some/place would produce this on macos:

└── usr
    └── local
        └── lib
            ├── libz_rs.0.2.1.dylib
            ├── libz_rs.0.2.dylib -> libz_rs.0.2.1.dylib
            ├── libz_rs.a
            ├── libz_rs.dylib -> libz_rs.0.2.1.dylib
            └── pkgconfig
                └── libz_rs.pc

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.98%. Comparing base (85bc778) to head (9b4809f).
Report is 8 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #176      +/-   ##
==========================================
- Coverage   92.47%   91.98%   -0.49%     
==========================================
  Files          41       44       +3     
  Lines       14174    14835     +661     
==========================================
+ Hits        13107    13646     +539     
- Misses       1067     1189     +122     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[folkertdev]

@lu-zero is there a reason cargo cbuild puts its things in target/<target tripple>/release rather than just target/release? it's annoyingly inconsistent with a standard cargo build.

[lu-zero]

It is required until cargo learns to differentiate the RUSTFLAGS for the build.rs and the RUSTFLAGS for the host.

using cargo cbuild -v it emits a note with the uninstalled pkg-config path.

[folkertdev]

are you aware of a cargo issue that describes the problem?

I'll be meeting with some members of the cargo team in October, and I'd like to prepare some concrete things to make progress on. Given how crucial this is for sneaking rust into C code bases I think progress can be made.

[lu-zero]

rust-lang/cargo#4423 is another way to see the problem and rust-lang/cargo#9452 is how to solve it.

But normally cinstall is used to produce the .a that is then linked in the bigger C project. Even C projects support cross compilation ^^.

I guess I should really prepare a blogpost showing how to use cargo-c in many deployment scenarios :)

[bjorn3]

The original zlib uses libz.so.1 as SONAME. I think using libz_rs.so.0.4 as SONAME for zlib-rs is wrong. We are matching the ABI of the original zlib and when zlib-rs bumps to version 0.5, the ABI will stay the same and thus SONAME shouldn't change.

[lu-zero]

you may set package.metadata.capi.library.version to address it.

[folkertdev]

hmm. That 0.4 is the rust version, and not the version of zlib that we mirror. We're not at 1.0 yet with zlib-rs, so in the meantime, how should we handle the situation?

I think mostly this c dylib is for individuals that want to use zlib-rs in their projects; we're not ready for distributions yet (I expect that to only happen at 1.0 and later). So is there a problem in practice here?

[bjorn3]

Using a version that doesn't have a relation to the ABI in SONAME kinda invalidates the point of having SONAME in the first place I would think. There are two main users of dylibs:

• Distros: These want SONAME to match the ABI compatibility such that they can upgrade the dylib without needing to rebuild everything when the new version is ABI compatible with the old version.
• Projects who bundle the dylib as part of their program: These shouldn't need SONAME at all as the dylib will never be updated independently of the program that uses it.

[folkertdev]

cool, set that to 1.3.0 now, which is the actual api version that we say we provide (though some stuff is missing currently)

[bjorn3]

I think it looks fine now, but I'm not really familiar with cargo-c.

[folkertdev]

In the absence of cargo being able to generate a proper dynamic library, it's the best solution we have.

[folkertdev]

thanks @lu-zero for the help here!