Re: [cmake-developers] Export files in the build tree have a total path length which is unnecessarily long
On 2016-08-09 10:11-0400 Brad King wrote: On 08/08/2016 02:54 PM, Alan W. Irwin wrote: For all such staging areas, would it be straightforward to hash the paths for the cmake-generated EXPORT files in the build tree to substantially reduce their pathlengths for the absolute install location case while still avoiding name collisions? Actually it looks like we already do this, but the logic forgot to account for the length of the file name. Please try this fix: install(EXPORT): Fix support for mid-length install destinations on Windows https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c7a319ab Hi Brad: I don't have access to Windows, but I tried this fix on Linux with a very long CMAKE_INSTALL_PREFIX (to trigger the hashing), and all seems to be well. software@raven> ~/cmake/install-c7a319a/bin/cmake -DCMAKE_INSTALL_PREFIX=$(pwd)/42397430947234398793874973983732987249739347293472938729487239472439782394723492374294847234927423497971498749237349723958749473934873497235987549023475/92752349572349053475945729729527234957349735209573999725497834957249524752904573975295742957349857934539709925294754973957493720274903485230252239/42397430947234398793874973983732987249739347293472938729487239472439782394723492374294847234927423497971498749237349723958749473934873497235987549023475/92752349572349053475945729729527234957349735209573999725497834957249524752904573975295742957349857934539709925294754973957493720274903485230252239/42397430947234398793874973983732987249739347293472938729487239472439782394723492374294847234927423497971498749237349723958749473934873497235987549023475/92752349572349053475945729729527234957349735209573999725497834957249524752904573975295742957349857934539709925294754973957493720274903485230252239/423974309472343987 93874973983732987249739347293472938729487239472439782394723492374294847234927423497971498749237349723958749473934873497235987549023475/92752349572349053475945729729527234957349735209573999725497834957249524752904573975295742957349857934539709925294754973957493720274903485230252239/42397430947234398793874973983732987249739347293472938729487239472439782394723492374294847234927423497971498749237349723958749473934873497235987549023475/92752349572349053475945729729527234957349735209573999725497834957249524752904573975295742957349857934539709925294754973957493720274903485230252239/42397430947234398793874973983732987249739347293472938729487239472439782394723492374294847234927423497971498749237349723958749473934873497235987549023475/92752349572349053475945729729527234957349735209573999725497834957249524752904573975295742957349857934539709925294754973957493720274903485230252239/4239743094723439879387497398373298724973934729347293872948723947243978239472349237429484723492742349797149874923734 9723958749473934873497235987549023475/92752349572349053475945729729527234957349735209573999725497834957249524752904573975295742957349857934539709925294754973957493720274903485230252239/42397430947234398793874973983732987249739347293472938729487239472439782394723492374294847234927423497971498749237349723958749473934873497235987549023475/92752349572349053475945729729527234957349735209573999725497834957249524752904573975295742957349857934539709925294754973957493720274903485230252239/install_tree -DBUILD_TEST=ON .. -- The Fortran compiler identification is GNU 4.9.2 -- Check for working Fortran compiler: /usr/bin/f95 -- Check for working Fortran compiler: /usr/bin/f95 -- works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Checking whether /usr/bin/f95 supports Fortran 90 -- Checking whether /usr/bin/f95 supports Fortran 90 -- yes -- Configuring done -- Generating done -- Build files have been written to: /home/software/plplot/HEAD/plplot.git/cmake/test_fortran/build_dir Despite that long install prefix (note the numbers have "/" embedded periodically to avoid going over the individual filename length limit on Linux), the exported files in the build-tree staging area appeared in hashed form, e.g., software@raven> pwd /home/software/plplot/HEAD/plplot.git/cmake/test_fortran/build_dir software@raven> find $(pwd) -type f |grep -i export /home/software/plplot/HEAD/plplot.git/cmake/test_fortran/build_dir/src_lib/CMakeFiles/Export/57a65d04a859ba876e044822264a11fe/export_test_fortran.cmake /home/software/plplot/HEAD/plplot.git/cmake/test_fortran/build_dir/src_lib/CMakeFiles/Export/57a65d04a859ba876e044822264a11fe/export_test_fortran-noconfig.cmake and after "make install" were installed in unhashed form (pathname length as large as 2471 for this particular test case) without issues. By the way, an install prefix of roughly 500 in length did not trigger the hashing. But I assume that lack of hashing for smaller-sized prefixes on Linux is due to some knowledge CMake has about pathname length limits on that platform, and hashing will be triggered for much smaller install prefixes on MinGW-w64/MSYS2 because of the known much smaller total pathname length
Re: [cmake-developers] Email feed for new CMake bugs
On 08/09/2016 03:46 PM, Gregor Jasny via cmake-developers wrote: > in the past (with Mantis) I found it quite helpful to see new bugs > posted here on this mailing list. Is it planned to restore that > functionality? Not currently. GitLab has notification settings you can use to "Watch" a project, though then you will get all updates about everything instead of just new issues. It is like subscribing to another list that gets all updates about the project. GitLab notifications do not distinguish new issues/MRs from updates on existing ones. Implementing such a feed may require webhooks that send the notifications, or modification to GitLab. -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
Re: [cmake-developers] [PATCH] Fix RunCMake.Framework on case sensitive file systems.
On 09/08/16 22:01, Brad King wrote: > On 08/09/2016 03:47 PM, Chaoren Lin via cmake-developers wrote: >> The file is lowercase: Tests/RunCMake/Framework/osx.cmake > > Thanks, applied: > > Tests: Fix RunCMake.Framework on case sensitive file systems. > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=677e73cb Clang will get a warning for those kind of errors[1] regarding header files. Would it make sense to add similar warning-functionality to CMake? Thanks, Gregor [1] http://lists.llvm.org/pipermail/cfe-dev/2016-April/048406.html -- 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
Re: [cmake-developers] [PATCH] Fix RunCMake.Framework on case sensitive file systems.
On 08/09/2016 03:47 PM, Chaoren Lin via cmake-developers wrote: > The file is lowercase: Tests/RunCMake/Framework/osx.cmake Thanks, applied: Tests: Fix RunCMake.Framework on case sensitive file systems. https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=677e73cb -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
[cmake-developers] [PATCH] Fix RunCMake.Framework on case sensitive file systems.
The file is lowercase: Tests/RunCMake/Framework/osx.cmake
---
Tests/RunCMake/Framework/RunCMakeTest.cmake | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Tests/RunCMake/Framework/RunCMakeTest.cmake
b/Tests/RunCMake/Framework/RunCMakeTest.cmake
index d810283..eeea6f1 100644
--- a/Tests/RunCMake/Framework/RunCMakeTest.cmake
+++ b/Tests/RunCMake/Framework/RunCMakeTest.cmake
@@ -20,7 +20,7 @@ unset(RunCMake_TEST_OPTIONS)
set(RunCMake_TEST_BINARY_DIR ${RunCMake_BINARY_DIR}/OSXFrameworkLayout-build)
set(RunCMake_TEST_NO_CLEAN 1)
-set(RunCMake_TEST_OPTIONS
"-DCMAKE_TOOLCHAIN_FILE=${RunCMake_SOURCE_DIR}/OSX.cmake")
+set(RunCMake_TEST_OPTIONS
"-DCMAKE_TOOLCHAIN_FILE=${RunCMake_SOURCE_DIR}/osx.cmake")
file(REMOVE_RECURSE "${RunCMake_TEST_BINARY_DIR}")
file(MAKE_DIRECTORY "${RunCMake_TEST_BINARY_DIR}")
--
2.8.0.rc3.226.g39d4020
--
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
[cmake-developers] Email feed for new CMake bugs
Hello, in the past (with Mantis) I found it quite helpful to see new bugs posted here on this mailing list. Is it planned to restore that functionality? Thanks, Gregor -- 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
Re: [cmake-developers] QtAutogen 3.6.0 directory nesting overflow patch
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` 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
Re: [cmake-developers] QtAutogen 3.6.0 directory nesting overflow patch
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` 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
Re: [cmake-developers] QtAutogen 3.6.0 directory nesting overflow patch
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
Re: [cmake-developers] Export files in the build tree have a total path length which is unnecessarily long
On 08/08/2016 02:54 PM, Alan W. Irwin wrote: > For all such staging areas, would it be straightforward to hash the > paths for the cmake-generated EXPORT files in the build tree to > substantially reduce their pathlengths for the absolute install > location case while still avoiding name collisions? Actually it looks like we already do this, but the logic forgot to account for the length of the file name. Please try this fix: install(EXPORT): Fix support for mid-length install destinations on Windows https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c7a319ab 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
Re: [cmake-developers] QtAutogen 3.6.0 directory nesting overflow patch
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
