[cmake-developers] [CPackIFW] Adding QtIFW 2.0 Support (Technical Preview)
Online repository updated! Meet CMake 3.2.20150529 :-) Online installers for Linux and Windows are available at the links below. On 29.04.2015, 16:57, Konstantin Podsvirov konstan...@podsvirov.pro: Two installer collected in Debian 8: http://ifw.podsvirov.pro/cmake/cmake-master-i386-online.run http://ifw.podsvirov.pro/cmake/cmake-master-amd64-online.run Installer And two collected in Windows 7: http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe The presented version of CMake (CPackIFW) already know how to work with QtIFW 2.0 but not in full. I would like to know from users CPackIFW and QtIFW what functionality demanded in the first place. Suggest we discuss the quality of the generated configuration files. Also available documentation: http://ifw.podsvirov.pro/cmake/doc/sphinx http://ifw.podsvirov.pro/cmake/doc/doxygen Code was included in master branch and will be officially presented in CMake 3.3 cpack-ifw-updates: http://www.cmake.org/cmake/help/git-master/release/dev/cpack-ifw-updates.html?highlight=ifw [cmake-developers] CMake 3.3 feature freeze on 2015-06-01: http://public.kitware.com/pipermail/cmake-developers/2015-May/025310.html All anyone wants to try, but are too lazy to collect can use the development versions: http://www.cmake.org/files/dev Or try/be updated with the above installers :-) Regards, Konstantin Podsvirov-- 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] [CMake 0015593]: Overriding the project configuration (CMAKE_C_SOURCE_FILE_EXTENSIONS)
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15593 == Reported By:Art Assigned To: == Project:CMake Issue ID: 15593 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-05-29 07:31 EDT Last Modified: 2015-05-29 07:31 EDT == Summary:Overriding the project configuration (CMAKE_C_SOURCE_FILE_EXTENSIONS) Description: During the operation of the module CMakeCCompiler.cmake.in comes to overwrite the user's configuration parameter CMAKE_C_SOURCE_FILE_EXTENSIONS Proposed solution: https://github.com/Kitware/CMake/blob/master/Modules/CMakeCCompiler.cmake.in#L34 set(CMAKE_C_SOURCE_FILE_EXTENSIONS c;m) Can be replaced on IF(NOT CMAKE_C_SOURCE_FILE_EXTENSIONS) set(CMAKE_C_SOURCE_FILE_EXTENSIONS c;m) ENDIF() == Issue History Date ModifiedUsername FieldChange == 2015-05-29 07:31 ArtNew Issue == -- 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] [CMake 0015594]: Fix a bug in cmake-compile-features(7) manual : Replace target_link_libraries() with target_include_directories()
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15594 == Reported By:Erik Sjölund Assigned To: == Project:CMake Issue ID: 15594 Category: Documentation Reproducibility:N/A Severity: minor Priority: normal Status: new == Date Submitted: 2015-05-29 10:13 EDT Last Modified: 2015-05-29 10:13 EDT == Summary:Fix a bug in cmake-compile-features(7) manual : Replace target_link_libraries() with target_include_directories() Description: target_link_libraries() is being used in the example code in the cmake-compile-features(7) manual http://www.cmake.org/cmake/help/v3.2/manual/cmake-compile-features.7.html#manual:cmake-compile-features(7) but target_include_directories() was probably meant to be used. The sentence that starts with Consuming code then indicates that the example is about using the appropriate include directory. A patch was uploaded together with this bug report. == Issue History Date ModifiedUsername FieldChange == 2015-05-29 10:13 Erik Sjölund New Issue 2015-05-29 10:13 Erik Sjölund File Added: patch.txt == -- 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] Composability of INTERFACE properties and custom targets
Hi,
in a project, I have to generate some C++ header files at build time.
Targets that use these header files need to know the directory of the
generated files and depend on the custom target that in turn depends
on the generated files. Example:
target_include_directories(lib PRIVATE ${gen_dir})
add_dependency(lib gen_target)
I would like to modernize that to:
target_link_libraries(lib PRIVATE gen_interface)
However, there is afaik no way of combining INTERFACE properties and
custom targets.
I think CMake needs one of the following alternatives:
1. Allow adding target-level dependencies to INTERFACE library:
add_library(interface INTERFACE)
target_include_directories(interface INTERFACE ...)
add_custom_target(custom DEPENDS ...)
add_dependencies(interface custom)
2. Allow INTERFACE properties on custom targets:
add_custom_target(custom DEPENDS ...)
target_include_directories(custom INTERFACE ...)
3. Allow file level dependencies for INTERFACE libraries
add_library(interface INTERFACE DEPENDS ...)
Any of these three solutions satisfies my requirements, option 3 being
my favorite.
A similar question was left unanswered here:
http://public.kitware.com/pipermail/cmake/2014-April/057456.html
cheers, Daniel
--
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] Importing platform SDK libraries without a full path
On 05/27/2015 05:58 PM, Stephen Kelly wrote: I see INTERFACE as has no location (lower case), and I see IMPORTED_LIBNAME as a location. It specifies to the toolchain-supplied compiler to locate a particular toolchain-supplied library and link it. I define location as known full path to a file on disk. Everything else is just an option to the linker. So: - TARGET_FILE is not valid without a location - INTERFACE libraries have no location - TARGET_FILE is not valid for INTERFACE libraries This is all consistent. IMPORTED_LIBNAME is not a known full path to a file on disk. It is an option to the linker. why not in-line link items? it is in-placed because it represents a location. It is in-placed because we want to search that library before following libraries. In the future more general LINK_ITEMS case it could be a flag whose order matters. The IMPORTED_LIBNAME is different to everything else about how INTERFACE libraries work and the type of transitive properties and porcelain APIs they support. Since IMPORTED_LIBNAME is a predecessor to a future INTERFACE_LINK_ITEMS I think this comes down to whether INTERFACE libraries should support LINK_ITEMS. See next paragraph. To use this interface, put $items in-place on your link line. What would the use-case for that be? One should be able to replace any raw link item in a tll() call with a CMake library target in order to get that same raw item in-place but also add other usage requirements. If that raw item is a full path to a library file then we can do this with a SHARED/STATIC/UNKNOWN imported library. I'm proposing that INTERFACE libraries offer LINK_ITEMS in order to fill this role when the raw item is not a full path to a library file. Validity of TARGET_FILE should be based on the *type* of the target given, not its configuration. then adding another type would solve that issue. In the long run we're looking for a target type that: * has no location and does not allow TARGET_FILE, * supports usage requirements, and * supports in-place link items. The INTERFACE type already meets the first two requirements. Again the debate comes down to whether interface libraries should support in-place link items. I argue above that they should. If not, then we will have a new target type that is exactly like INTERFACE but also supports in-place link items. Actually I think this can and should be done for INTERFACE libraries even without IMPORTED_LIBNAME. I'll look at factoring this part out into a preceding commit. Cool, I think reviewing that separately would be preferable. I'm interested to see what it looks like without IMPORTED_LIBNAME and where the default mapping will come from then, or if there just won't be a default mapping until the INTERFACE library becomes 'particular' to something else with IMPORTED_LIBNAME. I agree. We should resolve configuration mapping for INTERFACE libraries first. I need to revert the 'imported-interface-libname' topic from 'next' in preparation for the 3.3 freeze anyway. After that we can return first to INTERFACE configuration mapping and later to link items. 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
[cmake-developers] [CMake 0015595]: FindPkgConfig does not use the CMAKE_FRAMEWORK_PATH and CMAKE_APPBUNDLE_PATH cache variables
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15595
==
Reported By:Daniele E. Domenichelli
Assigned To:Daniele E. Domenichelli
==
Project:CMake
Issue ID: 15595
Category: Modules
Reproducibility:have not tried
Severity: minor
Priority: normal
Status: assigned
==
Date Submitted: 2015-05-29 19:28 CEST
Last Modified: 2015-05-29 19:28 CEST
==
Summary:FindPkgConfig does not use the CMAKE_FRAMEWORK_PATH
and CMAKE_APPBUNDLE_PATH cache variables
Description:
The CMAKE_FRAMEWORK_PATH and CMAKE_APPBUNDLE_PATH cache variables are supposed
to be used to generate the extra paths passed to pkg-config, but instead the
CMAKE_PREFIX_PATH variable is used.
I wrote a patch and added a couple of unit tests
topic: FindPkgConfig_fix_extra_path
FindPkgConfig: Fix extra paths for CMAKE_{FRAMEWORK,APPBUNDLE}_PATH vars
http://www.cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=d4c6531
Let me know if I can merge this and to which branch (next or release?).
==
Issue History
Date ModifiedUsername FieldChange
==
2015-05-29 19:28 Daniele E. DomenichelliNew Issue
2015-05-29 19:28 Daniele E. DomenichelliStatus new = assigned
2015-05-29 19:28 Daniele E. DomenichelliAssigned To = Daniele E.
Domenichelli
==
--
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] [CMake 0015596]: CMakeClDeps.cmake doesn't work if CC contains arguments
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15596 == Reported By:Reid Kleckner Assigned To: == Project:CMake Issue ID: 15596 Category: (No Category) Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-05-29 13:47 EDT Last Modified: 2015-05-29 13:47 EDT == Summary:CMakeClDeps.cmake doesn't work if CC contains arguments Description: I am attempting to do a 32-bit self-host of clang on Windows with a 64-bit clang-cl binary. By default, the 64-bit binary generates 64-bit code, so I need to pass the -m32 flag to override that. I figured the most robust way to do this is something like setting CC=clang-cl -m32 and running cmake. This *almost* worked, but CMakeCLDeps.cmake runs CMAKE_C_COMPILER without the flags present in CC, and the link failed. It's regex then matched the error message from LINK, and I got this in rules.ninja: msvc_deps_prefix = LINK : error LNK2001: CMakeClDeps.cmake doesn't actually need to do a link, so one easy workaround would be to add /c to command line there. That's probably a good tweak in general, since it saves an invocation of link.exe, and cuts down on moving parts. :) Aside from the workaround, is there a more canonical way that CMakeClDeps should be invoking the compiler that includes flags from the CC env var? == Issue History Date ModifiedUsername FieldChange == 2015-05-29 13:47 Reid Kleckner New Issue == -- 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] Composability of INTERFACE properties and custom targets
On 05/29/2015 10:05 AM, Daniel Pfeifer wrote: 1. Allow adding target-level dependencies to INTERFACE library: add_library(interface INTERFACE) target_include_directories(interface INTERFACE ...) add_custom_target(custom DEPENDS ...) add_dependencies(interface custom) This was made possible recently: Allow add_dependencies() on INTERFACE libraries http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ac14cbf0 and will be in 3.3. -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] Compact dependency graph
On 05/27/2015 05:49 PM, Richard Ulrich wrote: So with this patch, I can define regex replace rules to group the external libraries together. Nice. Thanks for working on this. since cmake has to compile with older compilers Yes. I extracted the RegexReplace functionality from the string processor, and put it in a new file. For the moment I commented out the error reporting. I'm not sure how that would be handled best. That's where I could use some input. The string() command implementation can be refactored out into an internal helper as you propose. That internal helper will need to define an abstraction for the error cases so that the cmGraphVizWriter can capture the errors too. Then the string() implementation can capture them and transform them back into the original error messages. 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
[cmake-developers] [CMake 0015597]: Issues with the 'Eclipse CDT4 - NMake Makefiles' Generator
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15597 == Reported By:Anthony Ette Assigned To: == Project:CMake Issue ID: 15597 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-05-29 14:56 EDT Last Modified: 2015-05-29 14:56 EDT == Summary:Issues with the 'Eclipse CDT4 - NMake Makefiles' Generator Description: The project compiles and links in Eclipse but the preprocessor symbols are not defined by the .cproject file. As a result, sections with #ifdef _WIN32 #endif appear grayed out in the IDE and any included files can't be opened. Note that I'm using Eclipse 4 (Luna). Is there any way I can ensure that the Eclipse project has knowledge of my toolchain's preprocessor symbols without having to redefine them all in my CMakeLists.txt file(s)? Steps to Reproduce: 1) setup project with in source build for better eclipse support (see http://www.cmake.org/Wiki/Eclipse_CDT4_Generator) 2) run cmake with the following (please see attached toolchain file for reference): C:\Users\bzpl46\sim\sandbox\AE3007\C2cmake -DCMAKE_TOOLCHAIN_FILE=toolchains\to olchain_windows_vsc.cmake -G Eclipse CDT4 - NMake Makefiles -- The C compiler identification is MSVC 15.0.30729.1 -- The CXX compiler identification is MSVC 15.0.30729.1 -- Eclipse version is set to 4.4 (Luna). Adjust CMAKE_ECLIPSE_VERSION if this is wrong. -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin/cl.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studi o 9.0/VC/bin/cl.exe -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studi o 9.0/VC/bin/cl.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- CMAKE_BINARY_DIR: C:/Users/bzpl46/sim/sandbox/AE3007/C2 -- CMAKE_CURRENT_BINARY_DIR: C:/Users/bzpl46/sim/sandbox/AE3007/C2 -- CMAKE_SOURCE_DIR: C:/Users/bzpl46/sim/sandbox/AE3007/C2 -- CMAKE_CURRENT_SOURCE_DIR: C:/Users/bzpl46/sim/sandbox/AE3007/C2 -- PROJECT_BINARY_DIR: C:/Users/bzpl46/sim/sandbox/AE3007/C2 -- PROJECT_SOURCE_DIR: C:/Users/bzpl46/sim/sandbox/AE3007/C2 -- EXECUTABLE_OUTPUT_PATH: C:/Users/bzpl46/sim/sandbox/AE3007/C2 -- LIBRARY_OUTPUT_PATH: -- CMAKE_MODULE_PATH: -- CMAKE_COMMAND: I:/PortableApps/cmake-3.2.2-win32-x86/bin/cmake.exe -- CMAKE_ROOT: I:/PortableApps/cmake-3.2.2-win32-x86/share/cmake-3.2 -- CMAKE_CURRENT_LIST_FILE: C:/Users/bzpl46/sim/sandbox/AE3007/C2/CMakeLists.txt -- CMAKE_CURRENT_LIST_LINE: 90 -- CMAKE_INCLUDE_PATH: -- CMAKE_LIBRARY_PATH: -- CMAKE_SYSTEM: Windows -- CMAKE_SYSTEM_NAME: Windows -- CMAKE_SYSTEM_VERSION: -- CMAKE_SYSTEM_PROCESSOR: -- UNIX: -- CMAKE_SKIP_RULE_DEPENDENCY: -- CMAKE_SKIP_INSTALL_ALL_DEPENDENCY: -- CMAKE_SKIP_RPATH: NO -- CMAKE_VERBOSE_MAKEFILE: FALSE -- CMAKE_SUPPRESS_REGENERATION: -- CMAKE_C_FLAGS: /DWIN32 /D_WINDOWS /W3 -- CMAKE_C_FLAGS_DEBUG: /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 -- CMAKE_C_FLAGS_RELEASE: /MD /O2 /Ob2 /D NDEBUG -- CMAKE_CXX_FLAGS: /DWIN32 /D_WINDOWS /W3 /GR /EHsc -- CMAKE_BUILD_TYPE: Debug -- BUILD_SHARED_LIBS: -- CMAKE_C_COMPILER: C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin/c l.exe -- CMAKE_CXX_COMPILER: C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin /cl.exe -- CMAKE_COMPILER_IS_GNUCC: -- CMAKE_COMPILER_IS_GNUCXX : -- CMAKE_AR: -- CMAKE_RANLIB: -- Configuring done -- Generating done -- Build files have been written to: C:/Users/bzpl46/sim/sandbox/AE3007/C2 3) import the project into Eclipse, right click on the project, go to Properties - C/C++ General - Paths and Symbols and notice that there are no symbols defined. There is not even a Symbols tab which is typically the case for a valid CDT project. == Issue History Date ModifiedUsername FieldChange == 2015-05-29 14:56 Anthony Ette New Issue 2015-05-29 14:56 Anthony Ette File Added: toolchain_windows_vsc.cmake
