-
Notifications
You must be signed in to change notification settings - Fork 278
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
Remove libinih from codebase and add it as a dependency instead #2443
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2443 +/- ##
========================================
Coverage 65.43% 65.44%
========================================
Files 118 117 -1
Lines 21661 21554 -107
Branches 10465 10434 -31
========================================
- Hits 14174 14106 -68
+ Misses 5296 5266 -30
+ Partials 2191 2182 -9
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Et voila for MSYS2: msys2/MINGW-packages#14781 |
Wow, that was fast! I was looking into it and only just found that repo about a minute ago! |
I'll convert this PR to draft until msys2/MINGW-packages#14781 is ready. The build failure in CIFuzz should resolve itself automatically after this PR is merged, because OSS-Fuzz uses the install script from our main branch: https://github.com/google/oss-fuzz/blob/582e69cebf7a970faf4ffb0c5492e497d860cb12/projects/exiv2/Dockerfile#L19 |
@kevinbackhouse Merged. It might take a couple of hours/days until the binary package actually trickles down to the repo... |
00a0bac
to
a4164ce
Compare
@piponazo: do these cmake/conan changes look ok to you? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems to me that libinih is a strong dependency and we should be more strict in checking that the dependency is properly found.
Apart from that, all the changes look good to me 👏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks ❤️
FWIW: https://cygwin.com/pipermail/cygwin/2023-January/252780.html (couldn't find any other channel for such requests...) The other option of course is that someone here actually creates a port file and sends it upstream.... |
There is follow-up re Cygwin: https://cygwin.com/pipermail/cygwin/2023-January/252781.html Anyone able to test? |
@kevinbackhouse This seems to have broken the nighlty release build |
@hassec: sorry about that! I'll look into it. |
I build statically with msys2/ucrt64 to get one exe. Now |
Yep, the MSYS2 package did not ship the static library in the default build options... An update should hit the repo in a couple of hours/days. |
Recently, Exiv2 removed some files from their tree to make it a proper dependency: Exiv2/exiv2#2443 Though a comment in this MR seems to say it should be a hard dependency, this other patch says it only disable readExiv2Config() which makes Exiv2 not read custom user config files: Exiv2/exiv2#2465 (also verified by grepping EXV_ENABLE_INIH which indeed shows it is only used by this one function) I assume this is the config file which is discussed of: https://exiv2.org/manpage.html#config_file For GIMP, I am unsure if this custom optional config file is that important and if anyone actually makes use of this. Even more in the flatpak, where eventually the access to $HOME (where the user file would be) is meant to disappear for sandboxing reasons. So instead of adding this additional dep, let's just disable the user config file feature.
Recently, Exiv2 removed some files from their tree to make it a proper dependency: Exiv2/exiv2#2443 Though a comment in this MR seems to say it should be a hard dependency, this other patch says it only disable readExiv2Config() which makes Exiv2 not read custom user config files: Exiv2/exiv2#2465 (also verified by grepping EXV_ENABLE_INIH which indeed shows it is only used by this one function) I assume this is the config file which is discussed of: https://exiv2.org/manpage.html#config_file For GIMP, I am unsure if this custom optional config file is that important and if anyone actually makes use of this. Even more in the flatpak, where eventually the access to $HOME (where the user file would be) is meant to disappear for sandboxing reasons. So instead of adding this additional dep, let's just disable the user config file feature. (cherry picked from commit 4335a09)
Just curious, is there a reason the
On |
Granted, this was not envisaged when I updated the module. I briefly checked the "major" distros - these are usually packaged together... For a such a tiny (few KB) library, splitting is more overhead than benefit IMHO... |
On alpine, they are separate installs. Seems like a quick one-liner could fix it. I'll make a patch. |
* Fixes issue on alpine where inih-dev is installed without inih-inireader-dev * Exiv2#2443 (comment) Signed-off-by: Ryan Friedman <ryan.friedman+github@avinc.com>
* Fixes issue on alpine where inih-dev is installed without inih-inireader-dev * Exiv2#2443 (comment) Signed-off-by: Ryan Friedman <ryan.friedman+github@avinc.com>
* Fixes issue on alpine where inih-dev is installed without inih-inireader-dev * #2443 (comment) Signed-off-by: Ryan Friedman <ryan.friedman+github@avinc.com>
* Fixes issue on alpine where inih-dev is installed without inih-inireader-dev * #2443 (comment) Signed-off-by: Ryan Friedman <ryan.friedman+github@avinc.com> (cherry picked from commit 16c533f)
* Fixes issue on alpine where inih-dev is installed without inih-inireader-dev * #2443 (comment) Signed-off-by: Ryan Friedman <ryan.friedman+github@avinc.com> (cherry picked from commit 16c533f)
Fixes: #1811
ini.cpp
andini.hpp
are copied from this repo: https://github.com/benhoyt/inih. Most platforms have alibinih-dev
library that we can add as a dependency, so we can removeini.cpp
andini.hpp
from the exiv2 codebase.On most platforms, it is easy to replace
ini.cpp
andini.hpp
with a dependency, but some platforms only have alibinih
library and not alibinih-devel
library, which is insufficient for building exiv2. On those platforms, I had to update the Actions workflows to build inih from source. This is the list of platforms where I had to do that:MSYS2On several other platforms, I had to upgrade to a newer version to get a sufficiently recent version of libinih. For example, I upgraded Ubuntu from 20.04 to 22.04.