Re: [cmake-developers] automoc: Use a pre-build event in VS = 7
On Tuesday 02 April 2013, Stephen Kelly wrote: Brad King wrote: Alex, Steve, I just made this automoc change: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=20c99b1d in response to discussion here: http://www.cmake.org/Bug/view.php?id=13900#c32710 In addition to working around a VS 2012 bug, it also makes projects look nicer in the VS IDE by not loading *_automoc targets. Instead it uses PRE_BUILD events in the respective original targets. IIUC VS runs these events when starting a target if and only iff any of the rules in the target are out of date. Therefore when headers or sources change that require any re-compilation in a target it will be re-automoc-ed again. I didn't try it out, and I don't really know anything about the windows generators or PRE_BUILD commands to comment about those aspect. If it works, I'm happy though. Same for me. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] usr-move v. cross-compiling
On Wednesday 03 April 2013, Brad King wrote: On 04/01/2013 10:25 AM, Brad King wrote: http://www.cmake.org/Bug/view.php?id=14041 Our usr-move changes to hard-code the /usr prefix conflicts with cross-compiling cases where the host side relocates a package under some new root and finds it with CMAKE_FIND_ROOT_PATH. Here is a fix using a new approach to support usr-move: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6c613b43 While implementing this I realized the old approach was not fully implemented in configure_package_config_file anyway because while not referencing PACKAGE_PREFIX_DIR it would still leave that variable set improperly after PACKAGE_INIT. The new approach restores the original references to PACKAGE_PREFIX_DIR in all cases but adds code to fix its value in the usr-move case. Thanks, I'll have a closer look at it later today. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Issuing errors for faulty INTERFACE_INCLUDE_DIRECTORIES
On Thursday 28 March 2013, Brad King wrote:
On 03/27/2013 05:21 PM, Alexander Neundorf wrote:
Maybe instead of generating code which immediately results in failure at
the find_package() step, how about generating code which contains a list
of imported targets with missing dependencies/files/directories ?
This is blowing the proposed feature way out of scope. Currently there
will be no error until build time.
... when using Config.cmake files, which are only starting to get commonly
used, and I have seen plenty of mistakes in existing Config.cmake files.
Usually it is already hard to explain to developers the fundamental difference
between Find-modules and Config.cmake files.
Currently when using Find-modules, you get proper error reporting from
find_package().
With the proposed feature the error
will be at CMake time when there could have been one at build time, but
not extra errors at CMake time that would not have occurred at build
time.
if(Xxx_IMPORTED_TARGETS_WITH_MISSING_STUFF)
set(Xxx_${comp}_FOUND FALSE)
endif()
A package config file and consuming projects should not be expected to
adapt to broken installations of packages to use the non-broken parts.
If an include dir is missing who knows what else is wrong.
This feature should be about making things simpler by erroring out early
when we know the build is likely to break because something is missing.
Your proposal will make it more complicated by trying to adapt to the
breakage.
BTW, take a look at this problem:
http://www.cmake.org/Bug/view.php?id=14041
triggered by some of the existing checks for missing files.
Yes, but this is something we have to take care of (thanks for doing that), if
we want developers to like Config.cmake files.
What I like about Find-modules is that they give reliable information about
the actual state of the system. If a Find-module tells me jpeglih.h can be
found in some directory, it actually exists there, if it tells me the path to
a libjpeg.so, I can rely on that this file actually exists.
If find_package() only reads some cmake script file, i.e. a Config.cmake
file, this doesn't give me those guarantees as long as this file does not
verify that the information it provides is actually correct, by checking that
the files and directories it reports to me actually exist.
This is a step backwards compared to Find-modules.
Config.cmake files are much more powerful than Find-modules, but they are also
a lot more complex, at least for simple cases.
We should not add more disadvantages to them (like not actually being a
reliable source of information).
I had enough of bad experiences with libtool la files, I want Config.cmake to
be much much better.
For me, this includes that if we do not use find_library()/find_path() to
actually introspect the system, we need to make sure that the files we refer
to actually do exist, so that the contents of the Config.cmake files will
hopefully never be the cause for build debugging by developers.
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Is it a bug that cmake / cpack could not handle directory name with @?
Eric Noulard wrote 2013/4/5 hce lt; jupiter.hce@ gt; Eric Noulard wrote I did open a bug report for that. I did try a patch. Would you try it please? http://public.kitware.com/Bug/view.php?id=14063 And comment on the tracker for the follow-up. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org Great work, the patch fixes the problem, I can generate the RPM package. I made comment on bug tracker as well. Thank your very much Eric. Jupiter -- View this message in context: http://cmake.3232098.n2.nabble.com/Is-it-a-bug-that-cmake-cpack-could-not-handle-directory-name-with-tp7583963p7583976.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] compiler defines for sub projects
You can make a variable contain the defines you want and the use that variable
in the set_target_properties command. The value of the variable will be
inherited by all of the sup directories.
option(FOO_OPTION enable foo OFF)
option(BAR_OPTION enable bar OFF)
if(FOO_OPTION)
set(CUSTOM_DEFINE FOO_X)
elseif(BAR_OPTION)
set(CUSTOM_DEFINE FOO_Y)
else
set(CUSTOM_DEFINE OTHER)
endif()
set_target_properties(my_lib PROPERTIES COMPILE_DEFINITIONS ${CUSTOM_DEFINE} )
On Apr 6, 2013, at 1:21 AM, Olaf Peter ope-de...@gmx.de wrote:
thanks for your answer.
I've forgot to mention in the hurry yesterday, that inisde the lib
project generator exist which must not compiled with these defines.
if(FOO_OPTION OR BAR_OPTION)
add_executable(generator_target ...)
set_target_properties(generator_target ... COMPILE_DEFINITIONS ...)
endif()
This is the reason for set_target_properties(my_lib ...)
So this solution with add_definitions won't work. Possible it could work
if I removed those defs from target.
Thanks,
Olaf
If you want to have all of the sub directories to have the defines
present, you could use ADD_DEFINITIONS().
option(FOO_OPTION enable foo OFF)
option(BAR_OPTION enable bar OFF)
if(FOO_OPTION)
add_definitions(-DFOO_X )
elseif(BAR_OPTION)
add_definitions(-DFOO_Y)
else()
add_definitions(-DOTHER)
endif()
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On
Behalf Of Olaf Peter
Sent: Friday, April 05, 2013 12:58 PM
To: cmake@cmake.org
Subject: [CMake] compiler defines for sub projects
Hello,
is it possible to inherit compiler defines for sub projects in sub
directories?
I have a library project which can be configured at compile time
using preprocessor defines (cmake option)
option(FOO_OPTION enable foo OFF)
option(BAR_OPTION enable bar OFF)
if(FOO_OPTION)
set_target_properties(my_lib PROPERTIES COMPILE_DEFINITIONS
FOO_X )
elseif(BAR_OPTION)
set_target_properties(my_lib PROPERTIES COMPILE_DEFINITIONS
FOO_Y)
else()
set_target_properties(my_lib PROPERTIES COMPILE_DEFINITIONS
OTHER )
endif()
now, in the sub of this I have unit tests which need to know about
this compile defs, hence I have the same if/else again.
Is there an easy way for this?
Thanks,
Olaf
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Installing and Exporting for multiple configurations
I see so the proper full path would be
get_property( existing_outname TARGET ${target} PROPERTY
OUTPUT_NAME )
if( NOT existing_outname )
set( existing_outname ${target} )
endif( NOT existing_outname )
DESTINATION
lib${LIB_SUFFIX}/${CMAKE_{STATIC,SHARED}_LIBRARY_PREFIX}${existing_outname}${CMAKE_{STATIC,SHARED}_LIBRARY_SUFFIX.
On Fri, Apr 5, 2013 at 8:29 AM, Matthew Woehlke matthew.woeh...@kitware.com
wrote:
On 2013-04-04 19:19, J Decker wrote:
On Thu, Apr 4, 2013 at 2:25 PM, Matthew Woehlke wrote:
On 2013-04-04 17:04, J Decker wrote:
Also, you should install to 'lib${LIB_SUFFIX}', not 'lib'. This will
allow
you (and distros packaging your software) to set LIB_SUFFIX to separate
arch-specific components of 32- and 64-bit builds. E.g. on Linux,
lib_suffix is usually ''/'64' or '32'/'', and on Windows might be
''/'/amd64'.
if you're mentioning ${LIB_SUFFIX} you might as well mention
${LIB_PREFIX}
which is the 'lib' prepended on gnuish systems.
?
I'm pretty sure my libraries don't get installed to /usr/liblib64...
Maybe
you are thinking of the file name prefix, which is something different?
right...but they do go to
/usr/lib64/${CMAKE_[SHARED/**STATIC]_LIBRARY_PREFIX}...${**
CMAKE_[SHARED/STATIC]_LIBRARY_**SUFFIX}
Like I said... LIB_SUFFIX != CMAKE_{STATIC,SHARED}_LIBRARY_**PREFIX.
CMAKE_{STATIC,SHARED}_LIBRARY_**PREFIX is a built-in variable that
affects default library file names in the build.
LIB_SUFFIX is a de facto convention (originating from distro packagers I
believe) which is appended to the 'lib' destination directory when
installing things into 'lib', in order to conveniently support multi-arch
aware systems; e.g. things get installed to /usr/lib64 because they are
correctly installed to 'DESTINATION lib${LIB_SUFFIX}' with -DLIB_SUFFIX=64.
--
Matthew
--
Powered by www.kitware.com
Visit other Kitware open-source projects at http://www.kitware.com/**
opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] The else() in CMAKE_TOOLCHAIN_FILE
Hi, Daniel, I've tried this, but it doesn't work, it returns same error as before. And there are 2 lines in CMakeCache.txt: //No help, variable specified on the command line. A:BOOL=ON Best Regards, ashi On Tue, Apr 2, 2013 at 7:44 PM, Daniel Pfeifer dan...@pfeifer-mail.dewrote: http://cmake.org/cmake/help/v2.8.10/cmake.html#opt:-Dvar:typevalue What is missing in the documentation, is that no cache entry is created if the type is not given. Set A as a cache entry of type BOOL like this: $ cmake -DCMAKE_TOOLCHAIN_FILE=./config.cmake -DA:BOOL=ON . 2013/4/2 Ashi ashi08...@gmail.com I think I find something to explain this: the config.cmake(the CMAKE_TOOLCHAIN_FILE) is reloaded several times. on first-load, the A is set, but on second-load and later-load, the A is not set. I think I can get around this problem when A is kept set. However, I don't know how can I keep the value set in cmake. Could anyone give me some suggestion? Thanks! On Mon, Apr 1, 2013 at 7:47 PM, Ashi ashi08...@gmail.com wrote: Hi all, I've a problem in using else() in CMAKE_TOOLCHAIN_FILE, all files are: #==CMakeLists.txt== message(TEST) #==config.cmake== if(A) message(A) elseif(B) message(B) elseif(C) message(C) else() message(FATAL_ERROR NONE) endif() and I run the cmake: $ cmake -DCMAKE_TOOLCHAIN_FILE=./config.cmake -DA=true . cmake returns: A A -- The C compiler identification is GNU 4.7.2 -- The CXX compiler identification is GNU 4.7.2 -- Check for working C compiler: /I usr/bin/gcc CMake Error at /home/zhongwei/projects/cmake_test/config.cmake:8 (message): NONE Call Stack (most recent call first): /home/zhongwei/projects/cmake_test/build/CMakeFiles/CMakeSystem.cmake:1 (INCLUDE) CMakeLists.txt:2 (PROJECT) CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage CMake Error: Internal CMake error, TryCompile configure of cmake failed -- Configuring incomplete, errors occurred! My problem is why the else() statement is still run when A=true? Thanks, ashi -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] The else() in CMAKE_TOOLCHAIN_FILE
Yeah, my current approach is exactly creating different toolchain files. Best Regards, ashi On Wed, Apr 3, 2013 at 8:19 PM, Yngve Inntjore Levinsen yngve.levin...@gmail.com wrote: On 03. april 2013 13:13, Johannes Zarl wrote: Hi, On Tuesday, 2. April 2013, 06:42:47, Ashi wrote: I think I find something to explain this: the config.cmake(the CMAKE_TOOLCHAIN_FILE) is reloaded several times. on first-load, the A is set, but on second-load and later-load, the A is not set. I think I can get around this problem when A is kept set. However, I don't know how can I keep the value set in cmake. Could anyone give me some suggestion? Thanks! I'm not entirely sure what you're trying to do, but it seems like you would want to make A, B, and C into cache variables. That way subsequent cmake runs will use the same value... Johannes Hi, I'm thinking that one solution could be to create three (or four?) toolchain files, one for each if clause? Cheers, Yngve -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, master, updated. v2.8.10.2-981-g4336fad
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 4336fadff05b4e490ff48282e1b9e30c89de5d39 (commit) from 88073c8e08302c9cea309d9753c11dc01a7d5f1c (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=4336fadff05b4e490ff48282e1b9e30c89de5d39 commit 4336fadff05b4e490ff48282e1b9e30c89de5d39 Author: Kitware Robot kwro...@kitware.com AuthorDate: Sun Apr 7 00:01:04 2013 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Sun Apr 7 00:01:04 2013 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 51d9b0e..aacfc97 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ set(CMake_VERSION_MAJOR 2) set(CMake_VERSION_MINOR 8) set(CMake_VERSION_PATCH 10) -set(CMake_VERSION_TWEAK 20130406) +set(CMake_VERSION_TWEAK 20130407) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
