[cmake-developers] [CMake 0014490]: Wrong Windows SDK location detected
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14490 == Reported By:Domagoj Saric Assigned To: == Project:CMake Issue ID: 14490 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2013-10-17 08:39 EDT Last Modified: 2013-10-17 08:39 EDT == Summary:Wrong Windows SDK location detected Description: I use Visual Studio 2010 Express with SP1 and I installed the Windows SDK 7.1 into a non default/'standard' location (D:/3rdParty/WindowsSDK/7.1) yet CMake reports: Found Windows SDK v7.1: C:\Program Files\Microsoft SDKs\Windows\v7.1\ and then fails with: CMake Error at C:/Program Files (x86)/CMake/share/cmake-2.8/Modules/CMakeDetermineCompilerId.cmake:446 (execute_process): execute_process given COMMAND argument with no value. Call Stack (most recent call first): C:/Program Files (x86)/CMake/share/cmake-2.8/Modules/CMakeDetermineCompilerId.cmake:48 (CMAKE_DETERMINE_COMPILER_ID_VENDOR) C:/Program Files (x86)/CMake/share/cmake-2.8/Modules/CMakeDetermineCXXCompiler.cmake:127 (CMAKE_DETERMINE_COMPILER_ID) CMakeLists.txt:62 (project) ps. even if I did install it into the default location, the detected/reported location would still be wrong because it point to the 64 bit Program Files (whereas the SDK installs into the x86 version) pps. I tried to solve the problem with directory symlinks but it did not help... == Issue History Date ModifiedUsername FieldChange == 2013-10-17 08:39 Domagoj Saric New Issue == -- 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] C++11 and target_compiler_feature proposal
Stephen Kelly wrote:
I'll try to get a reviewable and first-feature-complete infrastructure
branch together soon.
I've pushed a first iteration of the target_compiler_features branch to my
clone.
For the language specification, I added a prefix to each feature. This
matches the feature tests of clang for standard features, and it is
extensible to extensions with gnuxx_typeof, msvc_sealed etc.
http://clang.llvm.org/docs/LanguageExtensions.html
So far, it only supports the REQUIRED signature of the command.
It will need to get a PUBLIC|PRIVATE specifier, so that the
INTERFACE_COMPILER_FEATURES property can be populated in PUBLIC mode. It
also needs to learn to process generator expressions and how to consume that
property.
Optional features with defines are not yet implemented. I was considering
renaming target_compiler_features to target_required_features and not using
the same command for optional features. Instead I think it might be a good
idea to have a separate command for optional features. Something like:
write_compiler_feature_file(
FILENAME ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_features.h
FEATURES cxx_static_assert gnuxx_typeof cxx_variadic_templates
)
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_features.h
DESTINATION include
)
which writes the file with appropriate content. I don't see any need to use
preprocessor macros for that instead of a file.
I also prototyped a simple way to test clang features as reportedly
supported by clang itself. This won't get us all of the way there with
clang, as some features (such as the gnu typeof extension) do not have
support via __has_extension.
Additionally, I changed my mind on the issue of whether to bump the dialect
to c++11 if the compiler supports the requested feature in c++98 mode. For
example, cxx_variadic_templates would be in CMAKE_CXX98_COMPILER_FEATURES
for GCC and clang, because both support variadic templates even when using
the -std=c++98 dialect. This will still warn, but that's ok, I think.
Note that adding -std=c++11 is almost, but not quite, entirely source
compatible.
For example, this will work with c++98, but errors with c++11:
#define add_prefix(suf) pre_suf
add_prefix(_end);
The feature can be extended for the C standard (89, 99, 11) features too as
well as extensions.
Any comments so far?
Thanks,
Steve.
--
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
[cmake-developers] [CMake 0014491]: file(GLOB) and file(GLOB_RECURSE) indeterministic
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14491
==
Reported By:ingolf
Assigned To:
==
Project:CMake
Issue ID: 14491
Category: (No Category)
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2013-10-17 11:02 EDT
Last Modified: 2013-10-17 11:02 EDT
==
Summary:file(GLOB) and file(GLOB_RECURSE) indeterministic
Description:
file(GLOB) and file(GLOB_RECURSE) have indeterministic behavior. Apparently, the
ordering of the files which match the specified pattern depends on the sequence
in which files are delivered by the file system.
While this might be on purpose, this should at least be clearly documented --
together with a proposal to use list(SORT) afterwards if a fixed ordering is
desired.
Nevertheless, I would expect the cmake output to be reproducible when all the
files involved in the project (including the cmake tool itself) as well as the
user environment variables have the same content.
Steps to Reproduce:
Create an empty project directory with the following contents (all files can be
empty):
./f1.abx
./folder1/8764gh.abb
./folder1/q.ab0
./folder1/z.ab_
./folder2/.abz
./folder2/__.abd
./folder2/bea7.96.abc
./folder2/xcx.abcd
./fsbi213.ab
./z.ab5
Then use the following CMakeLists.txt:
88888888
cmake_minimum_required(VERSION 2.8)
file(GLOB FILES_LOCAL RELATIVE ${CMAKE_SOURCE_DIR} *.ab?)
message(STATUS Non-recursive: ${FILES_LOCAL})
file(GLOB_RECURSE FILES_RECURSE RELATIVE ${CMAKE_SOURCE_DIR} *.ab?)
message(STATUS Recursive: ${FILES_RECURSE})
88888888
On the same machine (with the same user environment), CMake might output
-- Non-recursive: z.ab5;f1.abx
-- Recursive:
z.ab5;folder1/8764gh.abb;folder1/q.ab0;folder1/z.ab_;f1.abx;folder2/.abz;folder2/bea7.96.abc;folder2/__.abd
when run in one folder and
-- Non-recursive: f1.abx;z.ab5
-- Recursive:
f1.abx;folder2/__.abd;folder2/.abz;folder2/bea7.96.abc;folder1/z.ab_;folder1/q.ab0;folder1/8764gh.abb;z.ab5
when run in another folder.
==
Issue History
Date ModifiedUsername FieldChange
==
2013-10-17 11:02 ingolf New Issue
==
--
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] Documentation or parse bug
On 10/16/2013 02:40 PM, James Bigler wrote: The documentation for target_link_libraries has this description: target_link_libraries(target LINK_PRIVATE|LINK_PUBLIC [[debug|optimized|general] lib] ... [LINK_PRIVATE|LINK_PUBLIC [[debug|optimized|general] lib] ...]) From my understanding I should be able to do this: target_link_libraries(target LINK_PRIVATE lib1 LINK_PRIVATE lib2) however CMake 2.8.11.2 returns: CMake Error at prime/CMakeLists.txt:128 (target_link_libraries): The LINK_PUBLIC or LINK_PRIVATE option must appear as the second argument, just after the target name. Steve, I think this is a parsing problem here: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTargetLinkLibrariesCommand.cxx;hb=v2.8.12#l151 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTargetLinkLibrariesCommand.cxx;hb=v2.8.12#l181 It should allow LINK_PUBLIC to occur after another LINK_PUBLIC, and LINK_PRIVATE to occur after another LINK_PRIVATE. Currently it requires that they alternate. Thew newer PUBLIC/PRIVATE/INTERFACE options allow any order and repeats. Thanks, -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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Hi Steve,
Thanks for working on this!
On 10/17/2013 10:28 AM, Stephen Kelly wrote:
For the language specification, I added a prefix to each feature. This
matches the feature tests of clang for standard features, and it is
extensible to extensions with gnuxx_typeof, msvc_sealed etc.
http://clang.llvm.org/docs/LanguageExtensions.html
Good idea.
So far, it only supports the REQUIRED signature of the command.
It will need to get a PUBLIC|PRIVATE specifier, so that the
INTERFACE_COMPILER_FEATURES property can be populated in PUBLIC mode. It
also needs to learn to process generator expressions and how to consume that
property.
Yes.
Optional features with defines are not yet implemented. I was considering
renaming target_compiler_features to target_required_features
I think target_compiler_features is a clearer name even if it only
supports required features. Please leave room in the signature for
future expansion to optional features just in case.
and not using the same command for optional features. Instead I think
it might be a good idea to have a separate command for optional features.
FWIW, I thought he optional features with macros was quite elegant.
Also that approach didn't require header generation, right? I have
no strong opinion on which approach is better, but here are some
comments.
What is an example use case for optional features? What if a header
file selects an available optional feature when included by a .cxx
in the package's libraries, but not when it is later included by an
application? Might that generate an ABI mismatch?
write_compiler_feature_file(
FILENAME ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_features.h
FEATURES cxx_static_assert gnuxx_typeof cxx_variadic_templates
)
IIUC this header will contain hard-coded preprocessor tests and present
the results in preprocessor symbols testable by the project. Shouldn't
it take some kind of namespace prefix for those names? Also this may
need the VERSION interface number previously discussed.
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_features.h
DESTINATION include
)
If the header is not in the public interface it need not be installed either.
which writes the file with appropriate content. I don't see any need to use
preprocessor macros for that instead of a file.
That will also simplify consuming an interface without CMake because no
magic addition of preprocessor definitions will be needed.
I also prototyped a simple way to test clang features as reportedly
supported by clang itself. This won't get us all of the way there with
clang, as some features (such as the gnu typeof extension) do not have
support via __has_extension.
Neat. I see no reason Modules/FeatureTests/clang_feature_tests.cxx
can't be just Modules/Compiler/clang_feature_tests.cxx. For those
features not covered by __has_extension we can list them explicitly.
You'll also have to deal with cases when CMAKE_CXX_COMPILER is not
set. It should always be set at this point but we need to fail with
a readable explanation if it is not.
Additionally, I changed my mind on the issue of whether to bump the dialect
to c++11 if the compiler supports the requested feature in c++98 mode. For
example, cxx_variadic_templates would be in CMAKE_CXX98_COMPILER_FEATURES
for GCC and clang, because both support variadic templates even when using
the -std=c++98 dialect. This will still warn, but that's ok, I think.
Note that adding -std=c++11 is almost, but not quite, entirely source
compatible.
Okay.
Any comments so far?
Should we memoize the language feature lists as std::set at the end of
cmGlobalGenerator::EnableLanguage to make lookup faster and avoid projects
corrupting the lists?
Thanks,
-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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Documentation or parse bug
Brad King wrote: On 10/16/2013 02:40 PM, James Bigler wrote: The documentation for target_link_libraries has this description: target_link_libraries(target LINK_PRIVATE|LINK_PUBLIC [[debug|optimized|general] lib] ... [LINK_PRIVATE|LINK_PUBLIC [[debug|optimized|general] lib] ...]) From my understanding I should be able to do this: target_link_libraries(target LINK_PRIVATE lib1 LINK_PRIVATE lib2) however CMake 2.8.11.2 returns: CMake Error at prime/CMakeLists.txt:128 (target_link_libraries): The LINK_PUBLIC or LINK_PRIVATE option must appear as the second argument, just after the target name. Steve, I think this is a parsing problem here: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTargetLinkLibrariesCommand.cxx;hb=v2.8.12#l151 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTargetLinkLibrariesCommand.cxx;hb=v2.8.12#l181 It should allow LINK_PUBLIC to occur after another LINK_PUBLIC, and LINK_PRIVATE to occur after another LINK_PRIVATE. Currently it requires that they alternate. Thew newer PUBLIC/PRIVATE/INTERFACE options allow any order and repeats. I pushed the allow-repeated-LINK-keywords to fix this. Thanks, Steve. -- 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] C++11 and target_compiler_feature proposal
Brad King wrote:
Optional features with defines are not yet implemented. I was considering
renaming target_compiler_features to target_required_features
I think target_compiler_features is a clearer name even if it only
supports required features. Please leave room in the signature for
future expansion to optional features just in case.
Ok. When PUBLIC|PRIVATE is part of it, that will be easy even if I remove
REQUIRED.
and not using the same command for optional features. Instead I think
it might be a good idea to have a separate command for optional features.
FWIW, I thought he optional features with macros was quite elegant.
Also that approach didn't require header generation, right?
Correct.
I have
no strong opinion on which approach is better, but here are some
comments.
What is an example use case for optional features?
Adding a move constructor to a class. Many Qt classes have move constructors
and they are inline and bounded by a define.
Another: Define Foo_OVERRIDE to either 'override' or nothing, depending on
the using compiler capability.
What if a header
file selects an available optional feature when included by a .cxx
in the package's libraries, but not when it is later included by an
application? Might that generate an ABI mismatch?
As far as I know, no. Things like r-value references, variadic templates etc
would just be unavailable to the caller if not using a capable compiler.
Things like final and override are not encoded into the ABI afaik. At least
that seems to be the assumption Qt makes.
write_compiler_feature_file(
FILENAME ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_features.h
FEATURES cxx_static_assert gnuxx_typeof cxx_variadic_templates
)
IIUC this header will contain hard-coded preprocessor tests and present
the results in preprocessor symbols testable by the project. Shouldn't
it take some kind of namespace prefix for those names? Also this may
need the VERSION interface number previously discussed.
Oops, yes, you're right on both counts. I didn't re-read the previous thread
before writing the above.
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_features.h
DESTINATION include
)
If the header is not in the public interface it need not be installed
either.
If the intention is to define Grantlee_OVERRIDE to either 'override' or
nothing depending on the compiler capability, and to use classes using that
define in the interface, then it does have to be installed.
which writes the file with appropriate content. I don't see any need to
use preprocessor macros for that instead of a file.
That will also simplify consuming an interface without CMake because no
magic addition of preprocessor definitions will be needed.
Yes.
I also prototyped a simple way to test clang features as reportedly
supported by clang itself. This won't get us all of the way there with
clang, as some features (such as the gnu typeof extension) do not have
support via __has_extension.
Neat. I see no reason Modules/FeatureTests/clang_feature_tests.cxx
can't be just Modules/Compiler/clang_feature_tests.cxx. For those
features not covered by __has_extension we can list them explicitly.
You'll also have to deal with cases when CMAKE_CXX_COMPILER is not
set. It should always be set at this point but we need to fail with
a readable explanation if it is not.
Ok.
Any comments so far?
Should we memoize the language feature lists as std::set at the end of
cmGlobalGenerator::EnableLanguage to make lookup faster and avoid projects
corrupting the lists?
I'm not sure. We might not list a feature which a compiler has, either
because the compiler release is newer than the cmake release, or because the
compiler is unknown to us.
In that case, being able to use
list(APPEND CMAKE_CXX_COMPILER_FEATURES cxx_variadic_templates)
would be useful.
Thanks,
Steve.
--
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] Perforce Patch for CTest
Ok, I have the patch working and I'm going to send it soon. One question, is it possible to launch a detached process from within CMake? If I use EXECUTE_PROCESS to start p4d, CMake waits for it to finish so -for now- I'm launching the Perforce daemon outside CMake. Pedro On Wed, Oct 16, 2013 at 1:10 PM, Brad King brad.k...@kitware.com wrote: On 10/16/2013 03:11 PM, Pedro Navarro wrote: I was thinking that as the test requires the p4 tool to be installed, we might as well require also p4d (the server, which is now free for up to 20 users). In that case the test can bring up a local server and work against it which, in the end, will create less issues as the p4 database will be deleted when the test ends. If we work against a real production server we might not be able to use p4 obliterate and we will be leaving those temporary checkins the test does polluting the history, and that might not be desired. We definitely need the test to run against a fresh repository each time. The other VCS tool tests all create local repos from scratch when they run. Whatever you need to require to achieve this with P4 is acceptable. Thanks, -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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Perforce Patch for CTest
On 10/17/2013 1:52 PM, Pedro Navarro wrote: Ok, I have the patch working and I'm going to send it soon. One question, is it possible to launch a detached process from within CMake? If I use EXECUTE_PROCESS to start p4d, CMake waits for it to finish so -for now- I'm launching the Perforce daemon outside CMake. Pedro It is not possible to do this. One work around is to put the start of the process in a shell script or bat file that is used to run the ctest script which is basically what you are doing. :) -Bill -- 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] Perforce Patch for CTest
On 10/17/2013 02:18 PM, Bill Hoffman wrote: On 10/17/2013 1:52 PM, Pedro Navarro wrote: Ok, I have the patch working and I'm going to send it soon. One question, is it possible to launch a detached process from within CMake? If I use EXECUTE_PROCESS to start p4d, CMake waits for it to finish so -for now- I'm launching the Perforce daemon outside CMake. It is not possible to do this. One work around is to put the start of the process in a shell script or bat file that is used to run the ctest script which is basically what you are doing. :) If this is restricted to a UNIX-like environment one can use a shell script that internally executes a background job, e.g. execute_process(COMMAND sh -c nohup p4d /dev/null 21 ) Actually the internal KWSys Process library used to implement the execute_process command does know how to create and disown daemon processes. If necessary one could teach execute_process options to trigger this behavior. In either case there is no clear way to terminate the daemon when the test is done. -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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Perforce Patch for CTest
I experimented with nohup but from inside a shell script that was being executed from execute_process, but that didn't work. I'll give that a try, thanks! There happens to be a way to cleanly shutdown perforce, executing p4 admin stop, so this could mean that we can start p4d if it's present and on Unix and exit and remote the database when the test finishes, which would be the preferred approach. Pedro On Thu, Oct 17, 2013 at 11:44 AM, Brad King brad.k...@kitware.com wrote: On 10/17/2013 02:18 PM, Bill Hoffman wrote: On 10/17/2013 1:52 PM, Pedro Navarro wrote: Ok, I have the patch working and I'm going to send it soon. One question, is it possible to launch a detached process from within CMake? If I use EXECUTE_PROCESS to start p4d, CMake waits for it to finish so -for now- I'm launching the Perforce daemon outside CMake. It is not possible to do this. One work around is to put the start of the process in a shell script or bat file that is used to run the ctest script which is basically what you are doing. :) If this is restricted to a UNIX-like environment one can use a shell script that internally executes a background job, e.g. execute_process(COMMAND sh -c nohup p4d /dev/null 21 ) Actually the internal KWSys Process library used to implement the execute_process command does know how to create and disown daemon processes. If necessary one could teach execute_process options to trigger this behavior. In either case there is no clear way to terminate the daemon when the test is done. -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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Perforce Patch for CTest
On 10/17/2013 03:23 PM, Pedro Navarro wrote: I experimented with nohup but from inside a shell script that was being executed from execute_process, but that didn't work. You also need to disconnect the stdout/stderr pipes by redirecting them to /dev/null. Then execute_process can fully let go because the pipes it uses to communicate with the child will be closed when the shell exits. -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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --find-package (was: Roadmap to CMake 3.0)
On 10/17/2013 04:58 PM, Alexander Neundorf wrote: Yes, that was the idea, but I can't rely anymore on a Foo_LIBRARIES variable (or a slight variation) being set after a successful find_package(Foo): http://lists.kde.org/?l=kde-core-develm=138198795723680w=2 I.e. in the future there will be Find-modules which typically export one of (Foo|FOO)_(LIBRARIES|LIBRARY), some Config.cmake files which do that too, and a big number, probably majority, of Config.cmake files, which do not export such variables. The only chance I see would be to simply collect all library targets and return what they provide, but this doesn't feel good. I would have much prefered using a clear interface like the Foo_LIBRARIES variable. Perhaps we need to establish a convention for find modules and package configuration files to interact with --find-package mode. I have no thoughts on the specifics of how that would work though. -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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --find-package (was: Roadmap to CMake 3.0)
Brad King wrote: On 10/17/2013 04:58 PM, Alexander Neundorf wrote: Yes, that was the idea, but I can't rely anymore on a Foo_LIBRARIES variable (or a slight variation) being set after a successful find_package(Foo): http://lists.kde.org/?l=kde-core-develm=138198795723680w=2 I.e. in the future there will be Find-modules which typically export one of (Foo|FOO)_(LIBRARIES|LIBRARY), some Config.cmake files which do that too, and a big number, probably majority, of Config.cmake files, which do not export such variables. The only chance I see would be to simply collect all library targets and return what they provide, but this doesn't feel good. I would have much prefered using a clear interface like the Foo_LIBRARIES variable. Perhaps we need to establish a convention for find modules and package configuration files to interact with --find-package mode. I have no thoughts on the specifics of how that would work though. A new, similar --find-target mode or similar may be more appropriate: cmake --find-target --package Qt5Widgets --target Qt5::Widgets ... # KF5Config exports 3 independent targets: cmake --find-target --package KF5Config --target KF5::ConfigCore ... cmake --find-target --package KF5Config --target KF5::ConfigGui ... cmake --find-target --package KF5Config --target KF5::ConfigWidgets ... Thanks, Steve. -- 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] CTest: Request review of topic ctest-fix-run-serial
On 10/17/2013 4:41 PM, Nils Gladitz wrote: I pushed my topic ctest-fix-run-serial to stage. I am taking a look. It has been a long time since I looked at this code. However, it seems like your patch removes the running of dependent tests. old code did this: StartTest(int test) ... foreach d in depend tests of test startTests New code removes that. I guess it depends on SortedTests having taken depends into consideration, which I am not seeing. However, I might be missing something What was your thinking on this? -Bill -- 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] Perforce Patch for CTest
On 10/17/2013 4:59 PM, Brad King wrote: As I explained in a sibling response the KWSys Process library has support for creating detached processes. It should only be a matter of exposing that through execute_process command options. +1, this does come up a lot. It would be good to have this exposed in the API. -Bill -- 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] CTest: Request review of topic ctest-fix-run-serial
Hello Bill, thanks for looking into this! All four tests in my example are still run (as you can see in the test output I provided). This includes the dependent test. What I did change is that all tests (from an dependency or otherwise) are run from StartNextTests() which ensures that serial tests run alone rather than from StartTest() which did not seem to account for this. Nils On 17.10.2013 23:19, Bill Hoffman wrote: On 10/17/2013 4:41 PM, Nils Gladitz wrote: I pushed my topic ctest-fix-run-serial to stage. I am taking a look. It has been a long time since I looked at this code. However, it seems like your patch removes the running of dependent tests. old code did this: StartTest(int test) ... foreach d in depend tests of test startTests New code removes that. I guess it depends on SortedTests having taken depends into consideration, which I am not seeing. However, I might be missing something What was your thinking on this? -Bill -- 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 -- 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] CTest: Request review of topic ctest-fix-run-serial
On Thu, Oct 17, 2013 at 5:31 PM, Nils Gladitz nilsglad...@gmail.com wrote: Hello Bill, thanks for looking into this! All four tests in my example are still run (as you can see in the test output I provided). This includes the dependent test. What I did change is that all tests (from an dependency or otherwise) are run from StartNextTests() which ensures that serial tests run alone rather than from StartTest() which did not seem to account for this. I am not saying it won't run all of the tests. I am saying there is a danger it will ignore the depends with your change and run a depend before the test that depends on it. I don't see it using the depends in the sort. Maybe a better fix would be to make sure the sort takes the depends into consideration. Or, just change the depend starting in StartTest to make sure it does not start a serial test with another test running. -Bill -- 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] CTest: Request review of topic ctest-fix-run-serial
StartTest() returns false without running the test if there are any dependencies remaining. Nils On 17.10.2013 23:57, Bill Hoffman wrote: On Thu, Oct 17, 2013 at 5:31 PM, Nils Gladitz nilsglad...@gmail.com mailto:nilsglad...@gmail.com wrote: Hello Bill, thanks for looking into this! All four tests in my example are still run (as you can see in the test output I provided). This includes the dependent test. What I did change is that all tests (from an dependency or otherwise) are run from StartNextTests() which ensures that serial tests run alone rather than from StartTest() which did not seem to account for this. I am not saying it won't run all of the tests. I am saying there is a danger it will ignore the depends with your change and run a depend before the test that depends on it. I don't see it using the depends in the sort. Maybe a better fix would be to make sure the sort takes the depends into consideration. Or, just change the depend starting in StartTest to make sure it does not start a serial test with another test running. -Bill -- 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] Perforce Patch for CTest
On 2013-10-17 16:59, Brad King wrote: On 10/17/2013 04:56 PM, Rolf Eike Beer wrote: We should think if this should be something that is needed. Running some sort of background process is a common pattern for all sorts of tests. Often really detaching is not needed, It is usually sufficient to have one process running in the background while the tests runs. As I explained in a sibling response the KWSys Process library has support for creating detached processes. It should only be a matter of exposing that through execute_process command options. Probably not a bad idea. Does KWSys get the resulting PID? If yes, it might be good to have a way to pass that back into CMake in order to also add a kill_process command at the same time in order to have a general way to stop processes launched in the background. (And/or a wait_process, etc.) Something to keep in mind... -- Matthew -- 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
