Am 09.08.2016 um 17:52 schrieb Brad King:
On 08/09/2016 11:45 AM, Sebastian Holtermann wrote:
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.
Okay. Please update the documentation accordingly.
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.
I'm not tied to Base64 but I think it provies the best uniqueness
with respect to the file-length and allowed-characters limitations.
Okay. Please look at extending cmCryptoHash to offer access to
the _Final functions to get the binary digests directly as
`std::vector<unsigned char>` or something like that. That will
avoid the binary->hex->binary conversion sequence before going
to Base64. Also, please explain the motivation in comments.
I'll look into it within the next days.
-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
