Re: [cmake-developers] Run program/command before test

[Roman Wüger]

Ok thanks

Would it be an opinion to have a COMMAND parameter for the add_test function 
like execute_process where every COMMAND must return the exit code and this 
would be ored?

add_test(MyTest COMMAND myserver --port 80
  COMMAND mytest 
  COMMAND myserver --graceful-shutdown)

Or

add_test(MyTest PRE_COMMAND myserver --port 80
  COMMAND mytest 
  POST_COMMAND myserver --graceful-shutdown)

Best Regards
Roman

> Am 16.02.2016 um 16:49 schrieb Brad King :
> 
>> On 02/16/2016 07:17 AM, Roman Wüger wrote:
>> Is it possible with CMake >= 3.4.0 to run a program/command before the
>> test and another program after the test was run?
>> 
>> The meaning of that would be, that I want to start a small server
>> program and run the "client" test. After the test was finished,
>> kill the process of the server program or do a graceful shutdown of it.
> 
> There is currently no builtin feature for that.  Other than a few
> test output matching properties, ctest always expects the process
> to be independent and report results via its exit code.
> 
> -Brad
> 
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0015977]: include_directories() gags on ".." embedded in directory path

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15977 
== 
Reported By:Richard Lang
Assigned To:
== 
Project:CMake
Issue ID:   15977
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-02-16 20:28 EST
Last Modified:  2016-02-16 20:28 EST
== 
Summary:include_directories() gags on ".." embedded in
directory path
Description: 
Working on port of collection of existing projects from proprietary toolchain to
cmake, where some source and include files reside in sibling/common ancestor
folders of of the project folders


   |-- SharedSource
   ||--SharedSource1.c
   ||--SharedSource2.c
   |+--SharedSource1.h
   +-- Project1 
   ||--Project1.c
   |+--MakeLists.txt
   +-- Project2
|--Project2.c
+--MakeLists.txt

Using Windows native cmake v3.4.1 I can quite happily specify "SharedSource" as
an include directory in my project cmake scripts using a "../' parent directory
relative reference as follows:


  ...
  include_directories(../SharedSource)
  ...

however when I try and run the same script using cmake within the cygwin & MSYS2
UNIX emulation environments it fails with a "Found relative path while
evaluating include directories" message.

The problem still occurs when I explicitly prepend CMAKE_CURRENT_SOURCE_DIR on
the path, as follows

  include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../SharedSource)  

The cygwin cmake version is 3.3.1, while the MSYS2 one is 3.2.3, and probably
reflects the current version in these environments, as I've installed them
pretty recently.

 

Additional Information: 
Don't currently have a native UNIX/linux environment to try this on.  I'm a UNIX
novice, but AFAIK "../SharedSource" should be a valid relative path on UNIX
platforms.

Can't see anything obvious in the bug tracker that would suggest that this has
been fixed between 3.3.1 and 3.4.1, suggesting it's maybe a platform
idiosyncrasy.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-02-16 20:28 Richard Lang   New Issue
==

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0015976]: cmSystemTools::RandomSeed() requests excessive entropy per invocation

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15976 
== 
Reported By:Cristian Rodríguez
Assigned To:
== 
Project:CMake
Issue ID:   15976
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-02-16 20:26 EST
Last Modified:  2016-02-16 20:26 EST
== 
Summary:cmSystemTools::RandomSeed() requests excessive
entropy per invocation
Description: 
cmSystemTools::RandomSeed() opens a *buffered* ifstream, the final result is
that each invocation requests  _IO_BUFSIZ -1 of entropy to the operating system
instead of just sizeof(seed)

Steps to Reproduce: 
mkdir test_cmake
echo "PROJECT(foo)" > CMakeLists.txt
cd test_cmake
strace -f -ocmake.trace cmake .

open cmake.trace 

10768 26289 open("/dev/urandom", O_RDONLY)= 4
10769 26289 read(4,
"h\304j\vx\314\26\0042\250g\275\0014,\256\251\257T&\304\212\310\347q\201\263\324\330\273z8"...,
8191) = 8191
10770 26289 close(4)  = 0
10771 26289 write(3, "cmake_minimum_required(VERSION 3"..., 795) = 795
10772 26289 close(3)  = 0
10773 26289 stat("/home/crrodriguez/test_cmake/CMakeFiles/CMakeTmp",
{st_mode=S_IFDIR|0755, st_size=58, ...}) = 0
10774 26289 getcwd("/home/crrodriguez/test_cmake", 2048) = 29

Additional Information: 
git diff
diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index 3ba7287..26bec34 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -2184,8 +2184,10 @@ unsigned int cmSystemTools::RandomSeed()
   } seed;
 
   // Try using a real random source.
-  cmsys::ifstream fin("/dev/urandom");
-  if(fin && fin.read(seed.bytes, sizeof(seed)) &&
+  cmsys::ifstream fin;
+  fin.rdbuf()->pubsetbuf(0, 0);
+  fin.open("/dev/urandom");
+  if(fin.good() && fin.read(seed.bytes, sizeof(seed)) &&
  fin.gcount() == sizeof(seed))
 {
 return seed.integer;

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-02-16 20:26 Cristian RodríguezNew Issue   

==

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Pssible documentation error in install(TARGETS ) signature

[Daniel Wirtz]

The current CMake version has an error in the Documentation (or a Bug in the 
Code, depending on how this turns out).
In https://cmake.org/cmake/help/v3.5/command/install.html#installing-targets,
the optional argument order is

[...]
[INCLUDES DESTINATION [ ...]]
[PERMISSIONS permissions...]
[CONFIGURATIONS [Debug|Release|...]]
[COMPONENT ]
[...]

if i use that in the order as documented, e.g.

install(TARGETS mytarget
EXPORT myexport
RUNTIME DESTINATION bin
COMPONENT Runtime
ARCHIVE DESTINATION lib
INCLUDES DESTINATION include
COMPONENT Runtime
),
the resulting cmake_install.cmake file will contain the install type 
"Unspecified" for my .lib archives (using windows)
i have to change the order of the arguments (using COMPONENT before INCLUDES 
DESTINATION):

install(TARGETS mytarget
EXPORT myexport
RUNTIME DESTINATION bin
COMPONENT Runtime
ARCHIVE DESTINATION lib
COMPONENT Runtime # Note swap here
INCLUDES DESTINATION include # Note swap here
)

then it correctly puts "Runtime" in the cmake_install.cmake file.
if the order of the arguments matters: update documentation?
if the order does not matter: could be a bug in the parser (two-element keyword 
INCLUDES DESTINATION?)?

any opinions welcome ..
Best,
Daniel

--
Dr. Daniel Wirtz
Dipl. Math. Dipl. Inf.
SRC SimTech
Pfaffenwaldring 5a, D-70569 Stuttgart
+49 (711) 685-60044

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH 2/2] FindwxWidgets.cmake: Resolve CygWin/MSYS paths to Windows paths

[Simon Richter]

Hi Brad.

On 16.02.2016 20:17, Brad King wrote:

> I've applied the change with minor tweaks and tried to explain this
> in the commit message:

Hm, only problem is patch attribution here -- I've written that these
are from Wayne, and should be attributed to him (but submitting these
with his name in the From: field obviously would not have worked).

Can this still be fixed?

   Simon




signature.asc
Description: OpenPGP digital signature
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Bugfix for CPack / CPACK_INSTALL_CMAKE_PROJECTS

[Daniel Wirtz]

Dear all,

i think i've encountered a bug where the fourth (=SubDirectory) entry of 
the CPACK_INSTALL_CMAKE_PROJECTS list is simply ignored.
I stumbled on this as i was trying to use something other than "/" for 
that part (Superbuild project with collecting CPack).


I've searched the source code and i think the bug is located at 
\Source\CPack\cmCPackGenerator.cxx:729: (Git Rev 
8dfb6f8b372b159c050b6ea5e16b4e44dd9ed095)


726: std::string realInstallDirectory = tempInstallDirectory;
727: if ( !installSubDirectory.empty() && installSubDirectory != "/" )
728: {
729: realInstallDirectory += installSubDirectory;
730:}

The variable "realInstallDirectory" is simply not used anymore within 
the entire CMake source after line 729.
I've changed this to "tempInstallDirectory" and the behaviour is as i 
expected it - works for me now.


The offending lines of code have been committed in 2006 with 
c09c3c6bfadb41bd0b43082642ce76abbf02df06 - i doubt that no one ever 
tried to use something other than "/" since then? Or is there something 
else i'm missing?


Best,
Daniel

--
Dr. Daniel Wirtz
Dipl. Math. Dipl. Inf.
SRC SimTech
Pfaffenwaldring 5a, D-70569 Stuttgart
+49 (711) 685-60044

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake Daemon blog

[Taylor Braun-Jones]

On Sat, Jan 30, 2016 at 2:06 AM, Stephen Kelly  wrote:
> I've just pushed the daemon code here:
>
>  https://github.com/steveire/cmake/tree/cmake-daemon
>
> The Kate plugin should soon appear here I think:
>
>  https://quickgit.kde.org/?p=scratch%2Fskelly%2Fcmakekate.git

Thanks for sharing, Stephen! Do you plan to also share the standalone
Qt-based editor/client as well (cmake-browser)? That would be
immediately useful to me and allow me to more easily test drive all
this work that you've done.

Cheers,
Taylor
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH 2/2] FindwxWidgets.cmake: Resolve CygWin/MSYS paths to Windows paths

[Greg Jung]

>
> A true MinGW wx-config should report Windows paths.


Good point, which is why modifying wx-config is done.
 MSYS/configure ... will build wx as if it knows nothing about
windows' paths and the wx-config output works as it should,
it is an MSYS weakness that fails in one aspect downstream
(I forget exactly what), the workaround is to make the paths
come out of wx-config in DOS format. Since this workaround
 wasn't implemented until the more recent msys2 package builds
(which are compiled with a different compiler - worse possible headaches),
Simon worked a cmake fix.  For my usage I've been editing wx-config.

On Tue, Feb 16, 2016 at 10:22 AM, Brad King  wrote:

> On 02/16/2016 01:16 PM, Greg Jung wrote:
> > Simon is working on MSYS2 for a mingw build.  The MSYS2-native CMake
> > is a different beast, and wouldn't be producing mingw programs.
>
> Okay, then why do we need to support a MSYS2-native `wx-config` tool?
> A true MinGW wx-config should report Windows paths.
>
> -Brad
>
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH 2/2] FindwxWidgets.cmake: Resolve CygWin/MSYS paths to Windows paths

[Brad King]

On 02/16/2016 01:16 PM, Greg Jung wrote:
> Simon is working on MSYS2 for a mingw build.  The MSYS2-native CMake
> is a different beast, and wouldn't be producing mingw programs.

Okay, then why do we need to support a MSYS2-native `wx-config` tool?
A true MinGW wx-config should report Windows paths.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH 2/2] FindwxWidgets.cmake: Resolve CygWin/MSYS paths to Windows paths

[Brad King]

On 02/16/2016 11:29 AM, Simon Richter wrote:
> The patched wx-config in MSYS2 invokes cygpath to resolve the Unix path
> they would otherwise return to a native path with forward slashes, so my
> expectation would be that it is guaranteed to exist on MSYS2.

How is it that a native-Windows CMake is able to execute the wx-config
tool?  If it is a CMake that is built with the MSYS2 runtime then it
should be able to understand the unix paths.

There has been discussion on cmake-developers before about having
a MSYS2-native CMake build much like the Cygwin-native build we
have already.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH 2/2] FindwxWidgets.cmake: Resolve CygWin/MSYS paths to Windows paths

[Simon Richter]

Hi,

Am 16.02.2016 um 16:49 schrieb Brad King:

> Thanks.  Is that utility guaranteed to exist?  IIRC the original MSYS
> intentionally did not include such a utility.

The patched wx-config in MSYS2 invokes cygpath to resolve the Unix path
they would otherwise return to a native path with forward slashes, so my
expectation would be that it is guaranteed to exist on MSYS2.

The patch falls back to doing nothing if the tool does not exist, so
older versions that don't patch wx-config should still work.

   Simon



signature.asc
Description: OpenPGP digital signature
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0015975]: GHS Multi Generator: COPY_FILE in try_compile does not work

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15975 
== 
Reported By:stw_sesa
Assigned To:
== 
Project:CMake
Issue ID:   15975
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2016-02-16 10:58 EST
Last Modified:  2016-02-16 10:58 EST
== 
Summary:GHS Multi Generator: COPY_FILE in try_compile does
not work
Description: 
try_compile COPY_FILE: The GHS MULTI Compiler compiles+links the executable to
"targetname.as", but the CMake Generator currently looks for "targetname"
(without extension). As a folder with such a name exists in the build directory
COPY_FILE copies the folder instead of the built executable and the try_compile
execution does not fail.



Steps to Reproduce: 
Create a simple CMakeLists.txt like this:

try_compile(
result
"${CMAKE_BINARY_DIR}/CMakeFiles/CMakeTmp" 
"${CMAKE_SOURCE_DIR}/test.c" 
COPY_FILE "${CMAKE_BINARY_DIR}/test_executable" 
)
message(STATUS "result of try_compile: " ${result})


Create a simple test program as "test.c":

int main(int argc, char *argv[])
{
return 0;
}

Run CMake using GHS MULTI Generator (ARM Integrity).

Actual result:
try_compile succeeds and a empty folder "test_executable" is created in the
build directory

Expected result:
try_compile succeeds and the built executable "test_executable" is located in
the build directory

Additional Information: 
I've tried setting
set("CMAKE_EXECUTABLE_SUFFIX", ".as")
manually at various locations but it didn't work. Either it wasn't set at all or
overwritten; I don't know.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-02-16 10:58 stw_sesa   New Issue
==

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH 1/2] FindwxWidgets.cmake: Fix up wxWidgets_CXXFLAGS

[Brad King]

On 02/14/2016 02:51 PM, Simon Richter wrote:
> This variable contains a semicolon-separated list, but a string of
> space-separated options is needed. As -I and -D options are separated out,
> this usually does not cause any trouble, unless more than one option is
> needed.
[snip]
> +# Flags are a string, not a list, fix it here
> +string(REPLACE ";" " "
> +  wxWidgets_CXX_FLAGS "${wxWidgets_CXX_FLAGS}")

This was discussed here:

  https://cmake.org/Bug/view.php?id=15087#c36639

We cannot simply change the flags because existing code could be depending
on the old value.  We addressed it here instead as of CMake 3.1:

 UsewxWidgets: CFLAGS are expected to be a string here, not a list.
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e6fa6e60

Uses in other projects simply need to be fixed.

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH]: CodeBlocks: improve support for different compilers

[Brad King]

On 02/12/2016 03:24 AM, melven.roehrig-zoell...@dlr.de wrote:
> Just a small patch for the CodeBlocks generator

Thanks!  Applied:

 CodeBlocks: improve support for different compilers
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=184da3f4

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Run program/command before test

[Brad King]

On 02/16/2016 07:17 AM, Roman Wüger wrote:
> Is it possible with CMake >= 3.4.0 to run a program/command before the
> test and another program after the test was run?
> 
> The meaning of that would be, that I want to start a small server
> program and run the "client" test. After the test was finished,
> kill the process of the server program or do a graceful shutdown of it.

There is currently no builtin feature for that.  Other than a few
test output matching properties, ctest always expects the process
to be independent and report results via its exit code.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] Proposal of fix for issue #12873 (AUTOMOC produces same output moc file if target has two source files resides in different sub-directory)

[Brad King]

On 02/13/2016 06:08 AM, Mariusz Pluciński wrote:
> I would like to propose a fix for an issue 12873
> 
> Part of the patch is also the change in test QtAutogen that verifies the fix.

Thanks.  Applied with minor tweaks:

 Automoc: Fix support of files with the same name (#12873)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9beb2744

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH 2/2] FindwxWidgets.cmake: Resolve CygWin/MSYS paths to Windows paths

[Brad King]

On 02/14/2016 02:51 PM, Simon Richter wrote:
> CMake expects Windows style paths on MSYS, so use the cygpath utility to
> resolve them.

Thanks.  Is that utility guaranteed to exist?  IIRC the original MSYS
intentionally did not include such a utility.

In the past I've used a helper function like this:

native_path() {
  cmd //c echo "$1" | sed 's/^"//;s/"$//'
}

to convert paths in a shell script without the cygpath tool.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] FindProtobuf: check version

[Brad King]

On 02/12/2016 02:23 AM, Antonio Perez Barrero wrote:
> Check found libraries version to match user required version.

Thanks.  Applied with minor tweaks and a test case:

 FindProtobuf: check version
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bb7a41ab

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Run program/command before test

[Roman Wüger]

Hello,

Is it possible with CMake >= 3.4.0 to run a program/command before the test and 
another program after the test was run?

The meaning of that would be, that I want to start a small server program and 
run the "client" test. After the test was finished, kill the process of the 
server program or do a graceful shutdown of it.

Thanks in advance

Best Regards
Roman
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers