[CMake] FindFLTK behavior changes between Ubuntu 14.04 and 15.10

[Rob McDonald]

On Ubuntu 14.04 (CMake 2.8.12.2), FindFLTK.cmake sets
FLTK_FLUID_EXECUTABLE to '/usr/bin/fluid'.  This is good.

On 15.10 (CMake 3.2.2), FLTK_FLUID_EXECUTABLE gets set to 'fluid'.  This is bad.

An eyeball comparison of the FindFLTK.cmake scripts included with each
doesn't reveal anything suspicious.  On another mailing list, someone
suggested that the root cause of the change could be a change in bash
behavior.

Does anyone know what caused this?  Does anyone have a workaround?

Is there a way to set the CMake variable to the result of a 'which' command?

Thanks for any help,

Rob
-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1750-g1c87eba

[Nils Gladitz]

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  1c87eba4a16e0d31175f955ed6d7a55ce86931a7 (commit)
   via  6ed1a5bb93664b4654a2f1528530d8d4e67db668 (commit)
  from  b1ee0f0c0c6999b4c83e66ee6fe009d0c53f8d57 (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 -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1c87eba4a16e0d31175f955ed6d7a55ce86931a7
commit 1c87eba4a16e0d31175f955ed6d7a55ce86931a7
Merge: b1ee0f0 6ed1a5b
Author: Nils Gladitz 
AuthorDate: Tue Dec 15 12:36:30 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Tue Dec 15 12:36:30 2015 -0500

Merge topic 'release-wix-config-ng' into next

6ed1a5bb CMake: Mimic NSIS options dialog in WiX installer


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6ed1a5bb93664b4654a2f1528530d8d4e67db668
commit 6ed1a5bb93664b4654a2f1528530d8d4e67db668
Author: Nils Gladitz 
AuthorDate: Thu Dec 10 23:55:07 2015 +0100
Commit: Nils Gladitz 
CommitDate: Tue Dec 15 18:36:14 2015 +0100

CMake: Mimic NSIS options dialog in WiX installer

diff --git a/CMakeCPackOptions.cmake.in b/CMakeCPackOptions.cmake.in
index 4ebf306..25af0c9 100644
--- a/CMakeCPackOptions.cmake.in
+++ b/CMakeCPackOptions.cmake.in
@@ -234,10 +234,35 @@ if("${CPACK_GENERATOR}" STREQUAL "WIX")
   set(CPACK_WIX_LIGHT_EXTRA_FLAGS "-dcl:high")
 
   set(CPACK_WIX_UI_BANNER
-"@CMake_SOURCE_DIR@/Utilities/Release/cpack_wix_ui_banner.jpg"
+"@CMake_SOURCE_DIR@/Utilities/Release/WiX/ui_banner.jpg"
   )
 
   set(CPACK_WIX_UI_DIALOG
-"@CMake_SOURCE_DIR@/Utilities/Release/cpack_wix_ui_dialog.jpg"
+"@CMake_SOURCE_DIR@/Utilities/Release/WiX/ui_dialog.jpg"
   )
+
+  set(CPACK_WIX_EXTRA_SOURCES
+"@CMake_SOURCE_DIR@/Utilities/Release/WiX/install_dir.wxs"
+"@CMake_SOURCE_DIR@/Utilities/Release/WiX/cmake_extra_dialog.wxs"
+  )
+
+  set(CPACK_WIX_UI_REF "CMakeUI_InstallDir")
+
+  set(CPACK_WIX_PATCH_FILE
+"@CMake_SOURCE_DIR@/Utilities/Release/WiX/patch_path_env.xml"
+  )
+
+  set(CPACK_WIX_TEMPLATE
+"@CMake_SOURCE_DIR@/Utilities/Release/WiX/WIX.template.in"
+  )
+
+  set(BUILD_QtDialog "@BUILD_QtDialog@")
+
+  if(BUILD_QtDialog)
+list(APPEND CPACK_WIX_PATCH_FILE
+  "@CMake_SOURCE_DIR@/Utilities/Release/WiX/patch_desktop_shortcut.xml"
+)
+
+set(CPACK_WIX_CANDLE_EXTRA_FLAGS "-dBUILD_QtDialog=1")
+  endif()
 endif()
diff --git a/Utilities/Release/WiX/WIX.template.in 
b/Utilities/Release/WiX/WIX.template.in
new file mode 100644
index 000..8f10f61
--- /dev/null
+++ b/Utilities/Release/WiX/WIX.template.in
@@ -0,0 +1,46 @@
+
+
+
+
+http://schemas.microsoft.com/wix/2006/wi;
+RequiredVersion="3.6.3303.0">
+
+
+
+
+
+
+
+
+
+
+
+
+
+ProductIcon.ico
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/Utilities/Release/WiX/cmake_extra_dialog.wxs 
b/Utilities/Release/WiX/cmake_extra_dialog.wxs
new file mode 100644
index 000..0ee3d99
--- /dev/null
+++ b/Utilities/Release/WiX/cmake_extra_dialog.wxs
@@ -0,0 +1,36 @@
+http://schemas.microsoft.com/wix/2006/wi;>
+   
+   
+   
+   
+
+   
+   
+
+   
+   1
+   
+
+   
+   
+   
+   
+   
+
+   
+
+   
+   
+   
+   
+   
+   
+   
+
+   
+   
+   
+   
+   
+   
+
diff --git a/Utilities/Release/WiX/install_dir.wxs 
b/Utilities/Release/WiX/install_dir.wxs
new file mode 100644
index 000..883efba
--- /dev/null
+++ b/Utilities/Release/WiX/install_dir.wxs
@@ -0,0 +1,61 @@
+http://schemas.microsoft.com/wix/2006/wi;>
+   
+   
+   
+   
+   
+
+   
+   
+
+   
+
+   
+   
+  

Re: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd)

[Ben Boeckel]

On Mon, Dec 14, 2015 at 23:01:31 -0800, Alan W. Irwin wrote:
> On the cmake general list, Brad recently answered my original query on this
> subject and appears to agree with me that that ctest --timeout
> option should always have the highest priority, i.e., override any
> timeout set by the project such as the above TIMEOUT property.  If the
> consensus continues to be that is the desired behaviour it appears
> some CMake/CTest code changes will be necessary to change to that
> behaviour.

Hmm. I don't know. Some tests have timeouts set because they either *do*
take that long or *shouldn't* take as long as the timeout (e.g., those
that might deadlock).

I think, instead, that --min-timeout and --max-timeout options might be
better which allow you to say "this machine is slow; tests may take
longer (max(property, option))" or "this machine is fast, clamp down the
timeout (min(property, option))". Alternatively, a --timeout-scale
option to multiply all timeouts in properties might be better.

--Ben
-- 

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] external project add and configure

[Owen Hogarth II]

In response to myself I've figure it out with using add_step function and
calling some commands.

Full source for what's working building both external libraries.

include(ExternalProject)

ExternalProject_Add(sdl
HG_REPOSITORY http://hg.libsdl.org/SDL
UPDATE_COMMAND hg pull -u http://hg.libsdl.org/SDL

CMAKE_ARGS -DSDL_STATIC:BOOL=FALSE
-DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_BINARY_DIR}

SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL

INSTALL_DIR ${CMAKE_BINARY_DIR}
)

ExternalProject_Get_Property(sdl install_dir)
SET(SDL_INSTALL_DIR ${install_dir})

ExternalProject_Add(sdl_image
DEPENDS sdl
HG_REPOSITORY http://hg.libsdl.org/SDL_image/
UPDATE_COMMAND hg pull -u http://hg.libsdl.org/SDL_image/
COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image/./autogen.sh #this works

CONFIGURE_COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image/./configure
  --prefix=${SDL_INSTALL_DIR}

SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image

INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR}
)
ExternalProject_Get_Property(sdl_image install_dir)
SET(SDL_IMAGE_INSTALL_DIR ${install_dir})

this installs the sdl things in
build-tree/lib
build-tree/include
build-tree/share

but even if I try to hardcode the path's they don't get picked up. The
other libraries not build with external project add cannot find those
files. How do I get those files to be picked up by the regular cmake build?

Also I have one further question though they might be related and can be
solved at the same time.

I would like to add this to my external projects, their include directories
are located in
TARGET_INCLUDE_DIRECTORIES(sdl PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include)



On Tue, Dec 15, 2015 at 8:47 PM, Owen Hogarth II 
wrote:

> I was able to build the external project that required cmake like this:
> include(ExternalProject)
>
> ExternalProject_Add(sdl
> HG_REPOSITORY http://hg.libsdl.org/SDL
> UPDATE_COMMAND hg pull -u http://hg.libsdl.org/SDL
>
> CMAKE_ARGS -DSDL_STATIC:BOOL=FALSE
> -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_BINARY_DIR}/lib
>
> SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL
>
> INSTALL_DIR ${CMAKE_BINARY_DIR}
> )
> ExternalProject_Get_Property(sdl install_dir)
> SET(SDL_INSTALL_DIR ${install_dir})
>
>
> now this second file uses ./configure to set up it's environment.
> I can build it by going into the folder first running ./autogen.sh then
> ./configure ...
>
> or If I use this external project script below
> ExternalProject_Add(sdl_image
> DEPENDS sdl
> HG_REPOSITORY http://hg.libsdl.org/SDL_image/
> UPDATE_COMMAND hg pull -u http://hg.libsdl.org/SDL_image/
>
> # MAKE_COMMAND make
> CONFIGURE_COMMAND  ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image/./configure
> --prefix=${SDL_INSTALL_DIR}/lib
> #adding this prefix I get further in my build then I get an error
>
> SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image
>
> INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR}
> )
>
> error:
> missing: line 81: aclocal-1.13:
>  command not found
> WARNING: 'aclocal-1.13' is missing on your system.
>  You should only need it if you modified 'acinclude.m4' or
>  'configure.ac' or m4 files included by 'configure.ac'.
>  The 'aclocal' program is part of the GNU Automake package:
>  
>  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
>  
>  
>  
>
> I can't actually get cmake to run the autogen script for me. If I leave
> and manually go run ./autogen.sh and then re-run this cmake command things
> will built correctly.
>
> How can I run the autogen.sh command from within that
> "ExternalProject_Add(sdl_image ..)" block?
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd)

[David Cole via cmake-developers]

Thanks, Ben. That was gonna be my 2 cents, too:

If I set a test property to have a 1, 5 or 10 second timeout, then I
want the test to timeout if it takes any longer than that. I do this
on tests which must execute quickly even in a loaded CPU scenario. I
would not want the global timeout to take precedence in this case and
have my performance critical test taking much longer than it's
supposed to, and then pass anyway with no timeout indication.

More use cases to consider.

Although I do agree, a command line specified option should take
precedence over the global variable/property.

(Just like the test's timeout property should take precedence over the
global too: it's more local in scope, and should be preferred unless
there's a **new** mechanism introduced to change the existing
behavior.)


D




On Tue, Dec 15, 2015 at 11:20 AM, Ben Boeckel  wrote:
> On Mon, Dec 14, 2015 at 23:01:31 -0800, Alan W. Irwin wrote:
>> On the cmake general list, Brad recently answered my original query on this
>> subject and appears to agree with me that that ctest --timeout
>> option should always have the highest priority, i.e., override any
>> timeout set by the project such as the above TIMEOUT property.  If the
>> consensus continues to be that is the desired behaviour it appears
>> some CMake/CTest code changes will be necessary to change to that
>> behaviour.
>
> Hmm. I don't know. Some tests have timeouts set because they either *do*
> take that long or *shouldn't* take as long as the timeout (e.g., those
> that might deadlock).
>
> I think, instead, that --min-timeout and --max-timeout options might be
> better which allow you to say "this machine is slow; tests may take
> longer (max(property, option))" or "this machine is fast, clamp down the
> timeout (min(property, option))". Alternatively, a --timeout-scale
> option to multiply all timeouts in properties might be better.
>
> --Ben
> --
>
> 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
-- 

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] Determining if the function pthread_create exists in the pthreads failed with the following output:

[sothy shan]

Hello,

I am compiling the source code from
https://github.com/flowgrammable/onf2013/
My platform is
cmake version 2.8.12.2
Ubunutu 14.04

Error from CmakeError.Log  is


File 
/home/sothy/Téléchargements/onfc/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include 

int main(int argc, char** argv)
{
  (void)argv;
#ifndef pthread_create
  return ((int*)(_create))[argc];
#else
  (void)argc;
  return 0;
#endif
}

Determining if the function pthread_create exists in the pthreads
failed with the following output:
Change Dir: /home/sothy/Téléchargements/onfc/build/CMakeFiles/CMakeTmp

Run Build Command:/usr/bin/make "cmTryCompileExec779452178/fast"
/usr/bin/make -f CMakeFiles/cmTryCompileExec779452178.dir/build.make
CMakeFiles/cmTryCompileExec779452178.dir/build
make[1]: Entering directory
`/home/sothy/Téléchargements/onfc/build/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report
/home/sothy/Téléchargements/onfc/build/CMakeFiles/CMakeTmp/CMakeFiles
1
Building C object
CMakeFiles/cmTryCompileExec779452178.dir/CheckFunctionExists.c.o
/usr/bin/cc   -DCHECK_FUNCTION_EXISTS=pthread_create   -o
CMakeFiles/cmTryCompileExec779452178.dir/CheckFunctionExists.c.o   -c
/usr/share/cmake-2.8/Modules/CheckFunctionExists.c
Linking C executable cmTryCompileExec779452178
/usr/bin/cmake -E cmake_link_script
CMakeFiles/cmTryCompileExec779452178.dir/link.txt --verbose=1
/usr/bin/cc   -DCHECK_FUNCTION_EXISTS=pthread_create
CMakeFiles/cmTryCompileExec779452178.dir/CheckFunctionExists.c.o  -o
cmTryCompileExec779452178 -rdynamic -lpthreads
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
make[1]: Leaving directory
`/home/sothy/Téléchargements/onfc/build/CMakeFiles/CMakeTmp'
make[1]: *** [cmTryCompileExec779452178] Error 1
make: *** [cmTryCompileExec779452178/fast] Error 2

Can you give me suggestion how to solve the problem?

Best regards
Sothy
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd)

[Alan W. Irwin]

On 2015-12-15 13:53-0500 Ben Boeckel wrote:


On Tue, Dec 15, 2015 at 10:33:38 -0800, Alan W. Irwin wrote:

On 2015-12-15 11:20-0500 Ben Boeckel wrote:

I think, instead, that --min-timeout and --max-timeout options might be
better which allow you to say "this machine is slow; tests may take
longer (max(property, option))" or "this machine is fast, clamp down the
timeout (min(property, option))". Alternatively, a --timeout-scale
option to multiply all timeouts in properties might be better.


I think we are stuck with --timeout since it has been available as a
ctest option for a long time.  So the first priority is that option
should override anything set by the project, i.e., anything set by
the project should be considered to be a default value.


Changing --timeout's behavior isn't going to help you since old CMake
versions won't work as intended. I don't think changing its behavior is
best. For example, in our Buildbot infrastructure, we set the default
timeout to 3 minutes because the default timeout for CTest causes tests
to take *way* too long (I think it seems to be 25 minutes?). Some tests,
however, *do* take longer than that on even reasonable hardware, so
those should ignore the lower default timeout we set. Breaking this gets
a *big* -1 from me.


There are a number of issues you have lumped together here.

1. Old versus new.  We should plan the ideal timeout experience for
the user here, and if we get that right once the modified version of
--timeout and the proposed new --timeout-scale lands, then those
having trouble with timeouts for old CMake/CTest versions can be
referred to the new CMake/CTest version.

2. Global versus individual test timeouts set by the project.  I
believe we are all agreed here; individual project timeouts supersedes global
project timeouts.

The above considerations are orthogonal to my principal concern which
is the user should have command-line freedom to supersede any timeout
set by a project since it is usually impossible for the project to
anticipate the user's timeout needs 100 per cent of the time.  I think
the --timeout-scale option you proposed which would multiply both a
project's global and individual test timeouts would be a very nice way
to implement this desired user freedom.

So our disagreement really boils down to what to do with --timeout. 
It is obvious that is an extremely brute force option, but sometimes

that is useful so I think it should be changed to take precedence
(just like the proposed --timeout-scale) over both global and
individual test timeouts set by the project.  However, if you feel
strongly for some reason that this option should have precedence over
the global default set by the project but not over individual test
timeouts set by the project, then I would be willing to go along with
that so long as --timeout-scale is there to provide the desired user
freedom and that departure in behaviour for --timeout for what happens
with --timeout-scale was clearly documented.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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] How to set _default_ timeout for the ctest command? (fwd)

[Ben Boeckel]

On Tue, Dec 15, 2015 at 10:33:38 -0800, Alan W. Irwin wrote:
> On 2015-12-15 11:20-0500 Ben Boeckel wrote:
> > I think, instead, that --min-timeout and --max-timeout options might be
> > better which allow you to say "this machine is slow; tests may take
> > longer (max(property, option))" or "this machine is fast, clamp down the
> > timeout (min(property, option))". Alternatively, a --timeout-scale
> > option to multiply all timeouts in properties might be better.
> 
> I think we are stuck with --timeout since it has been available as a
> ctest option for a long time.  So the first priority is that option
> should override anything set by the project, i.e., anything set by
> the project should be considered to be a default value.

Changing --timeout's behavior isn't going to help you since old CMake
versions won't work as intended. I don't think changing its behavior is
best. For example, in our Buildbot infrastructure, we set the default
timeout to 3 minutes because the default timeout for CTest causes tests
to take *way* too long (I think it seems to be 25 minutes?). Some tests,
however, *do* take longer than that on even reasonable hardware, so
those should ignore the lower default timeout we set. Breaking this gets
a *big* -1 from me.

If you want compatibility between ctest versions, write a script to add
arguments to a list based on the version that is running the script (any
new command line arguments should get corresponding ctest_test()
keywords).

> That said, most cases including the ones I discussed above are scaling
> ones so I agree it would be worthwhile to implement an additional
> overriding --timeout-scale option for ctest which multiplies all
> default timeouts set by the project.  If the user specifies both
> --timeout and --timeout-scale then one of them should be ignored in a
> well-documented way (probably --timeout since --timeout-scale is a bit
> more sophisticated).

I think it would be "apply the scaling, but if there is no value, use
the --timeout value". Whether that is pre- or post-scaling is arguable
(one makes more sense reading, the other makes it easier to script).

--Ben
-- 

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] How to set _default_ timeout for the ctest command? (fwd)

[Alan W. Irwin]

On 2015-12-15 11:20-0500 Ben Boeckel wrote:


On Mon, Dec 14, 2015 at 23:01:31 -0800, Alan W. Irwin wrote:

On the cmake general list, Brad recently answered my original query on this
subject and appears to agree with me that that ctest --timeout
option should always have the highest priority, i.e., override any
timeout set by the project such as the above TIMEOUT property.  If the
consensus continues to be that is the desired behaviour it appears
some CMake/CTest code changes will be necessary to change to that
behaviour.


Hmm. I don't know. Some tests have timeouts set because they either *do*
take that long or *shouldn't* take as long as the timeout (e.g., those
that might deadlock).


That's fine.  Projects should be able to set _default_ timeouts on
individual tests or their entire set of tests in the most intelligent
way they can think of.  But ultimately the user should have the
ability to override whatever value was set in case they have an
extraordinarily slow or fast machine or there is a configuration
possible on the project (the case I ran into with lapack where I
promoted double precision to quadruple precision on an Intel box which
must fall back to software emulation of quadruple precision) where all
tests average much slower than normal.  (The average slowdown factor
is roughly 60 for the quadruple precision lapack tests.)


I think, instead, that --min-timeout and --max-timeout options might be
better which allow you to say "this machine is slow; tests may take
longer (max(property, option))" or "this machine is fast, clamp down the
timeout (min(property, option))". Alternatively, a --timeout-scale
option to multiply all timeouts in properties might be better.


I think we are stuck with --timeout since it has been available as a
ctest option for a long time.  So the first priority is that option
should override anything set by the project, i.e., anything set by
the project should be considered to be a default value.

That said, most cases including the ones I discussed above are scaling
ones so I agree it would be worthwhile to implement an additional
overriding --timeout-scale option for ctest which multiplies all
default timeouts set by the project.  If the user specifies both
--timeout and --timeout-scale then one of them should be ignored in a
well-documented way (probably --timeout since --timeout-scale is a bit
more sophisticated).

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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] adding external project

[Owen Hogarth II]

I have been reading this:
https://cmake.org/cmake/help/v3.0/module/ExternalProject.html

trying to add sdl external project but I am  having issues. I created a new
cmake project to test.

I already downloaded the sdl library and can build it correctly by manually
calling cmake commands but this is how I'd like to distribute sdl w/ my
library.

here's my new test cmake:

cmake_minimum_required(VERSION2.8)
project(sdl_external)

include(ExternalProject)

ExternalProject_Add(sdl
HG_REPOSITORY clone http://hg.libsdl.org/SDL
# PREFIX ${CMAKE_SOURCE_DIR}/sdl

# SOURCE_DIR ${CMAKE_SOURCE_DIR}/sdl

# INSTALL_COMMAND cmake ../ PREFIX=${CMAKE_CURRENT_BINARY_DIR}
)

I get this build output:
cmake ../
-- The C compiler identification is GNU 4.9.2
-- The CXX compiler identification is GNU 4.9.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- 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
-- Found Hg: /usr/bin/hg (found version "3.1.2")
-- Configuring done
-- Generating done
-- Build files have been written to: /home/blubee/sdk/test/build
Scanning dependencies of target sdl
[ 12%] Creating directories for 'sdl'
[ 25%] Performing download step (hg clone) for 'sdl'
-- Avoiding repeated hg clone, stamp file is up to date:
'/home/blubee/sdk/_b/build/test/
build/sdl-prefix/src/sdl-stamp/sdl-hginfo.txt'
[ 37%] No patch step for 'sdl'
[ 50%] Performing update step (hg pull) for 'sdl'
abort: no repository found in
' /home/blubee/sdk/test/build/sdl-prefix/src/sdl' (
.hg not found)!
CMakeFiles/sdl.dir/build.make:89: recipe for target
'sdl-prefix/src/sdl-stamp/sdl-update'
 failed
make[2]: *** [sdl-prefix/src/sdl-stamp/sdl-update] Error 255
CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/sdl.dir/all' failed
make[1]: *** [CMakeFiles/sdl.dir/all] Error 2
Makefile:76: recipe for target 'all' failed
make: *** [all] Error 2

my external build file isn't very verbose but I don't get the error

why is it reporting that no repository found.
abort: no repository found in
'/home/blubee/sdk/test/build/sdl-prefix/src/sdl' (
.hg not found)!

Why isn't the mercurial project not being downloaded?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] ExternalProject_Add and inheritance

[CHEVRIER, Marc]

The problem is not a CMake one but a runtime environment one.
You built an executable with a specific environment (GCC 5) but try to execute 
it in a different environment (default platform): When an executable is built, 
system libraries paths are not stored as part of the executable so without 
specific env, wrong library is used. You can solve this problem using, as you 
already found, LD_LIBRARY_PATH or, may be (not tried), using various CMake 
related RPATH variables and properties to force storage of system library path.


From: Cedric Doucet >
Date: Friday 11 December 2015 at 10:05
To: SAP SAP >
Cc: "cmake@cmake.org" 
>
Subject: Re: [CMake] ExternalProject_Add and inheritance


Hello Marc,

thank you very much for your answer!

I am not sure to understand how to overcome my problem with these variables.
I can explain my problem further.

I have a toy example of the problem which contains:
- a call to ExternalProject_Add to install boost and yaml-ccp (the latter 
depends on the former)
- a main function which loads a file with yaml-cpp (just one line of code)

Everything compiles with GCC 5 and I obtain an executable file (called 
gcc_example).
However, when I run this executable file, I get the following error message :

./gcc_example: relocation error: ./gcc_example: symbol 
_ZTVNSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEEE, version 
GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference

And I can overcome this problem by setting LD_LIBRARY_PATH to the right value:

LD_LIBRARY_PATH=/home/libraries/gcc/5.2.0/lib64/ ./gcc_example

The origin of the problem is that the definition of strings is different since 
GCC 5.
Unfortunately, the default behavior is to call the C++ standard library of my 
Ubuntu system, and the version of this library is older than the version of GCC 
5.

I can check it with 'ldd ./gcc_example':

linux-vdso.so.1 =>  (0x7ffd02ef7000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x003a7140)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x003d03a0)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x003a7100)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x003d02e0)
/lib64/ld-linux-x86-64.so.2 (0x003d02a0)

But I don't understand why I have still this problem since I put these lines in 
my CMakeLists file (of course the right value of GCC_ROOT is passed to the 
cmake command at configuration step):

link_directories(${GCC_ROOT}/lib64)
target_link_libraries(gcc_example ${GCC_ROOT}/lib64/libstdc++.so)

I can provide my simple toy example if it helps to understand.
You just need to compile it with GCC 5 to see the problem (with older versions 
of GCC, everything works fine because strings are defined in the "classical" 
way).


Best,


Cédric






De: "Marc CHEVRIER" >
À: "Cedric Doucet" >, 
cmake@cmake.org
Envoyé: Vendredi 11 Décembre 2015 08:44:38
Objet: Re: [CMake] ExternalProject_Add and inheritance

With CMake, you can control compilation and link flags with the following 
environment variables:

  *   CC: specify C compiler
  *   CFLAGS: C compiler flags
  *   CXX: specify C++ compiler
  *   CXXFLAGS: C++ compiler flags
  *   LDFLAGS: linker flags

And to finish you can overload make command for generation using CMAKE_COMMAND 
option of ExternalProject_Add:
CMAKE_CMMAND “${CMAKE_COMMAND}” -E env CXX=${CMAKE_CXX_COMPILER} LDFLAGS=“…” 
“${CMAKE_COMMAND}”




From: CMake > on behalf 
of Cedric Doucet >
Date: Thursday 10 December 2015 at 18:21
To: "cmake@cmake.org" 
>
Subject: [CMake] ExternalProject_Add and inheritance


Hello,

I use the ExternalProject_Add command to manage third-party libraries.
In the same time, I need to overcome some compatibility problems between GCC 4 
and GCC 5 (strings are not defined in the same way in the STL).
The solution I use is the one given here:
http://stackoverflow.com/questions/33500337/how-to-handle-dual-abi-in-gcc-5
It allows me to force to use the libstdc++.so given by the GCC repository given 
to the cmake command.

The problem is that trick does not work with the ExternalProject_Add command 
because configuration steps of third-party libraries are autonomous.
Do you know how to solve the problem?

For example, if I use the ExternalProject_Add command to manage a third-library 
whose configuration also depends on a cmake script, how could I tell this 
script to use the compilers and the libstdc++.so I provided to my own cmake 

Re: [CMake] adding external project

[Owen Hogarth II]

oh, that was it a typo!

A few more questions. I build the project like this:
ExternalProject_Add(sdl
HG_REPOSITORY http://hg.libsdl.org/SDL
UPDATE_COMMAND ""

CMAKE_ARGS -DSDL_STATIC:BOOL=FALSE
-DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_BINARY_DIR}/lib

SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL

INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR}/bin
)

That seems to build everything and put everything in the right place.
Another thing that I did with other parts of my code was add these lines to
the end of the cmakelists.txt files

TARGET_INCLUDE_DIRECTORIES(mylib PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/headers)

so that I can just #include "mylib" instead of the path to the file. With
this setup, I can't do target_include_directories from the
external_project_add command, how do I get those headers?

On Tue, Dec 15, 2015 at 6:26 PM, Nicholas Braden  wrote:

> What's the word "clone" doing in there? That should be a URL, not
> command parameters.
>
> On Tue, Dec 15, 2015 at 2:01 AM, Owen Hogarth II 
> wrote:
> > I have been reading this:
> > https://cmake.org/cmake/help/v3.0/module/ExternalProject.html
> >
> > trying to add sdl external project but I am  having issues. I created a
> new
> > cmake project to test.
> >
> > I already downloaded the sdl library and can build it correctly by
> manually
> > calling cmake commands but this is how I'd like to distribute sdl w/ my
> > library.
> >
> > here's my new test cmake:
> >
> > cmake_minimum_required(VERSION2.8)
> > project(sdl_external)
> >
> > include(ExternalProject)
> >
> > ExternalProject_Add(sdl
> > HG_REPOSITORY clone http://hg.libsdl.org/SDL
> > # PREFIX ${CMAKE_SOURCE_DIR}/sdl
> >
> > # SOURCE_DIR ${CMAKE_SOURCE_DIR}/sdl
> >
> > # INSTALL_COMMAND cmake ../ PREFIX=${CMAKE_CURRENT_BINARY_DIR}
> > )
> >
> > I get this build output:
> > cmake ../
> > -- The C compiler identification is GNU 4.9.2
> > -- The CXX compiler identification is GNU 4.9.2
> > -- Check for working C compiler: /usr/bin/cc
> > -- Check for working C compiler: /usr/bin/cc -- 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
> > -- Found Hg: /usr/bin/hg (found version "3.1.2")
> > -- Configuring done
> > -- Generating done
> > -- Build files have been written to: /home/blubee/sdk/test/build
> > Scanning dependencies of target sdl
> > [ 12%] Creating directories for 'sdl'
> > [ 25%] Performing download step (hg clone) for 'sdl'
> > -- Avoiding repeated hg clone, stamp file is up to date:
> > '/home/blubee/sdk/_b/build/test/
> > build/sdl-prefix/src/sdl-stamp/sdl-hginfo.txt'
> > [ 37%] No patch step for 'sdl'
> > [ 50%] Performing update step (hg pull) for 'sdl'
> > abort: no repository found in '
> > /home/blubee/sdk/test/build/sdl-prefix/src/sdl' (
> > .hg not found)!
> > CMakeFiles/sdl.dir/build.make:89: recipe for target
> > 'sdl-prefix/src/sdl-stamp/sdl-update'
> >  failed
> > make[2]: *** [sdl-prefix/src/sdl-stamp/sdl-update] Error 255
> > CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/sdl.dir/all'
> failed
> > make[1]: *** [CMakeFiles/sdl.dir/all] Error 2
> > Makefile:76: recipe for target 'all' failed
> > make: *** [all] Error 2
> >
> > my external build file isn't very verbose but I don't get the error
> >
> > why is it reporting that no repository found.
> > abort: no repository found in
> > '/home/blubee/sdk/test/build/sdl-prefix/src/sdl' (
> > .hg not found)!
> >
> > Why isn't the mercurial project not being downloaded?
> >
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> > http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For more
> > information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/cmake/help/training.html
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to 

Re: [CMake] adding external project

[Nicholas Braden]

What's the word "clone" doing in there? That should be a URL, not
command parameters.

On Tue, Dec 15, 2015 at 2:01 AM, Owen Hogarth II  wrote:
> I have been reading this:
> https://cmake.org/cmake/help/v3.0/module/ExternalProject.html
>
> trying to add sdl external project but I am  having issues. I created a new
> cmake project to test.
>
> I already downloaded the sdl library and can build it correctly by manually
> calling cmake commands but this is how I'd like to distribute sdl w/ my
> library.
>
> here's my new test cmake:
>
> cmake_minimum_required(VERSION2.8)
> project(sdl_external)
>
> include(ExternalProject)
>
> ExternalProject_Add(sdl
> HG_REPOSITORY clone http://hg.libsdl.org/SDL
> # PREFIX ${CMAKE_SOURCE_DIR}/sdl
>
> # SOURCE_DIR ${CMAKE_SOURCE_DIR}/sdl
>
> # INSTALL_COMMAND cmake ../ PREFIX=${CMAKE_CURRENT_BINARY_DIR}
> )
>
> I get this build output:
> cmake ../
> -- The C compiler identification is GNU 4.9.2
> -- The CXX compiler identification is GNU 4.9.2
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- 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
> -- Found Hg: /usr/bin/hg (found version "3.1.2")
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/blubee/sdk/test/build
> Scanning dependencies of target sdl
> [ 12%] Creating directories for 'sdl'
> [ 25%] Performing download step (hg clone) for 'sdl'
> -- Avoiding repeated hg clone, stamp file is up to date:
> '/home/blubee/sdk/_b/build/test/
> build/sdl-prefix/src/sdl-stamp/sdl-hginfo.txt'
> [ 37%] No patch step for 'sdl'
> [ 50%] Performing update step (hg pull) for 'sdl'
> abort: no repository found in '
> /home/blubee/sdk/test/build/sdl-prefix/src/sdl' (
> .hg not found)!
> CMakeFiles/sdl.dir/build.make:89: recipe for target
> 'sdl-prefix/src/sdl-stamp/sdl-update'
>  failed
> make[2]: *** [sdl-prefix/src/sdl-stamp/sdl-update] Error 255
> CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/sdl.dir/all' failed
> make[1]: *** [CMakeFiles/sdl.dir/all] Error 2
> Makefile:76: recipe for target 'all' failed
> make: *** [all] Error 2
>
> my external build file isn't very verbose but I don't get the error
>
> why is it reporting that no repository found.
> abort: no repository found in
> '/home/blubee/sdk/test/build/sdl-prefix/src/sdl' (
> .hg not found)!
>
> Why isn't the mercurial project not being downloaded?
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Determining if the function pthread_create exists in the pthreads failed with the following output:

[Rolf Eike Beer]

Am Dienstag, 15. Dezember 2015, 21:09:36 schrieb sothy shan:
> Hello,
> 
> I am compiling the source code from
> https://github.com/flowgrammable/onf2013/
> My platform is
> cmake version 2.8.12.2
> Ubunutu 14.04

> /usr/bin/ld: cannot find -lpthreads

This shouldn't be a problem, as that library is call pthread on Linux. I hope 
this is just calling find_package(Threads), which should handle all this.

Greetings,

Eike

signature.asc
Description: This is a digitally signed message part.
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Restriction on target types for GraphViz dependency graph generation

[Andrey Mishchenko]

Hi,

I noticed that the automatic dependency graph generation in CMake targeting
GraphViz only considers targets of certain types. In particular, it only
adds nodes for executables and shared, static, and module libraries.

Is this deliberate?

If I submit a patch extending this functionality to (optionally, via
configuration variables) work with more target types, would it be received
well?

Andrey Mishchenko
-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, master, updated. v3.4.1-711-g7e29021

[Kitware Robot]

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  7e290214659b2b253bd7034a2f56e47d0ff032b5 (commit)
  from  7a47745d69003ec580e8f38d26dbf8858a4f5b18 (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 -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e290214659b2b253bd7034a2f56e47d0ff032b5
commit 7e290214659b2b253bd7034a2f56e47d0ff032b5
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Wed Dec 16 00:01:06 2015 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Wed Dec 16 00:01:06 2015 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index b7a3791..d760757 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 4)
-set(CMake_VERSION_PATCH 20151215)
+set(CMake_VERSION_PATCH 20151216)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[CMake] external project add and configure

[Owen Hogarth II]

I was able to build the external project that required cmake like this:
include(ExternalProject)

ExternalProject_Add(sdl
HG_REPOSITORY http://hg.libsdl.org/SDL
UPDATE_COMMAND hg pull -u http://hg.libsdl.org/SDL

CMAKE_ARGS -DSDL_STATIC:BOOL=FALSE
-DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_BINARY_DIR}/lib

SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL

INSTALL_DIR ${CMAKE_BINARY_DIR}
)
ExternalProject_Get_Property(sdl install_dir)
SET(SDL_INSTALL_DIR ${install_dir})


now this second file uses ./configure to set up it's environment.
I can build it by going into the folder first running ./autogen.sh then
./configure ...

or If I use this external project script below
ExternalProject_Add(sdl_image
DEPENDS sdl
HG_REPOSITORY http://hg.libsdl.org/SDL_image/
UPDATE_COMMAND hg pull -u http://hg.libsdl.org/SDL_image/

# MAKE_COMMAND make
CONFIGURE_COMMAND  ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image/./configure
--prefix=${SDL_INSTALL_DIR}/lib
#adding this prefix I get further in my build then I get an error

SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image

INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR}
)

error:
missing: line 81: aclocal-1.13:
 command not found
WARNING: 'aclocal-1.13' is missing on your system.
 You should only need it if you modified 'acinclude.m4' or
 'configure.ac' or m4 files included by 'configure.ac'.
 The 'aclocal' program is part of the GNU Automake package:
 
 It also requires GNU Autoconf, GNU m4 and Perl in order to run:
 
 
 

I can't actually get cmake to run the autogen script for me. If I leave and
manually go run ./autogen.sh and then re-run this cmake command things will
built correctly.

How can I run the autogen.sh command from within that
"ExternalProject_Add(sdl_image ..)" block?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] external project add and configure

[Owen Hogarth II]

can I bump this, I have the build working just fine now and installing the
files in the correct directories, but I can't seem to get my non external
projects [the ones I wrote] to link or include with the external projects.

how can I get my local cmake projects to link with the files built
with ExternalProject_Add?

On Wed, Dec 16, 2015 at 12:53 AM, Owen Hogarth II 
wrote:

> In response to myself I've figure it out with using add_step function and
> calling some commands.
>
> Full source for what's working building both external libraries.
>
> include(ExternalProject)
>
> ExternalProject_Add(sdl
> HG_REPOSITORY http://hg.libsdl.org/SDL
> UPDATE_COMMAND hg pull -u http://hg.libsdl.org/SDL
>
> CMAKE_ARGS -DSDL_STATIC:BOOL=FALSE
> -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_BINARY_DIR}
>
> SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL
>
> INSTALL_DIR ${CMAKE_BINARY_DIR}
> )
>
> ExternalProject_Get_Property(sdl install_dir)
> SET(SDL_INSTALL_DIR ${install_dir})
>
> ExternalProject_Add(sdl_image
> DEPENDS sdl
> HG_REPOSITORY http://hg.libsdl.org/SDL_image/
> UPDATE_COMMAND hg pull -u http://hg.libsdl.org/SDL_image/
> COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image/./autogen.sh #this works
>
> CONFIGURE_COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image/./configure
>   --prefix=${SDL_INSTALL_DIR}
>
> SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image
>
> INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR}
> )
> ExternalProject_Get_Property(sdl_image install_dir)
> SET(SDL_IMAGE_INSTALL_DIR ${install_dir})
>
> this installs the sdl things in
> build-tree/lib
> build-tree/include
> build-tree/share
>
> but even if I try to hardcode the path's they don't get picked up. The
> other libraries not build with external project add cannot find those
> files. How do I get those files to be picked up by the regular cmake build?
>
> Also I have one further question though they might be related and can be
> solved at the same time.
>
> I would like to add this to my external projects, their include
> directories are located in
> TARGET_INCLUDE_DIRECTORIES(sdl PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include)
>
>
>
> On Tue, Dec 15, 2015 at 8:47 PM, Owen Hogarth II 
> wrote:
>
>> I was able to build the external project that required cmake like this:
>> include(ExternalProject)
>>
>> ExternalProject_Add(sdl
>> HG_REPOSITORY http://hg.libsdl.org/SDL
>> UPDATE_COMMAND hg pull -u http://hg.libsdl.org/SDL
>>
>> CMAKE_ARGS -DSDL_STATIC:BOOL=FALSE
>> -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_BINARY_DIR}/lib
>>
>> SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL
>>
>> INSTALL_DIR ${CMAKE_BINARY_DIR}
>> )
>> ExternalProject_Get_Property(sdl install_dir)
>> SET(SDL_INSTALL_DIR ${install_dir})
>>
>>
>> now this second file uses ./configure to set up it's environment.
>> I can build it by going into the folder first running ./autogen.sh then
>> ./configure ...
>>
>> or If I use this external project script below
>> ExternalProject_Add(sdl_image
>> DEPENDS sdl
>> HG_REPOSITORY http://hg.libsdl.org/SDL_image/
>> UPDATE_COMMAND hg pull -u http://hg.libsdl.org/SDL_image/
>>
>> # MAKE_COMMAND make
>> CONFIGURE_COMMAND  ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image/./configure
>> --prefix=${SDL_INSTALL_DIR}/lib
>> #adding this prefix I get further in my build then I get an error
>>
>> SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image
>>
>> INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR}
>> )
>>
>> error:
>> missing: line 81: aclocal-1.13:
>>  command not found
>> WARNING: 'aclocal-1.13' is missing on your system.
>>  You should only need it if you modified 'acinclude.m4' or
>>  'configure.ac' or m4 files included by 'configure.ac'.
>>  The 'aclocal' program is part of the GNU Automake package:
>>  
>>  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
>>  
>>  
>>  
>>
>> I can't actually get cmake to run the autogen script for me. If I leave
>> and manually go run ./autogen.sh and then re-run this cmake command things
>> will built correctly.
>>
>> How can I run the autogen.sh command from within that
>> "ExternalProject_Add(sdl_image ..)" block?
>>
>
>
-- 

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:

Re: [CMake] adding external project

[Nicholas Braden]

I think the issue you are running into is order of execution - when
using external projects it is often a good idea to have all the
ExternalProject_Add commands in a superproject file with your own
project source directory as one of the external projects. This way you
can use the DEPENDS parameter to guarantee order of execution - this
also makes it so people can just build your project from the source
directory if they already have the dependencies, and you can use
things like find_package and such.

On Tue, Dec 15, 2015 at 4:57 AM, Owen Hogarth II  wrote:
> oh, that was it a typo!
>
> A few more questions. I build the project like this:
> ExternalProject_Add(sdl
> HG_REPOSITORY http://hg.libsdl.org/SDL
> UPDATE_COMMAND ""
>
> CMAKE_ARGS -DSDL_STATIC:BOOL=FALSE
> -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_BINARY_DIR}/lib
>
> SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL
>
> INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR}/bin
> )
>
> That seems to build everything and put everything in the right place.
> Another thing that I did with other parts of my code was add these lines to
> the end of the cmakelists.txt files
>
> TARGET_INCLUDE_DIRECTORIES(mylib PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/headers)
>
> so that I can just #include "mylib" instead of the path to the file. With
> this setup, I can't do target_include_directories from the
> external_project_add command, how do I get those headers?
>
> On Tue, Dec 15, 2015 at 6:26 PM, Nicholas Braden
>  wrote:
>>
>> What's the word "clone" doing in there? That should be a URL, not
>> command parameters.
>>
>> On Tue, Dec 15, 2015 at 2:01 AM, Owen Hogarth II 
>> wrote:
>> > I have been reading this:
>> > https://cmake.org/cmake/help/v3.0/module/ExternalProject.html
>> >
>> > trying to add sdl external project but I am  having issues. I created a
>> > new
>> > cmake project to test.
>> >
>> > I already downloaded the sdl library and can build it correctly by
>> > manually
>> > calling cmake commands but this is how I'd like to distribute sdl w/ my
>> > library.
>> >
>> > here's my new test cmake:
>> >
>> > cmake_minimum_required(VERSION2.8)
>> > project(sdl_external)
>> >
>> > include(ExternalProject)
>> >
>> > ExternalProject_Add(sdl
>> > HG_REPOSITORY clone http://hg.libsdl.org/SDL
>> > # PREFIX ${CMAKE_SOURCE_DIR}/sdl
>> >
>> > # SOURCE_DIR ${CMAKE_SOURCE_DIR}/sdl
>> >
>> > # INSTALL_COMMAND cmake ../ PREFIX=${CMAKE_CURRENT_BINARY_DIR}
>> > )
>> >
>> > I get this build output:
>> > cmake ../
>> > -- The C compiler identification is GNU 4.9.2
>> > -- The CXX compiler identification is GNU 4.9.2
>> > -- Check for working C compiler: /usr/bin/cc
>> > -- Check for working C compiler: /usr/bin/cc -- 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
>> > -- Found Hg: /usr/bin/hg (found version "3.1.2")
>> > -- Configuring done
>> > -- Generating done
>> > -- Build files have been written to: /home/blubee/sdk/test/build
>> > Scanning dependencies of target sdl
>> > [ 12%] Creating directories for 'sdl'
>> > [ 25%] Performing download step (hg clone) for 'sdl'
>> > -- Avoiding repeated hg clone, stamp file is up to date:
>> > '/home/blubee/sdk/_b/build/test/
>> > build/sdl-prefix/src/sdl-stamp/sdl-hginfo.txt'
>> > [ 37%] No patch step for 'sdl'
>> > [ 50%] Performing update step (hg pull) for 'sdl'
>> > abort: no repository found in '
>> > /home/blubee/sdk/test/build/sdl-prefix/src/sdl' (
>> > .hg not found)!
>> > CMakeFiles/sdl.dir/build.make:89: recipe for target
>> > 'sdl-prefix/src/sdl-stamp/sdl-update'
>> >  failed
>> > make[2]: *** [sdl-prefix/src/sdl-stamp/sdl-update] Error 255
>> > CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/sdl.dir/all'
>> > failed
>> > make[1]: *** [CMakeFiles/sdl.dir/all] Error 2
>> > Makefile:76: recipe for target 'all' failed
>> > make: *** [all] Error 2
>> >
>> > my external build file isn't very verbose but I don't get the error
>> >
>> > why is it reporting that no repository found.
>> > abort: no repository found in
>> > '/home/blubee/sdk/test/build/sdl-prefix/src/sdl' (
>> > .hg not found)!
>> >
>> > Why isn't the mercurial project not being downloaded?
>> >
>> > --
>> >
>> > 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 

Re: [CMake] transitive dependencies (again)

[Tom Kacvinsky]

On Mon, Dec 14, 2015 at 3:36 PM, iosif neitzke
 wrote:
> If you can build Ada sources first, you might wish to make that a
> standalone project that is consumed downstream natively as an Imported
> Library.  Do you generate the import library from a .def file, or via
> some other means?
>

Via a def file.  I first call gnatdll to make the DLL, then call
MSVC's lib tool to create the import library from a def file.

I pored through the cmake configuration removing everything that the
would appear to give a transitivedependency, yet the dependencies
linger.  I'll keep digging, this didn't happen before so something
must have changed in the configuration when I merged against master
for our code base.


> On Mon, Dec 14, 2015 at 9:59 AM, Tom Kacvinsky
>  wrote:
>> Hi Petr,
>>
>>
>> On Mon, Dec 14, 2015 at 10:53 AM, Petr Kmoch  wrote:
>>> Hi Tom,
>>>
>>> linking the static archive into the DLL should not be done by
>>> add_dependencies(), but by target_link_libraries(). There, you can
>>> explicitly list the archive as PRIVATE so that it does not become a part of
>>> the linking interface of the DLL:
>>>
>>> add_library(staticArchive STATIC ...)
>>>
>>> add_library(theDLL SHARED ...)
>>>
>>> target_link_libraries(theDLL PRIVATE staticArchive)
>>>
>>
>> Thanks for the tip.   I'll try it out.  I hope it works as I am not
>> using the MSVC tool chain
>> to build the DLL (i.e., not using add_library and target_link_libraries).
>>
>> I sent a separate reply detailing what I am using to build the DLL.
>>>
>>> On Mon, Dec 14, 2015 at 3:34 PM, Tom Kacvinsky
>>>  wrote:

 I am getting link errors because cmake is adding transitive
 dependencies.  I am building a DLL which depends on a static archive
 (and is marked as such with add_dependencies), but when I link an
 executable that depends on the DLL, both libraries (import library for
 the DLL and static archive) are specified on the link. leading to
 duplicate symbol errors as the symbol are exported form the DLL and
 defined in the static archive.

 How do I work around this?  This is the one thing that has frustrated
 me over the last couple of years - I have never received an answer
 telling me how to turn off transitive dependencies.

 Sorry for the minor rant.

 Regards,

 Tom
 --

 Powered by www.kitware.com

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

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

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

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

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/mailman/listinfo/cmake
>>>
>>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: 
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more 
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at 
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware open-source projects at