[CMake] check_library_exists, built-in, and -Werror
Hi, When using CFLAGS=-Werror $ check_library_exists(m sqrt HAVE_LIBM) fails to give the correct result. A very similar issue has been reported before for CHECK_FUNCTION_EXISTS http://www.cmake.org/Bug/view.php?id=8246 There the recommendation was to use CHECK_SYMBOL_EXISTS instead. My questions: 1) Is there an replacement for check_library_exists which gives the correct results for built-ins even with -Werror? 2) Should check_library_exists correctly work in this case and should I open a bug for it? Roland -- ORNL/UT Center for Molecular Biophysics cmb.ornl.gov 865-241-1537, ORNL PO BOX 2008 MS6309 -- 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
Re: [CMake] How does :: actually works?
Klaim - Joël Lamotte wrote: I didn't realize at all that the FindPackage way is supposed to be obsolete now. It is not obsolete, but it is not a good approach (since CMake 2.6.0 already) if the upstream uses cmake, because config file packages provide a better experience for downstreams http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html Even for upstreams that do not use cmake, it is preferable to generate config file packages for a good downstream experience for cmake users. That is what Qt qmake and LLVM Makefile buildsystems do. Boost b2 could do it too: http://thread.gmane.org/gmane.comp.lib.boost.devel/259011/focus=259445 I'm quite surprised actually. We prefer not to accept new Find modules into the cmake tree because that puts the maintenance burden on us, and because it is an inferior user experience. Some new Find modules still get in, but they need to have a reason to get in. Ok I'll check PackageConfig.cmake for my new and even current projects if it can help with managing the tons of libraries I work on. Do please let us know how that goes. I will consider providing patches, if I can spend time on this once and not bother later it would help a lot. Documentation here explains how to do that for Find modules: http://www.cmake.org/cmake/help/v3.2/manual/cmake-developer.7.html#a-sample-find-module 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://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Xcode project generation failed
On 17/06/15 16:29, Michael Jackson wrote:
Just to follow up with this issue in case anyone else has issues with Xcode
here is what happened. Thanks to Gregor for taking a look at the generated
project file he was able to identify an issue where there were file paths in
the form of // inside the project file. They specifically showed in the
form of: /* // */. This was enough to throw the Xcode parser and send Xcode
into the spin-of-death. The root cause of the issue is that I had a cmake
variable that held all my source files. In that list was a file path, where
the path was completely created through cmake variables,
set(FOO_FILE ${SomethingLib_path}/${SOME_HEADER_PATH})
but neither of those variables had been defined for this project. (Copy paste
mistake). This resulted in the cmake variable (FOO_FILE from above) being
empty but still included as a source in the add_library() call. Fixing the
cmake variables fixed the Xcode generation issue.
I will create a topic branch with a fixed Xcode generator.
Thanks,
Gregor
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] What is the recommended ways to find libraries
Hi Oto,
On Wed, Jun 17, 2015 at 11:18 AM, Oto Petřík oto.pet...@gmail.com wrote:
Hi,
Let's say my project wants to depend on a library PKG1 (here PKG1 can
be MPFR, MPC, PTHREAD, GMP, BZIP2, you name it). Let's say the library
is installed in $PKG1/include, $PKG1/lib, alternatively, all my
dependencies are installed in $HASHSTACK/include and $HASHSTACK/lib,
or perhaps they are installed system wide.
Perhaps I am missing the official recommendation regarding the above,
so that's why I am asking here. But if there is none, then I think the
current state is unsatisfactory.
you may be looking for CMAKE_PREFIX_PATH
(http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_PREFIX_PATH.html)
cmake
-DCMAKE_PREFIX_PATH=$HOME/built-libs/gmp;$HOME/built-libs/arb;$HOME/built-libs/otherdependencies
(or have a script that sets CMAKE_PREFIX_PATH environment variable)
works with find_module, find_file, find_library,... expects
directories to have standard structure (include,lib,...), see
documentation of find_* commands for details.
it is usually enough to set CMAKE_PREFIX_PATH to DESTDIRs used in
dependencies' make install DESTDIR=/foo
you may want to remove NO_DEFAULT_PATH as used in linked
LibFindMacros.cmake, it disables this functionality.
Yes, indeed CMAKE_PREFIX_PATH is a replacement for our COMMON_DIR,
i.e. the case 3. above. So one can apply the following patch to our
macros:
--- a/cmake/LibFindMacros.cmake
+++ b/cmake/LibFindMacros.cmake
@@ -42,7 +42,6 @@ macro (libfind_library libname pkg)
${libname}
PATHS
${${PKG}_DIR}
-${COMMON_DIR}
PATH_SUFFIXES
lib
lib64
@@ -73,7 +72,6 @@ macro (libfind_include HEADER pkg)
${HEADER}
PATHS
${${PKG}_DIR}
-${COMMON_DIR}
PATH_SUFFIXES
include
NO_DEFAULT_PATH
and just use CMAKE_PREFIX_PATH instead of COMMON_DIR. I tried it in
our code and it works.
However, for 1. and 2. there is no solution in CMake. There is
CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH, but Isuru just tested it
and CMAKE_PREFIX_PATH takes precedence over CMAKE_INCLUDE_PATH, which
means that if you have a stack of packages installed in
CMAKE_PREFIX_PATH, you cannot specify PKG1 using CMAKE_INCLUDE_PATH.
And even if cmake changes the order, then if CMAKE_INCLUDE_PATH
besides PKG1 also contains PKG2, but you want PKG2 from
CMAKE_PREFIX_PATH, it won't work. The true solution is per package
include/lib paths, just like we implemented in our macros.
We tried many things, but we haven't figured out a solution other than
our macros. So it looks like CMake itself should have our macros (or
an equivalent functionality).
Ondrej
--
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
[CMake] Recursively include target include directories only
Is there a way to only take (recursively) the include directories from a target or set of targets? I know that include directories propagate when passing targets to target_link_libraries(), but I do not want to link the libs; I only want the include directories. How can I do this? Thanks. -- 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
Re: [CMake] Recursively include target include directories only
On Wed, Jun 17, 2015 at 4:31 PM, Dan Liew d...@su-root.co.uk wrote:
On 17 June 2015 at 12:28, Robert Dailey rcdailey.li...@gmail.com wrote:
Is there a way to only take (recursively) the include directiories from
a target or set of targets? I know that include directories propagate
when passing targets to target_link_libraries(), but I do not want to
link the libs; I only want the include directories.
How can I do this? Thanks.
I presume recursively you mean propagating the required include
directories between targets rather anything to do recursively handling
directories.
As you mentioned include directories do propagate but this only
happens under certain conditions (when using PUBLIC or INTERFACE
scopes).
I don't know of a way of doing it without target_link_libraries but if
it is necessary for you to do this it sounds like you have bigger
problems relating to the way you have your project header files
organised.
The approach I use for include directories is to have all includes for
the project rooted in a single include directory in the source tree
and have all includes relative to that directory. Then if I you
```
include_directories(${CMAKE_SOURCE_DIR}/include)
include_directories(${CMAKE_BINARY_DIR}/include) # for generated header files
```
in the root of the project you never need to set include paths
anywhere else for sources that are in your project tree. E.g. if there
is header file in
${CMAKE_SOURCE_DIR}/include/project/moduleA/interface.h
then in the sources this is included as
#include project/moduleA/interface.h
(note there are never relative header file includes).
This is the approach that the LLVM project uses which is very simple
and very clean (take a look at the sources). This also works very well
for installing your header files, the contents of ${CMAKE_SOURCE_DIR}
just need to be copied into /usr/include .
Thanks, I will go through this and see if it helps.
The reason I'm asking this question is because of how I handle unit
tests in CMake right now. Instead of just defining an executable
target for the test and then adding a link dependency on the library
containing the class or set of classes to be tested, I am manually
pulling in the CPP and H file into the test target and building them
inline with the test code. This is to support mocking (I can't mock
objects already compiled into a static library). As such, I need the
transitive includes and defines, but I do not want the transitive link
libraries.
If there is a better structure or overall approach I'm happy to
listen! This has been a nightmare so far.
--
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
Re: [CMake] What is the recommended ways to find libraries
2015-06-17 21:00 GMT+02:00 Ondřej Čertík ondrej.cer...@gmail.com: and just use CMAKE_PREFIX_PATH instead of COMMON_DIR. I tried it in our code and it works. the idea is, that there is no need for PKG1_INCLUDE_DIRS, no PKG1_LIBRARIES and no PKG1_DIR just one path per dependency in CMAKE_PREFIX_PATH (or per group of dependencies in common directory) if dependency 'MyDependency' is installed in /opt/mydependency then after adding /opt/mydependency to CMAKE_PREFIX_PATH, following happens: find_library searches in: /opt/mydependency/lib /opt/mydependency and find_path,find_file searches in: /opt/mydependency/include /opt/mydependency (and if CMAKE_LIBRARY_ARCHITECTURE is set, then it is used as additional subdirectory under 'lib' and 'include') it looks like cmake documentation implies that only 'lib' and 'include' subdirectories are searched, and not the actual directory. at least cmake 3.2.1 on windows searches even the directory itself, looks like the behavior is not platform dependent: Source/cmSearchPath.cxx: method cmSearchPath::AddPrefixPaths lines 241-254 (http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmSearchPath.cxx;h=c9cc81737ac9ae65593ddea30f98233844274112;hb=HEAD#l241) when writing cmake/FindMyDependency.cmake, instead of libfind_* macros use plain find_* commands: find_library(MYDEPENDENCY_LIBRARY NAMES mydependency) find_path(MYDEPENDENCY_INCLUDE_DIR NAMES mydependency.h) if the header is in one of the following two locations, the work is done. /opt/mydependency/include/mydependency.h /opt/mydependency/mydependency.h two users installing/building same dependency end up with more or less the same directory structure, if you get path to that directory as part of CMAKE_PREFIX_PATH, you should be able to find headers/libraries. for unusual directory structure or platform/compiler differences use PATH_SUFFIXES. in exceptional cases find headers, then assemble path to libraries based on the header path - use it as a HINTS to find_library (probably called with NO_DEFAULT_PATH) However, for 1. and 2. there is no solution in CMake. There is CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH, but Isuru just tested it and CMAKE_PREFIX_PATH takes precedence over CMAKE_INCLUDE_PATH, which means that if you have a stack of packages installed in CMAKE_PREFIX_PATH, you cannot specify PKG1 using CMAKE_INCLUDE_PATH. And even if cmake changes the order, then if CMAKE_INCLUDE_PATH besides PKG1 also contains PKG2, but you want PKG2 from CMAKE_PREFIX_PATH, it won't work. The true solution is per package include/lib paths, just like we implemented in our macros. when using only CMAKE_PREFIX_PATH, it should be possible to solve this by reordering paths within CMAKE_PREFIX_PATH (PKG1 first, stack of packages last). it should work for cases of new version of PKG1 in separate directory overriding (old) PKG1 in another directory containing e.g. oldPKG1, PKG2, ... it will break for two directories e.g. 'stable' and 'testing', each with both PKG1 and PKG2 - you cannot get stable PKG1 and testing PKG2, but in that case it is a problem to even construct the list of include directories for the compiler. We tried many things, but we haven't figured out a solution other than our macros. So it looks like CMake itself should have our macros (or an equivalent functionality). is there a case where dependencies are in following directories, search them in order behavior of CMAKE_PREFIX_PATH is not enough ? Oto -- 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
Re: [CMake] Recursively include target include directories only
On 17 June 2015 at 12:28, Robert Dailey rcdailey.li...@gmail.com wrote:
Is there a way to only take (recursively) the include directiories from
a target or set of targets? I know that include directories propagate
when passing targets to target_link_libraries(), but I do not want to
link the libs; I only want the include directories.
How can I do this? Thanks.
I presume recursively you mean propagating the required include
directories between targets rather anything to do recursively handling
directories.
As you mentioned include directories do propagate but this only
happens under certain conditions (when using PUBLIC or INTERFACE
scopes).
I don't know of a way of doing it without target_link_libraries but if
it is necessary for you to do this it sounds like you have bigger
problems relating to the way you have your project header files
organised.
The approach I use for include directories is to have all includes for
the project rooted in a single include directory in the source tree
and have all includes relative to that directory. Then if I you
```
include_directories(${CMAKE_SOURCE_DIR}/include)
include_directories(${CMAKE_BINARY_DIR}/include) # for generated header files
```
in the root of the project you never need to set include paths
anywhere else for sources that are in your project tree. E.g. if there
is header file in
${CMAKE_SOURCE_DIR}/include/project/moduleA/interface.h
then in the sources this is included as
#include project/moduleA/interface.h
(note there are never relative header file includes).
This is the approach that the LLVM project uses which is very simple
and very clean (take a look at the sources). This also works very well
for installing your header files, the contents of ${CMAKE_SOURCE_DIR}
just need to be copied into /usr/include .
--
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
Re: [CMake] How does :: actually works?
On 17 June 2015 at 20:50, Stephen Kelly steve...@gmail.com wrote: Klaim - Joël Lamotte wrote: I didn't realize at all that the FindPackage way is supposed to be obsolete now. It is not obsolete, but it is not a good approach (since CMake 2.6.0 already) if the upstream uses cmake, because config file packages provide a better experience for downstreams http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html Even for upstreams that do not use cmake, it is preferable to generate config file packages for a good downstream experience for cmake users. That is what Qt qmake and LLVM Makefile buildsystems do. Boost b2 could do it too: http://thread.gmane.org/gmane.comp.lib.boost.devel/259011/focus=259445 I remember the discussion but did not realize that it was a tool supposed to be useful for any project. Thinking about boost, if package files works well with header-only libraries (which I suppose it should as long as the boost define header-only targets) then it would be very useful indeed. By the way, in one of my project I end up using one FindBoost call with all the components needed by all the libraries of the project. I do this to avoid having to call FindBoost separately for every library with different components (still using the COMPONENTS option listing what the whole project needs). Then I have to have all my libraries to link with all the boost libraries listed in the boost library variable generated by FindBoost. If I understand correctly, if FindBoost was supporting imported targets and using Boost as a namespace (like Qt does), then I could link my libraries to boost libraries in a more precise way as I would link each library separately instead of everything FindBoost put in the boost libraries variable. Is my understanding correct? I'm quite surprised actually. We prefer not to accept new Find modules into the cmake tree because that puts the maintenance burden on us, and because it is an inferior user experience. Some new Find modules still get in, but they need to have a reason to get in. Ok I'll check PackageConfig.cmake for my new and even current projects if it can help with managing the tons of libraries I work on. Do please let us know how that goes. I will. I will consider providing patches, if I can spend time on this once and not bother later it would help a lot. Documentation here explains how to do that for Find modules: http://www.cmake.org/cmake/help/v3.2/manual/cmake-developer.7.html#a-sample-find-module Thanks, Thanks for the pointer. 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://public.kitware.com/mailman/listinfo/cmake
[cmake-developers] CMake instances sharing some modifiable resources
Hi all,
I'm trying to write a custom command that will run a CMake script to add some
content in a file. Problem is, if I'm building with multiple process enabled in
Visual Studio project, and the custom command is added to a few different
CMakeLists.txt files, I get synchronizations issues.
In my a bunch of CMakeLists.txt I have:
add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD COMMAND ${CMAKE_COMMAND}
ARGS -P file_append.cmake)
In file_append.cmake I have:
file(APPEND output.txt some content\n)
When looking at the content of output.txt, we see that some lines are
truncated, half-written or skipped entirely. Is there a way to make the file
command lock the file during the append so that multiple process sharing some
modifiable resource do not run into conflict between each other? I saw the
file(LOCK...) command but it doesn't seems to work for this case?
Thanks!
--
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-commits] CMake branch, master, updated. v3.3.0-rc2-174-gf17e89c
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 f17e89c00406d243370f03c8df28efb8e128bbad (commit) from ee5c40a5f8e7dbbea7b0576c184003a7f86646ba (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=f17e89c00406d243370f03c8df28efb8e128bbad commit f17e89c00406d243370f03c8df28efb8e128bbad Author: Kitware Robot kwro...@kitware.com AuthorDate: Thu Jun 18 00:01:04 2015 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Thu Jun 18 00:01:04 2015 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index c0f56d2..267e49a 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 3) -set(CMake_VERSION_PATCH 20150617) +set(CMake_VERSION_PATCH 20150618) #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/mailman/listinfo/cmake-commits
[cmake-developers] [CMake 0015622]: Add support for 64-bit Visual Studio Toolchains
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15622 == Reported By:Paul TBBle Hampson Assigned To: == Project:CMake Issue ID: 15622 Category: CCMake Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2015-06-17 22:39 EDT Last Modified: 2015-06-17 22:39 EDT == Summary:Add support for 64-bit Visual Studio Toolchains Description: Visual Studio 2013 onwards have added a property to MSBuild PreferredToolArchitecture which can be set to x64 to use the 64-bit compiler toolchain. This toolchain can produce all the same output targets: Win32, x64 and ARM; as the default (32-bit) compiler toolchain can. It'd be great if this was supported somehow in CMake. Now that we have the -A flag for output architecture from the Visual Studio generators, this might be a duplicated set of generators, which only support -A for output architecture support. If there is an appropriate CMAKE property, that'd work too. Ideally, we could flag off CMAKE_SYSTEM_PROCESSOR and CMAKE_HOST_SYSTEM_PROCESSOR to control this sort of cross-compiler behaviour, except that would: (a) introduce a behaviour change for existing projects (hence perhaps a Visual Studio generator-specific policy); and (b) require fixing CMAKE_SYSTEM_PROCESSOR, see issue http://www.cmake.org/Bug/view.php?id=15170 PreferredToolArchitecture is safe to set to x64 on 32-bit platforms, as the VS2013 MSBuild scripts detect when the build is run on a 32-bit host or without the 64-bit toolset installed, and (silently) fall back to the 32-bit toolset. As a workaround, PreferredToolArchitecture can be set as an environment variable, in case anyone finds this feature request and doesn't want to wait for implementation. Additional Information: MSBuild documentation at https://msdn.microsoft.com/en-us/library/dd293607(v=vs.120).aspx shows this flag for VS2013 and VS2015 RC. In VS2010 and VS2012, you could set the property _IsNativeEnvironment to true to use the 64-bit toolchain. This was not formally documented on MSDN, but in various blog posts. Anecdotally, it didn't support cross-compiling 32-bit or ARM targets from the 64-bit toolchain. The _IsNativeEnvironment property is actually an internal property for the MSBuild C++ targets, but you must set it manually in pre-VS2013 because the IDE is always 32-bit and always provides the PROCESSOR_ARCHITECTURE environment variable as x86. The actual intent of the toolchain code was to detect and enable _IsNativeEnvironment when running from a 64-bit environment, as seen in this snippet: _IsNativeEnvironment Condition='$(PROCESSOR_ARCHITECTURE)' == 'AMD64' and '$(Platform)' == 'X64'true/_IsNativeEnvironment _IsNativeEnvironment Condition='$(PROCESSOR_ARCHITECTURE)' == 'IA64' and '$(Platform)' == 'Itanium'true/_IsNativeEnvironment See https://social.msdn.microsoft.com/Forums/en-US/d6b352ea-12b6-4867-b86d-a052fbab1da4/how-can-switch-to-native-x64-compiler-to-compile-x64-program for discussion. This logic is still present in VS2013, but the PreferredToolArchitecture presents the user-selectable interface. VS2013 attempts to honour the _IsNativeEnvironment property and set PreferredToolArchitecture to match, but apparently that doesn't work, see https://connect.microsoft.com/VisualStudio/feedback/details/800059/isnativeenvironment-true-no-longer-works-on-visual-studio-2013-rc A request for this appeared on Stack Overflow at http://stackoverflow.com/questions/23186620/use-native-64bit-toolset-in-visual-studio-2013 and a CMake mailing list request for a workaround at http://www.cmake.org/pipermail/cmake/2014-February/057045.html == Issue History Date ModifiedUsername FieldChange == 2015-06-17 22:39 Paul TBBle HampsonNew 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:
[cmake-developers] [CMake 0015621]: CMAKE_GENERATOR_PLATFORM references toolset instead of platform
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15621 == Reported By:Paul TBBle Hampson Assigned To: == Project:CMake Issue ID: 15621 Category: Documentation Reproducibility:N/A Severity: tweak Priority: low Status: new == Date Submitted: 2015-06-17 21:29 EDT Last Modified: 2015-06-17 21:29 EDT == Summary:CMAKE_GENERATOR_PLATFORM references toolset instead of platform Description: The help for CMAKE_GENERATOR_PLATFORM says: If the user specifies a toolset name (e.g. via the cmake -A option) the value will be available in this variable. which is clearly a cut-and-paste from CMAKE_GENERATOR_TOOLSET: If the user specifies a toolset name (e.g. via the cmake -T option) the value will be available in this variable. It _should_ say: If the user specifies a platform name (e.g. via the cmake -A option) the value will be available in this variable. i.e. replace 'toolset' with 'platform', to match the variable name and the -A command-line parameter help. See http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_GENERATOR_PLATFORM.html#variable:CMAKE_GENERATOR_PLATFORM == Issue History Date ModifiedUsername FieldChange == 2015-06-17 21:29 Paul TBBle HampsonNew 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] What is the recommended ways to find libraries
Hi, Let's say my project wants to depend on a library PKG1 (here PKG1 can be MPFR, MPC, PTHREAD, GMP, BZIP2, you name it). Let's say the library is installed in $PKG1/include, $PKG1/lib, alternatively, all my dependencies are installed in $HASHSTACK/include and $HASHSTACK/lib, or perhaps they are installed system wide. Perhaps I am missing the official recommendation regarding the above, so that's why I am asking here. But if there is none, then I think the current state is unsatisfactory. you may be looking for CMAKE_PREFIX_PATH (http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_PREFIX_PATH.html) cmake -DCMAKE_PREFIX_PATH=$HOME/built-libs/gmp;$HOME/built-libs/arb;$HOME/built-libs/otherdependencies (or have a script that sets CMAKE_PREFIX_PATH environment variable) works with find_module, find_file, find_library,... expects directories to have standard structure (include,lib,...), see documentation of find_* commands for details. it is usually enough to set CMAKE_PREFIX_PATH to DESTDIRs used in dependencies' make install DESTDIR=/foo you may want to remove NO_DEFAULT_PATH as used in linked LibFindMacros.cmake, it disables this functionality. Regards, Oto Petrik -- 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
Re: [CMake] How does :: actually works?
Klaim - Joël Lamotte wrote: Thinking about boost, if package files works well with header-only libraries (which I suppose it should as long as the boost define header-only targets) then it would be very useful indeed. Yes, I wrote some cmake 3.0 features specifically for the Boost use cases (header only and lots of cyclic dependencies). Then I have to have all my libraries to link with all the boost libraries listed in the boost library variable generated by FindBoost. I don't have working knowledge of FindBoost, so I can't give a good answer. The documentation at the top of the file says it creates a variable per library though. If I understand correctly, if FindBoost was supporting imported targets and using Boost as a namespace (like Qt does), then I could link my libraries to boost libraries in a more precise way as I would link each library separately instead of everything FindBoost put in the boost libraries variable. This still has other advantages anyway, such as transitivity, conciseness, consistency, better error messages etc. 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://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How does :: actually works?
On 16 June 2015 at 11:49, Johannes Zarl-Zierl johannes.zarl-zi...@jku.at wrote: On Monday 15 June 2015 22:43:41 you wrote: Just a last question: I assume that most find module scripts distributed with cmake are not using this feature at the moment, right? Sadly, no. After reading your explaination I looked at documentation for FindBoost and FindGTest which are both used in all my projects and they dont seem to provide import targets. Are there plans to update the cmake scripts distributed with CMake On the one hand, FindPackage modules are, as far as I'm aware, slowly being updated to use imported targets. On the other hand, quite a few packages are missing a maintainer[1]. If you are using a package and want it to provide imported targets, I think your best bet is to propose a patch for the module and get it into cmake. That said, its worth mentioning that FindPackage modules are only intended for legacy projects which do not provide a PackageConfig.cmake file. If you are writing a new project, especially if it's based on cmake, you should write a PackageConfig.cmake file instead [2]. I didn't realize at all that the FindPackage way is supposed to be obsolete now. I'm quite surprised actually. Ok I'll check PackageConfig.cmake for my new and even current projects if it can help with managing the tons of libraries I work on. or is it just assumed that projects willing to use importing targets will write them somewhere before using them? Creating imported targets on your own is not the way to go. Better file a bug report or write a patch to add the functionality and get that into cmake. IMO, until the official module provides imported targets, you're better off using the old way. I will consider providing patches, if I can spend time on this once and not bother later it would help a lot. Thanks again for these explainations. Cheers, Johannes [1] http://www.cmake.org/Wiki/CMake:Module_Maintainers#List [2] http://www.cmake.org/Wiki/CMake/Tutorials#CMake_Packages -- 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 -- 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
[CMake] MinGW and sh.exe
Hi! i get an error at cmake configure step on windows with -G MinGW Makefiles, if the OpenSSH bin folder is in the PATH environment cause cmake detects sh.exe and then throws an error. This seems to be intended due to this link http://www.cmake.org/Wiki/CMake_MinGW_Compiler_Issues But if i now configure a second time, everything is fine and the generated MinGW Makefiles are generated properly and could be build normaly with mingw32-make wihtout any msys or sh environment. So is the first cmake error an error? The link ist quite old (2006) Thanks for any help. Joerg -- 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
[cmake-developers] Adding Swift support to CMake
Hello all,
I wanted to see if I could get the ball rolling on (Apple) Swift
support for CMake.
For more detail, here is the bug I’ve been chatting in:
http://public.kitware.com/Bug/view.php?id=15401
Here is the summary:
- For Apple developers, we need Swift support because it is going to
be increasingly common to have Swift files in the project, often as
backends for the Apple platform specific stuff in cross-platform
projects, just as Objective-C is today.
- Coming this fall, Swift is going to be open sourced, starting with a
Linux port. So we may start seeing more use cases on non-Apple
platforms as well.
To meet these objectives, I see two things we need to do:
- For the first and simplest case, we need to enhance the CMake Xcode
generator so it can handle Swift. Xcode already knows how to handle
Swift files automatically, so we should leverage it by making CMake
generate a correct project for it.
- The next step is to look at the Makefile generator and command line
invocation. With luck, this will work for Mac, Linux, and probably any
other Unix-like platform that gets Swift/LLVM running.
As a first stab to get Xcode support working,
in cmGlobalXCodeGenerator.cxx in the function
GetSourcecodeValueFromFileExtension(), I added swift right after the
Obj-C entries.
else if (ext == swift)
{
sourcecode += .swift;
}
This correctly set the source code type in Xcode for Swift files.
However, every Swift file was lacking any target association (blank
checkboxes for all targets). This means no Swift files were getting
compiled.
After some random guessing, I found in CMakeCCompiler.cmake.in, adding
swift to the CMAKE_C_SOURCE_FILE_EXTENSIONS, would cause the Swift
files to be correctly associated with a target.
set(CMAKE_C_SOURCE_FILE_EXTENSIONS c;m;swift)
This works pretty well for my initial test case which is a mixture of
C/Obj-C/Swift. But I was told we should be looking at building a
separate language generator instead of this latter hack.
So this is where I’m starting to get lost/overwhelmed, and am hoping
to find other people that might be able to help make this happen.
At the moment, I created 4 new files:
CMakeDetermineSwiftCompiler.cmake
CMakeSwiftCompiler.cmake.in
CMakeSwiftInformation.cmake
CMakeTestSwiftCompiler.cmake
I originally started with C as the template and got lost quickly. I
have since started using Java as the template and have muddled through
a little bit more. In my current Xcode prototype, I’ve been fighting
various flags, e.g. my C flags getting clobbered by Swift, when in
fact I need both. (e.g. lost my @rpath/@loader_path stuff.)
So, I’m still lacking a lot of knowledge on both the CMake side (how
to implement a new language), and also a lot of the reverse
engineering details of how Swift works. Maybe we can layout the
details in this thread.
These are the various details that I’m aware of at the moment:
- The swift compiler is called swiftc
- Swift doesn’t really have a preprocessor or linker in the traditional C sense.
- However, since Swift is designed to operate with C and Obj-C, there
does seem to be a mechanism to create files that can be linked with
C/Obj-C (needed by the Makefile generator; should be automatic by
Xcode)
- I don’t think Swift needs dependency management like in Makefiles
and swift handles everything for you transparently (ignoring
intermixing with C/Obj-C). However, you still need a build system to
handle other things like asset files (images, icons, etc.)
- Swift projects generally need to provide a “bridging header” to be
able to call C/Obj-C code
- Swift projects need a generated Interface Header so C/Obj-C can call
Swift code
- Swift has its own optimization flag settings separate from C/Obj-C
- Swift seems to have its own ‘other flags’
- I think there is a way to build Swift-only modules, but I have not
looked into this. Intermixing C/Obj-C probably means you can fall back
to the clang mechanisms.
- On OSX/iOS, it would be nice to make Swift automatically enabled
since it is kind of a required language now. (Requiring
ENABLE_LANGAUGE(Swift) seems annoying.)
- I’m kind of assuming, but don’t really know, that Obj-C and the
Obj-C runtime will be available with the Linux port of Swift, and that
you will generally want it and might even be required. (Note: I am
being careful to distinguish between Obj-C and libraries like
Foundation.) Being able to call Swift from C requires Obj-C (in my
limited experience). Swift’s easy interoperability with C (in both
directions) I think is a selling point for Swift and expect it to be
used, particularly on Linux where C is prevalent. So I think we need
to make sure this intermixing can be handled by the Makefile
generator.
- Here is the best resource I've found so far on building a Makefile for Swift:
http://owensd.io/2015/01/15/swift-makefiles-take-2.html
So anybody who wants to chime in, please do so!
Let's see if we can make this happen.
[Cmake-commits] CMake branch, next, updated. v3.3.0-rc2-493-g89eee46
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 89eee4640c4429da70ddf32689d80e47c07213fb (commit) via 833be0ef44fbdecfe7785693396c69b9ebb9bd80 (commit) via 109cb9a679b71f61829745c86b1d1aed153a049c (commit) via 88b6f02a1624d03aad79a7fff41e0c85b69e5f41 (commit) from 76e4fea2e61b35f16982973c8b25d954907c086a (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=89eee4640c4429da70ddf32689d80e47c07213fb commit 89eee4640c4429da70ddf32689d80e47c07213fb Merge: 76e4fea 833be0e Author: Brad King brad.k...@kitware.com AuthorDate: Wed Jun 17 08:58:47 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jun 17 08:58:47 2015 -0400 Merge topic 'GNUInstallDirs-special-prefixes' into next 833be0ef Help: Add notes for topic 'GNUInstallDirs-special-prefixes' 109cb9a6 GNUInstallDirs: Add special cases for certain prefixes 88b6f02a GNUInstallDirs: Add test cases http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=833be0ef44fbdecfe7785693396c69b9ebb9bd80 commit 833be0ef44fbdecfe7785693396c69b9ebb9bd80 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Jun 16 15:41:33 2015 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Jun 16 16:10:26 2015 -0400 Help: Add notes for topic 'GNUInstallDirs-special-prefixes' diff --git a/Help/release/dev/GNUInstallDirs-special-prefixes.rst b/Help/release/dev/GNUInstallDirs-special-prefixes.rst new file mode 100644 index 000..83c1352 --- /dev/null +++ b/Help/release/dev/GNUInstallDirs-special-prefixes.rst @@ -0,0 +1,9 @@ +GNUInstallDirs-special-prefixes +--- + +* The :module:`GNUInstallDirs` module learned special default values + for certain installation prefixes according to the `GNU Coding + Standards`_ and the `Filesystem Hierarchy Standard`_. + +.. _`GNU Coding Standards`: https://www.gnu.org/prep/standards/html_node/Directory-Variables.html +.. _`Filesystem Hierarchy Standard`: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=109cb9a679b71f61829745c86b1d1aed153a049c commit 109cb9a679b71f61829745c86b1d1aed153a049c Author: Alex Turbov i.za...@gmail.com AuthorDate: Tue Jun 16 01:16:57 2015 +0700 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Jun 16 16:10:26 2015 -0400 GNUInstallDirs: Add special cases for certain prefixes Teach the module to handle SYSCONFDIR and LOCALSTATEDIR properly if CMAKE_INSTALL_PREFIX is set to `/` or `/usr` -- i.e. as expected by GNU Coding Standard (i.e. set SYSCONFDIR to `/etc` and `LOCALSTATEDIR` to `/var`). Also if CMAKE_INSTALL_PREFIX is set to /opt/pkg, `SYSCONFDIR` must be set to `/etc/opt/pkg` and `LOCALSTATEDIR` to `/var/opt/pkg` according to FHS. diff --git a/Modules/GNUInstallDirs.cmake b/Modules/GNUInstallDirs.cmake index 82258d1..b42084e 100644 --- a/Modules/GNUInstallDirs.cmake +++ b/Modules/GNUInstallDirs.cmake @@ -9,6 +9,9 @@ # # .. _`GNU Coding Standards`: https://www.gnu.org/prep/standards/html_node/Directory-Variables.html # +# Result Variables +# +# # Inclusion of this module defines the following variables: # # ``CMAKE_INSTALL_dir`` @@ -22,7 +25,8 @@ # The absolute path generated from the corresponding ``CMAKE_INSTALL_dir`` # value. If the value is not already an absolute path, an absolute path # is constructed typically by prepending the value of the -# :variable:`CMAKE_INSTALL_PREFIX` variable. +# :variable:`CMAKE_INSTALL_PREFIX` variable. However, there are some +# `special cases`_ as documented below. # # where ``dir`` is one of: # @@ -60,8 +64,44 @@ # # If the includer does not define a value the above-shown default will be # used and the value will appear in the cache for editing by the user. +# +# Special Cases +# ^ +# +# The following values of :variable:`CMAKE_INSTALL_PREFIX` are special: +# +# ``/`` +# +# For ``dir`` other than the ``SYSCONFDIR`` and ``LOCALSTATEDIR``, +# the value of ``CMAKE_INSTALL_dir`` is prefixed with ``usr/`` if +# it is not user-specified as an absolute path. For example, the +# ``INCLUDEDIR`` value ``include`` becomes ``usr/include``. +# This is required by the `GNU Coding Standards`_, which state: +# +# When building the complete GNU system, the prefix will be empty +# and ``/usr`` will be a symbolic link to ``/``. +# +# ``/usr`` +# +# For ``dir`` equal to ``SYSCONFDIR`` or ``LOCALSTATEDIR``, the +# ``CMAKE_INSTALL_FULL_dir`` is computed by prepending just ``/`` +# to the value
[Cmake-commits] CMake branch, next, updated. v3.3.0-rc2-495-g8a99f6d
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 8a99f6d24c67cdc2ab68c18cbe4da7174f9a8b62 (commit) via f43defaec4e8610e90886a831dcc0a15fdeea1cb (commit) from 89eee4640c4429da70ddf32689d80e47c07213fb (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=8a99f6d24c67cdc2ab68c18cbe4da7174f9a8b62 commit 8a99f6d24c67cdc2ab68c18cbe4da7174f9a8b62 Merge: 89eee46 f43defa Author: Brad King brad.k...@kitware.com AuthorDate: Wed Jun 17 08:59:17 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jun 17 08:59:17 2015 -0400 Merge topic 'linux-GNU-Fortran-no-rdynamic' into next f43defae GNU: Drop -rdynamic flag from Fortran http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f43defaec4e8610e90886a831dcc0a15fdeea1cb commit f43defaec4e8610e90886a831dcc0a15fdeea1cb Author: Brad King brad.k...@kitware.com AuthorDate: Tue Jun 16 13:55:42 2015 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Jun 16 13:58:41 2015 -0400 GNU: Drop -rdynamic flag from Fortran The GNU Fortran compiler does not document support for this flag as the GNU C and C++ compilers do. diff --git a/Modules/Platform/Linux-GNU-Fortran.cmake b/Modules/Platform/Linux-GNU-Fortran.cmake index 68e9540..85e1226 100644 --- a/Modules/Platform/Linux-GNU-Fortran.cmake +++ b/Modules/Platform/Linux-GNU-Fortran.cmake @@ -1,2 +1,3 @@ include(Platform/Linux-GNU) __linux_compiler_gnu(Fortran) +set(CMAKE_SHARED_LIBRARY_LINK_Fortran_FLAGS ) --- Summary of changes: Modules/Platform/Linux-GNU-Fortran.cmake |1 + 1 file changed, 1 insertion(+) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
Re: [CMake] Xcode project generation failed
On Jun 16, 2015, at 3:27 PM, Gregor Jasny gja...@googlemail.com wrote:
Hello,
I applied some fixes to what becomes CMake 3.3. could you please test
the release candidate?
On 16/06/15 16:27, Michael Jackson wrote:
Running OS X 10.8.5 with Xcode 5.1.1 and Cmake 3.2.x and 3.3.RC and neither
generate a Xcode project file that can be opened by Xcode. We get valid
Ninja and Makefile projects for our project. I was wondering if anyone else
has seen this issue. Not sure if there is something in our project that is
hanging up CMake.
Could you share your project.pbxproj file (if don't want to share it
here you could also mail it to me directly).
Thanks,
Gregor
Just to follow up with this issue in case anyone else has issues with Xcode
here is what happened. Thanks to Gregor for taking a look at the generated
project file he was able to identify an issue where there were file paths in
the form of // inside the project file. They specifically showed in the form
of: /* // */. This was enough to throw the Xcode parser and send Xcode into the
spin-of-death. The root cause of the issue is that I had a cmake variable that
held all my source files. In that list was a file path, where the path was
completely created through cmake variables,
set(FOO_FILE ${SomethingLib_path}/${SOME_HEADER_PATH})
but neither of those variables had been defined for this project. (Copy paste
mistake). This resulted in the cmake variable (FOO_FILE from above) being empty
but still included as a source in the add_library() call. Fixing the cmake
variables fixed the Xcode generation issue.
I also want to recognize git for being helpful in all of this which allowed
to quickly figure out which commit broke the Xcode functionality.
Hope this helps someone in the future.
Mike Jackson
--
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
[CMake] CUDA OBJECT libraries?
I would like to use OBJECT libraries with CUDA. If I try cuda_add_library(foo OBJECT some .cpp files some .cu files) I get CMake Error at /opt/contrib-clangcxx11/cmake-3.2.2-ser/share/cmake-3.2/Modules/FindCUDA.cmake:1518 (add_library): OBJECT library txsbaseobj contains: txsbaseobj_generated_TxsGpuInterpolator.cu.o txsbaseobj_generated_TxsBaseTestKernels.cu.o txsbaseobj_intermediate_link.o Is there a standard way of dealing with this? Thx... -- 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
[cmake-developers] [CMake 0015620]: Ninja generator triggers race condition in Borland bcc32 linker causing intermittent build failure
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15620
==
Reported By:James Johnston
Assigned To:
==
Project:CMake
Issue ID: 15620
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2015-06-17 11:37 EDT
Last Modified: 2015-06-17 11:37 EDT
==
Summary:Ninja generator triggers race condition in Borland
bcc32 linker causing intermittent build failure
Description:
Unfortunately, it appears that the Borland linker utilizes temporary files with
a hard-coded name (e.g. turboc.$ln); these temporary files are written to the
linker's current directory. (Determined via Process Monitor). If two or more
concurrent linkers are run with the same current directory, some of them may
fail as shown below because they will both be trying to use the same temporary
filename.
The Ninja generator, unfortunately seems to keep the current directory to
CMAKE_BINARY_DIR. If the CMake project contains multiple libraries (e.g. VTK
5.4.2, which I tested and has dozens), then it is possible that Ninja will
invoke two concurrent linkers with the same current directory of
CMAKE_BINARY_DIR. They may then conflict with each other - both attempting to
write to a file named ${CMAKE_BINARY_DIR}/turboc.$ln, for example.
To compare, the NMake jom generator runs the linker for each target in a unique
target-specific directory, such that this problem never arises. If the Ninja
generator could also do this, it would work around this issue. (In fact, it
would work around any compiler that happens to write temporary files to its
current directory).
Steps to Reproduce:
My configuration:
* Quad-core hyper-threaded Core i7 CPU
* C++ Builder 5 Update 1
* VTK 5.4.2 (this version still builds under C++ Builder, unlike some newer
versions)
* CMake 3.3.0-rc1 (Kitware-provided binary)
* Ninja 1.5.3, built from source using VC++ 2008 Express
* VTK configured: CMAKE_BUILD_TYPE=RelWithDebInfo, VTK_REMOVE_LEGACY=ON,
BUILD_TESTING=OFF, BUILD_SHARED_LIBS=ON
1. Configure VTK with the above settings. (e.g. to C:\VTK-build)
2. Run ninja to start the build.
3. The build *may* fail if two projects happen to link concurrently. Of
course, it will always succeed if you pass -j 1 to Ninja to only use one CPU
core.
4. Even if you don't immediately experience failure, you can use Sysinternals
Process Monitor from Microsoft to monitor the files being written on your
system. Note that you'll see repeated writes to files like
C:\VTK-build\turboc.$ln.
Additional Information:
While I tested this with C++ Builder 5, the error appears to exist even in the
newest C++ Builder versions:
http://docwiki.embarcadero.com/RADStudio/XE8/en/E2216_Unable_to_create_turboc.$ln_(C%2B%2B)
Sample error when building VTK 5.4.2:
=
[214/2008] Linking CXX shared library bin\vtkDICOMParser.dll Borland C++ 5.5.1
for Win32 Copyright (c) 1993, 2000 Borland Turbo Incremental Link 5.66 Copyright
(c) 1997-2002 Borland
Fatal: No object file or .EXE name was given
Borland Implib Version 3.0.22 Copyright (c) 1991, 2000 Inprise Corporation Error
bin\: unable to open file [215/2008] Linking C shared library bin\vtkzlib.dll
FAILED: cmd.exe /C cd . C:\PROGRA~2\Borland\CBUILD~1\Bin\bcc32.exe -tWR
-tW- -tWD -ebin\vtkzlib.dll -tWM -lS:104857
6 -lSc:4098 -lH:1048576 -lHc:8192 -v import32.lib
Utilities\vtkzlib\CMakeFiles\vtkzlib.dir\adler32.obj snip more OBJ files
implib -c -w bin\vtkzlib.lib bin\vtkzlib.dll cd .
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland Turbo Incremental
Link 5.66 Copyright (c) 1997-2002 Borland
Fatal: Unable to open file 'turboc.$ln'
=
Here is the offending snippet from one of the generated ninja files -
build.ninja:
=
build bin\vtkzlib.dll bin\vtkzlib.lib: C_SHARED_LIBRARY_LINKER__vtkzlib
Utilities\vtkzlib\CMakeFiles\vtkzlib.dir\adler32.obj snip more OBJ files
LANGUAGE_COMPILE_FLAGS = -tWM -Od
LINK_FLAGS = -tWM -lS:1048576 -lSc:4098 -lH:1048576 -lHc:8192 -v
LINK_LIBRARIES = import32.lib
POST_BUILD = cd .
PRE_LINK = cd .
TARGET_FILE = bin\vtkzlib.dll
TARGET_IMPLIB = bin\vtkzlib.lib
TARGET_PDB = vtkzlib.dll.dbg
=
And the corresponding ninja rule:
=
rule C_SHARED_LIBRARY_LINKER__vtkzlib
command = cmd.exe /C $PRE_LINK
Re: [CMake] fortran compiler failed to compile simple test program
I've scoured the cf77 docs and found nothing native so I've responded to
concurrent and again asked how I can find unique identifying information for
cmake to latch onto. Will report back.
Please see the response below about uniquely identifying cf77. Does this seem
doable? How do we proceed with rolling into CMakeDetermineFortranCompiler and
do I have a workaround that I can use for now until this gets rolled into cmake?
Anthony,
Some commands and answers to your last email...
Can you elaborate as to why cf77 must treat -rdynamic different from GNU
standard?
In many ways, cf77 pre-dates GNU.
When porting cf77 to the Linux/GNU environment, option processing was made
GNU-like when appropriate, but without allowing legacy options to change (would
breaking exiting customer build schemes).
In reality, cf77 treats -rdynamic as a string of individual options, which in
this case is being parsed as:
* -r -- Pass to ld; generate a shared object
* -d -- A cf77 debug option. The remainder of the option string (namic)
is considered as additional -d flags.
Now gcc interprets -rdynamic as an individual option, and ends up not passing
the -r to ld, but -export-dynamic, as you indicated in your email.
The cmake developers have agreed to roll this in, I just need a way of
uniquely identifying cf77 from any other compiler.
Unfortunately, I don't have a nice clean solution for you. I guess it depends
on how much trouble the cmake developers want to go to to detect cf77.
In order to identify the compiler as cf77, do something akin to the following:
$ echo ' PROGRAM V' /tmp/nil.f
$ echo ' END' /tmp/nil.f
$ cf77 -v -o /dev/null -c /tmp/nil.f 21 | fgrep Concurrent Fortran 21 |
fgrep Concurrent
Concurrent Fortran 77 Compiler - Version 7.3 Wed Jun 17 06:52:27 2015
Alternatively, one could examine the resultant object file's DWARF information
and extract the DW_AT_producer attribute from the DW_TAG_compilation unit DIE
for the object file.
$ cf77 -c -g /tmp/nil.f -o /tmp/nil.o
$ readelf --debug-dump=info /tmp/nil.o | fgrep DW_AT_producer
DW_AT_producer: Concurrent Fortran 77
In terms of identifying the major and minor versions, the information isn't as
readily available as one would like. The major version number is included in
the -v output of the compiler (see above). However, the minor version number
is only available from the RPM:
$ rpm -qa --qf=%{NAME}-%{VERSION}\n 'ccur-f77-[0-9]*'
ccur-f77-32-7.3-006
$ rpm -qa --qf=%{NAME}-%{VERSION}\n 'ccur-f77-[0-9]*' | sed
s/^ccur-f77-..-//
7.3-006
Note that the major version number is actually part of the RPM's name and the
minor version number is the RPM's version (cf77 supports having multiple
major versions of the compiler installed on one system -- hence the major
version number being embedded in the name).
Did you receive my email regarding the cf77 man page issue?
Regards,
Jeff
This e-mail (including attachments) contains contents owned by Rolls-Royce plc
and its subsidiaries, affiliated companies or customers and covered by the laws
of England and Wales, Brazil, US, or Canada (federal, state or provincial). The
information contained in this email is intended to be confidential, may be
legally privileged and subject to export controls which may restrict the access
to and transfer of the information. If you are not the intended recipient, you
are hereby notified that any retention, dissemination, distribution,
interception or copying of this communication is strictly prohibited and may
subject you to further legal action. Reply to the sender if you received this
email by accident, and then delete the email and any attachments.
--
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
