[cmake-developers] [CMake 0013385]: Ninja: LINK_LIBRARIES not spilled to response file
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13385 == Reported By:Zaheer Chothia Assigned To: == Project:CMake Issue ID: 13385 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-07-09 11:03 WAT Last Modified: 2012-07-09 11:03 WAT == Summary:Ninja: LINK_LIBRARIES not spilled to response file Description: * Command line length is limited on Windows. * To alleviate this, CMake places object files into a response file, but the same is not done for libraries. * This can pose a problem when the link line becomes too long. Steps to Reproduce: See attached testcase generator. Additional Information: I am primarily interested in a solution for the Ninja generator, although this issue affects other generators too (e.g. NMake, MinGW Makefiles). For further discussion see the mailing list: http://www.cmake.org/pipermail/cmake/2012-June/051065.html == Issue History Date ModifiedUsername FieldChange == 2012-07-09 11:03 Zaheer Chothia New Issue 2012-07-09 11:03 Zaheer Chothia File Added: testcase.sh == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Weird behavior with spaces in ctest_configure
Well, the documentation is The OPTIONS argument specifies command line arguments to pass to the configuration tool. So I'd say it's more of a code bug and should be fixed in the code if possible. On the CMake command line we would accept either -DCMAKE_... or -D CMAKE_... On Mon, Jul 9, 2012 at 6:05 AM, Rolf Eike Beer e...@sf-mail.de wrote: I found this in one of my dashboards: CMake Warning: Manually-specified variables were not used by the project: CMAKE_BUILD_TYPE This was sort of a WTF as you may guess. I played around with it and found that this was caused by this instruction: ctest_configure( OPTIONS -D CMAKE_BUILD_TYPE=Debug ) If I remove the space between the -D and the rest everything works fine. What is up there? This is a bug, the question is: a documentation one or a code one? Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Weird behavior with spaces in ctest_configure
2012/7/9 David Cole david.c...@kitware.com: I'm wondering if we should fix the place where that warning is emitted as well. It seems like perhaps the variable it's complaining about is CMAKE_BUILD_TYPE (with a leading space) and if we had some non-white-space bracketing characters around the variable name, the real problem would have been suggested more strongly by the output on the dashboard. Something like: CMake Warning: Manually-specified variables were not used by the project: [ CMAKE_BUILD_TYPE] This would be nice and make it easier to catch some whitespace related error. I Usually use [] or in order to exhibit such user defined values. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013386]: CPack-generated Debian packages do not comply to Debian policy (discovered via lintian)
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13386
==
Reported By:Johannes Wienke
Assigned To:
==
Project:CMake
Issue ID: 13386
Category: CPack
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-07-09 08:22 EDT
Last Modified: 2012-07-09 08:22 EDT
==
Summary:CPack-generated Debian packages do not comply to
Debian policy (discovered via lintian)
Description:
Running lintian on a CPack-generated Debian package produces the following
output (some warnings not related to CPack bugs have been removed; our package
name is rsb0.7, the library is called librsbcore.so):
E: rsb0.7: control-file-has-bad-permissions md5sums 0640 != 0644
E: rsb0.7: no-copyright-file [1]
W: rsb0.7: non-standard-dir-perm usr/ 0700 != 0755[2]
W: rsb0.7: non-standard-dir-perm usr/bin/ 0700 != 0755
W: rsb0.7: non-standard-dir-perm usr/include/ 0700 != 0755
W: rsb0.7: non-standard-dir-perm usr/lib/ 0700 != 0755
W: rsb0.7: non-standard-dir-perm usr/share/ 0700 != 0755
E: rsb0.7: md5sums-lists-nonexisting-file usr/lib/librsbcore.so [3]
E: rsb0.7: no-shlibs-control-file usr/lib/librsbcore.so.0.7.0
E: rsb0.7: postinst-must-call-ldconfig usr/lib/librsbcore.so.0.7.0
Notes:
[1] We use SET(CPACK_RESOURCE_FILE_LICENSE
${CMAKE_CURRENT_SOURCE_DIR}/COPYING.txt), therefore CPack should use the
specified file as package license file
[2] The exact permissions and therefore error message depend on the current
umask. CPack should set a fixed, compliant umask independently of what the user
happens to use.
[3] This is caused by symlinking usr/lib/librsbcore.so to
usr/lib/librsbcore.so.0.7.0 which happens when sonames and -versions are used in
CMake.
Steps to Reproduce:
Our CMake and CPack files are a bit length to include here (viewable at
https://code.cor-lab.org/projects/rsb/repository/entry/trunk/cpp/core/CMakeLists.txt).
We called cpack (or make package) with fakeroot to achieve correct user- and
group-ids.
Packaging any CMake based library project should produce identical warnings.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-07-09 08:22 Johannes WienkeNew Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] The BuildFlags test you attempted last week...
Not sure what your main goal was for that test, but a similar test already exists to ensure proper definition of CMAKE_BUILD_TYPE or proper selection of build configuration in a multi-config generator. But only in the context of running a ctest -D dashboard or a ctest -S dashboard script. See the files Tests/CTestConfig/CMakeLists.txt and Tests/CTestConfig/CTestConfig.cxx for details. You would need a block for if(CMAKE_CONFIGURATION_TYPES) in order to get the logic just right w.r.t. CMAKE_BUILD_TYPE in your test. The Visual Studio and/or Xcode dashboards that did pass your test, passed it by luck because the built configuration happened to match the CMAKE_BUILD_TYPE that you were trying to expect. The important piece of knowledge to have here is that CMAKE_BUILD_TYPE is not defined for multi-config generators, and in fact, it should be considered bad practice, although it's not strictly an error, to define it in such a build tree. Because in a multi-config generator you can actually have multiple builds (Debug+Release+...) existing side-by-side in the same build tree. Hope this helps, David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] SONAME on APPLE?
Hi there, The patch at: https://codereview.qt-project.org/#change,30084 sets the IMPORTED_SONAME on linux for Qt 5 IMPORTED targets. I don't know whether it should also be set on APPLE, but I have now done some investigation. I created a dummy project to test the output created by CMake when generating IMPORTING targets with install(EXPORT). It seems that on APPLE, otool -D the_lib will output the shared library id name. I don't know for certain that it is the same thing (I know very little about APPLE), but CMake seems to set that based on the name of the library, the SOVERSION property, and the file suffix. So far it seems similar to the SONAME reported by objdump on linux. CMake seems to populate the shared library id name (Let's call it SONAME for now, even on APPLE) with a full path when the library is in the build directory (/Users/kdab/dev/cmake/build/libcmakeqt.5.dylib), and without the path when installed (Only libcmakeqt.5.dylib). I don't know if that is configurable. I didn't find any way to create 'frameworks' with CMake, so I don't know if there is even the concept of a SONAME when creating a 'framework' on APPLE. Running otool -D on QtCore from Qt 5 (configured with -no-frameworks), I get a full path to the install location when running it on the binaries in both the build location and the install location. Running otool -D on QtCore from Qt 5 (configured as it is by default, that is, with -frameworks), I get a full versioned path to QtCore.framework/Versions/5/QtCore in the install location when run on QtCore.framework/QtCore in both the build dir and the install dir. CMake seems to use this information to compute the link line, so it would seem advantagous that I set it correctly on relevant platforms. Can anyone add clarity to anything I wrote? Should I set the IMPORTED_SONAME to these full paths to the installation location on APPLE? Wouldn't that make the frameworks non-relocatable, or is that a bug in Qt anyway? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] LINK_LIBRARIES not spilled to response file
I have added a patch that should help. (Tested on Darwin only) Please check it for Windows before apply. Claus On 09.07.2012, at 12:13, Zaheer Chothia wrote: Done: http://public.kitware.com/Bug/view.php?id=13385 --Zaheer -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
