Re: [cmake-developers] Where to document the graphviz options ?
2013/7/24 Alexander Neundorf neund...@kde.org: Hi, using cmake --graphviz=filename . you can generate graphs showing the dependencies between the targets. If present, cmake will read a CMakeGraphVizOptions.cmake file, and use options from it, e.g. GRAPHVIZ_GRAPH_TYPE and GRAPHVIZ_EXTERNAL_LIBS. AFAIK this is not documented anywhere, and I would like to change this. But where should I put this information ? I would suggest to document it inside CMakeGraphVizOptions.cmake using basic markup used for documenting CPack generators. Then simply make cmake parse the file the way cpack does and you'll get the variables (or macro/functions) documented in --help-variable-* Simply list the variables in the variables section, and mention that they need to be set in a CMakeGraphVizOptions.cmake file ? Better ideas ? Nope. -- Erk L'élection 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 0014311]: CMake cannot install imported targets
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14311 == Reported By:Nikita Krupenko Assigned To: == Project:CMake Issue ID: 14311 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2013-07-25 05:19 EDT Last Modified: 2013-07-25 05:19 EDT == Summary:CMake cannot install imported targets Description: I use ExternalProject for building non-Cmake projects and add imported targets for that projects. For example: ExternalProject_add(mylib_proj ...) add_library(mylib SHARED IMPORTED) set_target_properties(mylib PROPERTIES IMPORTED_LOCATION ...) add_dependencies(mylib mylib_proj) I can link with that library, but CMake cannot install them. This code install(TARGETS mylib DESTINATION ...) produces following error: CMake Error at CMakeLists.txt:48 (install): install TARGETS given target mylib which does not exist in this directory. Because of broken install packaging using CPack also not working. == Issue History Date ModifiedUsername FieldChange == 2013-07-25 05:19 Nikita KrupenkoNew 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] CPack BAR package generator
Hi there, I've pushed a cpack-bar-package topic to my clone https://gitorious.org/~steveire/cmake/steveires-cmake It is the start of a CPack generator for BlackBerry BAR packages, required for deployment to those devices. I haven't worked much with CPack before, so I'd appreciate some feedback even at this early point. Some issues that have come up already are in the commit message. 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] Allowed chars in test names
On 07/24/2013 05:38 PM, Rolf Eike Beer wrote: So for the beginning I would go and just simply reject every test name that has spaces or quotes, because that has never worked. That sounds good. Thanks, -Brad -- 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 0014312]: Parallel builds using make break when two or more targets that share a dependency (or are dependent) are called explicitly
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14312 == Reported By:Wojciech Knapik Assigned To: == Project:CMake Issue ID: 14312 Category: CMake Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2013-07-25 15:14 CEST Last Modified: 2013-07-25 15:14 CEST == Summary:Parallel builds using make break when two or more targets that share a dependency (or are dependent) are called explicitly Description: In the example below, the top level targets for main and empty have recipes that call make. When make is called with -j, the two instances of make are called in parallel and, knowing nothing about each other, race to finish the same task. In the real world, this breaks builds in very common use cases. E.g. when you have 3 types of tests - ut, mt and it - it is reasonable to call `make -j24 ut mt it'. If those targets happen to share dependencies, the build will break. Creating top level targets that cover all such combinations is not an acceptable solution. Steps to Reproduce: $ cat CMakeLists.txt cmake_minimum_required(VERSION 2.8) project(foo) add_library(empty STATIC empty.cpp) add_custom_command(TARGET empty POST_BUILD COMMAND echo whoops) add_executable(main main.cpp) target_link_libraries(main empty) $ cd build $ cmake .. $ make -j empty main|grep whoops whoops whoops $ == Issue History Date ModifiedUsername FieldChange == 2013-07-25 15:14 Wojciech KnapikNew 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] target_link_libraries, IMPORTED targets and SYSTEM includes
Hi,
In response to
https://bugreports.qt-project.org/browse/QTBUG-32599
I first considered adding something like
if(NOT QT_INCLUDE_DIRS_NO_SYSTEM)
set_property(TARGET Qt5::Core
SYSTEM_INTERFACE_INCLUDE_DIRECTORIES
${Qt5Core_INCLUDE_DIRS}
)
endif()
for each imported target, which would cause CMake to treat the includes for
it as system includes.
Then I had the idea that I didn't like the API of
set(QT_INCLUDE_DIRS_NO_SYSTEM 1)
find_package(Qt5Core)
and I prefered
find_package(Qt5Core)
add_library(foo ...)
target_link_libraries(foo SYSTEM Qt5::Core)
which has a similar effect as the SYSTEM keyword in
target_include_directories.
I implemented that without a test so far in tll-system-includes-signature in
my clone. However, the motivation for that is that I generally want to treat
all 'external' headers as system includes, and Qt is just a common external
dependency.
Should we treat the INTERFACE_INCLUDE_DIRECTORIES of all IMPORTED targets as
SYSTEM includes automatically?
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
[cmake-developers] Shared library names with numerical suffix
Hi,
Commit 342fc0401005 (Recognize shared library files with a numerical suffix,
2013-04-11) resulted from
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6613/focus=6616
In a more-recent review, I thought that if there is an extension in the exts
list which already has a numerical extension, then the extra check for a
numerical extension shouldn't be added for that entry.
else if(type == LinkShared)
{
libext += (\\.[0-9]+)?;
}
The code is quite complex with regexes. I wonder if something like that can
be fixed, or should it just be left as-is?
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] target_link_libraries, IMPORTED targets and SYSTEM includes
On 07/25/2013 09:16 AM, Stephen Kelly wrote: target_link_libraries(foo SYSTEM Qt5::Core) That looks okay to me so long as SYSTEM must always be the first keyword. We could also consider adding it only to the modern (newest) keyword signature to encourage conversion to it. Should we treat the INTERFACE_INCLUDE_DIRECTORIES of all IMPORTED targets as SYSTEM includes automatically? I don't think so because one could be importing targets from a dependency that was just built as part of a superbuild and may want to see the warnings. -Brad -- 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] Shared library names with numerical suffix
On 07/25/2013 09:31 AM, Stephen Kelly wrote:
In a more-recent review, I thought that if there is an extension in the exts
list which already has a numerical extension, then the extra check for a
numerical extension shouldn't be added for that entry.
else if(type == LinkShared)
{
libext += (\\.[0-9]+)?;
}
This hunk occurs once at the end after all extensions have been considered.
The choice can't be made on a per-entry basis in the current design. I
think it is fine as-is.
-Brad
--
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 0014313]: Automoc outputs in CMAKE_CURRENT_BINARY_DIR, not customizable
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14313 == Reported By:Marc Plano-Lesay Assigned To: == Project:CMake Issue ID: 14313 Category: CMake Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2013-07-25 10:13 EDT Last Modified: 2013-07-25 10:13 EDT == Summary:Automoc outputs in CMAKE_CURRENT_BINARY_DIR, not customizable Description: Using Automoc with CMake 2.8.11/Qt5, there's no way to choose where the moc files are generated. AM_CMAKE_CURRENT_BINARY_DIR is defined in AutomocInfo.cmake and can't be defined anywhere else. == Issue History Date ModifiedUsername FieldChange == 2013-07-25 10:13 Marc Plano-LesayNew 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
Re: [cmake-developers] target_link_libraries, IMPORTED targets and SYSTEM includes
Brad King wrote: On 07/25/2013 09:16 AM, Stephen Kelly wrote: target_link_libraries(foo SYSTEM Qt5::Core) That looks okay to me so long as SYSTEM must always be the first keyword. Yes, that's how I've implemented it currently. We could also consider adding it only to the modern (newest) keyword signature to encourage conversion to it. I considered that, but I think the plain signature without INTERFACE_LINK_LIBRARIES is going to remain most common in executable lhs cases. I didn't see any need to exclude it from only the signature with INTERFACE_LINK_LIBRARIES. Should we treat the INTERFACE_INCLUDE_DIRECTORIES of all IMPORTED targets as SYSTEM includes automatically? I don't think so because one could be importing targets from a dependency that was just built as part of a superbuild and may want to see the warnings. I considered that, but if you're building it as part of a superbuild, you'll still get the warning when building the dependency itself. You control the flags used to build the dependency, so you can add the flag to trigger the warning when building the dependency. If the dependency is something you bundle, like zlib as in the case of Qt and cmake, then you don't want to maintain patches to clean the headers, but you want them upstream. At the same time, you don't want to trigger the warnings which may be new with your compiler (usused typedefs is a common one nowadays) when using the bundled dependency. When building it, you disable that warning, and when using it, you want its headers treated as system headers, but you still want the unused typedef warning for your own code. So, I think it still makes sense to treat all interface include directories of IMPORTED targets as SYSTEM includes. 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] target_link_libraries, IMPORTED targets and SYSTEM includes
On 2013-07-25 11:25, Stephen Kelly wrote: Brad King wrote: On 07/25/2013 09:16 AM, Stephen Kelly wrote: Should we treat the INTERFACE_INCLUDE_DIRECTORIES of all IMPORTED targets as SYSTEM includes automatically? I don't think so because one could be importing targets from a dependency that was just built as part of a superbuild and may want to see the warnings. I considered that, but if you're building it as part of a superbuild, you'll still get the warning when building the dependency itself. Not necessarily; library A may provide a utility header that it doesn't actually use internally, and library B may use it and produce a warning. (Besides there is more chance of noticing a warning the more times it trips. For that matter, wouldn't this defeat the purpose in the original post of being able to include Qt as non-SYSTEM?) -- Matthew -- 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 0014314]: GCC warns about strict aliasing in cm_sha2.c
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14314 == Reported By:Petr Machata Assigned To: == Project:CMake Issue ID: 14314 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-07-25 12:17 EDT Last Modified: 2013-07-25 12:17 EDT == Summary:GCC warns about strict aliasing in cm_sha2.c Description: When compiling cm_sha2.c, GCC gives the following warning: /builddir/build/BUILD/cmake-2.8.11.2/Source/cm_sha2.c: In function 'cmSHA1_Final': /builddir/build/BUILD/cmake-2.8.11.2/Source/cm_sha2.c:743:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] *(sha_word64*)context-s1.buffer[56] = context-s1.bitcount; ^ There are four cases total. Steps to Reproduce: 1) Compile with recent GCC (4.8?) 2) Inspect compile log Additional Information: I propose fixing this by copying the necessary bytes through union. This should lead to the same binary, but will make it clear to GCC that we are only using the buffer as a bunch of characters. The test suite passes after applying the patch, that I attach. == Issue History Date ModifiedUsername FieldChange == 2013-07-25 12:17 Petr Machata New Issue 2013-07-25 12:17 Petr Machata File Added: cmake-2.8.11-strict_aliasing.patch == -- 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] target_link_libraries, IMPORTED targets and SYSTEM includes
Matthew Woehlke wrote: On 2013-07-25 11:25, Stephen Kelly wrote: Brad King wrote: On 07/25/2013 09:16 AM, Stephen Kelly wrote: Should we treat the INTERFACE_INCLUDE_DIRECTORIES of all IMPORTED targets as SYSTEM includes automatically? I don't think so because one could be importing targets from a dependency that was just built as part of a superbuild and may want to see the warnings. I considered that, but if you're building it as part of a superbuild, you'll still get the warning when building the dependency itself. Not necessarily; library A may provide a utility header that it doesn't actually use internally, and library B may use it and produce a warning. Edge case. Even then, library A should have a unit test which attempts to compile all of its headers with all warnings enabled. In Qt every module has a 'headersclean' unit test which does exactly that. https://qt.gitorious.org/qt/qtbase/blobs/dev/mkspecs/features/qt_headersclean.prf (Besides there is more chance of noticing a warning the more times it trips. For that matter, wouldn't this defeat the purpose in the original post of being able to include Qt as non-SYSTEM?) The purpose in the bug report is not to include Qt as non-SYSTEM, but the opposite. I don't see any reason for downstreams to include Qt headers as non-SYSTEM headers. 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
[cmake-developers] [CMake 0014315]: Icon name in CMake.desktop should not contain file extension
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14315 == Reported By:Petr Machata Assigned To: == Project:CMake Issue ID: 14315 Category: QtDialog Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-07-25 12:50 EDT Last Modified: 2013-07-25 12:50 EDT == Summary:Icon name in CMake.desktop should not contain file extension Description: This is described in the following spec: http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html While it's not mentioned explicitly, it's clear from the way LookupFallbackIcon is written that icon name is name of the icon, not a path or name of a file with that icon. Steps to Reproduce: 1) Read through linked standard 2) Read Source/QtDialog/CMake.desktop 3) Observe that the latter doesn't conform to the spec Additional Information: At this time I believe this works anyway, but if themes should provide CMake icons in svg, they would have to name them CMakeSetup32.png.svg, or some such, which is awkward. == Issue History Date ModifiedUsername FieldChange == 2013-07-25 12:50 Petr Machata New Issue 2013-07-25 12:50 Petr Machata File Added: cmake-desktop_icon.patch == -- 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] target_link_libraries, IMPORTED targets and SYSTEM includes
On 07/25/2013 12:22 PM, Stephen Kelly wrote: library A should have a unit test which attempts to compile all of its headers with all warnings enabled. In Qt every module has a 'headersclean' unit test which does exactly that. While this is a good idea we're not going to assume every project has such discipline. Also some consumers may include headers with a different preprocessing context that exposes the warning. The purpose in the bug report is not to include Qt as non-SYSTEM, but the opposite. I don't see any reason for downstreams to include Qt headers as non-SYSTEM headers. Then why not make INTERFACE_SYSTEM_INCLUDE_DIRECTORIES the default in the Qt imported targets and have a switch to turn them off? The code set(QT_INCLUDE_DIRS_NO_SYSTEM 1) find_package(Qt5Core) is not so bad in the edge case that needs it. Either way, the tll() SYSTEM option could still be useful. -Brad -- 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] SelectLibraryConfigurations cached/advanced variables
Hello, Now that SelectLibraryConfigurations is good enough for me, I updated FindGTK2.cmake to use it. I pushed my changes in a FindGTK2Debug topic, does anyone want to review them before I merge the changes to next? Thanks, Cheers, Daniele -- 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] SelectLibraryConfigurations cached/advanced variables
On 07/25/2013 01:18 PM, Daniele E. Domenichelli wrote:
Now that SelectLibraryConfigurations is good enough for me, I updated
FindGTK2.cmake to use it. I pushed my changes in a FindGTK2Debug topic,
does anyone want to review them before I merge the changes to next?
I just glanced through and the changes all look good to me except one
minor detail. In this hunk:
+include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake)
it is not safe to include a standard module inside a function due to
variable scoping. Please revise the commit to include the file ahead
of time. Then go ahead and merge.
Thanks,
-Brad
--
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] target_link_libraries, IMPORTED targets and SYSTEM includes
On 2013-07-25 13:25, Stephen Kelly wrote: Brad King wrote: On 07/25/2013 12:22 PM, Stephen Kelly wrote: library A should have a unit test which attempts to compile all of its headers with all warnings enabled. In Qt every module has a 'headersclean' unit test which does exactly that. While this is a good idea we're not going to assume every project has such discipline. Also some consumers may include headers with a different preprocessing context that exposes the warning. Right. Even if all headers are used by the upstream itself, this still applies. However, I still think IMPORTED=SYSTEM by *default* is a good idea, and let the edge case switch it back. I'm not seeing support for it though, so I guess I'll drop it. Somewhat echoing Brad's reply here, but it's not that I'm opposed to the idea, merely concerned that it is possible to get non-system includes when that is desired. Perhaps that is a misreading on my part, but I was getting the impression this change would make it so that imported targets can only ever be SYSTEM. Then why not make INTERFACE_SYSTEM_INCLUDE_DIRECTORIES the default in the Qt imported targets and have a switch to turn them off? The code set(QT_INCLUDE_DIRS_NO_SYSTEM 1) find_package(Qt5Core) is not so bad in the edge case that needs it. I don't like it though :). I'd prefer not to have any variables that change the behavior of a find_package call, so that only one find_package is ever needed, not multiple in different directories for scope. FWIW, I agree; variables controlling find_package (except search paths) are almost always an inferior solution :-). That said... what about having a SYSTEM (and/or NO_SYSTEM) flag for find_package? This could, for config-based packages with imported targets, control the default behavior for imported include directories. Either way, the tll() SYSTEM option could still be useful. I'll add that tomorrow. Again FWIW, a nice advantage of this is the ability to specify SYSTEM includes per target. (I'm not sure why you'd want to build one target with imported includes as SYSTEM and another not, but you could...) -- Matthew -- 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 -E tar not working correctly with xz-compressed tarballs on MSYS
On 07/24/2013 03:27 PM, Alan W. Irwin wrote: The first priority is to verify on Microsoft Windows that this is actually an issue using the the simple test I outlined in my previous post. At a MSYS prompt under MS Windows this works: $ cat a.tar.xz | unxz | tar x but this hangs: $ cmake -E tar xvf a.tar.xz One can see in the process tree that there is a child process of cmake called unxz that was started with no command line arguments. One can attach a debugger to see CMake blocked inside libarchive code. This confirms that the hang occurs on MS Windows just as in Wine. I suggest getting upstream libarchive and building its sample tools but without lzma support built-in. Then try using that binary to extract the .tar.xz file. -Brad -- 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 0014316]: CMake can't find Ninja w/ Double Quotes
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14316 == Reported By:Brennon Brimhall Assigned To: == Project:CMake Issue ID: 14316 Category: (No Category) Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2013-07-25 17:27 EDT Last Modified: 2013-07-25 17:27 EDT == Summary:CMake can't find Ninja w/ Double Quotes Description: When PATH is set using double quotes, and builder is set to Ninja, CMake is unable to find ninja executable. Steps to Reproduce: * Download Ninja * Set PATH with Double Quotes * Open CMake * Select Ninja as builder == Issue History Date ModifiedUsername FieldChange == 2013-07-25 17:27 Brennon BrimhallNew 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
Re: [cmake-developers] target_link_libraries, IMPORTED targets and SYSTEM includes
Matthew Woehlke wrote: On 2013-07-25 13:25, Stephen Kelly wrote: Brad King wrote: On 07/25/2013 12:22 PM, Stephen Kelly wrote: library A should have a unit test which attempts to compile all of its headers with all warnings enabled. In Qt every module has a 'headersclean' unit test which does exactly that. While this is a good idea we're not going to assume every project has such discipline. Also some consumers may include headers with a different preprocessing context that exposes the warning. Right. Even if all headers are used by the upstream itself, this still applies. However, I still think IMPORTED=SYSTEM by *default* is a good idea, and let the edge case switch it back. I'm not seeing support for it though, so I guess I'll drop it. Somewhat echoing Brad's reply here, but it's not that I'm opposed to the idea, merely concerned that it is possible to get non-system includes when that is desired. Perhaps that is a misreading on my part, but I was getting the impression this change would make it so that imported targets can only ever be SYSTEM. I didn't really make that clear as the discussion developed, but yes, I think it makes sense to allow treating the include directories as non-system somehow, even if not by default. Then why not make INTERFACE_SYSTEM_INCLUDE_DIRECTORIES the default in the Qt imported targets and have a switch to turn them off? The code set(QT_INCLUDE_DIRS_NO_SYSTEM 1) find_package(Qt5Core) is not so bad in the edge case that needs it. I don't like it though :). I'd prefer not to have any variables that change the behavior of a find_package call, so that only one find_package is ever needed, not multiple in different directories for scope. FWIW, I agree; variables controlling find_package (except search paths) are almost always an inferior solution :-). That said... what about having a SYSTEM (and/or NO_SYSTEM) flag for find_package? This could, for config-based packages with imported targets, control the default behavior for imported include directories. I don't think that solves the problem. You might have one target which you want to treat the directories as SYSTEM, and one which you don't. I think the API for this should have target scope: A target property like set_property(TARGET foo PROPERTY IMPORTED_INTERFACE_DIRS_SYSTEM 1) and set(CMAKE_IMPORTED_INTERFACE_DIRS_SYSTEM 1) to set the default, as usual. or set_property(TARGET foo PROPERTY IMPORTED_INTERFACE_DIRS system) set_property(TARGET foo PROPERTY IMPORTED_INTERFACE_DIRS non_system) set(CMAKE_IMPORTED_INTERFACE_DIRS system) Either way, the tll() SYSTEM option could still be useful. I'll add that tomorrow. Again FWIW, a nice advantage of this is the ability to specify SYSTEM includes per target. (I'm not sure why you'd want to build one target with imported includes as SYSTEM and another not, but you could...) Yes. Even with the target property as above you could still do target_link_libraries(foo SYSTEM Bar::core) target_link_libraries(foo Bar::gui) We could also add the opposite if you want. target_link_libraries(foo NON_SYSTEM Bar::core) However, as the above already is enough for all use-cases and what we're discussing is an edge-case already, we don't need too much API for it. We can always add it later if needed. 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 -E tar not working correctly with xz-compressed tarballs on MSYS
On 2013-07-25 15:31-0400 Brad King wrote: On 07/24/2013 03:27 PM, Alan W. Irwin wrote: The first priority is to verify on Microsoft Windows that this is actually an issue using the the simple test I outlined in my previous post. At a MSYS prompt under MS Windows this works: $ cat a.tar.xz | unxz | tar x but this hangs: $ cmake -E tar xvf a.tar.xz One can see in the process tree that there is a child process of cmake called unxz that was started with no command line arguments. One can attach a debugger to see CMake blocked inside libarchive code. This confirms that the hang occurs on MS Windows just as in Wine. I suggest getting upstream libarchive and building its sample tools but without lzma support built-in. Then try using that binary to extract the .tar.xz file. Thanks, Brad, for that Microsoft Windows confirmation, and I will follow your advice for the rest to try and track down whether the problem is for the libarchive upstream version or the libarchive version within CMake. With luck I should be able to come up with a fix as well (since drop-through to command-line handling of *.tar.xz should be completely straightforward) assuming the MSYS version of gdb works similarly to the Linux version (which I am familiar with). Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
