Re: [CMake] providing library information, what's the cmake way
On 11/29/2010 02:28 PM, Johannes Zarl wrote:
Sorry for the late response, but your mail was simply to long for a
swift response...
No problem, this topic is not exactly trivial.
On 11/26/2010 at 05:47, Michael Hertling mhertl...@online.de wrote:
On 11/24/2010 04:51 PM, Johannes Zarl wrote:
About the components question again: I played around a bit, and I think I
now more or less have comprehended this. I guess for a package XXX with
components YYY and ZZZ, one could set variables XXX_HAS_YYY and XXX_HAS_ZZZ
and then use a loop like this one in the XXXConfig.cmake file:
foreach( component ${XXX_FIND_COMPONENTS} )
if ( XXX_HAS_${component})
set ( XXX_${component}_FOUND TRUE )
else( XXX_HAS_${component})
if ( ${XXX_FIND_REQUIRED})
message(FATAL_ERROR Required component ${component} not
found!)
elseif ( NOT XXX_FIND_QUIETLY)
message(STATUS Component ${component} not found!)
endif ( ${XXX_FIND_REQUIRED})
endif ( XXX_HAS_${component})
endforeach( component )
Correct?
While that's a possible approach it lacks the invocation-specific
variables, i.e. XXX_{INCLUDE_DIRS,LIBRARIES,DEFINITIONS}, and in
some cases, these can't be assembled in a simple component-wise
manner, see below. Moreover, there are further questions w.r.t.
multi-component packages and their config files:
Does this mean that XXX_LIBRARIES etc. should normally incorporate the
settings for the components as well? [...]
Yes, of course, if FIND_PACKAGE(XXX ...) returns successfully one would
expect XXX_LIBRARIES to hold all libraries necessary to link against in
order to use all components enabled by the FIND_PACKAGE() invocation,
i.e. the libraries provided by the components themselves as well as
their prerequisites.
[...] IMO this can't work if you call
find_package several times with different components. [...]
This is one of those questions to deal with when it comes to multi-
component packages: Does FIND_PACKAGE(XXX ...) act accumulatively?
[...] Also, this would
make it impossible to link to the base library alone, i.e. without
the components...
One might consider the base library as a component by itself, perhaps
enabled automatically by resolving inter-component dependencies. As an
alternative, one could a priori populate XXX_LIBRARIES et al. with the
base library stuff and add the components' contributions as required.
Furthermore, a package doesn't need to have a dedicated base library,
e.g. Boost hasn't, and if you don't specify any components the
Boost_LIBRARIES variable remains empty.
- Does the config file provide the component-specific variables like
XXX_YYY_FOUND for each available component or for the requested ones
only, i.e. can you rely on XXX_ZZZ_FOUND to have a definite value if
you just said FIND_PACKAGE(XXX COMPONENTS YYY)? With your foregoing
approach, you can't. That's alright, but should be mentioned in the
package's documentation. Imagine the following scenario: There's one
installation of XXX for the native system and another one for cross
compiling purposes. The latter has YYY and ZZZ while the former has
YYY only. Due to FIND_PACKAGE()'s ability to search for config files
in various locations, such a coexistence is easily possible. Now, a
FIND_PACKAGE(XXX COMPONENTS YYY ZZZ) for the cross compilation XXX
returns with XXX_ZZZ_FOUND=TRUE, but does a subsequent invocation of
FIND_PACKAGE(XXX COMPONENTS YYY) within the same scope for the native
XXX return with XXX_ZZZ_FOUND=FALSE, or does XXX_ZZZ_FOUND=TRUE still
hold from the previous invocation? Both alternatives are fine, but the
user should know the score.
Thanks, I hadn't thought of this. So the code-snippet above should
contain a set ( XXX_${component}_FOUND ${component}-NOTFOUND ).
Yes, one would expect that FOUND variables for requested components
receive defined values in all cases - positive as well as negative.
Besides, it's a good style to refer to any
component-related variables only if the particular component has been
requested explicitly.
Ok, so a better style would be to only set the XXX_HAS_* variables at
first (maybe unsetting them at the end of the config file?), and then
to conditionally set the XXX_YYY_INCLUDE_DIRS etc. if XXX_YYY_FOUND
is true.
Here, I meant it is a good *user* style to rely only on variables
related to explicitly requested components; maybe a bit ambiguous.
- Handling of inter-component dependencies: Imagine the user just says
FIND_PACKAGE(XXX COMPONENTS ZZZ), but ZZZ needs YYY. If YYY is to be
enabled automatically the config file must know about the dependency
and cannot simply add the ZZZ-specific variables to the invocation-
specific ones; the YYY-specific variables must be mentioned, too.
I don't really see this as a problem. Although the code at hand lacks
support for this kind of dependencies, in most cases you won't need it.
And if you as the config file writer
Re: [CMake] providing library information, what's the cmake way
On 11/30/2010 at 11:39, Michael Hertling mhertl...@online.de wrote:
Does this mean that XXX_LIBRARIES etc. should normally incorporate the
settings for the components as well? [...]
Yes, of course, if FIND_PACKAGE(XXX ...) returns successfully one would
expect XXX_LIBRARIES to hold all libraries necessary to link against in
order to use all components enabled by the FIND_PACKAGE() invocation,
i.e. the libraries provided by the components themselves as well as
their prerequisites.
About that one would expect: I would be rather stumped and scratching
my head if I saw this behaviour. But I'll get to that below...
[...] IMO this can't work if you call
find_package several times with different components. [...]
This is one of those questions to deal with when it comes to multi-
component packages: Does FIND_PACKAGE(XXX ...) act accumulatively?
Yes. Again, for a detailed explanation see below...
[...] Also, this would
make it impossible to link to the base library alone, i.e. without
the components...
One might consider the base library as a component by itself, perhaps
enabled automatically by resolving inter-component dependencies. As an
alternative, one could a priori populate XXX_LIBRARIES et al. with the
base library stuff and add the components' contributions as required.
Furthermore, a package doesn't need to have a dedicated base library,
e.g. Boost hasn't, and if you don't specify any components the
Boost_LIBRARIES variable remains empty.
Which is to be expected, given that Boost is mostly a headers-only
library. Still, after your find_package call for Boost alone, you can
use all Boost core libraries.
--
Johannes Zarl
Virtual Reality Services
Johannes Kepler University
Informationsmanagement
Altenbergerstrasze 69
4040 Linz, Austria
Phone: +43 732 2468-8321
johannes.z...@jku.at
http://vrc.zid.jku.at
- Handling of inter-component dependencies: Imagine the user just says
FIND_PACKAGE(XXX COMPONENTS ZZZ), but ZZZ needs YYY. If YYY is to be
enabled automatically the config file must know about the dependency
and cannot simply add the ZZZ-specific variables to the invocation-
specific ones; the YYY-specific variables must be mentioned, too.
I don't really see this as a problem. Although the code at hand lacks
support for this kind of dependencies, in most cases you won't need it.
And if you as the config file writer need it, you obviously know you
have dependencies and that you have to write code supporting those
dependencies.
Usually, handling of such dependencies means enabling some components
the user hasn't requested explicitly, so it's quite straight forward,
in fact. However, I've mentioned these dependencies to point out that
the invocation-specific variables like XXX_LIBRARIES sometimes can't
be assembled by a simple iteration over XXX_FIND_COMPONENTS; instead,
the dependencies must be resolved first. BTW, do you know an example
with a component A depending on B only if C is enabled? ;)
No, but you are posing questions that make my head hurt (in a good-ish
way ;-)
- Do multiple consecutive FIND_PACKAGE(XXX ...) invocations act in an
accumulative manner on the invocation-specific variables?
Generally speaking, I would say: yes. At least this is the way of the
least surprise for the user, as in sufficiently complex projects a
package may be included at different places with different arguments.
For the same reason, I'd tend to the opposite; look at the following:
FIND_PACKAGE(XXX COMPONENTS YYY)
...
ADD_SUBDIRECTORY(subdir)
In subdir/CMakeLists.txt:
FIND_PACKAGE(XXX COMPONENTS ZZZ)
...
TARGET_LINK_LIBRARIES(... ${XXX_LIBRARIES})
Here, the target is also linked against XXX_YYY_LIBRARY as the latter is
inherited via XXX_LIBRARIES from the parent directory, but if the target
only needs XXX_ZZZ_LIBRARY it will possibly be overlinked. Although this
can be avoided by resetting XXX_LIBRARIES before each FIND_PACKAGE()
invocation, I don't think that's the way one would like to go.
IMO, the invocation-specific results of any FIND_PACKAGE() call should
depend solely on the parameters passed in and the well-known variables
like CMAKE_PREFIX_PATH. The downside is that one must possibly process
or save the results before they could be overwritten, e.g.:
FIND_PACKAGE(XXX REQUIRED YYY)
SET(LIBRARIES ${XXX_LIBRARIES})
FIND_PACKAGE(XXX COMPONENTS ZZZ)
LIST(APPEND LIBRARIES ${XXX_LIBRARIES})
...
TARGET_LINK_LIBRARIES(... ${LIBRARIES})
Since such related calls to FIND_PACKAGE(XXX ...) usually occur nearby
each other within the same CMakeLists.txt, this little penalty should
be acceptable whereas accumulated XXX_LIBRARIES and the like may have
far reaching and surprising effects, especially in complex projects.
Funny enough, my example is almost the same:
FIND_PACKAGE(XXX COMPONENTS YYY)
...
ADD_SUBDIRECTORY(subdir)
...
TARGET_LINK_LIBRARIES(AAA ${XXX_LIBRARIES})
TARGET_LINK_LIBRARIES(BBB
Re: [CMake] Relink on library rebuild dilema
On 11/29/2010 6:52 AM, Michael Hertling wrote: Perhaps, this is a good opportunity to ask a related question: Some time ago, there has been an issue with special linker scripts which are part of a project. Of course, one would like to see the linker triggered when these scripts change, and the best solution I have found so far is - just like suggested to the OP - A feature was implemented for this recently: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=95f149e6 It will be in 2.8.4. -Brad ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Pass PATH to ExternalProject_Add
Hi,
I added some ExternalProject_Add directives to my project. Each of them runs
the sequence of configure, make all, make install. Later projects need run
commands generated in early projects during their build phases.
Each project installs generated files at the place ${BUILD_DIR} which is set
at the top of the cmake file and passed down to the configure command. I tried
setting ENV{PATH} to include the directory ${BUILD_DIR}/bin but cmake doesn't
pass the changed environment variable down to the ExternalProject_Add
directives. Since the changed environment isn't passed down later projects
don't look for generated commands in ${BUILD_DIR}/bin.
How can I pass down the PATH environment to ExternalProject_Add?
CMakeLists.txt:
set(BUILD_DIR ${CMAKE_CURRENT_BINARY_DIR}/build)
set(ENV{PATH} ${CMAKE_CURRENT_BINARY_DIR}/build/bin)
ExternalProject_Add(project0
CONFIGURE_COMMAND ./configure --prefix=${BUILD_DIR}
BUILD_IN_SOURCE 1
)
ExternalProject_Add(project1
DEPENDS project0
CONFIGURE_COMMAND ./configure --prefix=${BUILD_DIR}
BUILD_IN_SOURCE 1
)
signature.asc
Description: This is a digitally signed message part.
___
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] Pass PATH to ExternalProject_Add
Write a wrapper script for your configure command, set the ENV var
inside the wrapper script before calling configure.
That's the best way to do it with as-is CMake.
On Tuesday, November 30, 2010, Joke de Buhr j...@seiken.de wrote:
Hi,
I added some ExternalProject_Add directives to my project. Each of them runs
the sequence of configure, make all, make install. Later projects need run
commands generated in early projects during their build phases.
Each project installs generated files at the place ${BUILD_DIR} which is set
at the top of the cmake file and passed down to the configure command. I tried
setting ENV{PATH} to include the directory ${BUILD_DIR}/bin but cmake doesn't
pass the changed environment variable down to the ExternalProject_Add
directives. Since the changed environment isn't passed down later projects
don't look for generated commands in ${BUILD_DIR}/bin.
How can I pass down the PATH environment to ExternalProject_Add?
CMakeLists.txt:
set(BUILD_DIR ${CMAKE_CURRENT_BINARY_DIR}/build)
set(ENV{PATH} ${CMAKE_CURRENT_BINARY_DIR}/build/bin)
ExternalProject_Add(project0
CONFIGURE_COMMAND ./configure --prefix=${BUILD_DIR}
BUILD_IN_SOURCE 1
)
ExternalProject_Add(project1
DEPENDS project0
CONFIGURE_COMMAND ./configure --prefix=${BUILD_DIR}
BUILD_IN_SOURCE 1
)
___
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] test property COST not working in cmake 2.8.3?
On Fri, Nov 26, 2010 at 10:38:44AM -0500, Zach Mullen wrote: I just realized why this isn't working -- it's actually not a regression. Maybe we have different definitions of regression. I see a feature that used to do one thing but which now does something else. Here is what the docs say about the COST property: # COST: Set this to a floating point value. Tests in a test set will be # run in descending order of cost. This property describes the cost of a test. You can explicitly set this value; tests with higher COST values will run first. I don't see anything there about parallel or non-parallel runs. It seems to me that if I set the COST property, I should be able to control the order in which tests run, period. So at the very least, the docs should be updated if you intend to change the behavior. In this release we decided that the costs should only be taken into account in a parallel case (ctest -j N). Many users have implicit dependencies based on the order of their add_test calls, so we didn't want to break backward compatibility for those not using parallel ctest. It looks like ctest -j2 is respecting COST. Currently I have several tests that cannot run at the same time as others (they touch the same resources and/or running two of them at once would crush the machine). If I could get the old COST behavior by running ctest -j1, that might be an acceptable workaround, but it does not appear to work today. The non-parallel way to specify a test to run last is simply to make it the last add_test call. My CMake projects are modular (I imagine this is true for many CMake users). Each module is responsible for adding its own unit tests and code quality checks. As I said in my initial email, the code quality checks must run after the unit tests so that accurate code coverage values can be calculated. I can try to insure that my add_unittest() functions all run before my add_code_quality() functions, but that seems brittle and error-prone. It was much nicer when I could just tell add_code_quality() to add all its tests with COST -1000 to guarantee they run after everything else. I can imagine ways to work around this problem, but they all seem rather clunky, especially when COST used to solve the problem so simply and elegantly. I hope we can reach a useful middle ground about the future of the COST property. In its current state, it is of no use to me. Thanks, tyler On Fri, Nov 26, 2010 at 10:20 AM, Zach Mullen zach.mul...@kitware.comwrote: On Tue, Nov 23, 2010 at 6:02 PM, David Cole david.c...@kitware.comwrote: It might be due to this commit: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=142edf8ad4baccd991a6a8a3e5283d0b575acca2 (first released in 2.8.3) Or this one: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b4d27dc041c9164d6f3ad39e192f4b7d116ca3b3 (first released in 2.8.2) Either way, seems like a bug to me. If you explicitly specify a COST property value, especially a negative one to induce last run status, then it should be honored over either historical average measurement or failed last time, so run it first this time behavior. ___ 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] set CMAKE_INSTALL_PREFIX in CMakeLists
On Thu, Nov 25, 2010 at 02:01:31PM +0100, Marcel Loose wrote:
On 24-11-2010 at 17:45, in message
20101124164507.gg23...@cryptio.net, Tyler
Roscoe ty...@cryptio.net wrote:
On Wed, Nov 24, 2010 at 12:11:56PM +0100, Micha Renner wrote:
SET(CMAKE_INSTALL_PREFIX /foo/bar CACHE PATH Foo install
prefix)
So, without the test to
CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT,
and without the FORCE option.
No, as I mentioned, there was an article of one the
CMake-maintainers
who recommended this.
Micha is correct. CMAKE_INSTALL_PREFIX is set before your
CMakeLists.txt
is processed, so the above will never do anything.
tyler
Well, I tested this before I posted my reply. It does work the way I
describe it. Try it yourself.
It doesn't work for me:
[tyle...@tpb006:~/cmake-test-install-prefix]$ cmake --version
cmake version 2.8.3
[tyle...@tpb006:~/cmake-test-install-prefix]$ cat CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(p)
set (CMAKE_INSTALL_PREFIX foo CACHE PATH docstring)
message (CMAKE_INSTALL_PREFIX = ${CMAKE_INSTALL_PREFIX})
[tyle...@tpb006:~/cmake-test-install-prefix]$ mkdir b cd b cmake ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMAKE_INSTALL_PREFIX = /usr/local
-- Configuring done
-- Generating done
-- Build files have been written to: /tpb006/tylermr/cmake-test-install-prefix/b
___
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] test property COST not working in cmake 2.8.3?
Hm, yours was a use case we didn't really consider when we were making changes to cost behavior. The middle ground here would be to respect costs in the non-parallel case when they are expressed explicitly, but not to cost-order them automatically based on their previous run times. -Zach On Tue, Nov 30, 2010 at 12:43 PM, Tyler Roscoe ty...@cryptio.net wrote: On Fri, Nov 26, 2010 at 10:38:44AM -0500, Zach Mullen wrote: I just realized why this isn't working -- it's actually not a regression. Maybe we have different definitions of regression. I see a feature that used to do one thing but which now does something else. Here is what the docs say about the COST property: # COST: Set this to a floating point value. Tests in a test set will be # run in descending order of cost. This property describes the cost of a test. You can explicitly set this value; tests with higher COST values will run first. I don't see anything there about parallel or non-parallel runs. It seems to me that if I set the COST property, I should be able to control the order in which tests run, period. So at the very least, the docs should be updated if you intend to change the behavior. In this release we decided that the costs should only be taken into account in a parallel case (ctest -j N). Many users have implicit dependencies based on the order of their add_test calls, so we didn't want to break backward compatibility for those not using parallel ctest. It looks like ctest -j2 is respecting COST. Currently I have several tests that cannot run at the same time as others (they touch the same resources and/or running two of them at once would crush the machine). If I could get the old COST behavior by running ctest -j1, that might be an acceptable workaround, but it does not appear to work today. The non-parallel way to specify a test to run last is simply to make it the last add_test call. My CMake projects are modular (I imagine this is true for many CMake users). Each module is responsible for adding its own unit tests and code quality checks. As I said in my initial email, the code quality checks must run after the unit tests so that accurate code coverage values can be calculated. I can try to insure that my add_unittest() functions all run before my add_code_quality() functions, but that seems brittle and error-prone. It was much nicer when I could just tell add_code_quality() to add all its tests with COST -1000 to guarantee they run after everything else. I can imagine ways to work around this problem, but they all seem rather clunky, especially when COST used to solve the problem so simply and elegantly. I hope we can reach a useful middle ground about the future of the COST property. In its current state, it is of no use to me. Thanks, tyler On Fri, Nov 26, 2010 at 10:20 AM, Zach Mullen zach.mul...@kitware.com wrote: On Tue, Nov 23, 2010 at 6:02 PM, David Cole david.c...@kitware.com wrote: It might be due to this commit: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=142edf8ad4baccd991a6a8a3e5283d0b575acca2 (first released in 2.8.3) Or this one: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b4d27dc041c9164d6f3ad39e192f4b7d116ca3b3 (first released in 2.8.2) Either way, seems like a bug to me. If you explicitly specify a COST property value, especially a negative one to induce last run status, then it should be honored over either historical average measurement or failed last time, so run it first this time behavior. ___ 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] set CMAKE_INSTALL_PREFIX in CMakeLists
It probably works accidentally if you do the set before the project command.
Unfortunately, the project command has significant side effects.
Setting a default (cached) value for CMAKE_INSTALL_PREFIX might be one
of those...
On Tuesday, November 30, 2010, Tyler Roscoe ty...@cryptio.net wrote:
On Thu, Nov 25, 2010 at 02:01:31PM +0100, Marcel Loose wrote:
On 24-11-2010 at 17:45, in message
20101124164507.gg23...@cryptio.net, Tyler
Roscoe ty...@cryptio.net wrote:
On Wed, Nov 24, 2010 at 12:11:56PM +0100, Micha Renner wrote:
SET(CMAKE_INSTALL_PREFIX /foo/bar CACHE PATH Foo install
prefix)
So, without the test to
CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT,
and without the FORCE option.
No, as I mentioned, there was an article of one the
CMake-maintainers
who recommended this.
Micha is correct. CMAKE_INSTALL_PREFIX is set before your
CMakeLists.txt
is processed, so the above will never do anything.
tyler
Well, I tested this before I posted my reply. It does work the way I
describe it. Try it yourself.
It doesn't work for me:
[tyle...@tpb006:~/cmake-test-install-prefix]$ cmake --version
cmake version 2.8.3
[tyle...@tpb006:~/cmake-test-install-prefix]$ cat CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(p)
set (CMAKE_INSTALL_PREFIX foo CACHE PATH docstring)
message (CMAKE_INSTALL_PREFIX = ${CMAKE_INSTALL_PREFIX})
[tyle...@tpb006:~/cmake-test-install-prefix]$ mkdir b cd b cmake ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMAKE_INSTALL_PREFIX = /usr/local
-- Configuring done
-- Generating done
-- Build files have been written to:
/tpb006/tylermr/cmake-test-install-prefix/b
___
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] Pass PATH to ExternalProject_Add
Often you can also pass options to configure scripts specifying the
location of special tools.
Michael
On 11/30/2010 05:47 PM, David Cole wrote:
Write a wrapper script for your configure command, set the ENV var
inside the wrapper script before calling configure.
That's the best way to do it with as-is CMake.
On Tuesday, November 30, 2010, Joke de Buhr j...@seiken.de wrote:
Hi,
I added some ExternalProject_Add directives to my project. Each of them runs
the sequence of configure, make all, make install. Later projects need run
commands generated in early projects during their build phases.
Each project installs generated files at the place ${BUILD_DIR} which is set
at the top of the cmake file and passed down to the configure command. I
tried
setting ENV{PATH} to include the directory ${BUILD_DIR}/bin but cmake doesn't
pass the changed environment variable down to the ExternalProject_Add
directives. Since the changed environment isn't passed down later projects
don't look for generated commands in ${BUILD_DIR}/bin.
How can I pass down the PATH environment to ExternalProject_Add?
CMakeLists.txt:
set(BUILD_DIR ${CMAKE_CURRENT_BINARY_DIR}/build)
set(ENV{PATH} ${CMAKE_CURRENT_BINARY_DIR}/build/bin)
ExternalProject_Add(project0
CONFIGURE_COMMAND ./configure --prefix=${BUILD_DIR}
BUILD_IN_SOURCE 1
)
ExternalProject_Add(project1
DEPENDS project0
CONFIGURE_COMMAND ./configure --prefix=${BUILD_DIR}
BUILD_IN_SOURCE 1
)
___
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] test property COST not working in cmake 2.8.3?
On Tue, Nov 30, 2010 at 01:29:37PM -0500, Zach Mullen wrote: Hm, yours was a use case we didn't really consider when we were making changes to cost behavior. Clearly. :) The middle ground here would be to respect costs in the non-parallel case when they are expressed explicitly This sounds good. but not to cost-order them automatically based on their previous run times. I don't care too much about this behavior, but it seems like a nice feature. Perhaps if CTest reserved a range for its own COST data (-10 = CTest-calculated COST = 10?) then users could use costs -10 or 10 to insure ordering of certain tests? So what are the next steps? Should I open a bug to track this issue? Is this an easy change (so easy a monkey like me can do it) or can someone at Kitware take care of it? I am able and eager to test a CMake nightly build that fixes this bug/regression/misunderstanding. Thanks, tyler On Tue, Nov 30, 2010 at 12:43 PM, Tyler Roscoe ty...@cryptio.net wrote: On Fri, Nov 26, 2010 at 10:38:44AM -0500, Zach Mullen wrote: I just realized why this isn't working -- it's actually not a regression. Maybe we have different definitions of regression. I see a feature that used to do one thing but which now does something else. Here is what the docs say about the COST property: # COST: Set this to a floating point value. Tests in a test set will be # run in descending order of cost. This property describes the cost of a test. You can explicitly set this value; tests with higher COST values will run first. I don't see anything there about parallel or non-parallel runs. It seems to me that if I set the COST property, I should be able to control the order in which tests run, period. So at the very least, the docs should be updated if you intend to change the behavior. In this release we decided that the costs should only be taken into account in a parallel case (ctest -j N). Many users have implicit dependencies based on the order of their add_test calls, so we didn't want to break backward compatibility for those not using parallel ctest. It looks like ctest -j2 is respecting COST. Currently I have several tests that cannot run at the same time as others (they touch the same resources and/or running two of them at once would crush the machine). If I could get the old COST behavior by running ctest -j1, that might be an acceptable workaround, but it does not appear to work today. The non-parallel way to specify a test to run last is simply to make it the last add_test call. My CMake projects are modular (I imagine this is true for many CMake users). Each module is responsible for adding its own unit tests and code quality checks. As I said in my initial email, the code quality checks must run after the unit tests so that accurate code coverage values can be calculated. I can try to insure that my add_unittest() functions all run before my add_code_quality() functions, but that seems brittle and error-prone. It was much nicer when I could just tell add_code_quality() to add all its tests with COST -1000 to guarantee they run after everything else. I can imagine ways to work around this problem, but they all seem rather clunky, especially when COST used to solve the problem so simply and elegantly. I hope we can reach a useful middle ground about the future of the COST property. In its current state, it is of no use to me. Thanks, tyler On Fri, Nov 26, 2010 at 10:20 AM, Zach Mullen zach.mul...@kitware.com wrote: On Tue, Nov 23, 2010 at 6:02 PM, David Cole david.c...@kitware.com wrote: It might be due to this commit: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=142edf8ad4baccd991a6a8a3e5283d0b575acca2 (first released in 2.8.3) Or this one: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b4d27dc041c9164d6f3ad39e192f4b7d116ca3b3 (first released in 2.8.2) Either way, seems like a bug to me. If you explicitly specify a COST property value, especially a negative one to induce last run status, then it should be honored over either historical average measurement or failed last time, so run it first this time behavior. ___ 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] set CMAKE_INSTALL_PREFIX in CMakeLists
If we want this unintentional behavior to continue working as is into
the future, we should add a test for this behavior and make the test
fail if the value of CMAKE_INSTALL_PREFIX is not as expected at the
bottom of CMakeLists...
Anybody want to add some code to the test suite to validate this
particular idiosyncrasy?
On Tuesday, November 30, 2010, S Roderick kiwi@mac.com wrote:
On Nov 30, 2010, at 13:40 , David Cole wrote:
It probably works accidentally if you do the set before the project
command.
That is what we do, and it definitely works for us. Set it _before_ the
PROJECT() statement.
Unfortunately, the project command has significant side effects.
Setting a default (cached) value for CMAKE_INSTALL_PREFIX might be one
of those...
On Tuesday, November 30, 2010, Tyler Roscoe ty...@cryptio.net wrote:
On Thu, Nov 25, 2010 at 02:01:31PM +0100, Marcel Loose wrote:
On 24-11-2010 at 17:45, in message
20101124164507.gg23...@cryptio.net, Tyler
Roscoe ty...@cryptio.net wrote:
On Wed, Nov 24, 2010 at 12:11:56PM +0100, Micha Renner wrote:
SET(CMAKE_INSTALL_PREFIX /foo/bar CACHE PATH Foo install
prefix)
So, without the test to
CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT,
and without the FORCE option.
No, as I mentioned, there was an article of one the
CMake-maintainers
who recommended this.
Micha is correct. CMAKE_INSTALL_PREFIX is set before your
CMakeLists.txt
is processed, so the above will never do anything.
tyler
Well, I tested this before I posted my reply. It does work the way I
describe it. Try it yourself.
It doesn't work for me:
[tyle...@tpb006:~/cmake-test-install-prefix]$ cmake --version
cmake version 2.8.3
[tyle...@tpb006:~/cmake-test-install-prefix]$ cat CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(p)
set (CMAKE_INSTALL_PREFIX foo CACHE PATH docstring)
message (CMAKE_INSTALL_PREFIX = ${CMAKE_INSTALL_PREFIX})
[tyle...@tpb006:~/cmake-test-install-prefix]$ mkdir b cd b cmake ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMAKE_INSTALL_PREFIX = /usr/local
-- Configuring done
-- Generating done
-- Build files have been written to:
/tpb006/tylermr/cmake-test-install-prefix/b
___
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] set CMAKE_INSTALL_PREFIX in CMakeLists
On Nov 30, 2010, at 16:03 , David Cole wrote: If we want this unintentional behavior to continue working as is into the future, we should add a test for this behavior and make the test fail if the value of CMAKE_INSTALL_PREFIX is not as expected at the bottom of CMakeLists... I think it is a useful behavior to have. We use it within an enterprise environment to set a reasonable default, if the user hasn't specifically overridden it. As one other commentor stated though, as a project developer (not CMake) you need to make this very obvious in case the user tries to figure out why something was installed somewhere (without the user telling it anything)! S ___ 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] set CMAKE_INSTALL_PREFIX in CMakeLists
On Nov 30, 2010, at 13:40 , David Cole wrote:
It probably works accidentally if you do the set before the project command.
That is what we do, and it definitely works for us. Set it _before_ the
PROJECT() statement.
Unfortunately, the project command has significant side effects.
Setting a default (cached) value for CMAKE_INSTALL_PREFIX might be one
of those...
On Tuesday, November 30, 2010, Tyler Roscoe ty...@cryptio.net wrote:
On Thu, Nov 25, 2010 at 02:01:31PM +0100, Marcel Loose wrote:
On 24-11-2010 at 17:45, in message
20101124164507.gg23...@cryptio.net, Tyler
Roscoe ty...@cryptio.net wrote:
On Wed, Nov 24, 2010 at 12:11:56PM +0100, Micha Renner wrote:
SET(CMAKE_INSTALL_PREFIX /foo/bar CACHE PATH Foo install
prefix)
So, without the test to
CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT,
and without the FORCE option.
No, as I mentioned, there was an article of one the
CMake-maintainers
who recommended this.
Micha is correct. CMAKE_INSTALL_PREFIX is set before your
CMakeLists.txt
is processed, so the above will never do anything.
tyler
Well, I tested this before I posted my reply. It does work the way I
describe it. Try it yourself.
It doesn't work for me:
[tyle...@tpb006:~/cmake-test-install-prefix]$ cmake --version
cmake version 2.8.3
[tyle...@tpb006:~/cmake-test-install-prefix]$ cat CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(p)
set (CMAKE_INSTALL_PREFIX foo CACHE PATH docstring)
message (CMAKE_INSTALL_PREFIX = ${CMAKE_INSTALL_PREFIX})
[tyle...@tpb006:~/cmake-test-install-prefix]$ mkdir b cd b cmake ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMAKE_INSTALL_PREFIX = /usr/local
-- Configuring done
-- Generating done
-- Build files have been written to:
/tpb006/tylermr/cmake-test-install-prefix/b
___
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] cmake PyQT/SIP
Greetings I an learnig cmake. I recently learned that to 'compile headers into _moc.cpp files in a cmake/qt4 project one had to use the QT4_WRAP_CPP() utility. I now have a similar need to transformheader files into .cpp files for PyQT4/SIP scripts. I would be grateful if someone could suggest what the relevent utility in cmake is and an example of its application. thanks in advance luxInteg ___ 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] FindMPI: finding openmpi libs and includes
Hi, I have built debug and release win32 and x64 openmpi libs for windows, and I have them installed on linux x64. How does FindMPI work for auto detecting If I don't set any MPI_ variable at all? Does it search for mpic++ in the %PATH% or $PATH? What MPI_ variables is the user required to define? regards, ___ 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] FindBoost: find both win32 and x64 static libs
As boost libraries naming convention doesn't include in the lib names whether they are built by msvc9 win32 or x64, I am forced on a winxp 64 box where I hold both versions to have a different lib directory under boost_root. I set BOOST_ROOT then call FIND_PACKAGE(Boost 1.44 COMPONENTS ...). Am I supposed to detect which of vc9 32bit or 64bit am I generating for and then set BOOST_LIBRARYDIR depending on that before calling FIND_PACKAGE? How do I detect bitness? ___ 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] FindMPI: finding openmpi libs and includes
It will search standard locations (/usr/include /usr/lib) for the headers and libs. Set MPI_LIBRARY and MPI_INCLUDE_PATH if it doesn't locate them for you automatically. The FindMPI module does interrogate the mpicc compiler for some of this information but I am not sure if that is the case on Windows. On Tue, Nov 30, 2010 at 5:26 PM, Hicham Mouline hic...@mouline.org wrote: Hi, I have built debug and release win32 and x64 openmpi libs for windows, and I have them installed on linux x64. How does FindMPI work for auto detecting If I don't set any MPI_ variable at all? Does it search for mpic++ in the %PATH% or $PATH? What MPI_ variables is the user required to define? regards, ___ 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] Problems to find xmlrpc_server_abyss++.so on FreeBSD
On 11/30/2010 12:27 AM, Renato Botelho wrote:
On Mon, Nov 29, 2010 at 9:20 PM, Renato Botelho rbga...@gmail.com wrote:
Hi,
It's the first project i'm migrating from autotools to cmake,
and it's going really well, in 4 days it's almost done. \o/
The only issue I have now is following, i have this code
on my CMakeLists.txt:
find_package (XMLRPC REQUIRED abyss-server c++2)
It's always the same, one entire day trying to figure it out and
5 seconds after sending this email i found, i just changed the
order of components (c++2 abyss-server) and it detected my
xmlrpc fine. It's fixed now. The other problem below still persists.
Ah, since i'm talking about FindXMLRPC, I used REQUIRED
param, like i showed above, but if it doesn't find xmlrpc
it shows an error message but don't stop, i needed to add
this:
if (NOT XMLRPC_FOUND)
message (FATAL_ERROR XMLRPC-C not found)
endif (NOT XMLRPC_FOUND)
Is it the expected behavior?
It persists
AFAICS, this is due to the last code snippet in FindXMLRPC.cmake:
# Report the results.
IF(NOT XMLRPC_FOUND)
SET(XMLRPC_DIR_MESSAGE
XMLRPC was not found. Make sure the entries XMLRPC_* are set.)
IF(NOT XMLRPC_FIND_QUIETLY)
MESSAGE(STATUS ${XMLRPC_DIR_MESSAGE})
ELSE(NOT XMLRPC_FIND_QUIETLY)
IF(XMLRPC_FIND_REQUIRED)
MESSAGE(FATAL_ERROR ${XMLRPC_DIR_MESSAGE})
ENDIF(XMLRPC_FIND_REQUIRED)
ENDIF(NOT XMLRPC_FIND_QUIETLY)
ENDIF(NOT XMLRPC_FOUND)
If XMLRPC_FOUND is FALSE the MESSAGE(FATAL_ERROR ...) is emitted only
if XMLRPC_FIND_REQUIRED is TRUE - that's OK - and XMLRPC_FIND_QUIETLY
is TRUE also - which is wrong. IMO, the REQUIRED flag must absolutely
take precedence over the QUIET flag, e.g.:
IF(NOT XMLRPC_FOUND)
IF(XMLRPC_FIND_REQUIRED)
MESSAGE(FATAL_ERROR ...)
ELSEIF(NOT XMLRPC_FIND_QUIETLY)
MESSAGE(STATUS ...)
ENDIF()
ENDIF()
This is the pattern used by FIND_PACKAGE_HANDLE_STANDARD_ARGS(), too.
As it's done currently in FindXMLRPC.cmake, you must enable REQUIRED
*and* QUIET to make the find module bail out *with* a message if the
package hasn't been found.
As a general interpretation of the REQUIRED flag, the user does not
want to check whether the package has been found if FIND_PACKAGE()
returns, or vice versa: If there is any need to check whether the
requested stuff is actually present, the REQUIRED flag is useless.
In particular, this should apply also to the components of multi-
component packages.
Feel encouraged to file a bug report.
Regards,
Michael
___
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] Linking archives in a sibling directory
Hi all,
I'm having a problem understanding how I can link to an archive in
another directory which is not a subdirectory. For example:
myproj
+-- main
+-- CMakeLists.txt
+-- source files for main program
+-- dir-A
+-- CMakeLists.txt
+-- source files for sub-program A
+-- dir-B
+-- CmakeLists.txt
+-- source files for sub-program B
Basically, I would like to make a larger project (main) and I'm
building and testing each of its components separately.
Right now, the main's CMakeLists.txt looks something like this:
INCLUDE_DIRECTORIES (../dir-A)
SUBDIRS (../dir-A)
ADD_EXECUTABLE (main ${MAIN_SRCS})
TARGET_LINK_LIBRARIES (main subprogA_ar)
which works fine so far (the CMakeLists.txt in dir-A generates the
archive subprogA_ar).
However, I just found out that SUBDIRS is deprecated and so, replaced
it with ADD_SUBDIRECTORY. That's when I got an error about dir-A
not being a subdirectory. Obviously, I was not using SUBDIRS before
as it was intended... :-)
I've also tried adding dir-A as a LINK_DIRECTORIES with no success.
It is unable to find subprogA_ar.
I'm not sure if it is possible, but ideally, when I run make in
main/, I would like it to rebuild the targets in dir-A (including
the archive) and link that in.
I'm also open to the possibility that I got the above organization all
wrong and should have only one large CMakeLists.txt in a directory
structure like this:
myproj
+-- main
+-- CMakeLists.txt
+-- source files for main program
+-- dir-A
+-- source files for sub-program A
+-- dir-B
+-- source files for sub-program B
Is this what I should have done??
Thank you!
Ray
___
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] win32 and win64 on same box: CMAKE_SYSTEM_PREFIX_PATH
on win64 boxes, typically, 32bit binaries are under \Program Files (x86) and 64bit are under \Program Files It would be good if CMAKE_SYSTEM_PREFIX_PATH for e.g., and other similar paths, were set to the appropriate On win32 boxes: . If msvc = \program files . If msvc win64 (cross compiler) = ? nothing On win64 boxes: . If msvc (cross compiler) = \program files (x86) . If msvc win64 = \program files In the mean time, the doc says this is not intended to be modified by the project, but in this case, do I do right at the beginning of the cmake lists file? rds, ___ 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, next, updated. v2.8.3-714-g2b9f0dc
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 2b9f0dc4c869a63af7eac1326e79b3c35198b624 (commit) via 63828762a0a716871141552c2b7dc53a93718156 (commit) from 2703aa2f6c2fea451e0d98915f02014ff6b86f4c (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=2b9f0dc4c869a63af7eac1326e79b3c35198b624 commit 2b9f0dc4c869a63af7eac1326e79b3c35198b624 Merge: 2703aa2 6382876 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Nov 30 08:14:46 2010 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Nov 30 08:14:46 2010 -0500 Merge branch 'master' into next --- Summary of changes: Source/kwsys/kwsysDateStamp.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
[Cmake-commits] CMake branch, next, updated. v2.8.3-716-g1c5f993
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 1c5f9938acb4876fd182dc0fcece860f9793f907 (commit)
via 183d261b116decd6ab09a7d1a522a9ad4add47b4 (commit)
from 2b9f0dc4c869a63af7eac1326e79b3c35198b624 (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=1c5f9938acb4876fd182dc0fcece860f9793f907
commit 1c5f9938acb4876fd182dc0fcece860f9793f907
Merge: 2b9f0dc 183d261
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Nov 30 08:45:31 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Nov 30 08:45:31 2010 -0500
Merge topic 'find-command-crash' into next
183d261 Fix find_* argument parsing crash (#11513)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=183d261b116decd6ab09a7d1a522a9ad4add47b4
commit 183d261b116decd6ab09a7d1a522a9ad4add47b4
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Nov 30 08:39:16 2010 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Nov 30 08:39:16 2010 -0500
Fix find_* argument parsing crash (#11513)
Previously the command
find_path(VAR DOC )
would crash because the argument pre-processing removed the DOC
arguments but the rest of the parsing assumes at least 2 arguments.
Reject the call with an error instead.
diff --git a/Source/cmFindBase.cxx b/Source/cmFindBase.cxx
index 0416538..d0fe99f 100644
--- a/Source/cmFindBase.cxx
+++ b/Source/cmFindBase.cxx
@@ -164,6 +164,11 @@ bool cmFindBase::ParseArguments(std::vectorstd::string
const argsIn)
}
}
}
+ if(args.size() 2 )
+{
+this-SetError(called with incorrect number of arguments);
+return false;
+}
this-VariableName = args[0];
if(this-CheckForVariableInCache())
{
---
Summary of changes:
Source/cmFindBase.cxx |5 +
1 files changed, 5 insertions(+), 0 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. v2.8.3-138-g8b555d1
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 8b555d1d208b8bbc2f4c3ddbcd33fb8e716de058 (commit) from 63828762a0a716871141552c2b7dc53a93718156 (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=8b555d1d208b8bbc2f4c3ddbcd33fb8e716de058 commit 8b555d1d208b8bbc2f4c3ddbcd33fb8e716de058 Author: KWSys Robot kwro...@kitware.com AuthorDate: Wed Dec 1 00:01:04 2010 -0500 Commit: KWSys Robot kwro...@kitware.com CommitDate: Wed Dec 1 00:10:03 2010 -0500 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 8137bea..92e85f2 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -15,7 +15,7 @@ SET(KWSYS_DATE_STAMP_YEAR 2010) # KWSys version date month component. Format is MM. -SET(KWSYS_DATE_STAMP_MONTH 11) +SET(KWSYS_DATE_STAMP_MONTH 12) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 30) +SET(KWSYS_DATE_STAMP_DAY 01) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
