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. Thanks, -Brad -- 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
