Am 09.08.2016 um 16:11 schrieb Brad King:
On 08/08/2016 04:19 PM, Sebastian Holtermann wrote:
It is back to what it was in 3.5 for the all-qrc-names-unique case.
So yes, existing projects get the same symbol name they used to get.
Good, thanks.
New projects that now can use non unique file names
may get a symbol name based on the checksum extended file name
- but that one is also length limited and should be safe.
Is this checksum user-facing in that they may need to reference such
a symbol in their own code by this name? This would restrict us from
ever changing the hash algorithm in the future.
Well, it is user-facing.
Though for one-binary applications the user never needs
to know the the actual symbol name. Only when building libraries.
It is said n "Using Resources in a Library" in
http://doc.qt.io/qt-5/resources.html
--
Note: The use of Q_INIT_RESOURCE() and Q_CLEANUP_RESOURCE() is not
necessary when the resource is built as part of the application.
--
In the non-unique-qrc-name case the checksum is hard to reproduce for a
user. In this case I'd say CMake does not make any guaratees for
- the actual symbol name
- the symbol name to not change in the future
It only guarantees the symbol to be unique within the project.
If the user really needs a guranteed symbol name, e.g. for a library,
he/she has to ensure that the BASENAME.qrc file name is unique within
the project. In CMake 3.5 this was a requirement anyway.
But I found another issue.
The checksum string generator may generate a '-' in the file name.
This is allowed for file names but not for symbol names.
I have attached a small patch to fix this.
Thanks, I squashed that in.
Why does cmFilePathUuid::GetChecksumString go through so many steps
of transformation? Why not just take the original hex-valued hash
and use it directly (possibly truncated)?
Base64 uses 64 different characters. Hex values only 16.
Using Base64 the 14 character checksum string allows 64**14
different combinations versus 16**14 combinations when using hex.
Therefore a checksum collision is less likely when using Base64.
I'm not tied to Base64 but I think it provies the best uniqueness
with respect to the file-length and allowed-characters limitations.
-Sebastian
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
