[CMake] VS's /Zo flag

[James Bigler]

Has anyone been able to use the /Zo flag?  I tried to add it to my
RelWithDebInfo build, but the flag doesn't seem to be showing up in the
command line (in the GUI).

My flags are:

/MT /O2 /Ob2 /D NDEBUG /Zi /Zo

I'm using cmake 3.2.1.

Documentation on /Zo (available in VS2013.3+:
https://msdn.microsoft.com/en-us/library/dn785163.aspx

Thanks,
James
-- 

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] VS's /Zo flag

[James Bigler]

OK, so it is there in the project file and if I enable detailed build
output, the flag is there.  I wonder why the the AdditionalOptions aren't
appearing in the GUI.  They used to.


   /w34101 /w34189 /w34018 /w34389 /Zo
%(AdditionalOptions)

Nothing in the "Additional Options" section in the "Command Line" section
of the project settings.

On Mon, Dec 14, 2015 at 4:35 PM, James Bigler  wrote:

> Has anyone been able to use the /Zo flag?  I tried to add it to my
> RelWithDebInfo build, but the flag doesn't seem to be showing up in the
> command line (in the GUI).
>
> My flags are:
>
> /MT /O2 /Ob2 /D NDEBUG /Zi /Zo
>
> I'm using cmake 3.2.1.
>
> Documentation on /Zo (available in VS2013.3+:
> https://msdn.microsoft.com/en-us/library/dn785163.aspx
>
> Thanks,
> James
>
-- 

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] NO_SYSTEM_ENVIRONMENT_PATH globally?

[Ray Donnelly]

On Mon, Dec 14, 2015 at 2:42 AM, Alan W. Irwin
 wrote:
> On 2015-12-14 01:06- Ray Donnelly wrote:
>
>> Hi,
>>
>> I ran into a problem on MSYS2 recently building llvm+clang for
>> mingw-w64 using CMake 3.4.1 (we carry a few local patches, they're
>> fairly minor, except the qt5-static one, and I don't think they are
>> likely related to this:
>> https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-cmake)
>>
>> MSYS2 has two shells .. actually it's 3 or 4, but for simplicity we'll
>> ignore the 32-bit ones and pretend there's only 2 64-bit shells, one
>> launched with msys2_shell.bat and one launched with mingw64_shell.bat.
>> Under msys2_shell.bat, the "/mingw64/bin" folder doesn't appear at all
>> in PATH, while under mingw64_shell.bat, it appears at the very front,
>> before "/usr/bin" (which contains the msys2 software).
>>
>> When running CMake to configure the build for libclang, it tries to
>> see if if can find libdl with "find_library (DL_LIBRARY_PATH dl)".
>> Unfortunately it finds the msys-2.0.dll-linked libdl.a in /usr/lib
>> because NO_SYSTEM_ENVIRONMENT_PATH isn't set, which isn't then in
>> /mingw64/bin/g++.exe's linker search path (and even if it was, we
>> don't want to link msys-2.0.dll software into native software!).
>
>
> Hi Ray:
>
> I only have indirect experience with MinGW-w64/MSYS2 (i.e., reading detailed
> build reports from a tester of PLplot on that platform), but my
> understanding is
> to build software for that platform you would normally
> always use mingw64_shell.bat (or mingw32_shell.bat for the 32-bit
> case).  And if /mingw64/bin is first on the PATH for that shell my
> understanding is that if libdl is in the correct location in /mingw64,
> then it should normally and automatically be found by CMake for
> /mingw64/bin/g++.exe when NO_SYSTEM_ENVIRONMENT_PATH is not set.

Hi Alan,

I'm one of the founders of MSYS2 (not that that means I know what I'm
talking about mind you!) .. You are right, that normally for building
mingw-w64 x86_64 software on MSYS2 you'd use mingw64_shell.bat, but
when building MSYS2 packages via makepkg-mingw, you'd run
msys2_shell.bat instead since that builds both the 32-bit and 64-bit
variants setting the correct environment up beforehand each time.

The issue I've got here is that on MSYS2 we've decided that we don't
want to provide libdl for mingw-w64 but do provide it for msys2, so
there'll never be a /mingw{64,32}/lib/libdl.a or
/mingw{64,32}/lib/libdl.dll.a, but there is a /usr/lib/libdl.a. When
building mingw-w64 software, the front of PATH will be
"/mingw64/bin:/usr/bin" or "/mingw32/bin:/usr/bin" and that causes
CMake to find /usr/lib/libdl.a due to NO_SYSTEM_ENVIRONMENT_PATH.

I think the best I can do is to edit each of our CMake using PKGBUILD
scripts to set PATH to a clean value just before invoking CMake. This
is something I didn't really want to have to do.

To my mind, this rummaging around the user's system path feature seems
too prone to randomness and a large source of build variance. Some of
this comes from my liking for reproducible builds where environmental
differences are kept out of the equation.

>
> However, it appears that is not the find result you are getting and
> you have responded by trying to find a way to set
> NO_SYSTEM_ENVIRONMENT_PATH globally.  But I think it would be better
> instead to explore the case where the NO_SYSTEM_ENVIRONMENT_PATH
> command is not used to figure out how to get that scenario to
> correctly find libdl.
>
> Therefore, I suggest you make a simple test
> project which uses "find_library (DL_LIBRARY_PATH dl)" (without
> NO_SYSTEM_ENVIRONMENT_PATH) to find dl, and fiddle with your PATH (and
> also CMake version just in case it turns out you are fighting against
> some recently introduced find_library regression) to see what the
> results are.  And if nothing works for any cmake version with
> /mingw64/bin at the very front of your PATH, then you can always fall
> back to setting the -DCMAKE_LIBRARY_PATH:PATH cmake option to force
> finding the correct version of libdl.
>
> Note in your tests above you might also want to try both the "Unix
> Makefiles" and "MSYS Makefiles" generators.  Our PLplot experience is
> that choice does make a difference for one find module (wxwidgets) on
> MinGW-w64/MSYS2, and I suppose it is possible it might also make a
> difference to the results from a single find_library command as well.
>

"MSYS Makefiles" should be the correct choice on MSYS2 if you are
compiling with native compilers. If you are using cross compilers then
"Unix makefiles" should be the correct choice. There is a bug in
wxwidget's wx-config not being sympathetic towards the idiosyncrasies
of MSYS2 that I will push a fix for soon-ish (the prefix variable
needs to be modified through cygpath -m if MSYSTEM is MINGW32 or
MINGW64). However, due to person-power issues, the package will not be
rebuilt for a while, but hopefully you can build your own to 

[CMake] try_compile, again

[Alain Miniussi]

Hi,

I tried using try_compile, and, as usual, fail to understand how it's supposed 
to work (2.8.12).

The documentation says:
 Some extra flags that can be included are,  INCLUDE_DIRECTORIES, 
LINK_DIRECTORIES, and LINK_LIBRARIES.
but does not mention where they can be included (none of the two mentioned form 
indicate those flags).
I tried putting "INCLUDE_DIRECTORIES ${Boost_INCLUDE_DIRS}" just after the 
CMAKE_FLAGS., but it is just ignored.
 
Also:

 COMPILE_DEFINITIONS are -Ddefinition that will be passed to the compile line.
but that seems incorrect (which is good) as I can use them to pass "-std=c++11" 
which is not a -D option (and I don't know how I could pass that option otherwise).

Thanks

--
---
Alain
--

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] transitive dependencies (again)

[Tom Kacvinsky]

On Mon, Dec 14, 2015 at 9:34 AM, 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.

More details:

Windows 7, 64 bit, cmake 2.8.12.11 from cmake.org website.  DLL built
with gnatdll, import library built with MSVC's lib utility, static
library built with the MSVC tool chain.

I'll try to come up with a simple reproducer.  I hope to do this
completely with the MSVC tool chain as I don't expect people to jump
through the hoops of configuring cmake to use an Ada tool chain.
Unless Alan Irwin chimes in, that is.
-- 

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] parallel install of different cmake versions

[Eric Noulard]

2015-12-14 15:42 GMT+01:00 Brad King :

> On 12/11/2015 06:42 PM, Orion Poplawski wrote:
> > For Fedora EPEL we often end up packaging newer versions of cmake as
> cmakeXY
> > (e.g. cmake34) that can be installed in parallel with the system cmake.
> This
> > is a fairly invasive process.  I'm attaching the current patch I'm
> working on
> > for this.  Is there any interest in cmake itself for supporting this
> kind of
> > thing?
>
> Not particularly.  That does look pretty invasive.
>
> Why not just install it to /usr/lib/cmake34 with normal names and symlink
> the versioned names?  E.g.
>
>  /usr/bin/cmake34 -> /usr/lib/cmake34/bin/cmake
>  /usr/bin/ctest34 -> /usr/lib/cmake34/bin/ctest
>


+1
Personnally when I installed several version of CMake I do install them
with a particular prefix and then I use update-alternatives(1) to install
proper symlinks to the specific location.

I switch from one version to another using update-alternatives(1).

This can certainly be used on Fedora/EPEL as well:
https://fedoraproject.org/wiki/Packaging:Alternatives


-- 
Eric
-- 

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, release, updated. v3.4.1-4-ga9e8b12

[Brad King]

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, release has been updated
   via  a9e8b123de79a65074dab1944bf80d94dc101b12 (commit)
   via  f254276fc1a17de7cd5cfc016fd2137937830fca (commit)
   via  5914d5eabc8f050f9b1c9873d31598331eaeefa7 (commit)
   via  d8b251e2ea84e612dc30a1c9690a8b299aeb30fd (commit)
  from  fd7180f0c0c2554c31afda235469df986a109fe4 (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 -
---

Summary of changes:
 Modules/FindJava.cmake   |6 +++---
 Modules/Platform/AIX-GNU.cmake   |   12 +++-
 Modules/Platform/AIX-XL.cmake|   12 +++-
 Modules/Platform/HP-UX-GNU.cmake |4 +++-
 Modules/Platform/HP-UX-HP.cmake  |4 +++-
 5 files changed, 31 insertions(+), 7 deletions(-)


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

[Cmake-commits] CMake branch, master, updated. v3.4.1-709-g6a6d00a

[Brad King]

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  6a6d00aeeffadcb535b5a4cf4adaeda296f91b3a (commit)
   via  a9e8b123de79a65074dab1944bf80d94dc101b12 (commit)
   via  5914d5eabc8f050f9b1c9873d31598331eaeefa7 (commit)
  from  22ccae1d683b3d2e829edaa08abea0a7f6362000 (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 -
---

Summary of changes:


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

Re: [CMake] Parallel jobs failed for cmake

[Bill Hoffman]

On 12/14/2015 1:34 AM, Igor Sobinov wrote:


Thanks, that's clear.

So, If I write in makefile
No not really clear.  The problem is NOT in your makefile.  The problem 
is in your custom command that calls make again.  That is where the 
problem is.  In your custom command (which you have not provided the 
code for), it is clear that you call make without $(MAKE)


If you go back to your second post on this topic:
igor 5460 0.0 0.0 101152 972 pts/3 S+ 08:10 0:00 | \_ make build_release -j5
igor 5466 0.0 0.0 106096 1164 pts/3 S+ 08:10 0:00 | \_ /bin/sh -c cd 
/home/igor/build_root/release_target; make release


Right there is the problem.  The custom command does this:
/bin/sh -c cd /home/igor/build_root/release_target; make release

It needs to do this:

/bin/sh -c cd /home/igor/build_root/release_target; $(MAKE) release

You will need to escape the $ to get this right.

You can check the generated makefile if you are having trouble.

-Bill
--

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] transitive dependencies (again)

[Petr Kmoch]

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)

Petr

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

Re: [CMake] transitive dependencies (again)

[Tom Kacvinsky]

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

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

[Alan W. Irwin]

On 2015-12-15 07:09+0100 Attila Krasznahorkay wrote:


Hi Alan,

Are you just looking for the TIMEOUT property on the tests?


Hi Attila:

No.  As I said in my post, I tried that test property but
the problem was that absolutely fixed the timeout for the test
so it could not be overriden by the ctest --timeout option.
And similarly for every other way for a project to choose
a timeout.

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.

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)

[Attila Krasznahorkay]

Hi Alan,

Are you just looking for the TIMEOUT property on the tests?

https://cmake.org/cmake/help/v3.0/command/set_tests_properties.html

This is something that I managed to find with the most basic google-ing myself. 
:-/ And I use it like:

set_tests_properties( ${testName}Test PROPERTIES TIMEOUT 120 )

Or would you like to be able to set some global property/variable that would 
set the default timeout for all the created tests without you having to set 
these things individually? (I just wrote a wrapper function to set up all my 
tests in the way that I wanted to.)

Best,
   Attila

> On Dec 14, 2015, at 9:36 PM, Alan W. Irwin  wrote:
> 
> I would appreciate it if a CMake developer who is familiar with the CTest 
> timeout
> logic would answer my question below that was addressed to "@CMake 
> developers:".
> 
> Without such an answer (even if the conclusion is there is no way for
> an individual software package such as lapack to set a different
> _default_ timeout for CTest other than 1500 seconds), I will not be
> able to figure out what to advise the lapack developers.
> 
> 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
> __
> 
> -- Forwarded message --
> Date: Wed, 9 Dec 2015 19:06:00 -0800 (PST)
> From: Alan W. Irwin 
> To: Marcel Loose 
> Cc: cm...@cmake.org
> Subject: Re: [CMake] How to set _default_ timeout for the ctest command?
> 
> On 2015-12-09 09:23+0100 Marcel Loose wrote:
> 
>> Hi Alan,
>> Just by experimenting, I discovered that you also need to set
>> DART_TESTING_TIMEOUT. I'm not sure what the relationship (if any) is
>> between CTEST_TEST_TIMEOUT and DART_TESTING_TIMEOUT. I set them both in
>> the file CTestConfig.cmake. I get the feeling that DART_TESTING_TIMEOUT
>> is there for less than historic reasons. Maybe someone from Kitware can
>> shed a light on this.
> 
> Thanks, Marcel, for trying those experiments.
> 
> I tried some additional experiments and found that all that is needed is
> to set the CTEST_TEST_TIMEOUT value before CTest is included in my
> top-level CMakeLists.txt file.  (My previous experiment set that value
> after the include, but before the first add_test command.) Note that
> I do not use CTestConfig.cmake at all.
> 
> So the current experimental logic is
> # Control the default timeout for all ctests.
> set(CTEST_TEST_TIMEOUT 1)
> include(CTest)
> 
> Those commands generate the following timeout results in the build tree.
> 
> software@raven> find . -type f |xargs grep -i timeout
> ./CMakeCache.txt:DART_TESTING_TIMEOUT:STRING=1
> ./CMakeCache.txt://ADVANCED property for variable: DART_TESTING_TIMEOUT
> ./CMakeCache.txt:DART_TESTING_TIMEOUT-ADVANCED:INTERNAL=1
> ./DartConfiguration.tcl:# TimeOut is the amount of time in seconds to wait 
> for processes
> ./DartConfiguration.tcl:# to complete during testing.  After TimeOut seconds, 
> the
> ./DartConfiguration.tcl:TimeOut: 1
> ./DartConfiguration.tcl:# For CTest submissions that timeout, these options
> 
> So for this case, DART_TESTING_TIMEOUT is automatically set to the
> specified CTEST_TEST_TIMEOUT value.  (If CTEST_TEST_TIMEOUT is not set,
> the cached value of DART_TESTING_TIMEOUT is 1500, and the value of the
> timeout in DartConfiguration.tcl is also set to 1500).
> 
> Afterwards, ctest timed out at 1 second for all tests that exceeded
> that value, but it turns out that is a hard-coded value which cannot
> be superseded by the ctest --timeout option.  So this approach is not
> really ideal for the lapack developers who will want to increase the
> default limit by only an order of magnitude or less to substantially
> reduce the probability someone with a slow computer or special
> circumstances will have to override using the ctest --timeout option,
> but that change likely will not reduce that probability to zero so
> keeping the ability to override the lapack timeout default by the
> ctest --timeout option is still likely imporatant to them.
> 
> @CMake developers:
> 
> The documentation of CTEST_TEST_TIMEOUT (and DART_TESTING_TIMEOUT)
> includes the following language:
> 
> "The default timeout for each test if
> not specified by the `TIMEOUT` test property.
> 
> Also, the documentation of the ctest --timeout option says:
> 
> `--timeout `
> Set a global timeout on all tests.
> 
> This option will set a global timeout 

[Cmake-commits] CMake branch, master, updated. v3.4.1-710-g7a47745

[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  7a47745d69003ec580e8f38d26dbf8858a4f5b18 (commit)
  from  6a6d00aeeffadcb535b5a4cf4adaeda296f91b3a (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=7a47745d69003ec580e8f38d26dbf8858a4f5b18
commit 7a47745d69003ec580e8f38d26dbf8858a4f5b18
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Tue Dec 15 00:01:08 2015 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Tue Dec 15 00:01:08 2015 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 4e596d9..b7a3791 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 20151214)
+set(CMake_VERSION_PATCH 20151215)
 #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] Can CMake intelligently support GCC "-include" directive

[Richard Lang]

Hi all,

Porting a collection of IAR Embedded Workbench projects to CMake/GCC.

The IAR projects make use of "preinclude headers" (header files that are
automatically included in every source file in the project without being
explicitly pulled in with a #include statement - not to be confused with
precompiled headers).  These map nicely to the GCC "-include "
directive and I can manually implement it in my CMakeList.txt file as
follows


set(PREINCLUDE_FILE "${PROJ_BASE_DIR}/some-path/preinclude.h")

...

if (PREINCLUDE_FILE)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -include ${PREINCLUDE_FILE}")
endif()

and generate a makefile that builds OK.  However when I use CMake to
generate an Eclipse project there is no consideration given to the
preinclude header file(s).

In my case the preinclude contains several preprocessor definitions that
effectively drive the configuration of the rest of the system during
compilation - without them the Eclipse CDT Indexer does not get all the
definitions required to make sense of the codebase and requires additional
manual configuration before it will do anything useful.

Is there any way to automate this from the CMakeList.txt file?
-- 

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] HowTo: write install_package function

[Cedric Doucet]

Hello, 

I would like to write a function called install_package which works like the 
find_package function, but for installation of external packages (thanks to 
ExternalProject). 
Thus, I would like to write modules InstallFoo.cmake so as to be able to call 
my function like this: 
install_package(Foo) # installation of Foo library 

Do you know if it is possible to implement such a thing? 
Is there another function I could study to understand how to do it? 
I tried to look at the implementation of the find_package function in my 
CMake's installation but I did not manage to find it. 

Cédric 
-- 

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] Proposal to teach cmDepends to only take dependencies from the source tree

[Attila Krasznahorkay]

Dear All,

I was hoping to get some feedback from the developers on which direction to 
take this in. As I wrote before, I'm happy to help. But I don't want to spend 
time on an implementation that people will not accept in the end. I'd like us 
to first agree on how the code should behave after the addition of this new 
feature.

Cheers,
  Attila

> On 09 Dec 2015, at 15:38, Ben Boeckel  wrote:
> 
> On Wed, Dec 09, 2015 at 09:19:45 +0100, Attila Krasznahorkay wrote:
>> I myself am on the side of simplicity. Using regular expressions would
>> allow us to do what I want. But if >95% of the people using this new
>> possibility would use it exactly like I plan to, then implementing it
>> in a more complicated way than necessary would just be a bad design
>> choice.
> 
> Do you have performance numbers for the change in your build between
> using include_directories (or target_include_directories), with and
> without SYSTEM, each with and without this change?
> 
> --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] [PATCH] FindOpenGL: Don't add AGL to OPENGL_LIBRARIES on OS X.

[Brad King]

On 12/12/2015 02:12 PM, David Gobbi wrote:
> CMake had been setting OPENGL_glu_LIBRARY to AGL.framework, even
> though AGL is not GLU.  AGL is simply the GL component for the
> deprecated Carbon framework.  GLU is provided by OpenGL.framework.
> 
> A side effect of the old behavior was that if AGL was not found
> (it is absent from OS X SDK 10.10 or later), then OPENGL_GLU_FOUND
> would be incorrectly set to "NO".

Thanks.  I'm not familiar with those roles myself so I've long wondered
why we used AGL for GLU.  Applied:

 FindOpenGL: Don't add AGL to OPENGL_LIBRARIES on OS X.
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=08580be2

-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-commits] CMake branch, next, updated. v3.4.1-1732-gfb02b77

[Brad King]

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  fb02b77199c5ed153c9b4f7fe82b069017bbbeef (commit)
   via  22ccae1d683b3d2e829edaa08abea0a7f6362000 (commit)
   via  c952f2b42469c22b09570d35eb67d6521eeffbb7 (commit)
   via  09da79b40ff5a809490b40709a9e564e4ceec0b7 (commit)
   via  b97018534fbb4ce238561a1363f2698526bcda31 (commit)
   via  ac6025c5ff9a24a6a03b225c0b02ce67d65013d3 (commit)
  from  7bce703841f1204d82fb23fa2cfc3e91ee2d7fc4 (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=fb02b77199c5ed153c9b4f7fe82b069017bbbeef
commit fb02b77199c5ed153c9b4f7fe82b069017bbbeef
Merge: 7bce703 22ccae1
Author: Brad King 
AuthorDate: Mon Dec 14 10:00:26 2015 -0500
Commit: Brad King 
CommitDate: Mon Dec 14 10:00:26 2015 -0500

Merge branch 'master' into next


---

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

Re: [CMake] NO_SYSTEM_ENVIRONMENT_PATH globally?

[Ray Donnelly]

On Mon, Dec 14, 2015 at 12:43 PM, Ray Donnelly  wrote:
> On Mon, Dec 14, 2015 at 2:42 AM, Alan W. Irwin
>  wrote:
>> On 2015-12-14 01:06- Ray Donnelly wrote:
>>
>>> Hi,
>>>
>>> I ran into a problem on MSYS2 recently building llvm+clang for
>>> mingw-w64 using CMake 3.4.1 (we carry a few local patches, they're
>>> fairly minor, except the qt5-static one, and I don't think they are
>>> likely related to this:
>>> https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-cmake)
>>>
>>> MSYS2 has two shells .. actually it's 3 or 4, but for simplicity we'll
>>> ignore the 32-bit ones and pretend there's only 2 64-bit shells, one
>>> launched with msys2_shell.bat and one launched with mingw64_shell.bat.
>>> Under msys2_shell.bat, the "/mingw64/bin" folder doesn't appear at all
>>> in PATH, while under mingw64_shell.bat, it appears at the very front,
>>> before "/usr/bin" (which contains the msys2 software).
>>>
>>> When running CMake to configure the build for libclang, it tries to
>>> see if if can find libdl with "find_library (DL_LIBRARY_PATH dl)".
>>> Unfortunately it finds the msys-2.0.dll-linked libdl.a in /usr/lib
>>> because NO_SYSTEM_ENVIRONMENT_PATH isn't set, which isn't then in
>>> /mingw64/bin/g++.exe's linker search path (and even if it was, we
>>> don't want to link msys-2.0.dll software into native software!).
>>
>>
>> Hi Ray:
>>
>> I only have indirect experience with MinGW-w64/MSYS2 (i.e., reading detailed
>> build reports from a tester of PLplot on that platform), but my
>> understanding is
>> to build software for that platform you would normally
>> always use mingw64_shell.bat (or mingw32_shell.bat for the 32-bit
>> case).  And if /mingw64/bin is first on the PATH for that shell my
>> understanding is that if libdl is in the correct location in /mingw64,
>> then it should normally and automatically be found by CMake for
>> /mingw64/bin/g++.exe when NO_SYSTEM_ENVIRONMENT_PATH is not set.
>
> Hi Alan,
>
> I'm one of the founders of MSYS2 (not that that means I know what I'm
> talking about mind you!) .. You are right, that normally for building
> mingw-w64 x86_64 software on MSYS2 you'd use mingw64_shell.bat, but
> when building MSYS2 packages via makepkg-mingw, you'd run
> msys2_shell.bat instead since that builds both the 32-bit and 64-bit
> variants setting the correct environment up beforehand each time.
>
> The issue I've got here is that on MSYS2 we've decided that we don't
> want to provide libdl for mingw-w64 but do provide it for msys2, so
> there'll never be a /mingw{64,32}/lib/libdl.a or
> /mingw{64,32}/lib/libdl.dll.a, but there is a /usr/lib/libdl.a. When
> building mingw-w64 software, the front of PATH will be
> "/mingw64/bin:/usr/bin" or "/mingw32/bin:/usr/bin" and that causes
> CMake to find /usr/lib/libdl.a due to NO_SYSTEM_ENVIRONMENT_PATH.
>
> I think the best I can do is to edit each of our CMake using PKGBUILD
> scripts to set PATH to a clean value just before invoking CMake. This
> is something I didn't really want to have to do.

Replying to myself; first sign of something --good .. but I've thought
immediately of a case where I can't modify PATH like I suggested. We
have some packages (e.g. hlsl2glslfork) that use bison and flex, and
those packages use msys2 flex and bison. For those to work, I can't
remove /usr/bin from PATH for all PKGBUILDs that invoke CMake as I had
planned, so how should I proceed here? (I wouldn't be surprised if
clang/llvm also call bison and flex).

>
> To my mind, this rummaging around the user's system path feature seems
> too prone to randomness and a large source of build variance. Some of
> this comes from my liking for reproducible builds where environmental
> differences are kept out of the equation.
>
>>
>> However, it appears that is not the find result you are getting and
>> you have responded by trying to find a way to set
>> NO_SYSTEM_ENVIRONMENT_PATH globally.  But I think it would be better
>> instead to explore the case where the NO_SYSTEM_ENVIRONMENT_PATH
>> command is not used to figure out how to get that scenario to
>> correctly find libdl.
>>
>> Therefore, I suggest you make a simple test
>> project which uses "find_library (DL_LIBRARY_PATH dl)" (without
>> NO_SYSTEM_ENVIRONMENT_PATH) to find dl, and fiddle with your PATH (and
>> also CMake version just in case it turns out you are fighting against
>> some recently introduced find_library regression) to see what the
>> results are.  And if nothing works for any cmake version with
>> /mingw64/bin at the very front of your PATH, then you can always fall
>> back to setting the -DCMAKE_LIBRARY_PATH:PATH cmake option to force
>> finding the correct version of libdl.
>>
>> Note in your tests above you might also want to try both the "Unix
>> Makefiles" and "MSYS Makefiles" generators.  Our PLplot experience is
>> that choice does make a difference for one find module (wxwidgets) on
>> MinGW-w64/MSYS2, and I suppose it 

Re: [cmake-developers] parallel install of different cmake versions

[Brad King]

On 12/11/2015 06:42 PM, Orion Poplawski wrote:
> For Fedora EPEL we often end up packaging newer versions of cmake as cmakeXY
> (e.g. cmake34) that can be installed in parallel with the system cmake.  This
> is a fairly invasive process.  I'm attaching the current patch I'm working on
> for this.  Is there any interest in cmake itself for supporting this kind of
> thing?

Not particularly.  That does look pretty invasive.

Why not just install it to /usr/lib/cmake34 with normal names and symlink
the versioned names?  E.g.

 /usr/bin/cmake34 -> /usr/lib/cmake34/bin/cmake
 /usr/bin/ctest34 -> /usr/lib/cmake34/bin/ctest
 ...

I have many different CMake versions installed on my system in different
directories and use aliases or symlinks to reference them without being
in my PATH directly.

-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-commits] CMake branch, master, updated. v3.4.1-700-g09da79b

[Brad King]

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  09da79b40ff5a809490b40709a9e564e4ceec0b7 (commit)
   via  f254276fc1a17de7cd5cfc016fd2137937830fca (commit)
  from  b97018534fbb4ce238561a1363f2698526bcda31 (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=09da79b40ff5a809490b40709a9e564e4ceec0b7
commit 09da79b40ff5a809490b40709a9e564e4ceec0b7
Merge: b970185 f254276
Author: Brad King 
AuthorDate: Mon Dec 14 09:59:58 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 14 09:59:58 2015 -0500

Merge topic 'fix-CMP0065-NEW-AIX-HP'

f254276f AIX,HP-UX: Fix RPATH handling when CMP0065 is set to NEW


---

Summary of changes:
 Modules/Platform/AIX-GNU.cmake   |   12 +++-
 Modules/Platform/AIX-XL.cmake|   12 +++-
 Modules/Platform/HP-UX-GNU.cmake |4 +++-
 Modules/Platform/HP-UX-HP.cmake  |4 +++-
 4 files changed, 28 insertions(+), 4 deletions(-)


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

[CMake] transitive dependencies (again)

[Tom Kacvinsky]

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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1724-gf13c32c

[Brad King]

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  f13c32c336518c1ffbe319abebea4f3e5196943b (commit)
   via  08580be2ada7b226c3b8f91b6ecdbc57d843d42e (commit)
  from  a93d6bfc9f94463468acde105e9d9bfec830baf4 (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=f13c32c336518c1ffbe319abebea4f3e5196943b
commit f13c32c336518c1ffbe319abebea4f3e5196943b
Merge: a93d6bf 08580be
Author: Brad King 
AuthorDate: Mon Dec 14 09:48:06 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 14 09:48:06 2015 -0500

Merge topic 'FindOpenGL-no-osx-AGL' into next

08580be2 FindOpenGL: Don't add AGL to OPENGL_LIBRARIES on OS X.


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=08580be2ada7b226c3b8f91b6ecdbc57d843d42e
commit 08580be2ada7b226c3b8f91b6ecdbc57d843d42e
Author: David Gobbi 
AuthorDate: Sat Dec 12 09:32:42 2015 -0700
Commit: Brad King 
CommitDate: Mon Dec 14 09:46:32 2015 -0500

FindOpenGL: Don't add AGL to OPENGL_LIBRARIES on OS X.

CMake had been setting OPENGL_glu_LIBRARY to AGL.framework, even
though AGL is not GLU.  AGL is simply the GL component for the
deprecated Carbon framework.  GLU is provided by OpenGL.framework.

A side effect of the old behavior was that if AGL was not found
(it is absent from OS X SDK 10.10 or later), then OPENGL_GLU_FOUND
would be incorrectly set to "NO".

diff --git a/Modules/FindOpenGL.cmake b/Modules/FindOpenGL.cmake
index a7eefa7..93e488b 100644
--- a/Modules/FindOpenGL.cmake
+++ b/Modules/FindOpenGL.cmake
@@ -71,9 +71,11 @@ elseif (WIN32)
 
 elseif (APPLE)
 
-  find_library(OPENGL_gl_LIBRARY OpenGL DOC "OpenGL lib for OSX")
-  find_library(OPENGL_glu_LIBRARY AGL DOC "AGL lib for OSX")
-  find_path(OPENGL_INCLUDE_DIR OpenGL/gl.h DOC "Include for OpenGL on OSX")
+  # The OpenGL.framework provides both gl and glu
+  find_library(OPENGL_gl_LIBRARY OpenGL DOC "OpenGL library for OS X")
+  find_library(OPENGL_glu_LIBRARY OpenGL DOC
+"GLU library for OS X (usually same as OpenGL library)")
+  find_path(OPENGL_INCLUDE_DIR OpenGL/gl.h DOC "Include for OpenGL on OS X")
   list(APPEND _OpenGL_REQUIRED_VARS OPENGL_INCLUDE_DIR)
 
 else()
@@ -149,7 +151,9 @@ if(OPENGL_gl_LIBRARY)
 set( OPENGL_LIBRARIES  ${OPENGL_gl_LIBRARY} ${OPENGL_LIBRARIES})
 if(OPENGL_glu_LIBRARY)
   set( OPENGL_GLU_FOUND "YES" )
-  set( OPENGL_LIBRARIES ${OPENGL_glu_LIBRARY} ${OPENGL_LIBRARIES} )
+  if(NOT "${OPENGL_glu_LIBRARY}" STREQUAL "${OPENGL_gl_LIBRARY}")
+set( OPENGL_LIBRARIES ${OPENGL_glu_LIBRARY} ${OPENGL_LIBRARIES} )
+  endif()
 else()
   set( OPENGL_GLU_FOUND "NO" )
 endif()

---

Summary of changes:
 Modules/FindOpenGL.cmake |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)


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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1726-g7bce703

[Brad King]

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  7bce703841f1204d82fb23fa2cfc3e91ee2d7fc4 (commit)
   via  f0b5ce7f94ae699ed583777534742bbeb211407a (commit)
  from  f13c32c336518c1ffbe319abebea4f3e5196943b (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=7bce703841f1204d82fb23fa2cfc3e91ee2d7fc4
commit 7bce703841f1204d82fb23fa2cfc3e91ee2d7fc4
Merge: f13c32c f0b5ce7
Author: Brad King 
AuthorDate: Mon Dec 14 09:58:52 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 14 09:58:52 2015 -0500

Merge topic 'FindGTest-imported-targets' into next

f0b5ce7f Help: Add notes for topic 'FindGTest-imported-targets'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f0b5ce7f94ae699ed583777534742bbeb211407a
commit f0b5ce7f94ae699ed583777534742bbeb211407a
Author: Brad King 
AuthorDate: Mon Dec 14 09:56:30 2015 -0500
Commit: Brad King 
CommitDate: Mon Dec 14 09:56:30 2015 -0500

Help: Add notes for topic 'FindGTest-imported-targets'

diff --git a/Help/release/dev/FindGTest-imported-targets.rst 
b/Help/release/dev/FindGTest-imported-targets.rst
new file mode 100644
index 000..3cb98da
--- /dev/null
+++ b/Help/release/dev/FindGTest-imported-targets.rst
@@ -0,0 +1,4 @@
+FindGTest-imported-targets
+--
+
+* The :module:`FindGTest` module now provides imported targets.

---

Summary of changes:
 Help/release/dev/FindGTest-imported-targets.rst |4 
 1 file changed, 4 insertions(+)
 create mode 100644 Help/release/dev/FindGTest-imported-targets.rst


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

[Cmake-commits] CMake branch, master, updated. v3.4.1-706-g22ccae1

[Brad King]

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  22ccae1d683b3d2e829edaa08abea0a7f6362000 (commit)
   via  2908103d04daeaf396173b6f868f2cad5eb47b08 (commit)
  from  c952f2b42469c22b09570d35eb67d6521eeffbb7 (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=22ccae1d683b3d2e829edaa08abea0a7f6362000
commit 22ccae1d683b3d2e829edaa08abea0a7f6362000
Merge: c952f2b 2908103
Author: Brad King 
AuthorDate: Mon Dec 14 10:00:05 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 14 10:00:05 2015 -0500

Merge topic 'FindProtobuf-fix-case'

2908103d FindProtobuf: Set Protobuf_FOUND in addition to PROTOBUF_FOUND


---

Summary of changes:
 Modules/FindProtobuf.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

Re: [CMake] Parallel jobs failed for cmake

[Paul Smith]

On Mon, 2015-12-14 at 09:34 +0300, Igor Sobinov wrote:
> So, If I write in makefile
> 
> 
> build_release: $(RELEASE_DIR)
> @cd $(RELEASE_DIR); $(MAKE) release
> 
> I got an error
> 
> Also if I write
> build_release: $(RELEASE_DIR)
> $(MAKE) release -C  $(RELEASE_DIR)
> 
> I got an error too
> 
> But this is successfull command:
> # cd $RELEASE_DIR; make release -j10
> 
> Why make doesn't support jobs for subdirs?

All three of these work for me, so it must be something else in your
makefile that you haven't shown us that's causing the problem.  Can you
provide a SSCCE (http://sscce.org/)?

As Bill points out this is a make issue, NOT a cmake issue.  I recommend
you re-start this thread with all details (operating system, version of
make, SSCCE, etc.) on the help-m...@gnu.org mailing list rather than
here.

I'll offer one possible suggestion, first: you haven't by any chance
changed the SHELL variable in your external makefile to use csh, have
you?

SHELL = /bin/csh

(or tcsh either).  Because if you have, that's the problem.  Csh is a
terrible shell for many reasons but in particular it cannot be used as
the shell for makefiles, if you want the jobserver feature to work.

> core::
> +(cd core; make)
> 
> With this, GNU Make is able to distribute the jobs between the
> subdirectories. (I have a number of such targets in my main Makefile.)

Bill's comment, that you should use $(MAKE) and never plain "make", is
correct.  It's better to use $(MAKE) for many reasons, only some of
which are handled by prefixing the recipe with "+".
-- 

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] [PATCH] FindOpenGL: Don't add AGL to OPENGL_LIBRARIES on OS X.

[David Gobbi]

On Mon, Dec 14, 2015 at 7:48 AM, Brad King  wrote:

> On 12/12/2015 02:12 PM, David Gobbi wrote:
> > CMake had been setting OPENGL_glu_LIBRARY to AGL.framework, even
> > though AGL is not GLU.  AGL is simply the GL component for the
> > deprecated Carbon framework.  GLU is provided by OpenGL.framework.
> >
> > A side effect of the old behavior was that if AGL was not found
> > (it is absent from OS X SDK 10.10 or later), then OPENGL_GLU_FOUND
> > would be incorrectly set to "NO".
>
> Thanks.  I'm not familiar with those roles myself so I've long wondered
> why we used AGL for GLU.  Applied:
>
>  FindOpenGL: Don't add AGL to OPENGL_LIBRARIES on OS X.
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=08580be2


Carbon + AGL are like x11 + glx and Windows + wgl.
Thanks for the quick reply.

 - David
-- 

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, next, updated. v3.4.1-1736-gd75e40d

[Brad King]

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  d75e40d647d3d8869d375455a64a78aa0eca4f93 (commit)
   via  6a6d00aeeffadcb535b5a4cf4adaeda296f91b3a (commit)
   via  a9e8b123de79a65074dab1944bf80d94dc101b12 (commit)
   via  5914d5eabc8f050f9b1c9873d31598331eaeefa7 (commit)
  from  fb02b77199c5ed153c9b4f7fe82b069017bbbeef (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=d75e40d647d3d8869d375455a64a78aa0eca4f93
commit d75e40d647d3d8869d375455a64a78aa0eca4f93
Merge: fb02b77 6a6d00a
Author: Brad King 
AuthorDate: Mon Dec 14 10:02:30 2015 -0500
Commit: Brad King 
CommitDate: Mon Dec 14 10:02:30 2015 -0500

Merge branch 'master' into next


---

Summary of changes:


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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1738-g3d5ec08

[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  3d5ec083460e03b1ad57baa90cddbc543233f3fa (commit)
   via  95224b2152c8df6869f02f04a1f741f5607b111f (commit)
  from  d75e40d647d3d8869d375455a64a78aa0eca4f93 (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=3d5ec083460e03b1ad57baa90cddbc543233f3fa
commit 3d5ec083460e03b1ad57baa90cddbc543233f3fa
Merge: d75e40d 95224b2
Author: Nils Gladitz 
AuthorDate: Mon Dec 14 14:59:59 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 14 14:59:59 2015 -0500

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

95224b21 CMake: !fixup Support building WiX installer without Qt Dialog


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=95224b2152c8df6869f02f04a1f741f5607b111f
commit 95224b2152c8df6869f02f04a1f741f5607b111f
Author: Nils Gladitz 
AuthorDate: Mon Dec 14 20:58:59 2015 +0100
Commit: Nils Gladitz 
CommitDate: Mon Dec 14 20:58:59 2015 +0100

CMake: !fixup Support building WiX installer without Qt Dialog

diff --git a/CMakeCPackOptions.cmake.in b/CMakeCPackOptions.cmake.in
index eb36015..0562732 100644
--- a/CMakeCPackOptions.cmake.in
+++ b/CMakeCPackOptions.cmake.in
@@ -249,6 +249,14 @@ if("${CPACK_GENERATOR}" STREQUAL "WIX")
   set(CPACK_WIX_UI_REF "CMakeUI_InstallDir")
 
   set(CPACK_WIX_PATCH_FILE
-"@CMake_SOURCE_DIR@/Utilities/Release/WiX/patch.xml"
+"@CMake_SOURCE_DIR@/Utilities/Release/WiX/patch_path_env.xml"
   )
+
+  set(BUILD_QtDialog "@BUILD_QtDialog@")
+
+  if(BUILD_QtDialog)
+list(APPEND CPACK_WIX_PATCH_FILE
+  "@CMake_SOURCE_DIR@/Utilities/Release/WiX/patch_desktop_shortcut.xml"
+)
+  endif()
 endif()
diff --git a/Utilities/Release/WiX/patch_desktop_shortcut.xml 
b/Utilities/Release/WiX/patch_desktop_shortcut.xml
new file mode 100644
index 000..d30705d
--- /dev/null
+++ b/Utilities/Release/WiX/patch_desktop_shortcut.xml
@@ -0,0 +1,5 @@
+
+  
+DESKTOP_SHORTCUT_REQUESTED = 1
+  
+
diff --git a/Utilities/Release/WiX/patch.xml 
b/Utilities/Release/WiX/patch_path_env.xml
similarity index 87%
rename from Utilities/Release/WiX/patch.xml
rename to Utilities/Release/WiX/patch_path_env.xml
index 666c7ac..0e335c4 100644
--- a/Utilities/Release/WiX/patch.xml
+++ b/Utilities/Release/WiX/patch_path_env.xml
@@ -1,8 +1,4 @@
 
-  
-DESKTOP_SHORTCUT_REQUESTED = 1
-  
-
   
 
 

---

Summary of changes:
 CMakeCPackOptions.cmake.in  |   10 +-
 Utilities/Release/WiX/patch_desktop_shortcut.xml|5 +
 Utilities/Release/WiX/{patch.xml => patch_path_env.xml} |4 
 3 files changed, 14 insertions(+), 5 deletions(-)
 create mode 100644 Utilities/Release/WiX/patch_desktop_shortcut.xml
 rename Utilities/Release/WiX/{patch.xml => patch_path_env.xml} (87%)


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

Re: [CMake] NO_SYSTEM_ENVIRONMENT_PATH globally?

[Alan W. Irwin]

On 2015-12-14 12:43- Ray Donnelly wrote:


The issue I've got here is that on MSYS2 we've decided that we don't
want to provide libdl for mingw-w64 but do provide it for msys2, so
there'll never be a /mingw{64,32}/lib/libdl.a or
/mingw{64,32}/lib/libdl.dll.a, but there is a /usr/lib/libdl.a. When
building mingw-w64 software, the front of PATH will be
"/mingw64/bin:/usr/bin" or "/mingw32/bin:/usr/bin" and that causes
CMake to find /usr/lib/libdl.a due to NO_SYSTEM_ENVIRONMENT_PATH.


Hi Ray:

Did you mean "due to NO_SYSTEM_ENVIRONMENT_PATH _not_ being set"? 
That is the only way that sentence makes sense to me and is also

consistent with the subject line, but I may be missing something.

So if my interpretation of what you said is correct, your special
build problem on the MinGW-w64/MSYS2 platform is you want to reject
msys2 variants of the libraries (thus avoiding a dependency on the
msys2 dll) while still using msys2 build tools.

Assuming I have stated the problem correctly, then the solution
normally is to put /mingw{64,32} first on your PATH (like the
appropriate shell does as you have discussed) and that should
guarantee the /mingw{64,32} version of the library is found.  However,
for the special case where there is no /mingw{64,32} version of the
library (from what you said above libdl is an example of this special
case) the CMake-based build systems will incorrectly find the msys2
version of the library (because msys2 is necessarily on the PATH
because you need access to those build tools) rather than your desired
result that CMake finds no library at all for this special case.

I believe the MinGW-w64/MSYS2 distribution should address this problem
in general by making sure that /mingw{64,32} does provide all
libraries that msys2 provides if at all possible.  However, whenever
there is some absolutely ironclad reason not to provide a
/mingw{64,32} variant (as appears to be the case for libdl although
you may want to review that reason to make sure it is really ironclad)
then you must patch all build systems for software packages that have
a soft dependency on libdl to simply ignore any libdl that is found on
the MinGW-w64/MSYS2 platform.  My impression is that build system
patches are required quite often for distributions of free software to
help enforce some policy decisions they have made so it appears that
MinGW-w64/MSYS2 is also not immune to such a requirement.  Of course,
this is not a very good solution if there are tonnes of such package
build systems to patch, but my guess is that patches for just a
handful of packages would be required to deal completely with this
special libdl case.

By the way, you will be glad to know that I have a strong spectator
interest in MinGW-w64/MSYS2 because it turns out (thanks to the
testing reports sent to me by Greg Jung which allowed me to adjust the
PLplot build system to work properly for the MinGW-w64/MSYS2 case)
that has recently become one of our most powerful and reliable PLplot
platforms on Windows.

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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1740-g906215d

[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  906215d2fe7e9c6408be4c69935c150cf85210d3 (commit)
   via  017ef8f70f259e4b6f826fc6bd710fe6a5a386ae (commit)
  from  3d5ec083460e03b1ad57baa90cddbc543233f3fa (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=906215d2fe7e9c6408be4c69935c150cf85210d3
commit 906215d2fe7e9c6408be4c69935c150cf85210d3
Merge: 3d5ec08 017ef8f
Author: Nils Gladitz 
AuthorDate: Mon Dec 14 15:00:47 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 14 15:00:47 2015 -0500

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

017ef8f7 CMake: Mimic NSIS options dialog in WiX installer


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=017ef8f70f259e4b6f826fc6bd710fe6a5a386ae
commit 017ef8f70f259e4b6f826fc6bd710fe6a5a386ae
Author: Nils Gladitz 
AuthorDate: Thu Dec 10 23:55:07 2015 +0100
Commit: Nils Gladitz 
CommitDate: Mon Dec 14 21:00:18 2015 +0100

CMake: Mimic NSIS options dialog in WiX installer

diff --git a/CMakeCPackOptions.cmake.in b/CMakeCPackOptions.cmake.in
index 4ebf306..0562732 100644
--- a/CMakeCPackOptions.cmake.in
+++ b/CMakeCPackOptions.cmake.in
@@ -234,10 +234,29 @@ 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(BUILD_QtDialog "@BUILD_QtDialog@")
+
+  if(BUILD_QtDialog)
+list(APPEND CPACK_WIX_PATCH_FILE
+  "@CMake_SOURCE_DIR@/Utilities/Release/WiX/patch_desktop_shortcut.xml"
+)
+  endif()
 endif()
diff --git a/Utilities/Release/WiX/cmake_extra_dialog.wxs 
b/Utilities/Release/WiX/cmake_extra_dialog.wxs
new file mode 100644
index 000..6047c08
--- /dev/null
+++ b/Utilities/Release/WiX/cmake_extra_dialog.wxs
@@ -0,0 +1,35 @@
+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;>
+   
+   
+   
+   
+   
+
+   
+   
+
+   
+
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+
+   1
+   
+
+   1
+
+   NOT Installed
+   Installed AND PATCH
+
+   1
+   LicenseAccepted = "1"
+
+   1
+   1
+   NOT 
WIXUI_DONTVALIDATEPATH
+   
+   WIXUI_DONTVALIDATEPATH OR 
WIXUI_INSTALLDIR_VALID="1"
+   1
+   1
+
+   1
+   1
+
+   NOT 

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

[Alan W. Irwin]

I would appreciate it if a CMake developer who is familiar with the CTest 
timeout
logic would answer my question below that was addressed to 
"@CMake developers:".


Without such an answer (even if the conclusion is there is no way for
an individual software package such as lapack to set a different
_default_ timeout for CTest other than 1500 seconds), I will not be
able to figure out what to advise the lapack developers.

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
__

-- Forwarded message --
Date: Wed, 9 Dec 2015 19:06:00 -0800 (PST)
From: Alan W. Irwin 
To: Marcel Loose 
Cc: cm...@cmake.org
Subject: Re: [CMake] How to set _default_ timeout for the ctest command?

On 2015-12-09 09:23+0100 Marcel Loose wrote:


Hi Alan,

Just by experimenting, I discovered that you also need to set
DART_TESTING_TIMEOUT. I'm not sure what the relationship (if any) is
between CTEST_TEST_TIMEOUT and DART_TESTING_TIMEOUT. I set them both in
the file CTestConfig.cmake. I get the feeling that DART_TESTING_TIMEOUT
is there for less than historic reasons. Maybe someone from Kitware can
shed a light on this.


Thanks, Marcel, for trying those experiments.

I tried some additional experiments and found that all that is needed is
to set the CTEST_TEST_TIMEOUT value before CTest is included in my
top-level CMakeLists.txt file.  (My previous experiment set that value
after the include, but before the first add_test command.) Note that
I do not use CTestConfig.cmake at all.

So the current experimental logic is
# Control the default timeout for all ctests.
set(CTEST_TEST_TIMEOUT 1)
include(CTest)

Those commands generate the following timeout results in the build tree.

software@raven> find . -type f |xargs grep -i timeout
./CMakeCache.txt:DART_TESTING_TIMEOUT:STRING=1
./CMakeCache.txt://ADVANCED property for variable: DART_TESTING_TIMEOUT
./CMakeCache.txt:DART_TESTING_TIMEOUT-ADVANCED:INTERNAL=1
./DartConfiguration.tcl:# TimeOut is the amount of time in seconds to wait for 
processes
./DartConfiguration.tcl:# to complete during testing.  After TimeOut seconds, 
the

./DartConfiguration.tcl:TimeOut: 1
./DartConfiguration.tcl:# For CTest submissions that timeout, these options

So for this case, DART_TESTING_TIMEOUT is automatically set to the
specified CTEST_TEST_TIMEOUT value.  (If CTEST_TEST_TIMEOUT is not set,
the cached value of DART_TESTING_TIMEOUT is 1500, and the value of the
timeout in DartConfiguration.tcl is also set to 1500).

Afterwards, ctest timed out at 1 second for all tests that exceeded
that value, but it turns out that is a hard-coded value which cannot
be superseded by the ctest --timeout option.  So this approach is not
really ideal for the lapack developers who will want to increase the
default limit by only an order of magnitude or less to substantially
reduce the probability someone with a slow computer or special
circumstances will have to override using the ctest --timeout option,
but that change likely will not reduce that probability to zero so
keeping the ability to override the lapack timeout default by the
ctest --timeout option is still likely imporatant to them.

@CMake developers:

The documentation of CTEST_TEST_TIMEOUT (and DART_TESTING_TIMEOUT)
includes the following language:

"The default timeout for each test if
not specified by the `TIMEOUT` test property.

Also, the documentation of the ctest --timeout option says:

`--timeout `
 Set a global timeout on all tests.

This option will set a global timeout on all tests that do not
already have a timeout set on them.

So I guess it could be argued that CTEST_TEST_TIMEOUT does impose a
specific timeout on all tests, and that is why the --timeout option is
being ignored for this case.  But that is not particularly useful
behaviour, and it would be far better in my opinion for the --timeout
option to work for all tests where the TIMEOUT test property has
not been specifically set by the project's build system.

I would appreciate some further investigation of these matters by a
knowledgable CMake developer, and if it turns out this issue is
actually caused by a cmake or ctest bug, then I would be willing to
write up the appropriate bug report if it turns out an instantaneous
fix could not be made.

I also tried the experiment of dropping the setting of
CTEST_TEST_TIMEOUT and using set_tests_properties to set the TIMEOUT
for individual 

Re: [CMake] Parallel jobs failed for cmake

[Attila Krasznahorkay]

Hi Igor,

At this point it's really not a CMake question, but a GNU Make one... The 
answer is actually right there in the first warning that you got.

make[4]: warning: jobserver unavailable: using -j1.  Add `+' to parent make 
rule.

I have to admit that I'm not absolutely sure about all the subtleties of this, 
but I defined my own build rules in the past that call make themselves, like:

core::
+(cd core; make)

With this, GNU Make is able to distribute the jobs between the subdirectories. 
(I have a number of such targets in my main Makefile.)

Cheers,
  Attila

> On 14 Dec 2015, at 07:34, Igor Sobinov  wrote:
> 
> Hello Bill,
> 
> Thanks, that's clear.
> 
> So, If I write in makefile
> 
> 
> build_release: $(RELEASE_DIR)
> @cd $(RELEASE_DIR); $(MAKE) release
> 
> I got an error
> 
> Also if I write
> 
> build_release: $(RELEASE_DIR)
> $(MAKE) release -C  $(RELEASE_DIR)
> 
> I got an error too
> 
> But this is successfull command:
> # cd $RELEASE_DIR; make release -j10
> 
> Why make doesn't support jobs for subdirs?
> 
> 
> Пятница, 11 декабря 2015, 14:14 -05:00 от Bill Hoffman 
> :
> 
> On 12/11/2015 7:24 AM, Igor Sobinov wrote:
> > Hello Bill,
> >
> > yes, make release is a custom command but that's not important.
> > I do the following:
> > # cd /home/igor/build_root/release_target
> > # make release -j5
> Yes, it is important, it is the reason it is not working. The custom 
> command needs to use $(MAKE) and not make to call make or you will get 
> this error. Child make calls need environment variables to get parallel 
> builds to work. The MAKE env var is used to pass them around.
> 
> -Bill
> 
> 
> 
> Bye, Igor
> 
> -- 
> 
> 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] what options

[Attila Krasznahorkay]

Hi,

Just to clarify: CMAKE_INSTALL_PREFIX is the variable that sets where the 
project will be installed. CMAKE_PREFIX_PATH is used (amongst other things) to 
find external projects during the configuration.

Cheers,
 Attila

> On 13 Dec 2015, at 21:20, Owen Hogarth II  wrote:
> 
> wow, that's excellent cmake -LAH lead me to the variable that I was looking 
> for.
> 
> Thank you very much Roger!
> 
> On Mon, Dec 14, 2015 at 3:56 AM, Roger Leigh  wrote:
> On 13/12/2015 19:44, Owen Hogarth II wrote:
> If you have a cmake project, what's the way to see what type of
> configuration options are available?
> 
> For example I know that I can pass -DCMAKE_PREFIX_PATH the set where the
> project will be installed.
> 
> Sometimes project creators add other things, such as building static or
> share libraries, SSE, NEON or other flags like those.
> 
> Is there a way to have cmake show all of those that the current project
> has exposed?
> 
> cmake -L[A][H] .
> 
> Lists the cache variables to set, optionally including advanced options and 
> help text.
> 
> See "List non-advanced cached variables" in 
> https://cmake.org/cmake/help/v3.4/manual/cmake.1.html
> 
> These are also shown with cmake-gui, which lists them in the user interface.
> 
> 
> Regards,
> Roger
> -- 
> 
> 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

Re: [CMake] what options

[Owen Hogarth II]

Thanks for the clarification.

On Mon, Dec 14, 2015, 16:23 Attila Krasznahorkay <
attila.krasznahor...@gmail.com> wrote:

> Hi,
>
> Just to clarify: CMAKE_INSTALL_PREFIX is the variable that sets where the
> project will be installed. CMAKE_PREFIX_PATH is used (amongst other things)
> to find external projects during the configuration.
>
> Cheers,
>  Attila
>
> > On 13 Dec 2015, at 21:20, Owen Hogarth II  wrote:
> >
> > wow, that's excellent cmake -LAH lead me to the variable that I was
> looking for.
> >
> > Thank you very much Roger!
> >
> > On Mon, Dec 14, 2015 at 3:56 AM, Roger Leigh 
> wrote:
> > On 13/12/2015 19:44, Owen Hogarth II wrote:
> > If you have a cmake project, what's the way to see what type of
> > configuration options are available?
> >
> > For example I know that I can pass -DCMAKE_PREFIX_PATH the set where the
> > project will be installed.
> >
> > Sometimes project creators add other things, such as building static or
> > share libraries, SSE, NEON or other flags like those.
> >
> > Is there a way to have cmake show all of those that the current project
> > has exposed?
> >
> > cmake -L[A][H] .
> >
> > Lists the cache variables to set, optionally including advanced options
> and help text.
> >
> > See "List non-advanced cached variables" in
> https://cmake.org/cmake/help/v3.4/manual/cmake.1.html
> >
> > These are also shown with cmake-gui, which lists them in the user
> interface.
> >
> >
> > Regards,
> > Roger
> > --
> >
> > 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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1743-g8afdd81

[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  8afdd81e1c8ad9f42506fa38e5d005427beef0c0 (commit)
   via  b31550dba8557e9fe306b8123d172d484bb8c25c (commit)
   via  96c6c8574b0a176fd27401eb2464f88c6b76b47b (commit)
  from  906215d2fe7e9c6408be4c69935c150cf85210d3 (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=8afdd81e1c8ad9f42506fa38e5d005427beef0c0
commit 8afdd81e1c8ad9f42506fa38e5d005427beef0c0
Merge: 906215d b31550d
Author: Nils Gladitz 
AuthorDate: Mon Dec 14 17:27:50 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 14 17:27:50 2015 -0500

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

b31550db CMake: !fixup Omit desktop shortcut checkbox when not building 
QtDialog
96c6c857 CPackWIX: Allow multiple patch files and diagnose if any are 
missing


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b31550dba8557e9fe306b8123d172d484bb8c25c
commit b31550dba8557e9fe306b8123d172d484bb8c25c
Author: Nils Gladitz 
AuthorDate: Mon Dec 14 23:09:11 2015 +0100
Commit: Nils Gladitz 
CommitDate: Mon Dec 14 23:20:38 2015 +0100

CMake: !fixup Omit desktop shortcut checkbox when not building QtDialog

diff --git a/CMakeCPackOptions.cmake.in b/CMakeCPackOptions.cmake.in
index 0562732..09568c3 100644
--- a/CMakeCPackOptions.cmake.in
+++ b/CMakeCPackOptions.cmake.in
@@ -258,5 +258,7 @@ if("${CPACK_GENERATOR}" STREQUAL "WIX")
 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/cmake_extra_dialog.wxs 
b/Utilities/Release/WiX/cmake_extra_dialog.wxs
index 6047c08..0ee3d99 100644
--- a/Utilities/Release/WiX/cmake_extra_dialog.wxs
+++ b/Utilities/Release/WiX/cmake_extra_dialog.wxs
@@ -27,8 +27,9 @@


 
-   
-
+   
+   
+   




https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=96c6c8574b0a176fd27401eb2464f88c6b76b47b
commit 96c6c8574b0a176fd27401eb2464f88c6b76b47b
Author: Nils Gladitz 
AuthorDate: Mon Dec 14 23:04:41 2015 +0100
Commit: Nils Gladitz 
CommitDate: Mon Dec 14 23:04:41 2015 +0100

CPackWIX: Allow multiple patch files and diagnose if any are missing

CPACK_WIX_PATCH_FILE now accepts a list of patch files.
An error will now be produced if any of the patch files is missing.

Previously this would be silently ignored.

diff --git a/Modules/CPackWIX.cmake b/Modules/CPackWIX.cmake
index bef8e16..4994005 100644
--- a/Modules/CPackWIX.cmake
+++ b/Modules/CPackWIX.cmake
@@ -119,7 +119,8 @@
 #
 # .. variable:: CPACK_WIX_PATCH_FILE
 #
-#  Optional XML file with fragments to be inserted into generated WiX sources
+#  Optional list of XML files with fragments to be inserted into
+#  generated WiX sources
 #
 #  This optional variable can be used to specify an XML file that the
 #  WiX generator will use to inject fragments into its generated
diff --git a/Source/CPack/WiX/cmCPackWIXGenerator.cxx 
b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
index b55c5a5..ece327a 100644
--- a/Source/CPack/WiX/cmCPackWIXGenerator.cxx
+++ b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
@@ -242,7 +242,16 @@ bool cmCPackWIXGenerator::InitializeWiXConfiguration()
   const char* patchFilePath = GetOption("CPACK_WIX_PATCH_FILE");
   if(patchFilePath)
 {
-this->Patch->LoadFragments(patchFilePath);
+std::vector patchFilePaths;
+cmSystemTools::ExpandListArgument(patchFilePath, patchFilePaths);
+
+for(size_t i = 0; i < patchFilePaths.size(); ++i)
+  {
+  if(!this->Patch->LoadFragments(patchFilePaths[i]))
+{
+return false;
+}
+  }
 }
 
   return true;
diff --git a/Source/CPack/WiX/cmWIXPatch.cxx b/Source/CPack/WiX/cmWIXPatch.cxx
index 471c3a4..07375da 100644
--- a/Source/CPack/WiX/cmWIXPatch.cxx
+++ b/Source/CPack/WiX/cmWIXPatch.cxx
@@ -20,10 +20,18 @@ cmWIXPatch::cmWIXPatch(cmCPackLog* logger):
 
 }
 
-void cmWIXPatch::LoadFragments(std::string const& patchFilePath)
+bool cmWIXPatch::LoadFragments(std::string const& patchFilePath)
 {
   cmWIXPatchParser parser(Fragments, Logger);
-  parser.ParseFile(patchFilePath.c_str());
+  

[Cmake-commits] CMake branch, next, updated. v3.4.1-1746-gabe5e4a

[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  abe5e4a93c0f0a2041cf670371c4b8604595ae59 (commit)
   via  a4c6b4d6b17b430c23aab2f7452e4fe860244916 (commit)
   via  de77d4a741c84e0b5774e79a0c84e945e25ad9f8 (commit)
  from  8afdd81e1c8ad9f42506fa38e5d005427beef0c0 (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=abe5e4a93c0f0a2041cf670371c4b8604595ae59
commit abe5e4a93c0f0a2041cf670371c4b8604595ae59
Merge: 8afdd81 a4c6b4d
Author: Nils Gladitz 
AuthorDate: Mon Dec 14 17:29:06 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Dec 14 17:29:06 2015 -0500

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

a4c6b4d6 CMake: Mimic NSIS options dialog in WiX installer
de77d4a7 CPackWIX: Allow multiple patch files and diagnose if any are 
missing


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a4c6b4d6b17b430c23aab2f7452e4fe860244916
commit a4c6b4d6b17b430c23aab2f7452e4fe860244916
Author: Nils Gladitz 
AuthorDate: Thu Dec 10 23:55:07 2015 +0100
Commit: Nils Gladitz 
CommitDate: Mon Dec 14 23:28:44 2015 +0100

CMake: Mimic NSIS options dialog in WiX installer

diff --git a/CMakeCPackOptions.cmake.in b/CMakeCPackOptions.cmake.in
index 4ebf306..09568c3 100644
--- a/CMakeCPackOptions.cmake.in
+++ b/CMakeCPackOptions.cmake.in
@@ -234,10 +234,31 @@ 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(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/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;>
+   
+   
+   
+   
+   
+
+   
+   
+
+   
+
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+
+   1
+   
+
+   1
+
+   NOT Installed
+   Installed AND PATCH
+
+   1
+   LicenseAccepted = "1"
+
+   1
+   1
+   

[cmake-developers] [PATCH] CMakeParseArguments: Test suite and native implementation

[Matthias Männich]

Hi,

This is my pull request [1] brought to the list.

This adds a test suite for the CMakeParseArguments module. In addition
the second change implements cmake_parse_arguments(...) as native
command.

In our project we saw that cmake_parse_arguments is actually called a
lot of times due to macro expansion and we could almost halve our
configure time by using a native implementation of
cmake_parse_arguments. This implementation follows the implementation
of the former macro and both implementations of course pass the added
test suite.

I added a third change that makes cmake_parse_arguments() emit a
warning in case keywords are specified more than once. An error
instead actually would break compatibility (which is why I also made
it a separate commit) for some probably unused corner cases. But in my
opinion this improves the implementation as I assume that most of the
duplicate specifications are actual errors that else get silently
ignored. In a later CMake version one could even emit an error in this
case but as it would break compatibility it should be introduced along
with a policy.

Best regards,

Matthias

---

[1] https://github.com/Kitware/CMake/pull/202
From d34efe4001c289f20aee922881ec5c7f11c8b79d Mon Sep 17 00:00:00 2001
From: Matthias Maennich 
Date: Sat, 5 Dec 2015 19:02:19 +0100
Subject: [PATCH 3/3] cmake_parse_arguments: consider duplicate keyword as
 warning

The behaviour of double specified keywords is rather undefined or at
least not clearly documented. This change introduces a strict check and
emits a warning in case a keyword has been specified more than once.
---
 Help/command/cmake_parse_arguments.rst |  7 
 Source/cmParseArgumentsCommand.cxx | 16 +
 .../cmake_parse_arguments/Errors-stderr.txt| 42 --
 Tests/RunCMake/cmake_parse_arguments/Errors.cmake  | 10 ++
 4 files changed, 72 insertions(+), 3 deletions(-)

diff --git a/Help/command/cmake_parse_arguments.rst b/Help/command/cmake_parse_arguments.rst
index e497cae..134f72c 100644
--- a/Help/command/cmake_parse_arguments.rst
+++ b/Help/command/cmake_parse_arguments.rst
@@ -24,6 +24,13 @@ The  argument contains all keywords for this
 macro which can be followed by more than one value, like e.g. the
 ``TARGETS`` or ``FILES`` keywords of the :command:`install` command.
 
+.. note::
+
+   All keywords shall be unique. I.e. every keyword shall only be specified
+   once in either ,  or
+   . A warning will be emitted if uniqueness is
+   violated.
+
 When done, ``cmake_parse_arguments()`` will have defined for each of the
 keywords listed in ,  and
  a variable composed of the given 
diff --git a/Source/cmParseArgumentsCommand.cxx b/Source/cmParseArgumentsCommand.cxx
index f5492a3..0264e24 100644
--- a/Source/cmParseArgumentsCommand.cxx
+++ b/Source/cmParseArgumentsCommand.cxx
@@ -43,6 +43,10 @@ bool cmParseArgumentsCommand
   // anything else is put into a vector of unparsed strings
   std::vector unparsed;
 
+  // remember already defined keywords
+  std::set used_keywords;
+  const std::string dup_warning = "keyword defined more than once: ";
+
   // the second argument is a (cmake) list of options without argument
   std::vector list;
   cmSystemTools::ExpandListArgument(*argIter++, list);
@@ -50,6 +54,10 @@ bool cmParseArgumentsCommand
 end   = list.end();
 iter != end; ++iter)
 {
+if (!used_keywords.insert(*iter).second)
+  {
+  this->GetMakefile()->IssueMessage(cmake::WARNING, dup_warning + *iter);
+  }
 options[*iter]; // default initialize
 }
 
@@ -60,6 +68,10 @@ bool cmParseArgumentsCommand
 end   = list.end();
 iter != end; ++iter)
 {
+if (!used_keywords.insert(*iter).second)
+  {
+  this->GetMakefile()->IssueMessage(cmake::WARNING, dup_warning + *iter);
+  }
 single[*iter]; // default initialize
 }
 
@@ -70,6 +82,10 @@ bool cmParseArgumentsCommand
 end   = list.end();
 iter != end; ++iter)
 {
+if (!used_keywords.insert(*iter).second)
+  {
+  this->GetMakefile()->IssueMessage(cmake::WARNING, dup_warning + *iter);
+  }
 multi[*iter]; // default initialize
 }
 
diff --git a/Tests/RunCMake/cmake_parse_arguments/Errors-stderr.txt b/Tests/RunCMake/cmake_parse_arguments/Errors-stderr.txt
index 9835a22..748d1d0 100644
--- a/Tests/RunCMake/cmake_parse_arguments/Errors-stderr.txt
+++ b/Tests/RunCMake/cmake_parse_arguments/Errors-stderr.txt
@@ -1,16 +1,52 @@
-CMake Error at Errors\.cmake:1 \(cmake_parse_arguments\):
+CMake Error at Errors\.cmake:2 \(cmake_parse_arguments\):
   cmake_parse_arguments must be called with at least 4 arguments\.
 Call 

Re: [CMake] transitive dependencies (again)

[iosif neitzke]

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?

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

Re: [CMake] How to set _default_ timeout for the ctest command?

[Brad King]

On 12/09/2015 10:06 PM, Alan W. Irwin wrote:
> Also, the documentation of the ctest --timeout option says:
> 
> `--timeout `
>   Set a global timeout on all tests.
> 
> This option will set a global timeout on all tests that do not
> already have a timeout set on them.

Yes, one can see that implemented here:

 
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/CTest/cmCTestTestHandler.cxx;hb=v3.4.1#l1112
 https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmCTest.cxx#l2108

Here is a commit that set the order of precedence:

 Local test timeouts will now always take precedence over the global --timeout 
option.
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c32088cf

>From the history of that code it looks like --timeout was added with
no consideration of its relationship to CTEST_TEST_TIMEOUT.  Some
other CTest options in the same scope as CTEST_TEST_TIMEOUT can be
overridden by the command line, so I agree that --timeout should
override it too.

-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

Re: [CMake] NO_SYSTEM_ENVIRONMENT_PATH globally?

[Ray Donnelly]

On Mon, Dec 14, 2015 at 8:02 PM, Alan W. Irwin
 wrote:
> On 2015-12-14 12:43- Ray Donnelly wrote:
>
>> The issue I've got here is that on MSYS2 we've decided that we don't
>> want to provide libdl for mingw-w64 but do provide it for msys2, so
>> there'll never be a /mingw{64,32}/lib/libdl.a or
>> /mingw{64,32}/lib/libdl.dll.a, but there is a /usr/lib/libdl.a. When
>> building mingw-w64 software, the front of PATH will be
>> "/mingw64/bin:/usr/bin" or "/mingw32/bin:/usr/bin" and that causes
>> CMake to find /usr/lib/libdl.a due to NO_SYSTEM_ENVIRONMENT_PATH.
>
>
> Hi Ray:
>
> Did you mean "due to NO_SYSTEM_ENVIRONMENT_PATH _not_ being set"? That is
> the only way that sentence makes sense to me and is also
> consistent with the subject line, but I may be missing something.

Sure, that's what I meant.

>
> So if my interpretation of what you said is correct, your special
> build problem on the MinGW-w64/MSYS2 platform is you want to reject
> msys2 variants of the libraries (thus avoiding a dependency on the
> msys2 dll) while still using msys2 build tools.

Exactly.

>
> Assuming I have stated the problem correctly, then the solution
> normally is to put /mingw{64,32} first on your PATH (like the
> appropriate shell does as you have discussed) and that should
> guarantee the /mingw{64,32} version of the library is found.  However,
> for the special case where there is no /mingw{64,32} version of the
> library (from what you said above libdl is an example of this special
> case) the CMake-based build systems will incorrectly find the msys2
> version of the library (because msys2 is necessarily on the PATH
> because you need access to those build tools) rather than your desired
> result that CMake finds no library at all for this special case.
>
> I believe the MinGW-w64/MSYS2 distribution should address this problem
> in general by making sure that /mingw{64,32} does provide all
> libraries that msys2 provides if at all possible.  However, whenever
> there is some absolutely ironclad reason not to provide a
> /mingw{64,32} variant (as appears to be the case for libdl although
> you may want to review that reason to make sure it is really ironclad)
> then you must patch all build systems for software packages that have
> a soft dependency on libdl to simply ignore any libdl that is found on
> the MinGW-w64/MSYS2 platform.  My impression is that build system
> patches are required quite often for distributions of free software to
> help enforce some policy decisions they have made so it appears that
> MinGW-w64/MSYS2 is also not immune to such a requirement.  Of course,
> this is not a very good solution if there are tonnes of such package
> build systems to patch, but my guess is that patches for just a
> handful of packages would be required to deal completely with this
> special libdl case.

Generally speaking msys2 software is POSIX-y and mingw-w64 software is
Windows-y, so the library setup doesn't overlap very much and we won't
force it (actually we try to limit msys2 packages since Cygwin exists
to fill that need). We also want to apply as light a touch as possible
when it comes to patching software, but of course will when necessary.
For this issue, I think I've figured out what to do:

PATH=${MINGW_PREFIX}/bin:/usr/bin cmake -DCMAKE_SYSTEM_IGNORE_PATH=/usr/lib

>
> By the way, you will be glad to know that I have a strong spectator
> interest in MinGW-w64/MSYS2 because it turns out (thanks to the
> testing reports sent to me by Greg Jung which allowed me to adjust the
> PLplot build system to work properly for the MinGW-w64/MSYS2 case)
> that has recently become one of our most powerful and reliable PLplot
> platforms on Windows.
>

Great to hear. Hopefully MSYS2 can continue to prove useful and gain momentum.

>
> 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 

[CMake] Specifying dependencies in a project containing built-from-source artifact generators

[Andrey Mishchenko]

I have a project where I hope to build a binary, named `final_exe`. The
build directory where `final_exe` ends up needs to contain a file called
`final_resource` in order for `final_exe` to be considered "built."

The file `final_resource` is generated by another binary, called
`generating_exe`, which I also build from source as part of my project.
Furthermore, for `generating_exe` to be considered "built" or "usable," a
file called `generating_resource` needs to be present in the directory
where `generating_exe` ends up. The file `generating_resource` is, say,
copied verbatim from the source tree.

There are many binaries in the project whose builds depend on
`generating_exe` (and, transitively, on `generating_resource`) in this
manner.

I can't think of a way to express this dependency graph cleanly in CMake.

First, the easiest thing to do is to add `POST_BUILD` custom commands to
the `final_exe` and `generating_exe` targets. I don't like this approach,
for a couple of reasons. If the copy of `generating_resource` located in
the source tree changes, without some extra work the `POST_BUILD` custom
commands won't get called. Developers would need to somehow convince the
build system to re-link `generating_exe`. (I am not even clear about how to
work around this from within my project's CMake scripts.) Then, even once
`generating_exe` is rebuilt, the developer _again_ has to convince the
build system to re-link `final_exe` (and any other executable, library,
etc., that depends on `final_resource`) in order to obtain a correctly
updated build.

(Suppose that `final_resource` is not a CPP file, etc., so it is not
natural to shove it into the list of sources of `final_exe`.)

(The above problem can be summed up by asking, how do you create a custom
command in the flavor of, e.g., a `POST_BUILD` command invoking
`${CMAKE_COMMAND} -E copy_if_different`, but which will be re-run if the
"source files" of the custom command are modified?)

A nice(r) solution to the above problems would be to create a custom
target, called `copy_generating_resource`, which invokes `${CMAKE_COMMAND}
-E copy_if_different`, and which would be run every build (because those
are the semantics of custom targets). This approach actually solves the
above issues in a reasonable way, except for the following problem:

A natural definition of `copy_generating_resource` involves the use of
`$` to specify the directory into which to
place `generating_resource`, which would make `copy_generating_resource` a
dependency of `generating_exe`. It is natural that `final_exe` depends on
`generating_exe`. However `generating_exe` is not actually usable until
`copy_generating_resource` is run. Furthermore, we cannot even awkwardly
declare `copy_generating_resource` to be a dependency of `generating_exe`,
because there is already a dependency between these two targets going in
the other direction.

It is very annoying to insist that the author of the `CMakeLists.txt` file
corresponding to `final_exe` must be aware that he needs to encode that
`final_exe` depends on `copy_generating_resource` manually. If he fails to
do so, he risks `generating_exe` being run (to generate `final_resource`)
before it is actually usable, in particular, before
`copy_generating_resource` is run.

Am I missing something?

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