[cmake-developers] RFC - new module for multilib configuration
Hi all,
I've been working on a generic cmake stub that allows libraries to be
built with multiple configuration options a.k.a. multilib support in the
style of GCC, on behalf of my employer. This feature allows a user to
build multiple versions of the same library from the same source base
but compiled with different options and ABIs. Automake provides a
similar feature via macros in multilib.am.
May not seem very useful for desktops, but its pertinent for
embedded/cross development. Typical ARM/MIPS toolchains supply a dozen
multilib configurations, at least. I'd restrict the module to work with
GNU CC, but it seems to play along just fine with LLVM Clang compiler,
which has a gcc-compatible command-line.
Please review the attached module. Pasting an example in-line to
hopefully pique someone's interest.
Regards,
Faraz Shahbazker
Imagination Technologies
###
# Example Usage
###
set(sources_math sin.c cos.s floor.c ...)
include(MultiLibConfig)
# Initializer
multilib_build_setup()
if (MULTILIB_TOP)
Do everything you'd want to do only once, like installing headers,
top-level checks, etcetra
else () # MULTILIB_TOP
## This block is automagically repeated for each multilib configuration
# Creates target, sets compiler flags a handle for the user to
override target properties later.
# Signature is same as add_library()
multilib_add_library(m STATIC ${sources_math})
# Use the target handle `MULTILIB_TARGET_m' for customization
set_target_properties(${MULTILIB_TARGET_m} PROPERTIES OUTPUT_NAME mymath)
# Install, once again using the current target handle
install(TARGETS ${MULTILIB_TARGET_m} ARCHIVE DESTINATION
lib/${MULTILIB_DIR})
endif () # MULTILIB_TOP
## Configure with
## cmake -DMULTILIB_SELECT=ALL srcdir
#.rst:
# MultiLibConfig
# --
#
# This module provides generic stubs for building libraries with a C
# compiler that supports multi-lib configurations with the
# command-line option '-print-multi-lib'. Output format is expected to
# match that of . For compilers that do not support this option,
# MultiLibConfig has no effect and the default configuration of the
# library is built.
#
# Fine grained control of multilib configurations is provided with the
# variables MULTILIB_SELECT and MULTILIB_SKIP.
#
# MULTILIB_SELECT=[ALL|regex]
# ALL: all configurations, except those skipped by MULTILIB_SKIP are
# built
# regex: only configs matching the pattern, excluding those skipped by
# MULTILIB_SKIP are built
# If MULTILIB_SELECT is not specified, only the default configuration
# is built.
#
# MULTILIB_SKIP=[NONE|regex]
# NONE: all configurations selected by MULTILIB_SELECT are built
# regex: only those configurations selected by MULTILIB_SELECT, which
# do NOT match the pattern are built
# If MULTILIB_SKIP is not specified, behaviour is same as
# MULTILIB_SKIP=NONE. If MULTILIB_SELECT is not specified, MULTILIB_SKIP
# is ignored.
#
# This module defines the following variables:
#
# .. variable:: MULTILIB_TOP
# Flag to indicate top-level of multilib recursion, after creating
# multilib targets.
#
# .. variable:: MULTILIB_FLAVOUR
# `Compiler options' part of a multilib descriptor, only visible in
# the recursive sub-context.
#
# .. variable:: MULTILIB_DIR
# `Target directory' part of multilib descriptor, only visible in the
# recursive sub-context.
#
# .. variable:: MULTILIB_NAME
# Same as MULTILIB_FLAVOUR, or 'default' for the default multilib
# configuration, where MULTILIB_FLAVOUR is empty. Only visible in the
# recursive sub-context.
#
# .. variable:: MULTILIB_TARGET_name
# For each library added, a reference to the current multilib target.
#
# Example Usage:
# .. code-block::
set(sources_math sin.c cos.s floor.c ...)
include(MultiLibConfig)
multilib_build_setup()
if (MULTILIB_TOP)
Do everything you want to do only once, like installing headers,
top-level checks, etcetra
else (MULTILIB_TOP)
## build the library for each multilib configuration
## This step creates the target and sets up compiler flags for it based
## on the multilib configuration. It also creates a handle for the user
## to override target properties later.
add_library_multilib(m STATIC ${sources_math})
## The handle MULTILIB_TARGET_name allows user to override target
## properties or set install path
set_target_properties(${MULTILIB_TARGET_m} PROPERTIES OUTPUT_NAME mymath)
install(TARGETS ${MULTILIB_TARGET_m}
ARCHIVE DESTINATION lib/${MULTILIB_DIR})
endif (MULTILIB_TOP)
#
#=
# Copyright 2014 Imagination Technologies Limited
#
# Distributed under the OSI-approved BSD License (the License);
# see accompanying file Copyright.txt for details.
#
# This software is distributed WITHOUT ANY WARRANTY; without even the
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the License for more information.
Re: [cmake-developers] RFC - new module for multilib configuration
Am 23.04.2014 09:33, schrieb Faraz Shahbazker:
Hi all,
I've been working on a generic cmake stub that allows libraries to be
built with multiple configuration options a.k.a. multilib support in
the style of GCC, on behalf of my employer. This feature allows a user
to build multiple versions of the same library from the same source
base but compiled with different options and ABIs. Automake provides a
similar feature via macros in multilib.am.
May not seem very useful for desktops, but its pertinent for
embedded/cross development. Typical ARM/MIPS toolchains supply a dozen
multilib configurations, at least. I'd restrict the module to work
with GNU CC, but it seems to play along just fine with LLVM Clang
compiler, which has a gcc-compatible command-line.
I just did a quick look on the module because I do not have an urgent
need for it, so this is just a little nitpick:
string(REGEX REPLACE ; ; _C_MULTILIBS ${_C_MULTILIBS})
string(REGEX REPLACE \n ; _C_MULTILIBS ${_C_MULTILIBS})
Those can easily be written without REGEX, which will reduce the amount
of backslashes.
Eike
--
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/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014894]: Regression/Qt: cmake touches on each run moc_*.cxx_parameters
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14894 == Reported By:Peter Kuemmel Assigned To: == Project:CMake Issue ID: 14894 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2014-04-23 17:56 CEST Last Modified: 2014-04-23 17:56 CEST == Summary:Regression/Qt: cmake touches on each run moc_*.cxx_parameters Description: Reproduced with ninja on Windows: - build CMake with Qt-GUI - run cmake - call ninja -d explain which shows that all moc_*.cxx_parameters files are touched - all moc files are recompiled, all is new linked, this is very annoying == Issue History Date ModifiedUsername FieldChange == 2014-04-23 17:56 Peter Kuemmel 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --find-package (was: Roadmap to CMake 3.0)
On 2013-10-19 20:16+0200 Alexander Neundorf wrote: On Thursday 17 October 2013, Stephen Kelly wrote: Brad King wrote: On 10/17/2013 04:58 PM, Alexander Neundorf wrote: Yes, that was the idea, but I can't rely anymore on a Foo_LIBRARIES variable (or a slight variation) being set after a successful find_package(Foo): http://lists.kde.org/?l=kde-core-develm=138198795723680w=2 I.e. in the future there will be Find-modules which typically export one of (Foo|FOO)_(LIBRARIES|LIBRARY), some Config.cmake files which do that too, and a big number, probably majority, of Config.cmake files, which do not export such variables. The only chance I see would be to simply collect all library targets and return what they provide, but this doesn't feel good. I would have much prefered using a clear interface like the Foo_LIBRARIES variable. Perhaps we need to establish a convention for find modules and package configuration files to interact with --find-package mode. I have no thoughts on the specifics of how that would work though. A new, similar --find-target mode or similar may be more appropriate: cmake --find-target --package Qt5Widgets --target Qt5::Widgets ... # KF5Config exports 3 independent targets: cmake --find-target --package KF5Config --target KF5::ConfigCore ... cmake --find-target --package KF5Config --target KF5::ConfigGui ... cmake --find-target --package KF5Config --target KF5::ConfigWidgets ... Yes, that will work. And a new command/option is not even necessary. The name of the target could be given as additional option. If none is given, it will use the variables as it does now, if a target is given, it will use this target and its properties. I'll work on that when I find the time (and nobody is faster). How is that going, Alex? I have just reviewed this thread, and it appears at first you were rather discouraged about continuing with --find-package because of a lot of brokeness, but now you see a way forward. And that is good because being able to access compile or link flags for a given library with a simple command is extremely useful functionality. For example, as I explained in a different thread (see subject line --find-package option fails with some of the Qt5 components on the cmake mailing list), PLplot requires access to the compile and link flags for certain components of Qt5. And it appears (but please correct me if I am wrong) that --find-package is the only way to obtain that information. However, when I tried --find-package, it only partially worked for Qt5. Steve responded to that thread by saying --find-package was your department. :-) Now that I have found this thread, I tried the same experiment with CMake-3.0.0-rc3 with the following good and bad results: wine@raven ~software/cmake/install-3.0.0-rc3/bin/cmake --find-package -DNAME:STRING=Qt5Core -DCOMPILER_ID:STRING=GNU -DLANGUAGE:STRING=CXX -DMODE:STRING=COMPILE -I/home/wine/newstart/build_script/install-linux/include/ -I/home/wine/newstart/build_script/install-linux/include/QtCore -I/home/wine/newstart/build_script/install-linux//mkspecs/linux-g++ wine@raven ~software/cmake/install-3.0.0-rc3/bin/cmake --find-package -DNAME:STRING=Qt5Svg -DCOMPILER_ID:STRING=GNU -DLANGUAGE:STRING=CXX -DMODE:STRING=COMPILE CMake Error at /home/wine/newstart/build_script/install-linux/lib/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake:16 (message): Failed to find GL in with CMAKE_CXX_LIBRARY_ARCHITECTURE . Call Stack (most recent call first): /home/wine/newstart/build_script/install-linux/lib/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake:50 (_qt5gui_find_extra_libs) /home/wine/newstart/build_script/install-linux/lib/cmake/Qt5Gui/Qt5GuiConfig.cmake:141 (include) /home/wine/newstart/build_script/install-linux/lib/cmake/Qt5Widgets/Qt5WidgetsConfig.cmake:86 (find_package) /home/wine/newstart/build_script/install-linux/lib/cmake/Qt5Svg/Qt5SvgConfig.cmake:86 (find_package) /home/software/cmake/install-3.0.0-rc3/share/cmake-3.0/Modules/CMakeFindPackageMode.cmake:178 (find_package) Qt5Svg not found. CMake Error: Problem processing arguments. Aborting. I got identically bad results for Qt5Gui and Qt5PrintSupport (the other two components used by PLplot). So it appears the only component that currently works for CMake-2.8.12.2 and CMake-3.0.0-rc3 is Qt5Core. This was for a Qt5-5.2.1 that I built myself (see details of the configuration of that build in the other thread). Could you try the above two commands for yourself to confirm (or not) whether the above issue is a general one or specific to my particular Qt5 build? If it is a specific problem for my Qt5 build, and you have a recommendation to change that build so that --find-package works properly for me, that would be extremely helpful. However, if you discover the problem is a general one for --find-package and Qt5, then it appears that Qt5 might be a good illustrative example to use for your renewed effort at developing a reliable --find-package
Re: [cmake-developers] [PATCH] remove x placeholder from STREQUAL operands
On 2014-04-18 09:07, Brad King wrote: On 04/18/2014 08:58 AM, Rolf Eike Beer wrote: To forbid whitespace and control characters in variable names can IMHO only be good. Some people use arbitrary variable names as a way to do key/value tables. In such cases it is intentional to use arbitrary characters in variable names even though they are never written literally in the source. Adding actual data types (a true list type would be an enormous improvement) could remove the need for such trickery... -- Matthew -- 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/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] CMP0043 warnings everywhere
I'm getting tons of CMP0043 warnings on my existing project. I have cmake_policy(VERSION 2.6) set in my project. Why am I being pestered by warnings? Shouldn't I get a policy value appropriate for 2.6 (so CMP0043 should be set to OLD)? CMake Warning (dev) in src/CMakeLists.txt: Policy CMP0043 is not set: Ignore COMPILE_DEFINITIONS_Config properties. Run cmake --help-policy CMP0043 for policy details. Use the cmake_policy command to set the policy and suppress this warning. This warning is for project developers. Use -Wno-dev to suppress it. I'm using 3.0.0-rc4 I grabbed off the file site on windows 7 + VS 2012. Thanks, James -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMP0043 warnings everywhere
On 04/23/2014 12:57 PM, James Bigler wrote: I'm getting tons of CMP0043 warnings on my existing project. I have cmake_policy(VERSION 2.6) set in my project. Why am I being pestered by warnings? Shouldn't I get a policy value appropriate for 2.6 (so CMP0043 should be set to OLD)? Setting policies by VERSION leaves policies newer than that version unset, not set to OLD. If it were to set them to OLD then no new policies would ever warn. There is intentionally no way to turn off warnings about policies newer than those known to the project code, except by using -Wno-dev locally. Otherwise developers would never see the warnings and know to update their code. CMake Warning (dev) in src/CMakeLists.txt: Policy CMP0043 is not set: Ignore COMPILE_DEFINITIONS_Config properties. Run cmake --help-policy CMP0043 for policy details. Use the cmake_policy command to set the policy and suppress this warning. This warning is for project developers. Use -Wno-dev to suppress it. The non-config COMPILE_DEFINITIONS property has supported generator expressions since CMake 2.8.10. They can be used to get per-config values without using the per-config properties. -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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --find-package
On 4/23/2014 12:22 PM, Alan W. Irwin wrote: However, if you discover the problem is a general one for --find-package and Qt5, then it appears that Qt5 might be a good illustrative example to use for your renewed effort at developing a reliable --find-package capability. I recently ran into a project using --find-package and found a limitation that could be very problematic. If a find module in CMake uses a try-compile, or tries to figure out anything to do with the compiler, this command will fail.I am not sure there is a good way around this. Certainly try-compile is not actively discouraged in the CMake Modules, so this can be added to any module at any time, breaking --find-package in the future. -Bill -- 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/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014895]: cmake fails on Windows 8.1 SDK
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14895 == Reported By:Eric Malafeew Assigned To: == Project:CMake Issue ID: 14895 Category: CMake Reproducibility:always Severity: crash Priority: normal Status: new == Date Submitted: 2014-04-23 15:20 EDT Last Modified: 2014-04-23 15:20 EDT == Summary:cmake fails on Windows 8.1 SDK Description: I have found that cmake fails to run if only the Windows 8.1 SDK is installed, but not Windows 8.0 SDK. Steps to Reproduce: Clean full install of Visual Studio 12 Followed by install of Update 4 ...cmake fails to identify VS 2012... Manual install of Windows SDK 8.0 ...cmake identifies VS 2012... Additional Information: Failure to install web deploy component of Visual Studio 2012 full install may have led to incomplete 8.0 SDK installation. Msbuild, used by cmake, seems to be failing on undefined environment variables. == Issue History Date ModifiedUsername FieldChange == 2014-04-23 15:20 Eric Malafeew 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --find-package
On 2014-04-23 13:21-0400 Bill Hoffman wrote: On 4/23/2014 12:22 PM, Alan W. Irwin wrote: However, if you discover the problem is a general one for --find-package and Qt5, then it appears that Qt5 might be a good illustrative example to use for your renewed effort at developing a reliable --find-package capability. I recently ran into a project using --find-package and found a limitation that could be very problematic. If a find module in CMake uses a try-compile, or tries to figure out anything to do with the compiler, this command will fail.I am not sure there is a good way around this. Certainly try-compile is not actively discouraged in the CMake Modules, so this can be added to any module at any time, breaking --find-package in the future. Hi Bill: You cannot use --find-package unless you specify the language. So I assume that --find-package enables the specified language, and, in general, you would think that try-compile would work properly under those circumstances. Is perhaps the problem that two languages were needed (e.g., C Fortran) for the package libraries where you encountered the problem but --find-package only currently allows one language? If so, that should be an extremely easy bug to fix. Another possibility to explain your bad results for one project is that --find-package might be implemented in a way that needs compiler information propagated from one CMake environment to another. For example, to work around bug 9220 so that PLplot won't error out if some compiler is missing or broken from one of its many different supported languages, I implemented a small test project that was then configured with cmake using execute_process to check that a given language was working. (This idea for the workaround was suggested by Dave Cole a long time ago.) However, I keep making a plea for a proper fix to bug 9220 because propagating compiler information (held potentially in a large number of different environment variables and CMake variables for many different computer languages) from the principal CMake project to the test project is somewhat problematic. Therefore, I am wondering if that propagation difficulty is the fundamental issue in the current --find-package implementation as well? Note, it turns out that --find-package appears to be working OK for Qt5 without any try-compile issues. So if Qt5 configuration does use try-compile, it is done in a way that works. Instead, the problem I discovered with GL was due to an incorrect GL name in a find_library search being done with the CMake support files distributed with Qt5. So the fix is a simple patch to those support files to use the correct name of the GL-related library. For further details see my recent cmake mailing list post. 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 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --find-package (was: Roadmap to CMake 3.0)
On Wednesday, April 23, 2014 09:22:09 Alan W. Irwin wrote: On 2013-10-19 20:16+0200 Alexander Neundorf wrote: On Thursday 17 October 2013, Stephen Kelly wrote: Brad King wrote: On 10/17/2013 04:58 PM, Alexander Neundorf wrote: Yes, that was the idea, but I can't rely anymore on a Foo_LIBRARIES variable (or a slight variation) being set after a successful find_package(Foo): http://lists.kde.org/?l=kde-core-develm=138198795723680w=2 I.e. in the future there will be Find-modules which typically export one of (Foo|FOO)_(LIBRARIES|LIBRARY), some Config.cmake files which do that too, and a big number, probably majority, of Config.cmake files, which do not export such variables. The only chance I see would be to simply collect all library targets and return what they provide, but this doesn't feel good. I would have much prefered using a clear interface like the Foo_LIBRARIES variable. Perhaps we need to establish a convention for find modules and package configuration files to interact with --find-package mode. I have no thoughts on the specifics of how that would work though. A new, similar --find-target mode or similar may be more appropriate: cmake --find-target --package Qt5Widgets --target Qt5::Widgets ... # KF5Config exports 3 independent targets: cmake --find-target --package KF5Config --target KF5::ConfigCore ... cmake --find-target --package KF5Config --target KF5::ConfigGui ... cmake --find-target --package KF5Config --target KF5::ConfigWidgets ... Yes, that will work. And a new command/option is not even necessary. The name of the target could be given as additional option. If none is given, it will use the variables as it does now, if a target is given, it will use this target and its properties. I'll work on that when I find the time (and nobody is faster). How is that going, Alex? I have more or less given up on this. Due to all the changes in cmake recently (not recommending setting variables anymore in find_package(), and all the target property stuff), this would require quite some work, and I seriously don't have that much time for cmake currently. Also, one of the big benefits, not having to read documentation for every package anymore, but having a standard interface, is lost, AFAICS. So, if somebody wants to pick that up, feel free. Sorry Alex -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --find-package
On Wednesday, April 23, 2014 13:21:39 Alan W. Irwin wrote: On 2014-04-23 13:21-0400 Bill Hoffman wrote: On 4/23/2014 12:22 PM, Alan W. Irwin wrote: However, if you discover the problem is a general one for --find-package and Qt5, then it appears that Qt5 might be a good illustrative example to use for your renewed effort at developing a reliable --find-package capability. I recently ran into a project using --find-package and found a limitation that could be very problematic. If a find module in CMake uses a try-compile, or tries to figure out anything to do with the compiler, this command will fail.I am not sure there is a good way around this. Certainly try-compile is not actively discouraged in the CMake Modules, so this can be added to any module at any time, breaking --find-package in the future. Hi Bill: You cannot use --find-package unless you specify the language. So I assume that --find-package enables the specified language, and, in general, you would think that try-compile would work properly under those circumstances. No. It doesn't really enable a language, it only loads a bunch of files to set the most urgently required variables. Most of it is implemented in CMakeFindPackageMode.cmake It is basically wrapping a find_package() call, setting up just enough to make it succeed usually. try_compile() will fail. My plan was to limit this mode to Config.cmake files only, but as I said, due to the changes in CMake this has become too much work, so I won't work on that in the forseeable future. Alex -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --find-package
On 2014-04-23 16:21, Alan W. Irwin wrote: [...] I keep making a plea for a proper fix to bug 9220 because propagating compiler information (held potentially in a large number of different environment variables and CMake variables for many different computer languages) from the principal CMake project to the test project is somewhat problematic. This sounds like it would be relevant to external projects, also. Does this include propagating compile/link flags? A better and more canned solution to the problem of propagating tools and flags in general (e.g. from a superbuild project to its external_project 'children') would be most welcome... (That said... bonus points for allowing at least compile/link flags to be overridden per sub-project; I have at least one instance where I need this ability, in order to specify strict warning flags generally that need to be disabled for a specific sub-project.) -- Matthew -- 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --find-package
On 2014-04-23 17:19-0400 Matthew Woehlke wrote:
On 2014-04-23 16:21, Alan W. Irwin wrote:
[...] I keep making a plea for a proper fix to bug 9220 because
propagating compiler information (held potentially in a large number
of different environment variables and CMake variables for many
different computer languages) from the principal CMake project to the
test project is somewhat problematic.
This sounds like it would be relevant to external projects, also. Does this
include propagating compile/link flags?
A better and more canned solution to the problem of propagating tools and
flags in general (e.g. from a superbuild project to its external_project
'children') would be most welcome...
(That said... bonus points for allowing at least compile/link flags to be
overridden per sub-project; I have at least one instance where I need this
ability, in order to specify strict warning flags generally that need to be
disabled for a specific sub-project.)
I agree with what you have said. Of course, a caveat on your first
comment is that if the external projects are built consistently with
ExternalProject_Add and if you have Unix tools or MSYS installed
(including env), then you can use something like
CONFIGURE_COMMAND ${ENV_EXECUTABLE} PATH=${EPA_PATH} CFLAGS=${CFLAGS}
CXXFLAGS=${CXXFLAGS}
${source_PATH}/${EPA_CONFIGURE_COMMAND} @config_arguments@
for, e.g., autotools-based builds to propagate C and C++ flags in a
consistent way. (This example is taken from my autotools template
file for the epa_build subproject of PLplot.) So for that project I
request epa_build users only specify compile flags via the environment
variables so I can propagate those environment variables to many
different builds as above. And I do something similar to allow my bug
9220 workaround work as well.
Of course, this approach is problematic because users ignore your
suggestion to limit how they specify compile flags. So it would be
much better (as you have said) if there was a canned solution to help
propagate whatever method they have used to specify the compile flags
to one consistent method (e.g., by transforming every lang-related
method into the the equivalent langFLAGS CMake variable).
Has anyone here implemented such a canned solution? If so, I would
certainly love to test it not only for PLplot's epa_build subproject
but also for the bug 9220 workaround I use for PLplot.
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
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/cgi-bin/mailman/listinfo/cmake-developers
[CMake] --find-package option fails with some of the Qt5 components
Hi Steve: PLplot not only CMake exports its libraries but also provides library information in pkg-config form for our users that prefer that form. Therefore, for this component of our install I need to collect explicit compile and link flags for Qt5, and it appears to me the best way to do that is to run cmake with the --find-package option. However, some Qt5 components work and others do not. For example: wine@raven cmake --find-package -DNAME:STRING=Qt5Core \ -DCOMPILER_ID:STRING=GNU -DLANGUAGE:STRING=CXX -DMODE:STRING=COMPILE -I/home/wine/newstart/build_script/install-linux/include/ -I/home/wine/newstart/build_script/install-linux/include/QtCore -I/home/wine/newstart/build_script/install-linux//mkspecs/linux-g++ but wine@raven cmake --find-package -DNAME:STRING=Qt5Svg \ -DCOMPILER_ID:STRING=GNU -DLANGUAGE:STRING=CXX -DMODE:STRING=COMPILE CMake Error at /home/wine/newstart/build_script/install-linux/lib/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake:16 (message): Failed to find GL in with CMAKE_CXX_LIBRARY_ARCHITECTURE . Call Stack (most recent call first): /home/wine/newstart/build_script/install-linux/lib/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake:50 (_qt5gui_find_extra_libs) /home/wine/newstart/build_script/install-linux/lib/cmake/Qt5Gui/Qt5GuiConfig.cmake:141 (include) /home/wine/newstart/build_script/install-linux/lib/cmake/Qt5Widgets/Qt5WidgetsConfig.cmake:86 (find_package) /home/wine/newstart/build_script/install-linux/lib/cmake/Qt5Svg/Qt5SvgConfig.cmake:86 (find_package) /home/wine/newstart/build_script/install-linux_buildtools/share/cmake-2.8/Modules/CMakeFindPackageMode.cmake:169 (find_package) Qt5Svg not found. CMake Error: Problem processing arguments. Aborting. This GL-related issue is for a version of Qt5-5.2.1 that I configured, built, and installed myself. Everything PLplot related (including use of the Qt5Svg component) works fine with this version other than the above test. Is there something special I have to do with the configuration of that build to include GL? If so, here is the relevant configuration information for that Qt5 build: Build options: Configuration .. accessibility alsa audio-backend avx avx2 c++11 clock-gettime clock-monotonic compile_examples concurrent evdev e ventfd fontconfig full-config getaddrinfo getifaddrs inotify ipv6ifname large-config largefile linuxfb medium-config minimal-config mremap n o-gif no-harfbuzz opengl pcre png posix_fallocate precompile_header qpa qpa reduce_exports reduce_relocations release rpath shared small-con fig sse2 sse3 sse4_1 sse4_2 ssse3 system-freetype xcb xcb-qt xcb-sm xkbcommon-qt xlib xrender zlib Build parts libs Mode ... release Using C++11 yes Using PCH .. yes Target compiler supports: SSE2/SSE3/SSSE3 .. yes/yes/yes SSE4.1/SSE4.2 yes/yes AVX/AVX2 . yes/yes Qt modules and options: Qt D-Bus ... no Qt Concurrent .. yes Qt GUI . yes Qt Widgets . yes JavaScriptCore JIT . no QML debugging .. no Use system proxies . no Support enabled for: Accessibility .. yes ALSA ... yes CUPS ... no FontConfig . yes FreeType ... system Iconv .. no ICU no Image formats: GIF .. no JPEG . yes (plugin, using bundled copy) PNG .. yes (in QtGui, using bundled copy) Glib ... no GTK theme .. no Large File . yes mtdev .. no Networking: getaddrinfo .. yes getifaddrs ... yes IPv6 ifname .. yes OpenSSL .. no NIS no OpenGL . desktop OpenVG . no PCRE ... yes (bundled copy) pkg-config . yes PulseAudio . no QPA backends: DirectFB . no EGLFS no KMS .. no LinuxFB .. yes XCB .. yes (bundled copy) MIT-SHM yes Xcb-Xlib ... no Xcursor yes (loaded at runtime) Xfixes . yes (loaded at runtime) Xi . yes (loaded at runtime) Xi2 no Xinerama ... yes (loaded at runtime) Xrandr . yes (loaded at runtime) Xrender yes XKB yes XShape . yes XSync .. yes XVideo . yes Session management . yes SQL drivers: DB2 .. no InterBase no MySQL no OCI .. no ODBC . no PostgreSQL ... no SQLite 2 . no SQLite ...
Re: [CMake] --find-package option fails with some of the Qt5 components
P.S. The results I posted were for cmake-2.8.12.2. 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 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CDash questions
The way I’m doing this now is the following: a) I edit the CMakeList.txt file(s) and follow the procedure to create an Xcode IDE project. This project contains a bunch of targets including ALL_BUILD, RUN_TESTS, and Experimental - among others You should not have to edit the CMakeLists file to create an Xcode IDE project... The CMakeLists file should be written so that it may be used with any CMake generator, and then, to create an Xcode project, you would simply run: cd /path/to/build cmake -G Xcode /path/to/source a) I expect to see a list of all the test runs - or at least the the last run from each site. ... What do I have to do to get a list of all test runs from all sites for all dates. By default, the main CDash page shows only results that have been submitted since the most recently past nightly start time. To show other days, you click on previous and next. To show multiple days, you have to use a filtered view with a Build Time field. Click on Show Filters Use a filter of Build Time is before now Click Apply Click Create Hyperlink to create a link to this filtered view (Yields something like this: http://my.cdash.org/index.php?project=Safe+Numericsfiltercount=1showfilters=1field1=buildstarttime/datecompare1=84value1=now ) You won't want to see *everything* after you have more than a few hundred submissions to your project's CDash page... it will be too slow to retrieve and render all the results unless you use a limit. Use Build Time is after 2 weeks ago to see everything from the last two weeks. b) The whole setup is quite confusing. I would like to think that if if users of this library include the CTestConfig.cmake file that I give them ... They will be able to submit their test results in the same way I just did. Am I correct in my understanding of this? Yes, that's correct. They don't have to include anything -- you can just have the CTestConfig file next to the CMakeLists file, and include(CTest) in your CMakeLists file. Also I have some other questions which are not really related to my specific problem but rather to what the purpose of CDash actually is. a) Is it a system for gathering and recording the results of test runs made from different client configurations b) or is it a system for running tests on the actual server hardware c) or is it a system for automatically downloading projects to a client machine and running the tests and posting the results. Alas, it is only a) -- none of your code is run on the CDash server. CDash simply stores, organizes and presents the results you send it from a machine that does the building and testing. You can set up a CDash@home client machine... a machine that connects to the cdash server and requests a job. But then you also have to run something that schedules builds for these client machines, or ping the server through a CDash api call to instruct it to farm out a job to a waiting client. It seems that it’s all three - but this is not at all clear from the documentation. Do you mean the wiki pages? Or something on cdash.org? I sort of conclude this from the information that the myCDash server requests regarding how to run the tests, where is the code repository, etc. The code repository info is so CDash can show links to changes (on the viewUpdates and viewChanges pages) if there's a web viewer for the repo. It's also used when constructing scripts to send to the CDash@home clients. a) I have a programming library for Safe integegers see http://rrsd.com/blincubator.com/bi_library/safe-numerics/ b) I want users to be able to download the library, run the tests, check the results, if they want, submit them to the my.cdash server c) I want all other users to see these results so we can get an idea of the variety of platforms the tests have been run and where they might have failed. Am I doing this right? Am I missing anything? Seems reasoanble to me. You're on the right track... Let us know if you have further questions. HTH, David C. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] --find-package option fails with some of the Qt5 components
Alan W. Irwin wrote: Hi Steve: PLplot not only CMake exports its libraries but also provides library information in pkg-config form for our users that prefer that form. Therefore, for this component of our install I need to collect explicit compile and link flags for Qt5, and it appears to me the best way to do that is to run cmake with the --find-package option. The cmake --find-package feature is Alex Neundorf's department. I don't really know anything about it. Thanks, Steve. -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] good way to append link flags?
I am using set_property(TARGET mytarget APPEND PROPERTY LINK_FLAGS ...) multiple times to add various link flags. But when I inspect the actual link command, I see all my flags separated by semi-colons and no spaces between them, which is not what I want. Is this correct behavior for cmake? Clint -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] good way to append link flags?
On Wednesday, April 23, 2014 06:25:24 PM Nils Gladitz wrote: On 23.04.2014 18:16, Clinton Stimpson wrote: I am using set_property(TARGET mytarget APPEND PROPERTY LINK_FLAGS ...) multiple times to add various link flags. But when I inspect the actual link command, I see all my flags separated by semi-colons and no spaces between them, which is not what I want. Is this correct behavior for cmake? Clint Try APPEND_STRING (with explicit space) instead of APPEND. Some flag variables/properties are interpreted as strings rather than lists. Nils Oh! Thanks, it works. Clint -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] good way to append link flags?
On 23.04.2014 18:16, Clinton Stimpson wrote: I am using set_property(TARGET mytarget APPEND PROPERTY LINK_FLAGS ...) multiple times to add various link flags. But when I inspect the actual link command, I see all my flags separated by semi-colons and no spaces between them, which is not what I want. Is this correct behavior for cmake? Clint Try APPEND_STRING (with explicit space) instead of APPEND. Some flag variables/properties are interpreted as strings rather than lists. Nils -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Explanation....
On 2014-04-16 06:03, Rolf Eike Beer wrote:
Am 16.04.2014 11:39, schrieb Johannes Zarl:
Instead of ``${var} STREQUAL VALUE'', write:
IF ( var MATCHES ^VALUE$ )
NO, please don't! I try hard to kill all those as it requires
compiling a regular expression for a simple string match. Just change it
to something that is no valid variable name, i.e. will never get expanded:
if ( ${arg} STREQUAL TOTO)
set( TOTO evil)
Admittedly it's much less likely that variable names containing
non-identifier characters¹ will occur by accident, the only truly safe
way to avoid unintended implicit expansion is to either rely on implicit
expansion (i.e. always assign your operands to variables and give the
variable names as the literal arguments), or use some other command that
doesn't perform expansion.
(¹ except for '-', which will often occur in automatically created
variable names when used in project names, e.g. my-project_SOURCE_DIR.)
See also
http://permalink.gmane.org/gmane.comp.programming.tools.cmake.devel/9936.
--
Matthew
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] --find-package option fails with some of the Qt5 components
On 2014-04-23 14:30+0200 Stephen Kelly wrote: Alan W. Irwin wrote: Hi Steve: PLplot not only CMake exports its libraries but also provides library information in pkg-config form for our users that prefer that form. Therefore, for this component of our install I need to collect explicit compile and link flags for Qt5, and it appears to me the best way to do that is to run cmake with the --find-package option. The cmake --find-package feature is Alex Neundorf's department. I don't really know anything about it. I have just discovered a simple fix for the problem ___ --- Qt5GuiConfigExtras.cmake_orig 2014-04-23 10:03:52.240610724 -0700 +++ Qt5GuiConfigExtras.cmake2014-04-23 10:08:11.187945950 -0700 @@ -47,7 +47,7 @@ -_qt5gui_find_extra_libs(OPENGL GL ) +_qt5gui_find_extra_libs(OPENGL Qt5OpenGL ) ___ After that change to the installed version of Qt5-5.2.1 then I get the following good find-package result with either CMake-2.8.12.2 or CMake-3.0.0-rc3: wine@raven ~software/cmake/install-3.0.0-rc3/bin/cmake --find-package \ -DNAME:STRING='Qt5Svg' -DCOMPILER_ID:STRING=GNU -DLANGUAGE:STRING=CXX \ -DMODE:STRING=COMPILE -I/home/wine/newstart/build_script/install-linux/include/ -I/home/wine/newstart/build_script/install-linux/include/QtSvg -I/home/wine/newstart/build_script/install-linux/include/QtWidgets -I/home/wine/newstart/build_script/install-linux/include/QtGui -I/home/wine/newstart/build_script/install-linux/include/QtCore -I/home/wine/newstart/build_script/install-linux//mkspecs/linux-g++ and similarly for Qt5Gui and Qt5PrintSupport and also for the LINK and EXIST modes. Steve, I get the impression you have participated in the development of at least the CMake aspects of Qt5. The above Qt5 patch responds to the fundamental issue that CMake cannot find a library named libGL by substituting a search for libQt5OpenGL instead which exists in my present Qt5 installation. However, I am not sure that is the correct fix so I would appreciate your review of the above patch and making sure the correct fix gets into Qt5. 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 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://www.cmake.org/mailman/listinfo/cmake
[CMake] target_include_directories and relative paths inside generator expressions.
Running CMake 3.0-rc3 and the docs for target_include_directories say the
paths may be absolute or relative. Indeed the following works as desired:
target_include_directories( MyTarget PRIVATE some/dir )
The docs also mention that generator expressions can be used. However the
following produces an error:
target_include_directories( MyTarget PRIVATE
$$PLATFORM_ID:Linux:some/dir )
CMake Error in CMakeLists.txt:
Found relative path while evaluating include directories of
foo:
some/dir
It seems absolute paths are necessary. eg:
target_include_directories( MyTarget PRIVATE
$$PLATFORM_ID:Linux:${CMAKE_CURRENT_SOURCE_DIR}/some/dir )
will perform as expected.
Is this behaviour expected (and should be documented) or should I file a
bug?
Thanks,
-Andrew
--
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://www.cmake.org/mailman/listinfo/cmake
[CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
I'm using cmake version 2.8.12.1 and have just encountered an issue with my
cmake setup where I was using the [Project name]_SOURCE_DIR variable in an
include_directories command and it was being ignored. In my top level
CMakeLists.txt I had:
project(blah)
add_subdirectory(foo)
add_subdirectory(...)
...
add_subdirectory(bar)
and in the CMakeLists.txt in the foo directory:
include_directories(${bar_SOURCE_DIR})
The project failed to build because the foo project couldn't find header
files located in the bar project source directory. The fix was to move the
add_subdirectory(bar) before the add_subdirectory(foo) command. The
interesting thing is that this setup only caused an error when doing a
clean build from scratch. It looks like it only fails after a clean start
and a single run of the cmake generator. If you run cmake-gui and
configure more than once, as you may well do if you need to set some
options, then it appears to get the correct value for ${bar_SOURCE_DIR}.
Are the [Project name]_SOURCE_DIR variables being automatically stored in
the cmake cache, as that would explain what I am seeing ? I would expect
the above scenario to consistently fail every time due to the missing
header files. Having it only fail the first time and then work after
subsequent configure/generate steps is confusing. Is this a bug, or are
there occasions when this is desirable behaviour ?
--
Glenn
P.S. In an ideal world I'd like to see the expansion of the [Project
name]_SOURCE_DIR variables be deferred until after all the CMakeLists.txt
files have been read in so that the order doesn't matter, but I'm guessing
that isn't going to happen :-)
--
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://www.cmake.org/mailman/listinfo/cmake
[CMake] OSX Bundles and wrapper scripts
If I want to create an OSX bundle, but I want the main executable to be a configured wrapper script written in bash, what is the best way to go about doing that? It seems that the Also, how do I get the wrapper script to correctly call the compiled executable so that the app bundle is relocatable? Put another way, when the app bundle is packaged or installed, how do I fixup the script so that it will call an executable residing in the local app bundle? Thanks, Izaak Beekman === (301)244-9367 Princeton University Doctoral Candidate Mechanical and Aerospace Engineering ibeek...@princeton.edu UMD-CP Visiting Graduate Student Aerospace Engineering ibeek...@umiacs.umd.edu ibeek...@umd.edu -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] CMAKE_OSX_SYSROOT being ignored with frameworks in /Library/Frameworks
I have CMAKE_OSX_SYSROOT defined as something: set(CMAKE_OSX_SYSROOT /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk CACHE LIST OSX sysroot SDK directory FORCE) Then later I do a find_library command and it finds a library framework in /Library/Frameworks/mylib.framework The cache entry for mylib has the full path to the library, but later during linking it removes the full path and instead uses the name directly: -framework mylib Unfortunately, because the -isysroot command is invoked the linker no longer looks in the standard locations. I have to use -F /Library/Frameworks -framework mylib. I can't even use -framework /Library/Frameworks/mylib.framework Is there something I can do to make it work right? Thanks, James -- 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://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v3.0.0-rc4-2528-gab3cf9d
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via ab3cf9d3f175c83caaa7802635d58efe275899d8 (commit) via 35462070aad71d474cc99ff40c360fb5a447e161 (commit) from 6f8a70baec31a6ab9569c41a7ff992d6014cc2ef (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ab3cf9d3f175c83caaa7802635d58efe275899d8 commit ab3cf9d3f175c83caaa7802635d58efe275899d8 Merge: 6f8a70b 3546207 Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed Apr 23 08:17:48 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Apr 23 08:17:48 2014 -0400 Merge topic 'WriteCompilerDetectionHeader-module' into next 35462070 Fix tests. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=35462070aad71d474cc99ff40c360fb5a447e161 commit 35462070aad71d474cc99ff40c360fb5a447e161 Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed Apr 23 14:17:32 2014 +0200 Commit: Stephen Kelly steve...@gmail.com CommitDate: Wed Apr 23 14:17:32 2014 +0200 Fix tests. diff --git a/Tests/RunCMake/WriteCompilerDetectionHeader/ExtraArgs-stderr.txt b/Tests/RunCMake/WriteCompilerDetectionHeader/ExtraArgs-stderr.txt index 917cf15..62c4ff1 100644 --- a/Tests/RunCMake/WriteCompilerDetectionHeader/ExtraArgs-stderr.txt +++ b/Tests/RunCMake/WriteCompilerDetectionHeader/ExtraArgs-stderr.txt @@ -1,4 +1,4 @@ -CMake Error at .*Modules/WriteCompilerDetectionHeader.cmake:184 \(message\): +CMake Error at .*Modules/WriteCompilerDetectionHeader.cmake:[0-9]+ \(message\): Unparsed arguments: GarbageArg Call Stack \(most recent call first\): ExtraArgs.cmake:4 \(write_compiler_detection_header\) diff --git a/Tests/RunCMake/WriteCompilerDetectionHeader/FileTypo-stderr.txt b/Tests/RunCMake/WriteCompilerDetectionHeader/FileTypo-stderr.txt index 3d13a25..eb94426 100644 --- a/Tests/RunCMake/WriteCompilerDetectionHeader/FileTypo-stderr.txt +++ b/Tests/RunCMake/WriteCompilerDetectionHeader/FileTypo-stderr.txt @@ -1,4 +1,4 @@ -CMake Error at .*Modules/WriteCompilerDetectionHeader.cmake:166 \(message\): +CMake Error at .*Modules/WriteCompilerDetectionHeader.cmake:164 \(message\): write_compiler_detection_header: FILE parameter missing. Call Stack \(most recent call first\): FileTypo.cmake:4 \(write_compiler_detection_header\) diff --git a/Tests/RunCMake/WriteCompilerDetectionHeader/NoCompiler-stderr.txt b/Tests/RunCMake/WriteCompilerDetectionHeader/NoCompiler-stderr.txt index 61d1423..9451348 100644 --- a/Tests/RunCMake/WriteCompilerDetectionHeader/NoCompiler-stderr.txt +++ b/Tests/RunCMake/WriteCompilerDetectionHeader/NoCompiler-stderr.txt @@ -1,4 +1,4 @@ -CMake Error at .*Modules/WriteCompilerDetectionHeader.cmake:177 \(message\): +CMake Error at .*Modules/WriteCompilerDetectionHeader.cmake:[0-9]+ \(message\): Invalid arguments. write_compiler_detection_header requires at least one compiler. Call Stack \(most recent call first\): diff --git a/Tests/RunCMake/WriteCompilerDetectionHeader/NoFeature-stderr.txt b/Tests/RunCMake/WriteCompilerDetectionHeader/NoFeature-stderr.txt index a28cf6c..193f297 100644 --- a/Tests/RunCMake/WriteCompilerDetectionHeader/NoFeature-stderr.txt +++ b/Tests/RunCMake/WriteCompilerDetectionHeader/NoFeature-stderr.txt @@ -1,4 +1,4 @@ -CMake Error at .*Modules/WriteCompilerDetectionHeader.cmake:180 \(message\): +CMake Error at .*Modules/WriteCompilerDetectionHeader.cmake:[0-9]+ \(message\): Invalid arguments. write_compiler_detection_header requires at least one feature. Call Stack \(most recent call first\): diff --git a/Tests/RunCMake/WriteCompilerDetectionHeader/OldVersion-stderr.txt b/Tests/RunCMake/WriteCompilerDetectionHeader/OldVersion-stderr.txt index 6b34845..842eb3f 100644 --- a/Tests/RunCMake/WriteCompilerDetectionHeader/OldVersion-stderr.txt +++ b/Tests/RunCMake/WriteCompilerDetectionHeader/OldVersion-stderr.txt @@ -1,4 +1,4 @@ -CMake Error at /home/stephen/dev/src/cmake/Modules/WriteCompilerDetectionHeader.cmake:191 \(message\): +CMake Error at .*Modules/WriteCompilerDetectionHeader.cmake:[0-9]+ \(message\): VERSION parameter too low. Call Stack \(most recent call first\): OldVersion.cmake:4 \(write_compiler_detection_header\) diff --git a/Tests/RunCMake/WriteCompilerDetectionHeader/PrefixTypo-stderr.txt b/Tests/RunCMake/WriteCompilerDetectionHeader/PrefixTypo-stderr.txt index 90277cd..5fdcdb8 100644 --- a/Tests/RunCMake/WriteCompilerDetectionHeader/PrefixTypo-stderr.txt +++ b/Tests/RunCMake/WriteCompilerDetectionHeader/PrefixTypo-stderr.txt @@ -1,4 +1,4 @@ -CMake Error at .*Modules/WriteCompilerDetectionHeader.cmake:169 \(message\): +CMake Error at
[Cmake-commits] CMake branch, next, updated. v3.0.0-rc4-2530-g35641d6
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 35641d6cec09d7fbc37b07fe3ff43f8740eceb84 (commit)
via d67c4eb20e073318d5e34fbb1ee5f40d8d89 (commit)
from ab3cf9d3f175c83caaa7802635d58efe275899d8 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=35641d6cec09d7fbc37b07fe3ff43f8740eceb84
commit 35641d6cec09d7fbc37b07fe3ff43f8740eceb84
Merge: ab3cf9d d67c4eb
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Apr 23 08:18:42 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Apr 23 08:18:42 2014 -0400
Merge topic 'WriteCompilerDetectionHeader-module' into next
d67c4eb2 Add the WriteCompilerDetectionHeader module.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d67c4eb20e073318d5e34fbb1ee5f40d8d89
commit d67c4eb20e073318d5e34fbb1ee5f40d8d89
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Oct 21 16:59:40 2013 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Apr 23 14:18:01 2014 +0200
Add the WriteCompilerDetectionHeader module.
Provide a function to write a portable header to detect compiler
features.
diff --git a/Help/manual/cmake-modules.7.rst b/Help/manual/cmake-modules.7.rst
index 2bbe622..ecc9cc4 100644
--- a/Help/manual/cmake-modules.7.rst
+++ b/Help/manual/cmake-modules.7.rst
@@ -232,3 +232,4 @@ All Modules
/module/UsewxWidgets
/module/Use_wxWindows
/module/WriteBasicConfigVersionFile
+ /module/WriteCompilerDetectionHeader
diff --git a/Help/module/WriteCompilerDetectionHeader.rst
b/Help/module/WriteCompilerDetectionHeader.rst
new file mode 100644
index 000..4c81b48
--- /dev/null
+++ b/Help/module/WriteCompilerDetectionHeader.rst
@@ -0,0 +1 @@
+.. cmake-module:: ../../Modules/WriteCompilerDetectionHeader.cmake
diff --git a/Help/release/dev/module-WriteCompilerDetectionHeader.rst
b/Help/release/dev/module-WriteCompilerDetectionHeader.rst
new file mode 100644
index 000..d355d2c
--- /dev/null
+++ b/Help/release/dev/module-WriteCompilerDetectionHeader.rst
@@ -0,0 +1,5 @@
+module-WriteCompilerDetectionHeader
+---
+
+* The WriteCompilerDetectionHeader module was added to allow creation of
+ a portable header file for compiler optional feature detection.
diff --git a/Modules/WriteCompilerDetectionHeader.cmake
b/Modules/WriteCompilerDetectionHeader.cmake
new file mode 100644
index 000..89a1808
--- /dev/null
+++ b/Modules/WriteCompilerDetectionHeader.cmake
@@ -0,0 +1,367 @@
+#.rst:
+# WriteCompilerDetectionHeader
+#
+#
+# This module provides the function write_compiler_detection_header().
+#
+# The ``WRITE_COMPILER_DETECTION_HEADER`` function can be used to generate
+# a file suitable for preprocessor inclusion which contains macros to be
+# used in source code::
+#
+#write_compiler_detection_header(
+# FILE file
+# PREFIX prefix
+# COMPILERS compiler [...]
+# FEATURES feature [...]
+# [VERSION version]
+# [PROLOG prolog]
+# [EPILOG epilog]
+#)
+#
+# The ``write_compiler_detection_header`` function generates the
+# file ``file`` with macros which all have the prefix ``prefix``.
+#
+# ``VERSION`` may be used to specify a generation compatibility with older
+# CMake versions. By default, a file is generated with compatibility with
+# the :variable:`CMAKE_MINIMUM_REQUIRED_VERSION`. Newer CMake versions may
+# generate additional code, and the ``VERSION`` may be used to maintain
+# compatibility in the generated file while allowing the minimum CMake
+# version of the project to be changed indepenendently.
+#
+# ``PROLOG`` may be specified as text content to write at the start of the
+# header. ``EPILOG`` may be specified as text content to write at the end
+# of the header
+#
+# At least one ``compiler`` and one ``feature`` must be listed. Compilers
+# which are known to CMake, but not specified are detected and a preprocessor
+# ``#error`` is generated for them. A preprocessor macro matching
+# ``${PREFIX}_COMPILER_IS_${CompilerId}`` is generated for each compiler
+# known to CMake to contain the value ``0`` or ``1``.
+#
+# Feature Test Macros
+# ===
+#
+# For each compiler, a preprocessor test of the compiler version is generated
+# denoting whether the each feature is enabled. A preprocessor macro
+# matching ``${PREFIX}_COMPILER_${FEATURE_NAME_UPPER}`` is generated to
+# contain the value ``0`` or ``1`` depending on whether the compiler in
+# use supports the feature:
+#
+# ..
[Cmake-commits] CMake branch, next, updated. v3.0.0-rc4-2532-ge58f711
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via e58f7118430e0acc2aae640c10207662e9fbdf26 (commit)
via 55f5ea7b0eae53ba04315397f2874411a94943e5 (commit)
from 35641d6cec09d7fbc37b07fe3ff43f8740eceb84 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e58f7118430e0acc2aae640c10207662e9fbdf26
commit e58f7118430e0acc2aae640c10207662e9fbdf26
Merge: 35641d6 55f5ea7
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Wed Apr 23 16:49:53 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Apr 23 16:49:53 2014 -0400
Merge topic 'FindGTK2-X11' into next
55f5ea7b FindGTK2: search for Fontconfig and X11 before using them
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=55f5ea7b0eae53ba04315397f2874411a94943e5
commit 55f5ea7b0eae53ba04315397f2874411a94943e5
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Wed Apr 23 22:49:38 2014 +0200
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Wed Apr 23 22:49:38 2014 +0200
FindGTK2: search for Fontconfig and X11 before using them
diff --git a/Modules/FindGTK2.cmake b/Modules/FindGTK2.cmake
index 1bdad16..15bcab8 100644
--- a/Modules/FindGTK2.cmake
+++ b/Modules/FindGTK2.cmake
@@ -643,6 +643,10 @@ endif()
foreach(_GTK2_component ${GTK2_FIND_COMPONENTS})
if(_GTK2_component STREQUAL gtk)
+# Left for compatibility with previous versions.
+_GTK2_FIND_INCLUDE_DIR(FONTCONFIG fontconfig/fontconfig.h)
+_GTK2_FIND_INCLUDE_DIR(X11 X11/Xlib.h)
+
_GTK2_FIND_INCLUDE_DIR(GLIB glib.h)
_GTK2_FIND_INCLUDE_DIR(GLIBCONFIG glibconfig.h)
_GTK2_FIND_LIBRARY(GLIB glib false true)
@@ -721,10 +725,6 @@ foreach(_GTK2_component ${GTK2_FIND_COMPONENTS})
_GTK2_ADD_TARGET (GTK GTK2_DEPENDS gdk atk pangoft2 pango gdk_pixbuf
gthread gobject glib
GTK2_OPTIONAL_DEPENDS gio pangocairo cairo)
-# Left for compatibility with previous versions.
-_GTK2_FIND_INCLUDE_DIR(FONTCONFIG fontconfig/fontconfig.h)
-_GTK2_FIND_INCLUDE_DIR(X11 X11/Xlib.h)
-
elseif(_GTK2_component STREQUAL gtkmm)
_GTK2_FIND_INCLUDE_DIR(SIGC++ sigc++/sigc++.h)
---
Summary of changes:
Modules/FindGTK2.cmake |8
1 file changed, 4 insertions(+), 4 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.0.0-rc4-716-g533d10e
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 533d10e48c530fe10bc199fa00596c2c87d24bf8 (commit) from 608532fa2b0b9ac289eeb2052e0a9dfebba4d90f (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=533d10e48c530fe10bc199fa00596c2c87d24bf8 commit 533d10e48c530fe10bc199fa00596c2c87d24bf8 Author: Kitware Robot kwro...@kitware.com AuthorDate: Thu Apr 24 00:01:10 2014 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Thu Apr 24 00:01:10 2014 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index ba34535..69af0a0 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 0) -set(CMake_VERSION_PATCH 20140423) +set(CMake_VERSION_PATCH 20140424) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
