-
Notifications
You must be signed in to change notification settings - Fork 286
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
Robin's Changes between RC2 and RC3 #557
Conversation
Codecov Report
@@ Coverage Diff @@
## master #557 +/- ##
==========================================
+ Coverage 62.74% 62.77% +0.03%
==========================================
Files 154 154
Lines 20680 20695 +15
==========================================
+ Hits 12976 12992 +16
+ Misses 7704 7703 -1
Continue to review full report at Codecov.
|
I'm going to keep working on this until I understand exactly what happened to conversions.sh. And I want to add Gilles Test file DSC_3079.jpg to the test suite. In convert.cpp there is a call to xmpData_->erase(pos);. This is the function which I modified. Clearly there's a side-effect which seems to be benign. More work needed. I have added a new function XmpData::erase1() which has the "old" implementation and use xmpData_->erase1(pos) in convert.cpp. That's fine now. Clearly there's a functional difference between erase() and erase1() which should be fixed.
I've reproduced this behaviour with a simpler script acon.sh
Original behaviour:
After my change:
|
I have dug over this carefully. I believe the earlier version of this is safe and arrives at the correct result. However, the test suite detected a difference. I restored XmpDatum.erase() to its previous behaviour of deleting the item at 'pos'. I added a new API XmpDatum.eraseFamily() which deletes the item and its children. Also add Gilles test file DSC_3079.jpg to the test suite and added a test in conversions.sh. I think the earlier version of the code in which I modified XmpDatum.erase() to perform its previous role AND eraseFamily() is superior and logical. However, as we are close to the end of Exiv2 v0.27, I feel there is less risk by adding XmpDatum.eraseFamily(). actions.cpp has been modified to call eraseFamily(). |
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.
The changes look good to me.
I would have preferred to see the new tests in the python suite instead of adding them in the bash tests suite (test/conversions.sh
). However, I understand that you are not as familiar with the python suite as with the bash one. We can convert the remaining bash scripts after releasing v0.27.
Is there any chance of reducing further the size of the binary file (image) by extracting the metadata into a .exv file ?
endif() | ||
|
||
target_link_libraries( exiv2lib PRIVATE Threads::Threads) | ||
else() | ||
target_link_libraries( exiv2lib PRIVATE psapi ws2_32 ) |
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.
Now we have target_link_libraries( exiv2lib PRIVATE psapi ws2_32 )
in two different places (when MSVC or when CYGWIN OR MINGW OR MSYS
). I think that it would be simpler to just have it once when WIN32
.
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.
We could reuse for that the already existing conditional in line 184.
Yes. You are right. This can be simplified. When I was looking at the code I thought "oh that's odd, it doesn't seem to do this for MSVC. So how could it ever have worked? I'll try explicitly adding it and see what happens!". We now know how it works. When building exiv2.dll, the linker does not worry about unsatisfied externals. When building (static) exiv2.lib, psapi must be linked at build-time. You're right. Much better to do it for WIN32 as this has nothing really to do with MSVC. And it has nothing really to do with the build-type either (static/shared). |
set(CPACK_GENERATOR ZIP) # use .zip - less likely to damage bin/exiv2.dll permissions | ||
else() | ||
set(CPACK_GENERATOR TGZ) # MinGW/Cygwin/Linux/MacOS-X etc use .tar.gz | ||
set (CC "") # Compiler |
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.
Few comments here.
- The default value of CC is empty. Is that the intended behaviour? In case the compiler is not clang, the value will remain empty.
- The way to check for clang can be simplified (without creating variables for it):
if (${CMAKE_CXX_COMPILER_ID} MATCHES "Clang")
set (CC Clang)
endif()
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.
Yes. That's what I want. We'll end up with bundle names such as:
CYGWIN64ClangStaticDebug
However, if for a SharedRelease built with GCC, the name will simply be:
CYGWIN64
I think there are 60 common build possibilities.
{Linux|CYGWIN|MinGW}{64|32}{''|Clang}{''|Static}{''|Debug} = 3x2x2x2x2 = 48
{Darwin}{''|Static}{''|Debug} = 2x2 = 4
{msvc}{64|32}{''|Static}{''|Debug} = 8
Total = 60
If I decide to to build with the other versions of Visual Studio {2008|2010|2012|2013|2015), that will be 5x8=40 more builds.
If we have a FULL build (webready, video) that would double it to 200.
There's no problem presenting and storing this on the buildserver. http://exiv2.dyndns.org:8080/userContent/builds/Platform/
On the downloads page, we'll only offer 6 http://exiv2.dyndns.org/download.html
Source
msvc64
Linux64
Darwin
MinGW64
CYGWIN64
For RC1 and RC2, I published MinGW64 and MinGW32 on 'downloads' because we were experiencing different issues on those platforms. However, we've put that behind us now, so I'll only offer MinGW64 with RC3.
README.md
Outdated
$ make | ||
``` | ||
|
||
Due to the way in which ccache is installed in Fedora, this option is defeated on that platform. [https://github.com/Exiv2/exiv2/issues/361](https://github.com/Exiv2/exiv2/issues/361) |
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.
This sounds like ccache does not work on Fedora, which is no true. This option just can't turn it off, that's all.
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.
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.
@piponazo I've changed the code in cmake/packaging.cmake that detects clang.
@clanmills since this PR is going to merge 0.27-RC3 into master, which is fixing many issues, could you change the description of the PR and create a list of the issues which you have fixed in the branch ? Right now, if you look at the PR description it looks like it is just fixing one issue. |
Sure. When I get to the end of this marathon, I'll update releasenotes/releasenotes.txt with a list of everything changed since RC2. It will include:
We will reach RC3 tomorrow (Friday 30 November). Any security fixes next week will be added and RC3 will be published on Friday 7 December. I'm hoping for no changes between RC3 and GM. If we have "dot" releases, every quarter, security fixes will go into 0.27.1 at the end of March 2019. |
…eFamily(). Restored and augumented conversions.sh
…h conversions.sh
…s GetModuleFileName isn't effective!
- Consuming with CMake - Debugging Exiv2 - Added "2.13 Building Exiv2 with ccache". - Revised "Building Exiv2 with ccache" in response to Dan's feedback. - Fixed typo in README.md - ReleaseNotes update in preparation for RC3.
I'm rather surprised that conversions.sh reveals a (harmless) order change on:
No other part of the test suite notices any change and the order of the Xmp keys is not important.
I have stepped the code in the debugger and the key is added in xmp.cpp: