-
Notifications
You must be signed in to change notification settings - Fork 287
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
Consider replacing src/ini.cpp with an external library #1811
Comments
Issue #1515 concerns replacing the /xmpsdk code in Exiv2 with building and linking Adobe XMPsdk from source. Regrettably, #1515 has been modified to include a discussion concerning src/ini.cpp. I'm going to restore #1515 to the original focus. I've thought of a good/simple way to remove We should have a callback from the library to identify a lens. The exiv2 application can compile/link INIReader to search Here's a suggestion (not a proposal) for the call-back: std::string myLensRecognitionCallback(Exiv2::Image::UniquePtr& image)
{
std::string result ; // result.size() != 0 when recognised
// code can use image->exifData() etc to interrogate (and modify) the metadata
return result;
}
Exiv2::setLensRecognitionCallback(myLensCallback) This is a substantial change to the Exiv2 API and should be targeted at the 'main' branch. We cannot remove the API A downsides of this design is that existing users of libexiv2 (such as darktable) will loose the I do not understand the hostility expressed about src/ini.cpp. The code has been very robust and helped many users with lens recognition. The INIReader code is 297 lines and wrapped in the Exiv2 namespace. 510 rmills@rmillsmm-local:~/gnu/github/exiv2/0.27-maintenance/build $ finder "*.dylib" -type f | xargs nm -g | grep INI
0000000000042240 T __ZN5Exiv29INIReader10GetBooleanENSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEES7_b
0000000000041f50 T __ZN5Exiv29INIReader10GetIntegerENSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEES7_l
0000000000041c80 T __ZN5Exiv29INIReader10ParseErrorEv
00000000000419a0 T __ZN5Exiv29INIReader12ValueHandlerEPvPKcS3_S3_
0000000000041c90 T __ZN5Exiv29INIReader3GetENSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEES7_S7_
00000000000420b0 T __ZN5Exiv29INIReader7GetRealENSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEES7_d
0000000000041db0 T __ZN5Exiv29INIReader7MakeKeyENSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEES7_
0000000000041bd0 T __ZN5Exiv29INIReaderC1ERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE
00000000000418f0 T __ZN5Exiv29INIReaderC2ERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE
511 rmills@rmillsmm-local:~/gnu/github/exiv2/0.27-maintenance/build $
|
I just spent a hour looking at this. On Ubuntu, it's very easy to install the library: |
I just noticed that there seems to be a conan recipe for that library: I am happy to work on this when I find some spare time 😉 |
This is a single file of 297 lines.
I found this somewhere on the internet and edited to put it into the Exiv2 namespace. I added this as a single file because I thought it would be simpler than adding a new library dependency.
Both Dan and Christoph disagree with my decision.
With conan, adding new dependent libraries is easier than it used to be.
I only use conan with Visual Studio. For other platforms (macOS, Linux, Unix, MinGW and Cygwin) I find it easier to use the platform package manager to install the dependencies (libz, expat and curl). These are all "major players". I don't even know if the ini parser can be installed by the platform package manager and/or if there is an conan recipe. So, removing this little file, could result in lots of work. For sure, I wouldn't like to reach the point that building Exiv2 demands conan because I've never got conan to work on Cygwin and/or MinGW. #1224.
The text was updated successfully, but these errors were encountered: