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. > 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)? -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
