[inih] Build with Meson + update to r57

[DownerCase]

Follows on from #17388
Fixes #17385
Done in preparation to continue #31722 and properly address this review comment

If this PR updates an existing port, please uncomment and fill out this checklist:

• Changes comply with the maintainer guide
• SHA512s are updated for each updated download
• The "supports" clause reflects platforms that may be fixed by this new version
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

Repo I've used to verify proper usage: https://github.com/DownerCase/vcpkg_verifier/tree/inih

Writing a CMake package for this by hand was an interesting experience. There must be a better way to do this because it won't work for anything more complex.

[DownerCase]

@microsoft-github-policy-service agree

[DownerCase]

Yay! That actually worked 😄

Writing a CMake package for this by hand was an interesting experience. There must be a better way to do this because it won't work for anything more complex.

Well meson does have a CMake module that can write a version file, but beyond that it's not super useful

[JonLiu1993]

@DownerCase, Thanks for your PR, please restore the newline type for portfile.cmake and CMakeLists.txt.

[JonLiu1993]

Note: I will be converting your PR to draft status. When you respond, please revert to "ready for review". That way, I can be aware that you've responded since you can't modify the tags.

[JonLiu1993]

Please run command ./vcpkg x-add-version inih --overwrite-version and commit agagin.

[dg0yt]

IMO the port should get rid of vcpkg_cmake_... and just directly configure and install the desired (maybe simplified ) cmake config file. (I would also drop the corresponding version file. This is vcpkg, there are manifests.)

[DownerCase]

I mean sure, I considered that at one point but it felt wrong somehow to do all that in the portfile so I used the CMakeList instead.
If that’s actually preferable, and I can see how it would be, I can change it no problem.

The version file was thrown in just to “complete” the package and because it was easy. I’m not attached to it.

If you have particular suggestions on how to simplify the cmake.in file I’m all ears. The annoying bit for me was that the meson build generates two library files, as opposed to the current port build which bundles them into one, requiring two CMake imported targets and all the duplication thereof.

[JonLiu1993]

Tesed usage successfully by inih:x64-windows:

    find_package(unofficial-inih CONFIG REQUIRED)
    target_link_libraries(main PRIVATE unofficial::inih::libinih )

[DownerCase]

I'll address the review comments later today.

[dg0yt]

AFAIU the package offers two things: a C library, and a C++ class. Even if the latter uses the former, users will only access one or another directly.
IMO usage should list these patterns separately, e.g.

inih can be imported via CMake FindPkgConfig module:

    find_package(PkgConfig)
    # C API
    pkg_check_modules(inih REQUIRED IMPORTED_TARGET inih)
    target_link_libraries(main PRIVATE PkgConfig::inih)
    # C++ API
    pkg_check_modules(inih REQUIRED IMPORTED_TARGET INIReader)
    target_link_libraries(main PRIVATE PkgConfig::INIReader)

Simlilar for the unofficial cmake config.

[DownerCase]

@dg0yt Your understanding is correct. I'll make the change but this usage is becoming rather long. Is it ok for the C++ API usage to still be present even if the feature has been turned off and it is not present?

[dg0yt]

I'll make the change but this usage is becoming rather long.

I'm aware of the length. That's why I'm against promoting unofficial usage when there is an official pattern.
(But I do understand the limitations of pkg-config for multi-config builds.)

Is it ok for the C++ API usage to still be present even if the feature has been turned off and it is not present?

I think I made the point before: Remove the optional feature and always install the C++ API. I see no benefit from making it optional in this package.

[DownerCase]

Is it ok for the C++ API usage to still be present even if the feature has been turned off and it is not present?

I think I made the point before: Remove the optional feature and always install the C++ API. I see no benefit from making it optional in this package.

You did. I think I misunderstood and made it a default-option. IMO what we have now is good enough; inih is a C library first and they build INIReader as an optional feature, makes sense to me to reflect that, the work's already done for it. Something to revisit next update perhaps.

[DownerCase]

Great ci flaked out, 503 when downloading vcpkg tool. Rerunning x64_windows_static_md is needed.

[JonLiu1993]

Tested usage successfully by inih:x64-windows:

The package inih can be imported via CMake FindPkgConfig module:

    find_package(PkgConfig)

    # C API
    pkg_check_modules(INIH REQUIRED IMPORTED_TARGET inih)
    target_link_libraries(main PRIVATE PkgConfig::INIH)

    # C++ API (Requires "cpp" feature)
    pkg_check_modules(INIReader REQUIRED IMPORTED_TARGET INIReader)
    target_link_libraries(main PRIVATE PkgConfig::INIReader)

Alternatively, the package inih provides unofficial CMake targets:

    find_package(unofficial-inih CONFIG REQUIRED)

    # C API
    target_link_libraries(main PRIVATE unofficial::inih::libinih)

    # C++ API (Requires "cpp" feature)
    target_link_libraries(main PRIVATE unofficial::inih::inireader)

[JavierMatosD]

I don't think we should be giving instructions for using pckgconfig through cmake. I think it should just say something like, "if you are using CMake, the package provides unofficial CMake targets ...". If you are using pckgconfig here's the name.

Suggested change

	The package inih can be imported via CMake FindPkgConfig module:
	find_package(PkgConfig)
	# C API
	pkg_check_modules(INIH REQUIRED IMPORTED_TARGET inih)
	target_link_libraries(main PRIVATE PkgConfig::INIH)
	# C++ API (Requires "cpp" feature)
	pkg_check_modules(INIReader REQUIRED IMPORTED_TARGET INIReader)
	target_link_libraries(main PRIVATE PkgConfig::INIReader)
	Alternatively, the package inih provides unofficial CMake targets:
	find_package(unofficial-inih CONFIG REQUIRED)
	# C API
	target_link_libraries(main PRIVATE unofficial::inih::libinih)
	# C++ API (Requires "cpp" feature)
	target_link_libraries(main PRIVATE unofficial::inih::inireader)
	The package inih provides unofficial CMake targets:
	find_package(unofficial-inih CONFIG REQUIRED)
	# C API
	target_link_libraries(main PRIVATE unofficial::inih::libinih)
	# C++ API (Requires "cpp" feature)
	target_link_libraries(main PRIVATE unofficial::inih::inireader)
	Alternatively, if you are using pckgconfig use the name "inih" for the C API and "inireader" for the C++ API

[DownerCase]

I’ve just been going with established patterns, sounds like you guys need to form a consensus and guidance on how to handle usage texts and apply that uniformly. Something not in the scope of this PR which was to update a small package.

[DownerCase]

@dg0yt As the initial reviewer would you like to weigh in on this? You expressed a preference for the pkgconfig method previously as it is the officially supported method which I agree with and is why I put the unofficial CMake target second as the alternative usage.

Having full instructions for official usage makes sense to me and is what I would expect to see.

From my perspective as a user there are two things that matter.

1. Does the package build cleanly for my case. CI suggests yes.
2. Can I read the usage text and get it working in my project. JonLiu has verified that it can.

[dg0yt]

You expressed a preference for the pkgconfig method previously as it is the officially supported method which I agree with and is why I put the unofficial CMake target second as the alternative usage.

Give the feedback from vcpkg's @JavierMatosD, I don't want to ask for more changes. But I do have a clear <opinion>: Don't add or announce unofficial CMake config (vcpkg lock-in) when there is official pkg-config.
I could accept the short form of announcing the pkgconfig option, but IMO it is the primary form (official, no lock-in), not the alternative.</opinion>. From that POV, I can't approve, but it doesn't matter anyways.

Can I read the usage text and get it working in my project. JonLiu has verified that it can.

The usual quick validation of usage just scratches the surface. It detects some logical bugs, and this is a good thing. But normally it can't detect semantical defects in usage hints which are taken literally from the uninformed heuristics. So when adding usage, better spend an extra loop on reviewing it from the perspective of an uninitiated user.

[DownerCase]

Ok fine. @JavierMatosD how about this. We drop the unofficial CMake support completely and only retain the first half of the current usage text? Pkgconfig is made available by upstream and users must use that to use this package.

Downstream would just have to deal with the unofficial target disappearing on them. I know this at least this will affect minio-cpp. If this goes forward I will sort out the change with them.

[DownerCase]

Unofficial CMake support has been dropped in favor of pkgconfig. If people have trouble migrating, tag me in and I'll help.

I tried to do some work on my Exiv2 update after dropping it and found out why it should stick around. Becomes required if something is using it and tries to declare their own CMake targets to link to. They stop being available once you install.
I've taken your usage change suggestion. Hopefully that's all now 🙏

[DownerCase]

My respect for all the vcpkg maintainers has grown hugely after getting a taste of the madness you have to deal with. Thank you for all the hard work to make this all usable.
For some reason I still feel compelled to want to continue contributing though; hmm.

Anyway, hopefully this PR is almost done now...