Re: [CMake] Centos8 FindICU problems

[Roger Leigh]

On 23/10/2019 14:43, Kent Williams wrote:

That works for me, but is this a documented thing anywhere?

On 10/22/19 4:22 PM, Roger Leigh wrote:

On 22/10/2019 21:51, Kent Williams wrote:


find_package(ICU REQUIRED)

It reports failure to find ICU, and I can't work out what I'm 
supposed to do:


    CMake Error at 
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 
(message):
      Failed to find all ICU components (missing: ICU_LIBRARY) 
(found version

      "60.2")
    Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:378 
(_FPHSA_FAILURE_MESSAGE)
      /usr/share/cmake/Modules/FindICU.cmake:317 
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)

      CMakeLists.txt:3 (find_package)
Any suggestions?


Hi Kent,


You need to specify the ICU libraries you want to link with as 
COMPONENTS.  E.g.


find_package(ICU REQUIRED COMPONENTS data i18n io tu)

If you don't specify any components, then it won't find any libraries 
at all and that will cause the check to fail which caused the above 
error.



Regards,

Roger


Hi Kent,

The components are all listed in the documentation: 
https://cmake.org/cmake/help/v3.16/module/FindICU.html


It doesn't directly say that you have to have at least one component, 
but since ICU is a collection of libraries it's implied that you need to 
specify the libraries you want. Not specifying any doesn't make sense 
since it's going to find nothing, and that's why it fails.



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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Centos8 FindICU problems

[Roger Leigh]

On 22/10/2019 21:51, Kent Williams wrote:


find_package(ICU REQUIRED)

It reports failure to find ICU, and I can't work out what I'm supposed 
to do:


    CMake Error at 
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 
(message):
      Failed to find all ICU components (missing: ICU_LIBRARY) (found 
version

      "60.2")
    Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:378 
(_FPHSA_FAILURE_MESSAGE)
      /usr/share/cmake/Modules/FindICU.cmake:317 
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)

      CMakeLists.txt:3 (find_package)
Any suggestions?


Hi Kent,


You need to specify the ICU libraries you want to link with as 
COMPONENTS.  E.g.


find_package(ICU REQUIRED COMPONENTS data i18n io tu)

If you don't specify any components, then it won't find any libraries at 
all and that will cause the check to fail which caused the above error.



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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] FindBoost Warnings

[Roger Leigh]

On 23/09/2019 14:05, Brad Bell wrote:


When the target system does not have boost, the user gets the warning:

CMake Warning at /usr/share/cmake-3.10/Modules/FindBoost.cmake:567 
(message):
  Imported targets and dependency information not available for Boost 
version

  (all versions older than 1.33)
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/FindBoost.cmake:907 
(_Boost_COMPONENT_DEPENDENCIES)
  /usr/share/cmake-3.10/Modules/FindBoost.cmake:1558 
(_Boost_MISSING_DEPENDENCIES)

  CMakeLists.txt:245 (FIND_PACKAGE)

This is not a problem because if the user's system does not have boost,
they will no be using the case that the examples cover.

How do I suppress this warning ?


I think it's already fixed in more recent CMake versions.  It now only 
prints that message when Boost is found, and older than 1.33.



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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Automatically updating Doxygen documentation and making it readily available to users with CMake

[Roger Leigh]

On 21/02/2019 14:18, Timothy Wrona wrote:
Perhaps there is a standard location to "install" the documentation when 
running the install command for a project?


This collection builds and installs the documentation into a standard 
location, as well as reporting undocumented code.  Feel free to copy and 
adapt.  Could be turned into an official module if there was interest 
for a generic solution for doxygen docs building and installing.



https://gitlab.com/codelibre/ome-common-cpp/blob/master/docs/doxygen/CMakeLists.txt


https://gitlab.com/codelibre/ome-common-cpp/blob/master/docs/doxygen/api.dox.cmake


https://gitlab.com/codelibre/ome-common-cpp/blob/master/cmake/Doxygen.cmake


https://gitlab.com/codelibre/ome-common-cpp/blob/master/cmake/DoxygenCheck.cmake

Dependent modules can also cross-reference documentation for modules 
they depend upon.  See lines 44-56 for overriding the tagfiles, which 
are then substituted into the generated doxyfile configuration.  This 
could also be generalised to make into a reusable module.



https://gitlab.com/codelibre/ome-files-cpp/blob/master/docs/doxygen/CMakeLists.txt

You can see this on the GitLab documentation pages (linked from the 
README) for the project(s) in question.


Hope that's potentially of some use for anyone interested.


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:
https://cmake.org/mailman/listinfo/cmake

Re: [cmake-developers] Hi and issues with FindBoost

[Roger Leigh]

On 04/02/2019 10:10, Robert Sawko wrote:

I couldn't find a dedicated bug tracker for cmake modules.


https://gitlab.kitware.com/cmake/cmake/issues/

It's the same bug tracker as for the rest of CMake, since it's all a 
single codebase.  If you put "FindBoost: " as the prefix of the issue 
title, and maybe add me as the assignee, I'll see it that way.



I am happy to get involved in the maintenance, but would probably need a
guiding hand.


That's absolutely fine and would certainly be appreciated by me and the 
other people who work on FindBoost.  If you open a merge request, we'll 
be happy to review it and make any suggestions for how it could be 
improved if you're new to working on it (I certainly benefit from and 
appreciate the advice and suggestions of people more experienced than 
myself with CMake details).



Originally, I've written up my issue on SO originally, but had no
response:

https://stackoverflow.com/questions/54205073/boost-root-not-respected-at-link-stage-after-cmake-config


This does seem odd.  It should be using absolute paths to the libraries. 
 Which version of CMake are you using?  I notice the minimum version is 
very old (2.8).  Have you tried a current 3.x release which will have a 
newer version of FindBoost which will also support imported targets like 
"Boost::program_options"?


As an example, this is what I get locally (with cmake 3.12) in 
CMakeCache.txt:


//Boost program_options library (debug)
Boost_PROGRAM_OPTIONS_LIBRARY_DEBUG:FILEPATH=/usr/lib/x86_64-linux-gnu/libboost_program_options.so

//Boost program_options library (release)
Boost_PROGRAM_OPTIONS_LIBRARY_RELEASE:FILEPATH=/usr/lib/x86_64-linux-gnu/libboost_program_options.so

That will result in unambiguous linker options being passed.  You 
/should/ be seeing something similar, which is why I questioned the 
version of CMake you were using.



Kind 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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [CMake] Modern cmake advise for transitive library dependencies

[Roger Leigh]

On 18/12/2018 20:54, Craig Scott wrote:


Your XConfig.cmake is responsible for also ensuring all targets it 
depends on are defined. This shouldn't be left up to consumers of X. The 
way this is normally done is pretty much as Alan suggests (it's also the 
way I handle cases analogous to yours in our projects at work). There's 
even a find_dependency() 
 
command intended for precisely this situation to make it a little 
easier, although I generally advise against using it for packages that 
support components due to the way a particular optimisation in its 
implementation affects later find_dependency() calls for the same package.


Can't we drop this optimisation and fix find_dependency, making it 
properly usable?  I've tested a few of the modules using components to 
see if they behave correctly with different sets of components, and I've 
not yet encountered any problems due to calling multiple times.


In consequence, I wonder if we could simply drop the "optimisation" and 
have find_dependency do nothing more than be a thin wrapper around
find_package.  This would solve the problems and should not break 
backward compatibility.


The only difference would be if the first find_package call succeeds and 
subsequent calls fail, which would alter the value of _FOUND.  However,

that's likely exactly what one should expect.


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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] dependencies on system include files

[Roger Leigh]

On 17/12/2018 15:37, David Blaikie wrote:
On Sun, Dec 16, 2018, 4:24 PM Kris Thielemans 
mailto:kris.f.thielem...@gmail.com> wrote:


I’ve just had a problem caused by an upgrade of my system files (in
this particular case: boost). Rebuilding our software didn’t
correctly rebuild those files that depend on the updated boost
files. (I’m using CMake 3.9 with make on Ubuntu 16.04)

Checking a bit more carefully it appears that the system .h files
are not included in depend.make. I guess this is done to save some
time checking all those dependencies as system files are supposed to
be relatively stable, but if they’re not, it creates trouble of
course.

Is there any way to change this behaviour? (ideally something like
for one time only, check if dependent system include files are more
recent then what was compiled, but that’s a stretch of course).


> If you're willing to run a different command or flag when rebuilding
> after upgrading system libraries, I would guess the thing to do would be
> to do a clean and rebuild, perhaps?

This is unfortunately insufficient.  After upgrading any system 
libraries you will have to clean everything, including the CMake cache, 
and re-run CMake from a clean build tree, then rebuild everything.


The reason for this is that the cache contains the results of 
find_library etc., and these may have changed as a result of the system 
upgrade.  However, the cached values may be used despite this.  It's 
safest to start from a clean slate.


For example, if you upgraded boost from 1.6x to 1.69 Boost.Filesystem 
dropped its dependency upon Boost.System, which is no longer a library 
(it's header-only).  This would result in a link failure.  I've not 
specifically tested this case to see if it would cope, but there is 
plenty of stuff cached which could potentially cause problems, and the 
solution to drop the cache is simple.  I wouldn't want to risk the 
integrity of the build due to the potential for subtle inconsistency 
between the cache and the system.  After you've upgraded the system, 
it's essentially a different system.



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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Can an option enforce a default, even if cache is present?

[Roger Leigh]

On 27/11/2018 13:49, Mario Emmenlauer wrote:


I've just discovered that option() behaves differently than I anticipated.
After reading the docs and searching with google I'm still confused how to
achieve my desired behaviour.

What I've just learned is that unspecified options take their cached value
and do *not* go back to their default value, if a cache exists. I assumed
that options take their default when not explicitly specified.


I think this is exactly what happens.  For example, an example I quickly 
dug out is this:


# Doxygen documentation
find_package(Doxygen)
set(DOXYGEN_DEFAULT OFF)
if (DOXYGEN_FOUND AND DOXYGEN_DOT_FOUND)
  set (DOXYGEN_DEFAULT ON)
endif (DOXYGEN_FOUND AND DOXYGEN_DOT_FOUND)
option(doxygen "Enable doxygen documentation" ${DOXYGEN_DEFAULT})
set(BUILD_DOXYGEN ${doxygen})

which causes this to be set in the cache:

//Enable doxygen documentation
doxygen:BOOL=ON

In this case, doxygen and dot were installed.  But if one was missing, 
it would default to "OFF" and this would be set in the cache.  If the 
user noticed it was missing, installed it, then re-ran cmake, the cached 
value would not be changed even though the default set with option() 
changed in the meantime.


From the look of things, there's no metadata in the cache to say "this 
was defaulted; the user did not specify it explicitly".  If such 
metadata did exist, the option() call could check it and overwrite the 
cached value if the user had not explicitly set the option.  This would 
make cmake much more conveniently adaptable.


The cache already stored extra properties for ADVANCED.  Could we add a 
similar extra property for DEFAULTED?  I.e.


//DEFAULTED property for variable: doxygen
doxygen-DEFAULTED:INTERNAL=1

Perhaps with a mark_as_defaulted() function to mirror 
mark_as_advanced().  Or a DEFAULT option for set_property() and/or a 
DEFAULT option as the opposite of FORCE for set().  This would only set 
the cache value if unset, plus add the DEFAULTED property.  The 
difference in behaviour would that if DEFAULT is used AND DEFAULTED=ON 
then the value would be overwritten if changed.



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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Java not found

[Roger Leigh]

On 20/11/2018 01:02, szukw000 wrote:

cmake-3.12.4 did find the correct version:

-- Found Java: /usr/lib64/java/bin/java (found version "11.0.1")

But the cmake Module FindJava.cmake fails with this warning:

---
warning: [options] bootstrap class path not set in conjunction with 
-source 5

error: Source option 5 is no longer supported. Use 6 or later.
error: Target option 1.5 is no longer supported. Use 1.6 or later.


Java /was/ found correctly.  The problem is that Java 11 is not capable 
of compiling Java 5 (or 6, or 7) sources.  Java 11 can only compile Java 
8+ sources.


You need to either

- use an older JDK
- update the source and target versions to a minimum of 1.8

Since all the JDK versions supporting 1.5 are long out of support, I'd 
recommend the latter.  You might need some small source adjustments to 
fix up any obsolete feature removals or behaviour changes.



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:
https://cmake.org/mailman/listinfo/cmake

Re: [cmake-developers] module proposal: PreventInSourceBuilds

[Roger Leigh]

On 09/11/2018 10:34, Joachim Wuttke wrote:

In all my projects, the top-level CMakeLists.txt contains the line

include(PreventInSourceBuilds)

to protect users (and myself) from unintentionally running CMake
in the source directory.


I for one have an equivalent to this logic in all my projects to prevent 
in-source builds.  Having a standardised version would be very useful, 
and I would certainly make use of it.



Thanks,
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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [CMake] Docker container can't find cmake executable

[Roger Leigh]

On 30/10/2018 15:41, Osman Zakir wrote:

I put this command in the Dockerfile:
"
RUN mkdir $HOME/usr \
     && wget -O cmake-linux.sh 
https://cmake.org/files/v3.12/cmake-3.12.3-Linux-x86_64.sh \​

     && sh cmake-linux.sh -- --skip-license --prefix=$HOME/usr \​
     && cd $HOME/usr \​
     && ls \​
     && export PATH=$HOME/usr/bin:$PATH
"
But when it gets to running CMake, it can't find the executable.  Please 
help.


This is a docker question, nothing to do with cmake.  You need to use 
the ENV directive, not RUN.  The export you have here has no effect 
after the command finishes.



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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Installing CMake in Ubuntu Linux from command-line via wget

[Roger Leigh]

On 30/10/2018 10:56, Osman Zakir wrote:

Okay, thanks.

So how about this as the command?

"
RUN wget https://cmake.org/files/v3.12/cmake-3.12.3-Linux-x86_64.tar.gz  \
     && tar xzf cmake-3.12.3-Linux-x86_64.tar.gz  \​
     && rm -rf cmake-3.12.3-Linux-x86_64.tar.gz  \​
     && cd cmake-3.12.3-Linux-x86_64  \​
     && apt-get install \​
     && ./bin/cmake --version
"
I think I'll need the apt-get install part to install the library.  Is 
this true?


No.  Just add the bin directory to your PATH.

apt-get is only required when installing packages provided by the 
package manager.  It has nothing to do with installing archives you 
download.



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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Specifying Boost or third-party library paths to CMake

[Roger Leigh]

On 29/10/2018 13:49, Osman Zakir wrote:
How do I specify the path to the installations of third-party libraries 
to CMake?  Both GUI and command line.  I want to specify the path to the 
Boost libraries.  I'd also like to know if I just need to specify the 
path to the Boost Root or if I also need to specify the path to the 
directory where the compiled binaries are.  Or both.


Use -DCMAKE_PREFIX_PATH:PATH=/path/to/boost:…

The root directory is sufficient; the other paths will all be found 
relative to this location.

--

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake Can't Find Boost.Filesystem in Docker Container

[Roger Leigh]

On 28/10/2018 10:26, Osman Zakir wrote:
I'm creating a new email thread for this because the other thread's 
problem was already solved.


In the Dockerfile for my project, the build process can't go any farther 
from the point where I'm trying to build the Jinja2Cpp library.  CMake 
isn't able to find Boost.Filesystem, but it's still able to build the 
library and write the files to "/usr/local/Jinja2Cpp/build" just fine.  
But the Docker build process exits with a return code of 1 at that point 
due to the two CMake errors generated.  I've attached the text file I'd 
written documenting the CMake errors in question.


Should I delete the Docker images and containers created from previous 
attempts of building this Docker image, just in case there might be some 
problem there?  I did try deleting all Docker images and containers I 
had locally before trying to build the Dockerfile again, but had the 
same problem.


You will need to investigate why Boost.Filesystem was not found.  If you 
take a look at the various builds in this example repository: 
https://gitlab.com/codelibre/ome-common-cpp/pipelines/34467308
you will see FindBoost tested on a range of compilers and platforms, 
including three different Linux distributions in docker containers. 
It's working in all cases.


Firstly, check that the filesystem library is installed, both runtime 
and development packages.  FindBoost checks for the presence of both the 
headers and the library itself; both are required for it to be 
considered "found".


CMake Warning at /usr/share/cmake-3.10/Modules/FindBoost.cmake:801 
(message):

  New Boost version may have incorrect or missing dependencies and imported
  targets

This warning can be a minor warning if you have a slightly newer version 
of Boost which CMake isn't yet aware of explicitly.  Should be totally 
fine for an older component like Boost.Filesystem.  But it might also 
indicate a deeper problem.  You could also download and try the most 
recent stable release of CMake, which would likely have better support 
for newer Boost releases.


Are you using the Boost provided by the distribution (which distribution 
version and Boost version)?  Or a newer or custom build of Boost?


As suggested, run with -DBoost_DEBUG=ON and look through the search 
paths.  See why Boost isn't being picked up.  Also look at the CMake 
error log.



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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Problem with FindXercesC.cmake

[Roger Leigh]

On 27/09/18 22:55, Mateusz Loskot wrote:

On Thu, 27 Sep 2018 at 23:34, Dorier, Matthieu  wrote:


When I call find_package(XercesC REQUIRED) and XercesC is not in a standard 
location, I have to set XercesC_INCLUDE_DIR to its include directory and 
XercesC_LIBRARY to the location of the library.


[…]


I use to rely on a custom FindXercesC.cmake file that was using XercesC_ROOT to 
figure all this out.
Is there any way to do the same here?


There seem to be no Xxx_ROOT_DIR handled by this module
https://cmake.org/cmake/help/latest/module/FindXercesC.html


No, but CMAKE_PREFIX_PATH should be sufficient.  We can certainly add 
XercesC_ROOT, but is it really needed?  Matthieu, did you try 
CMAKE_PREFIX_PATH at all?


(I'm not sure what the CMake policy is on this point.  Is 
CMAKE_PREFIX_PATH support alone sufficient for Find modules?)


If the consensus is that Find modules should all provide ROOT_DIR type 
variables, then I'm sure patches to FindXercesC and FindXalanC would be 
appreciated.



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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Fwd: Boost + CMake + Windows + Sanity -> Possible?

[Roger Leigh]

On 08/08/18 12:39, Chris Wilson wrote:

Having set BOOST_ROOT, FindBoost should just work.

In this case, I didn't need to compile any of Boost, only its headers, 
but if you do need to, then you can change its CONFIGURE_COMMAND and 
BUILD_COMMAND.


Portable build and configure commands can be found here: 
https://github.com/ome/ome-cmake-superbuild/tree/master/packages/boost


There are plenty of other examples as well if you have a search around.

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] LD_LIBRARY_PATH not used by the linker

[Roger Leigh]

It's the quick and easy way to do it.

However, I'd suggest looking at getting CMake to use the proper path 
without it.  Can you use any module-specific variables like 
PYTHON_LIBRARY to override the search.  Or even just add to 
CMAKE_PREFIX_PATH.  (Does VTK support imported targets?)


Regards,
Roger

On 02/08/18 20:43, Ruben Di Battista wrote:

Hi Roger,
so I explicitly passing the LDFLAGS is the way to go?

On Thu, Aug 2, 2018 at 9:41 PM Roger Leigh <mailto:rle...@codelibre.net>> wrote:


On 02/08/18 20:03, Ruben Di Battista wrote:

 > I'm running cmake on a system where I have module-loaded software
such
 > that `LD_LIBRARY_PATH` gets populated by the module (actually I'm
using
 > Lmod) function.

LD_LIBRARY_PATH is used by the *runtime* linker, ld.so.  It is not used
when linking at *build* time, with ld.

--

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] LD_LIBRARY_PATH not used by the linker

[Roger Leigh]

On 02/08/18 20:03, Ruben Di Battista wrote:

I'm running cmake on a system where I have module-loaded software such 
that `LD_LIBRARY_PATH` gets populated by the module (actually I'm using 
Lmod) function.


LD_LIBRARY_PATH is used by the *runtime* linker, ld.so.  It is not used 
when linking at *build* time, with ld.



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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake: using dlopen

[Roger Leigh]

 Original message From: Franck Houssen 
<franck.hous...@inria.fr> Date: 07/01/2018  13:58  (GMT+00:00) To: Roger Leigh 
<rle...@codelibre.net> Cc: cmake@cmake.org Subject: Re: [CMake] CMake: using 
dlopen 
> OK, thanks. So, I go with: target_link_libraries(main PUBLIC ... 
> ${CMAKE_DL_LIBS})

Use PRIVATE if it is not used in any headers--it's an internal implementation 
detail.
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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake: using dlopen

[Roger Leigh]

On 06/01/18 17:01, J Decker wrote:
CMake/shared/modules will define the CMAKE_DL_LIBS  which a very high 
percentage of the time will just be library 'dl' .


Pretty much any man page on dlopen defines 'dl'


On Linux.  On MaxOSX and FreeBSD not at all, where the dl functions are 
in libSystem and libc, respectively.  Using CMAKE_DL_LIBS does the right 
thing on all platforms (though I wish it was an imported target to make 
exports a bit nicer).



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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Adding compile and build type tests to CMake/CTest

[Roger Leigh]

On 04/09/17 14:40, Edward Diener wrote:
Boost Build has tests for running an application successfully or not, 
for compiling one or more source files successfully or not, and for 
building one or more source files into an exe or not. These tests in 
Boost Build are the run/run-fail, compile/compile-fail, and 
link/link-fail rules.


CMake/CTest has the exact equivalent to the run/run-fail rule in its 
add_test framework, but there is not add_test equivalent to the other 
two sets of rules. It sure would be nice, when Boost transitions to 
using CMake/CTest instead of Boost Build, if CMake/CTest had the 
equivalent of the other two sets of types of test in its add_test 
framework.


Is there any consensus that these other two types of tests might be 
valuable for CMake/CTest, or any way to make this happen ?


I've certainly wished for them.  Particularly when testing templated 
code where you want to test that certain things fail correctly, e.g. via 
static_assert or simply being invalid.


I understand it's possible to make this work partially, by creating 
targets which aren't built by default, and then add tests which invoke 
the targets.  But this appears to have some caveats, such as potential 
misbehaviour with parallel testing.  Or you can have a separate CMake 
build for each individual target, but it's extra complexity.  Having a 
proper means of registering such tests would be very, very nice.



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

Re: [CMake] FindIce module and C++11

[Roger Leigh]

On 11/08/17 20:15, Rolf Eike Beer wrote:

Am Donnerstag, 10. August 2017, 10:28:31 schrieb rle...@codelibre.net:

On 2017-08-10 09:50, Jones J.W. wrote:

I'm building my code on Linux using the g++ flags "-std=c++11". This
means that I must link with the libIce++11 libraries instead of
libIce.

The FindIce module, however as no provision for choosing these
libraries thus resulting in unresolved symbols at link time.

I tried getting around the problem by simply listing Ice++11 as a
COMPONENT which works in Linux but the same CMakeLists.txt file in
Windows won't work as there is no Ice++11. Currently I have resolved
this by having two calls to the FindIce module inside an IF( MSVC )
conditional.

Would it be possible to add a flag to tell the FindIce module whether
C++11 is being used or not?


FindIce certainly needs an update for Ice 3.7.


To me this smells like an imported target with a generator expression that
uses the C++11 or other lib depending on the used interface of the target. No
idea if that is possible, but that would be the direction I would search in.


I'm unsure, but I suspect it's not appropriate.  I'm currently treating 
them as separate libraries because whether C++11 is used by the compiler 
is orthogonal to whether you're using the C++11 Ice API (and code 
generator).  Ice generates language-specific interfaces and 
implementations from abstract definitions, and it treats C++ and C++11 
as essentially different languages.  You need to explicitly opt into 
using C++11 in the interface definitions for code generation, and with 
respect to which libraries you link to.


For anyone using Ice who would like to test, I've opened
  https://gitlab.kitware.com/cmake/cmake/merge_requests/1137for testing 
and review.  Would be helpful if anyone wanting to use Ice 3.7 could 
give it a try, but equally if you're using 3.[3456] it would be great to 
know if there are any regressions.  I'll be testing Ice 3.5, but no 
longer have any of the others lying around (3.3 can probably be removed, 
it's so old and unsupported).



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

Re: [CMake] C++ standard version fallbacks.

[Roger Leigh]

On 05/06/17 23:50, Stephen Kelly wrote:

Craig Scott wrote:


On Tue, Jun 6, 2017 at 7:50 AM, Stephen Kelly
<steve...@gmail.com> wrote:


Roger Leigh wrote:


Hi folks,

I'm currently using this logic to use C++14 with a fallback to C++11
when C++14 is unavailable:

if(NOT CMAKE_CXX_STANDARD)
  set(CMAKE_CXX_STANDARD 14)
endif()
if(NOT CMAKE_CXX_STANDARD_REQUIRED)
  set(CMAKE_CXX_STANDARD_REQUIRED 11)
endif()

which seems to work OK.

However, for some new stuff, I'd like to use C++17 when available, but
fall back to C++14, C++11 or C++98.  Is it possible to do this?


Probably set CMAKE_CXX_STANDARD

without CMAKE_CXX_STANDARD_REQUIRED (That variable doesn't really make
sense
to me and I think it is overused when not needed).



If you don't set CMAKE_CXX_STANDARD_REQUIRED, then there's no guarantee
you get any particular minimum standard.


He wants to fall back all the way to C++98. Am I missing something?


No, that's exactly what I want.  I'd like to have the compiler put into 
the highest mode possible and then do feature tests for various things. 
For example, try std::thread and fall back to boost or POSIX/Win32 
threads if not available.  Not setting CMAKE_CXX_STANDARD_REQUIRED seems 
to be all that's required, so that solves my problem nicely.



Roger's example (sorry Roger!)
highlights part of the confusion about this latter variable (and the
target property it ultimately controls). He appears to be setting it
expecting it to specify a minimum version, but that's not how it works. It
is expected to be a boolean which says whether CMAKE_CXX_STANDARD must be
honoured or not, which most developers (myself included) tend to find
unintuitive.


Ok.


Yes, I misread the documentation here, and I think I also picked it up 
by reading someone else's (broken) example.  I've now fixed up my code 
to work according to the documented behaviour.  Thanks everyone for the 
corrections and suggestions in this thread.



I remember I was opposed to introducing CMAKE_CXX_STANDARD_REQUIRED in the
first place as I think it is redundant. I recommend populating compile
features for whatever you absolutely need and let cmake populate the std
flag. If your code can benefit from a more-recent std flag than the
requirement, then set CMAKE_CXX_STANDARD to that.


Roger's use would actually make it a bit better, if that was
how it worked, but unfortunately there's currently no way to set a
*minimum* standard version,


If you have a minimum, then you must be relying on some language features
existing and you can list those.


This would make sense, and I'll look at doing that.

I'm still not 100% sure that the behaviour is as good as it could be 
though.  Some scenarios:


1) I set CMAKE_CXX_STANDARD to 17.  This is unsupported and it falls 
back to 14.  Is the fallback introspectable?  Can I query that the 
fallback happened/is going to happen?


2) I do a check for  which succeeds, and I use it in a 
configuration header, but this later fails to build because it's only 
usable in C++11 mode, and if I set CMAKE_CXX_STANDARD to 98 it fails.


I know the *requested* standard version.  But I don't know the 
*effective* standard version, and I need to know that at cmake time.


Much of the standard version selection is based upon setting the minimum 
set of required compile features and having cmake put the compiler in a 
mode appropriate to support that featureset.  What I'd like to do here 
is the opposite: I want to dynamically adjust the features I use by 
gracefully falling back to alternative implementations based upon my own 
feature testing.  But I can't see how I can ask that question of CMake 
even by getting the appropriate target properties; these look like they 
are the requested version as well, do they ever get turned into the 
effective version?


I'm sure I can work around the lack with some more sophisticated feature 
tests if required, e.g. compile checks rather than header checks.



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

[CMake] C++ standard version fallbacks.

[Roger Leigh]

Hi folks,

I'm currently using this logic to use C++14 with a fallback to C++11 
when C++14 is unavailable:


  if(NOT CMAKE_CXX_STANDARD)
set(CMAKE_CXX_STANDARD 14)
  endif()
  if(NOT CMAKE_CXX_STANDARD_REQUIRED)
set(CMAKE_CXX_STANDARD_REQUIRED 11)
  endif()

which seems to work OK.

However, for some new stuff, I'd like to use C++17 when available, but 
fall back to C++14, C++11 or C++98.  Is it possible to do this?


- I'd like it to work on older CMake versions where "17" isn't a valid 
version for the above; is there any way to introspect the supported 
standards?
- And I'd like it to fall back intelligently, i.e. if 17 isn't available 
I want it to select the newest standard possible, rather than falling 
back all the way to 98


Any suggestions?


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

Re: [cmake-developers] Trouble with FindPNG module

[Roger Leigh]

On 24/04/2017 19:30, Ben Boeckel wrote:

On Mon, Apr 24, 2017 at 19:17:39 +0100, Roger Leigh wrote:

Sounds like that's exactly the problem.  You can only have one libpng
*development* package installed at once.  You probably want the regular
"libpng-dev" package installed if you want to build against the standard
libpng.


Ah, this is before the multiarch split from Debian came into Ubuntu? I'm
so used to Red Hat's lib64 split (multilib) (which, admittedly, has its
drawbacks in light of multiarch).


Yes, this is exactly the case.  There are actually four development 
packages which could be installed:


libpng-dev:amd64
libpng-dev:i386
libpng12-dev:amd64
libpng12-dev:i386

And that's not counting the other architectures which could /also/ be 
installed as well, e.g. libpng-dev:powerpc, libpng12-dev:armel etc.


While you can install as many of the runtime packages as you like, the 
headers go into /usr/include and so they conflict with each other, 
limiting you to a single development package at one time (checked the 
behaviour to verify this, and installing one triggers removal of any 
existing variant).  Not itself a multiarch limitation--many packages now 
use /usr/include/ for this reason--but certainly a limitation in 
the packaging of the current libpng, which for some reason hasn't yet 
started using arch-specific headers.


This is almost certainly why FindPNG fails.  The headers are found, but 
the library is missing since it's in the arch-specific lib path for the 
other architecture, and the compiler isn't using that path by default.



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

Re: [cmake-developers] Trouble with FindPNG module

[Roger Leigh]

On 24/04/2017 15:54, Robert Dailey wrote:

Sorry to bump; any info on this? I'm completely blocked :-(

On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey  wrote:

I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:

find_package(PNG REQUIRED)

Which gives me the output in CMake:

Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50")

The CMakeCache.txt file has these variables set:

PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND
PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND
PNG_PNG_INCLUDE_DIR:PATH=/usr/include

So it found the headers, but not the libs. Why did it not find the
libs? Note that my version of Ubuntu is 64-bit, and I've installed the
32-bit libs like so:

$ sudo apt-get install libpng12-dev:i386

Would the find module be confused because it is trying to find the
64-bit library? What's the issue?


Sounds like that's exactly the problem.  You can only have one libpng 
*development* package installed at once.  You probably want the regular 
"libpng-dev" package installed if you want to build against the standard 
libpng.


What's your goal here?  Why did you install a single i386 development 
package?


If you want to build i386 binaries, it's usually simpler to build in a 
virtual machine, i.e. a chroot, container, full VM or whatever you like, 
where you have a fully 32-bit environment.  The multiarch library 
support is primarily intended for *deploying and running* 32-bit code 
rather than development.  While you can use it for development, it gets 
painful due to the conflicts with the headers and other bits in the 
native development packages.



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

[cmake-developers] Support for version suffixes

[Roger Leigh]

Hi folks,

I'd like to bring this issue to your attention to canvas some feedback 
regarding the use of version suffixes:


  https://gitlab.kitware.com/cmake/cmake/issues/16716

This is basically a proposal to allow an optional version suffix like 
"-rc3", "-beta1" etc. in addition to the existing 
major.minor.patch.tweak pattern, for better interoperability with 
systems and software releases already using such suffixes, and also to 
permit the use of such suffixes by CMake projects for their own 
purposes.  A version suffix would be usable anywhere currently using 4 
digit versions, with all the necessary functionality in CMake being 
updated to handle this.


The proposal linked above contains a much more detailed rationale and 
suggested implementation strategy.  I'd be very happy to hear any 
thoughts anyone has regarding this either on the above issue, or here.



Thanks all,
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-developers

Re: [CMake] CMake with VS2015 C++ Build Tools and missing ucrtbased.dll

[Roger Leigh]

On 10/03/2017 16:47, TT wrote:

I'm having the same problem with "missing" ucrtbased.dll even though it is
present in all the platforms under C:\Program Files (x86)\Windows
Kits\10\bin\

I have tried reinstalling the Windows SDK and the Microsoft C++ Build Tools
(2015).


From Andrew Pardoe: "It turns out that the Build Tools SKU only 
installs the universal CRT for developers on Windows 10. We should have 
had it install on all OS. We'll fix this in the next release."  From a 
private reply from this thread: 
https://www.reddit.com/r/cpp/comments/4r8n41/what_are_some_reasons_why_visual_studio_seems_so/d51sh2f/?context=3


It's a bit broken.  The 2017 version seems OK though.


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

Re: [CMake] Adding a link?

[Roger Leigh]

On 06/03/2017 12:43, Bernhard Seckinger wrote:

Hi all,

I've got a project where meanwhile everything works, using cmake, but a tiny
detail. I've got a frontend which consists of several php files. I copy them
into a subfolder of share/ with the install command. Now I need a symlink from
bin/croco to share/croco/main.php that is, after installing everything else "ln
-s share/croco/main.php bin/croco" should be executed.

I know, that symlinks are not available in some other OSs, but for the time
being, I only need a solution, that works using linux.

What I found so far is:

add_custom_command(OUTPUT bin/croco
   COMMAND ln -s share/croco/main.php bin/croco
   DEPENDS share/croco/main.php)

But that seems to be ignored by "make install". Can you help me?


bzip2 example (from 
https://github.com/ome/ome-cmake-superbuild/blob/master/packages/bzip2/patches/cmake.diff#L163)


# Copy or symlink bunzip2 and bzcat to bzip2
if (WIN32)
install(CODE "configure_file(\"${CMAKE_INSTALL_FULL_BINDIR}/bzip2.exe\"

\"${CMAKE_INSTALL_FULL_BINDIR}/bunzip2.exe\"
 COPYONLY)"
COMPONENT "runtime")
install(CODE "configure_file(\"${CMAKE_INSTALL_FULL_BINDIR}/bzip2.exe\"
 \"${CMAKE_INSTALL_FULL_BINDIR}/bzcat.exe\"
 COPYONLY)"
COMPONENT "runtime")
else()
install(CODE "execute_process(COMMAND \"${CMAKE_COMMAND}\" -E
create_symlink bzip2
\"\$ENV{DESTDIR}${CMAKE_INSTALL_FULL_BINDIR}/bunzip2\")"
COMPONENT "runtime")
install(CODE "execute_process(COMMAND \"${CMAKE_COMMAND}\" -E
create_symlink bzip2
\"\$ENV{DESTDIR}${CMAKE_INSTALL_FULL_BINDIR}/bzcat\")"
COMPONENT "runtime")
endif()


Hope that's useful as an example,
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

Re: [cmake-developers] Boost 1.63 support

[Roger Leigh]

On 27/12/2016 14:34, Gregor Jasny via cmake-developers wrote:

Hello,

On 27/12/2016 13:20, Roger Leigh wrote:

I opened the following merge request to add support for the
newly-released Boost 1.63:

  https://gitlab.kitware.com/cmake/cmake/merge_requests/361


I wonder what's the reason for stating explicitly all the released
versions? It they are necessary at all, couldn't they be added in
speculative batches of 10 or so?


It would certainly be possible to add additional versions ahead
of time.  What would be more difficult are the component dependencies, 
which are needed for the imported targets.


That said, the dependency introspection script can compute these on the 
fly, at the expense of taking several minutes to grind through all the 
sources and headers.  We could potentially fall back to computing them 
if the embedded dependency information is missing, though it does make 
assumptions about the autolink macros in the headers--if they ever 
changed then it would need updating.


Fundamentally, the current approach is an overly complicated hack to 
work around the fact that Boost has never exported this information in a 
form consumable by any build system, leading to projects hardcoding all 
this information (or doing it in a single place as here).



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

[cmake-developers] Boost 1.63 support

[Roger Leigh]

I opened the following merge request to add support for the 
newly-released Boost 1.63:


  https://gitlab.kitware.com/cmake/cmake/merge_requests/361


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

Re: [CMake] cmake vs. Python 3.4

[Roger Leigh]

On 23/12/16 20:53, Alan W. Irwin wrote:

On 2016-12-23 20:57+0100 Lev wrote:


Hi list,


I have this:

FIND_PACKAGE(PythonInterp)

and cmake finds this:

-- Found PythonInterp: /usr/bin/python (found version "2.7.9")

However, 3.4 is also installed. How can I specify to find 3.4?

If I say:

set(Python_ADDITIONAL_VERSIONS 3.4)
FIND_PACKAGE(PythonInterp 3 REQUIRED)

still no luck.

This is on a Debian stable, so

$ cmake --version
cmake version 3.0.2


Try using the update-alternatives command so that "python" becomes
symbolically linked to python-3.4 rather than python-2.7.9

Or uninstall python 2.7.9.


This seems a little drastic; I wouldn't expect to have to alter the 
system for cmake to do what I want.  Does FindPython not have logic to 
check the versioned pythonx.y alternatives when doing these checks?  Why 
isn't it checking the python3 and python3.x commands in this circumstance?


Or, give the incompatibility here, do we need a separate 
FindPython3Interp and equivalents so that we can find Python 2 and 3 
version of the executable and libs independently.  This is something 
which has been bugging me for a while since the current behaviour seems 
somewhat unsatisfactory.



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

Re: [CMake] Find packages coming from homebrew

[Roger Leigh]

On 23/11/16 14:55, Cedric Doucet wrote:


Hello,

I would like to write some FindFoo.cmake files to find packages
installed on different systems including Mac.
I have noticed that homebrew install packages in a repertory whose name
depends on the version of the package.
For example, I have installed a scientific library called scotch, and it
is now installed here:

/usr/local/Cellar/scotch/6.0.4_4


You should never need to use the Cellar directories directly.  It should 
also be linked under /usr/local/opt/scotch *and* linked directly into 
/usr/local.


When writing a FindFoo.cmake file, you shouldn't need to do anything 
special to handle this.  Just find the headers and libraries as usual.


If it's linked into /usr/local (brew link scotch) then it should be 
picked up without any special action


If it's not linked into /usr/local then the user should be able to add 
/usr/local/opt/scotch (or /usr/local/Cellar/scotch/) to 
CMAKE_PREFIX_PATH and it should then be picked up, again with no special 
casing in your FindFoo script



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

Re: [CMake] FindBoost warning but working

[Roger Leigh]

On 11/11/2016 07:54, demelier.da...@gmail.com wrote:

Hi, with the following CMakeLists.txt:

cmake_minimum_required(VERSION 3.6)
project(point)
find_package(Boost REQUIRED COMPONENTS system)



CMake Warning at /usr/share/cmake-3.6/Modules/FindBoost.cmake:743
(message):
  Imported targets not available for Boost version 106200



The code compiles and builds fine though, but I would like to know and
fix this warning.

cmake version is 3.6.3 and boost is 1.62.0.


The FindBoost provided by this version of cmake doesn't support imported 
targets for the new Boost 1.62 release, i.e. Boost::system.


If you're not using imported targets, this won't cause you any problems, 
and you can ignore it.


Hopefully one day we can get Boost to provide this information directly 
by providing cmake configuration files (it's on my long todo list).  If 
anyone else wants to tackle this, it would certainly benefit a lot of 
people.



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

[cmake-developers] [patch] Add support for Ice 3.6.3 to FindIce

[Roger Leigh]

Branch: ice-3.6.3.  Pushed to next for testing.  This is for a new point 
release recently issued by upstream.



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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-416-g5ee591d

[Roger Leigh]

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  5ee591dbad84c38eb03e8d6d7f3c35ad9f010d87 (commit)
   via  6f3a8f0febae0753d0114b2d4dc53a788ce4637e (commit)
   via  8eb6038d0d98da7f7e04462a72bd2e7529a7baff (commit)
  from  e00cdcdd433824b1692856231c7e9791164f0ab3 (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=5ee591dbad84c38eb03e8d6d7f3c35ad9f010d87
commit 5ee591dbad84c38eb03e8d6d7f3c35ad9f010d87
Merge: e00cdcd 6f3a8f0
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Thu Oct 13 02:51:39 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Oct 13 02:51:39 2016 -0400

Merge topic 'ice-3.6.3' into next

6f3a8f0f FindIce: Add support for version 3.6.3
8eb6038d CMake Nightly Date Stamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6f3a8f0febae0753d0114b2d4dc53a788ce4637e
commit 6f3a8f0febae0753d0114b2d4dc53a788ce4637e
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Wed Oct 12 22:41:51 2016 +0100
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Wed Oct 12 22:41:51 2016 +0100

FindIce: Add support for version 3.6.3

diff --git a/Modules/FindIce.cmake b/Modules/FindIce.cmake
index 39dc171..a61d4a8 100644
--- a/Modules/FindIce.cmake
+++ b/Modules/FindIce.cmake
@@ -131,6 +131,7 @@ function(_Ice_FIND)
   set(ice_versions
   3
   3.6
+  3.6.3
   3.6.2
   3.6.1
   3.6.0

---

Summary of changes:
 Modules/FindIce.cmake |1 +
 Source/CMakeVersion.cmake |2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)


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

[cmake-developers] [patch] FreeBSD build fix

[Roger Leigh]

With FreeBSD 11, I was getting a link failure due to missing kvm symbols 
in Utilities/cmlibuv.


The fix is a trivial addition.  It's added unconditionally; I checked 
for its presence in FreeBSD 11, 10 and 9.  Branch: freebsd-kvm-link

Merged into stage for testing.


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

[cmake-developers] [patch] BZip2 imported targets

[Roger Leigh]

Adds BZip2::BZip2 imported target and documentation, along with unit 
test which may be enabled with the CMake_TEST_FindBZip2 option.  Derived 
from the existing code in FindZLib.


Branch: bzip2-imported-targets
Merged into stage for testing.


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

[Cmake-commits] CMake branch, next, updated. v3.6.2-1872-gd803aae

[Roger Leigh]

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  d803aae6f865545c4cc0702a52f73871aaf1de0e (commit)
   via  b3e62a0507a3cd749d9add0a5c926aa823e91827 (commit)
  from  3fad31b0c32aecf07dc29857e26ee3a803ec154b (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=d803aae6f865545c4cc0702a52f73871aaf1de0e
commit d803aae6f865545c4cc0702a52f73871aaf1de0e
Merge: 3fad31b b3e62a0
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Thu Sep 8 17:01:48 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Sep 8 17:01:48 2016 -0400

Merge topic 'bzip2-imported-targets' into next

b3e62a05 FindBZip2: Document imported target


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b3e62a0507a3cd749d9add0a5c926aa823e91827
commit b3e62a0507a3cd749d9add0a5c926aa823e91827
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Thu Sep 8 22:01:02 2016 +0100
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Thu Sep 8 22:01:02 2016 +0100

FindBZip2: Document imported target

diff --git a/Modules/FindBZip2.cmake b/Modules/FindBZip2.cmake
index ca7761d..152d812 100644
--- a/Modules/FindBZip2.cmake
+++ b/Modules/FindBZip2.cmake
@@ -4,7 +4,16 @@
 #
 # Try to find BZip2
 #
-# Once done this will define
+# IMPORTED Targets
+# 
+#
+# This module defines :prop_tgt:`IMPORTED` target ``BZip2::BZip2``, if
+# BZip2 has been found.
+#
+# Result Variables
+# 
+#
+# This module defines the following variables:
 #
 # ::
 #

---

Summary of changes:
 Modules/FindBZip2.cmake |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)


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.6.2-1868-gb4ab772

[Roger Leigh]

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  b4ab772483a971880e4e2baa844dfa40124e8332 (commit)
   via  30d13fa92cafd44e84a5e3b95373a21f2373afce (commit)
   via  efe622be144df37eeb0d09c924cd9ccd38b91b09 (commit)
  from  6f43ab3049540f3a0c62c50d9e6b43f10fa57897 (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=b4ab772483a971880e4e2baa844dfa40124e8332
commit b4ab772483a971880e4e2baa844dfa40124e8332
Merge: 6f43ab3 30d13fa
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Thu Sep 8 16:57:00 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Sep 8 16:57:00 2016 -0400

Merge topic 'bzip2-imported-targets' into next

30d13fa9 Tests: Add FindBZip2 unit tests
efe622be FindBZip2: Add imported target


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=30d13fa92cafd44e84a5e3b95373a21f2373afce
commit 30d13fa92cafd44e84a5e3b95373a21f2373afce
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Thu Sep 8 21:28:17 2016 +0100
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Thu Sep 8 21:54:43 2016 +0100

Tests: Add FindBZip2 unit tests

diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 8293286..aeff249 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1356,6 +1356,10 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P 
${CMake_SOURCE_DIR}/Utilities/Release
 add_subdirectory(FindBoost)
   endif()
 
+  if(CMake_TEST_FindBZip2)
+add_subdirectory(FindBZip2)
+  endif()
+
   if(CMake_TEST_FindGSL)
 add_subdirectory(FindGSL)
   endif()
diff --git a/Tests/FindBZip2/CMakeLists.txt b/Tests/FindBZip2/CMakeLists.txt
new file mode 100644
index 000..0eb3b99
--- /dev/null
+++ b/Tests/FindBZip2/CMakeLists.txt
@@ -0,0 +1,10 @@
+add_test(NAME FindBZip2.Test COMMAND
+  ${CMAKE_CTEST_COMMAND} -C $
+  --build-and-test
+  "${CMake_SOURCE_DIR}/Tests/FindBZip2/Test"
+  "${CMake_BINARY_DIR}/Tests/FindBZip2/Test"
+  ${build_generator_args}
+  --build-project TestFindBZip2
+  --build-options ${build_options}
+  --test-command ${CMAKE_CTEST_COMMAND} -V -C $
+  )
diff --git a/Tests/FindBZip2/Test/CMakeLists.txt 
b/Tests/FindBZip2/Test/CMakeLists.txt
new file mode 100644
index 000..e9cb618
--- /dev/null
+++ b/Tests/FindBZip2/Test/CMakeLists.txt
@@ -0,0 +1,16 @@
+cmake_minimum_required(VERSION 3.4)
+project(TestFindBZip2 C)
+include(CTest)
+
+find_package(BZip2 REQUIRED)
+
+add_definitions(-DCMAKE_EXPECTED_BZip2_VERSION="${BZip2_VERSION_STRING}")
+
+add_executable(test_tgt main.c)
+target_link_libraries(test_tgt BZip2::BZip2)
+add_test(NAME test_tgt COMMAND test_tgt)
+
+add_executable(test_var main.c)
+target_include_directories(test_var PRIVATE ${BZIP2_INCLUDE_DIRS})
+target_link_libraries(test_var PRIVATE ${BZIP2_LIBRARIES})
+add_test(NAME test_var COMMAND test_var)
diff --git a/Tests/FindBZip2/Test/main.c b/Tests/FindBZip2/Test/main.c
new file mode 100644
index 000..f8d1ddc
--- /dev/null
+++ b/Tests/FindBZip2/Test/main.c
@@ -0,0 +1,23 @@
+#include 
+#include 
+#include 
+
+int main()
+{
+  int chunksize = 1024;
+  FILE *file = fopen("test.bzip2", "wb");
+  char *buf = malloc(sizeof(char) * chunksize);
+  int error, rsize;
+  unsigned int in, out;
+  BZFILE *bzfile = BZ2_bzWriteOpen(, file, 64, 1, 10);
+
+  /* Don't actually write anything for the purposes of the test */
+
+  BZ2_bzWriteClose(, bzfile, 1, , );
+  free(buf);
+  fclose(file);
+
+  remove("test.bzip2");
+
+  return 0;
+}

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=efe622be144df37eeb0d09c924cd9ccd38b91b09
commit efe622be144df37eeb0d09c924cd9ccd38b91b09
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Thu Sep 8 21:16:09 2016 +0100
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Thu Sep 8 21:16:09 2016 +0100

FindBZip2: Add imported target

diff --git a/Modules/FindBZip2.cmake b/Modules/FindBZip2.cmake
index b670025..ca7761d 100644
--- a/Modules/FindBZip2.cmake
+++ b/Modules/FindBZip2.cmake
@@ -64,6 +64,31 @@ if (BZIP2_FOUND)
set(CMAKE_REQUIRED_LIBRARIES ${BZIP2_LIBRARIES})
CHECK_SYMBOL_EXISTS(BZ2_bzCompressInit "bzlib.h" BZIP2_NEED_PREFIX)
cmake_pop_check_state()
+
+if(NOT TARGET BZip2::BZip2)
+  add_library(BZip2::BZip2 UNKNOWN IMPORTED)
+  set_target_properties(BZip2::BZip2 PROPERTIES
+INTERFACE_INCLUDE_DIRECTORIES "${BZIP2_INCLUDE_DIRS}")
+
+  if(BZIP2_LIBRARY_RELEASE)
+set_property(TARGET BZip2::BZip2 APPEND PROPERTY
+  IMPORTED_CONFIGURATIONS

Re: [cmake-developers] [patch] Expose GNUInstallDirs absolute path algorithm

[Roger Leigh]

On 30/08/2016 14:53, Brad King wrote:

On 08/28/2016 01:51 PM, Roger Leigh wrote:

The macro name might need adjusting


The idea looks fine to me.  Typically we name module-provided APIs with
the module name.  How about "GNUInstallDirs_get_absolute_install_dir"?
I'm also open to other suggestions.


Seems fine to me.

I've merged this (with the above modification) into next for testing; 
branch gid-func.



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

[Cmake-commits] CMake branch, next, updated. v3.6.1-1827-gcb44094

[Roger Leigh]

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  cb44094bc5b30993d00e5bea055a02323b6dbee5 (commit)
   via  70d052f71ddbf15754073f0d3ba5621f5dc06524 (commit)
  from  45c6d45ad795580eb861ca13b4d81f8f6d35943b (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=cb44094bc5b30993d00e5bea055a02323b6dbee5
commit cb44094bc5b30993d00e5bea055a02323b6dbee5
Merge: 45c6d45 70d052f
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Tue Sep 6 17:04:39 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Sep 6 17:04:39 2016 -0400

Merge topic 'gid-func' into next

70d052f7 GNUInstallDirs: Add set_full_install_dir macro


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=70d052f71ddbf15754073f0d3ba5621f5dc06524
commit 70d052f71ddbf15754073f0d3ba5621f5dc06524
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Sun Aug 28 18:19:02 2016 +0100
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Tue Sep 6 21:54:16 2016 +0100

GNUInstallDirs: Add set_full_install_dir macro

diff --git a/Modules/GNUInstallDirs.cmake b/Modules/GNUInstallDirs.cmake
index b42084e..eec9cb0 100644
--- a/Modules/GNUInstallDirs.cmake
+++ b/Modules/GNUInstallDirs.cmake
@@ -99,6 +99,22 @@
 #   `Filesystem Hierarchy Standard`_.
 #
 # .. _`Filesystem Hierarchy Standard`: 
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
+#
+# Macros
+# ^^
+#
+# ::
+#
+#GNUInstallDirs_get_absolute_install_dir(absvar var)
+#
+# Set the given variable ``absvar`` to the absolute path contained
+# within the variable ``var``.  This is to allow the computation of an
+# absolute path, accounting for all the special cases documented
+# above.  While this macro is used to compute the various
+# ``CMAKE_INSTALL_FULL_`` variables, it is exposed publicly to
+# allow users who create additional path variables to also compute
+# absolute paths where necessary, using the same logic.
+#
 
 #=
 # Copyright 2015 Alex Turbov <i.za...@gmail.com>
@@ -300,55 +316,59 @@ mark_as_advanced(
   CMAKE_INSTALL_DOCDIR
   )
 
-# Result directories
-#
-foreach(dir
-BINDIR
-SBINDIR
-LIBEXECDIR
-SYSCONFDIR
-SHAREDSTATEDIR
-LOCALSTATEDIR
-LIBDIR
-INCLUDEDIR
-OLDINCLUDEDIR
-DATAROOTDIR
-DATADIR
-INFODIR
-LOCALEDIR
-MANDIR
-DOCDIR
-)
-  if(NOT IS_ABSOLUTE "${CMAKE_INSTALL_${dir}}")
+macro(GNUInstallDirs_get_absolute_install_dir absvar var)
+  if(NOT IS_ABSOLUTE "${${var}}")
 # Handle special cases:
 # - CMAKE_INSTALL_PREFIX == /
 # - CMAKE_INSTALL_PREFIX == /usr
 # - CMAKE_INSTALL_PREFIX == /opt/...
 if("${CMAKE_INSTALL_PREFIX}" STREQUAL "/")
   if("${dir}" STREQUAL "SYSCONFDIR" OR "${dir}" STREQUAL "LOCALSTATEDIR")
-set(CMAKE_INSTALL_FULL_${dir} "/${CMAKE_INSTALL_${dir}}")
+set(${absvar} "/${${var}}")
   else()
-if (NOT "${CMAKE_INSTALL_${dir}}" MATCHES "^usr/")
-  set(CMAKE_INSTALL_${dir} "usr/${CMAKE_INSTALL_${dir}}")
+if (NOT "${${var}}" MATCHES "^usr/")
+  set(${var} "usr/${${var}}")
 endif()
-set(CMAKE_INSTALL_FULL_${dir} "/${CMAKE_INSTALL_${dir}}")
+set(${absvar} "/${${var}}")
   endif()
 elseif("${CMAKE_INSTALL_PREFIX}" MATCHES "^/usr/?$")
   if("${dir}" STREQUAL "SYSCONFDIR" OR "${dir}" STREQUAL "LOCALSTATEDIR")
-set(CMAKE_INSTALL_FULL_${dir} "/${CMAKE_INSTALL_${dir}}")
+set(${absvar} "/${${var}}")
   else()
-set(CMAKE_INSTALL_FULL_${dir} 
"${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_${dir}}")
+set(${absvar} "${CMAKE_INSTALL_PREFIX}/${${var}}")
   endif()
 elseif("${CMAKE_INSTALL_PREFIX}" MATCHES "^/opt/.*")
   if("${dir}" STREQUAL "SYSCONFDIR" OR "${dir}" STREQUAL "LOCALSTATEDIR")
-set(CMAKE_INSTALL_FULL_${dir} 
"/${CMAKE_INSTALL_${dir}}${CMAKE_INSTALL_PREFIX}")
+set(${absvar} "/${${var}}${CMAKE_INSTALL_PREFIX}")
   else()
-set(CMAKE_INSTALL_FULL_${dir} 
"${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_${dir}}")
+set(${absvar} "${CMAKE_INSTALL_PREFIX}/${${var}}")
   end

[cmake-developers] [patch] Expose GNUInstallDirs absolute path algorithm

[Roger Leigh]

In several projects I've had a need to compute the "full" absolute path 
for an installation directory.  The logic to do this is in the 
GNUInstallDirs module, used to compute the CMAKE_INSTALL_FULL_* 
variables for each of the CMAKE_INSTALL_* cache variables it defines. 
In order to allow for this logic to be reused, I've separated it out 
into a macro "set_full_install_dir".  This can then be used by any end 
user to compute their own absolute paths using the same logic.


The reason for this is that my projects are creating their own 
project-specific installation directory cache variables based upon the 
GNUInstallDirs variables, or sometimes even from scratch.  I then need 
to compute the full path.  But I need this macro to be able to do that 
to match the GNUInstallDirs behaviour.


The macro name might need adjusting, but I hope the basic approach is OK 
in principle.



Kind regards,
Roger
>From ed6301e40a8b5d71fb45b55a8ac2dbacb5804be7 Mon Sep 17 00:00:00 2001
From: Roger Leigh <rle...@codelibre.net>
Date: Sun, 28 Aug 2016 18:19:02 +0100
Subject: [PATCH] GNUInstallDirs: Add set_full_install_dir macro

---
 Modules/GNUInstallDirs.cmake | 80 +++-
 1 file changed, 50 insertions(+), 30 deletions(-)

diff --git a/Modules/GNUInstallDirs.cmake b/Modules/GNUInstallDirs.cmake
index b42084e..50a6797 100644
--- a/Modules/GNUInstallDirs.cmake
+++ b/Modules/GNUInstallDirs.cmake
@@ -99,6 +99,22 @@
 #   `Filesystem Hierarchy Standard`_.
 #
 # .. _`Filesystem Hierarchy Standard`: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
+#
+# Macros
+# ^^
+#
+# ::
+#
+#set_full_install_dir(fullvar var)
+#
+# Set the given variable ``fullvar`` to the absolute path contained
+# within the variable ``var``.  This is to allow the computation of an
+# absolute path, accounting for all the special cases documented
+# above.  While this macro is used to compute the various
+# ``CMAKE_INSTALL_FULL_`` variables, it is exposed publicly to
+# allow users who create additional path variables to also compute
+# absolute paths where necessary, using the same logic.
+#
 
 #=
 # Copyright 2015 Alex Turbov <i.za...@gmail.com>
@@ -300,55 +316,59 @@ mark_as_advanced(
   CMAKE_INSTALL_DOCDIR
   )
 
-# Result directories
-#
-foreach(dir
-BINDIR
-SBINDIR
-LIBEXECDIR
-SYSCONFDIR
-SHAREDSTATEDIR
-LOCALSTATEDIR
-LIBDIR
-INCLUDEDIR
-OLDINCLUDEDIR
-DATAROOTDIR
-DATADIR
-INFODIR
-LOCALEDIR
-MANDIR
-DOCDIR
-)
-  if(NOT IS_ABSOLUTE "${CMAKE_INSTALL_${dir}}")
+macro(set_full_install_dir fullvar var)
+  if(NOT IS_ABSOLUTE "${${var}}")
 # Handle special cases:
 # - CMAKE_INSTALL_PREFIX == /
 # - CMAKE_INSTALL_PREFIX == /usr
 # - CMAKE_INSTALL_PREFIX == /opt/...
 if("${CMAKE_INSTALL_PREFIX}" STREQUAL "/")
   if("${dir}" STREQUAL "SYSCONFDIR" OR "${dir}" STREQUAL "LOCALSTATEDIR")
-set(CMAKE_INSTALL_FULL_${dir} "/${CMAKE_INSTALL_${dir}}")
+set(${fullvar} "/${${var}}")
   else()
-if (NOT "${CMAKE_INSTALL_${dir}}" MATCHES "^usr/")
-  set(CMAKE_INSTALL_${dir} "usr/${CMAKE_INSTALL_${dir}}")
+if (NOT "${${var}}" MATCHES "^usr/")
+  set(${var} "usr/${${var}}")
 endif()
-set(CMAKE_INSTALL_FULL_${dir} "/${CMAKE_INSTALL_${dir}}")
+set(${fullvar} "/${${var}}")
   endif()
 elseif("${CMAKE_INSTALL_PREFIX}" MATCHES "^/usr/?$")
   if("${dir}" STREQUAL "SYSCONFDIR" OR "${dir}" STREQUAL "LOCALSTATEDIR")
-set(CMAKE_INSTALL_FULL_${dir} "/${CMAKE_INSTALL_${dir}}")
+set(${fullvar} "/${${var}}")
   else()
-set(CMAKE_INSTALL_FULL_${dir} "${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_${dir}}")
+set(${fullvar} "${CMAKE_INSTALL_PREFIX}/${${var}}")
   endif()
 elseif("${CMAKE_INSTALL_PREFIX}" MATCHES "^/opt/.*")
   if("${dir}" STREQUAL "SYSCONFDIR" OR "${dir}" STREQUAL "LOCALSTATEDIR")
-set(CMAKE_INSTALL_FULL_${dir} "/${CMAKE_INSTALL_${dir}}${CMAKE_INSTALL_PREFIX}")
+set(${fullvar} "/${${var}}${CMAKE_INSTALL_PREFIX}")
   else()
-set(CMAKE_INSTALL_FULL_${dir} "${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_${dir}}")
+set(${fullvar} "${CMAKE_INSTALL_PREFIX}/${${var}}")
   endif()
 else()
-  set(CMAKE_INSTALL_FULL_${dir} "${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_${dir}}")
+  set(${fullvar} "${CMAKE_INSTALL_PREFIX}/${${var}}")
 endif()
   else()
-set(CMAKE_INST

Re: [cmake-developers] Security in CMake

[Roger Leigh]

CMake is not and can never be a replacement for a package manager.  They 
serve entirely different roles.  While you can extend CMake to give it 
the ability to build and install all sorts stuff, that does not make it 
a package manager.  It's a convenient way to build a complex set of 
interdependent packages, but that's all it is.  I think trying to make 
it do more than that is dangerous; it's currently got a fairly clearly 
defined scope, and there are numerous established tools to take care of 
packaging.  Basically, I do worry about the potential for scope creep here.


Speaking from my own experience as one of the main authors of the Debian 
build tools (sbuild, schroot):


- every package is built individually in a secure sandbox which is 
created before the build and deleted after it.  I wrote a tool 
specifically for this purpose (schroot)--predating docker, openstack and 
all the current hip stuff.  You should probably use a more up to date 
technology yourself; the main point I wanted to make was the isolation 
of the filesystem, network, user etc. for the build step; we run the 
build step without any functional networking other than the loopback to 
ensure every package cleanly builds as a self-contained entity


- a package might be using CMake for its build, inside the sandbox, but 
CMake has no involvement at a higher level


This means that any malicious or accidental privilege escalation, file 
deletion or whatever is contained and will not cause problems.  And if 
there is anything wrong, we blow the whole lot away as a matter of 
course anyway.


- when the packaged binary is installed, there is no code execution 
outside the (optional) maintainer scripts; everything else is just a 
static set of files which get installed.  This is completely decoupled 
from CMake, or whatever build system was used for the build step.


When it comes to CMake building using a super-build and/or running 
find_package and executing third-party Config scripts, other CMake 
modules etc. this is clearly unsafe.  There's clearly scope for 
unbounded code execution by this code.  While these might be required 
for the build step, there's no need for them to have any influence or 
involvement for the package creation step and subsequent 
installation/upgrade/removal by the package manager.



Regards,
Roger

On 20/08/16 22:42, Egor Pugin wrote:

Hi Tobias,

You are right at many points. It's hard to really secure the system
from build system/build artifacts/3rd party apps.
But step by step it's possible to decrease number of potential sources
of vulnerabilities.
Described cmake features would be very helpful for this.
Right now I'm just investigating possible security improvements and
this is only 'nice-to-have' feature.

On 21 August 2016 at 00:25, Tobias Hunger  wrote:

Hi Egor,

Am 20.08.2016 13:48 schrieb "Egor Pugin" :


Hi,

I'm working on a package manager based on cmake.
And some cmake instructions are downloaded with user packages.
I'd like to have an ability to deny some cmake features in such
external untrusted insertions.


I am no CMake expert, but you are talking about securing a program that is
meant to take arbitrary input and run user-defined commands on that to
produce possibly executable output.

I do not see any safe subset of CMake commands that is still able to do
anything useful.

I can see a way for "insertions" to be useful, that does not involve them
changing the configuration (e.g. for a cross compiler), involve running some
3rd party program (e.g. to add support for a new documentation system,
parser generator or whatnot), or the production of build artifacts (e.g.
build some library for the developer to use).

*All* of  these are inheritently unsafe.

Configuration change: Change the C compiler to rm and pass force -rf -- / as
flags.

3rd party program: Run rm -rf / when some certain input file is seen.

Build artifacts: Put running rm -rf / into the binary/library so that this
is run during normal development workflow.

I would try to run my package manager in an environment where running rm -rf
is harmless to the overall system health. Virtual machines or containers
spring to mind there. Not sure that is feasible.

Or come up with insertions signing, etc. so that users can at least know
they got what was uploaded and know whom to blame when their systems get
wiped.

Beat Regards,
Tobias





--

Powered by www.kitware.com

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

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

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

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

Follow this link to 

Re: [CMake] Need ideas/opinions on third party library management

[Roger Leigh]

On 12/08/2016 19:59, Robert Dailey wrote:

Hello,



I've been thinking of a different approach for a while. I've done some
toying around with the "Super Build" concept, where I have a separate
CMake project that does nothing but use the ExternalProject module to
build libraries in real time along with our project. So the order of
operations would be as follows (for our automated build server):

1. Clone our "Third Party" repository
2. Use CMake to generate & build the "Super Build" project (this
builds boost, openssl, freetype, etc for the current platform).
3. Clone the main code base's repository
4. Use CMake to generate & build, using find_package() to refer to
interface targets exported by those third party libraries built in
step 2


You can simplify this to two steps:

1. Clone the superbuild repository
2. Build the third-party and first-party packages

This is the approach we take with the OME super-build
https://github.com/ome/ome-cmake-superbuild/

See the packages in
https://github.com/ome/ome-cmake-superbuild/tree/develop/packages
all the ones with an "ome-" prefix are the first-party libraries;
everything else is third-party.  They are all external projects.

We have cmake options to select all packages, first-party packages only 
or select individual packages by hand; the recursive dependency 
resolution will add/ignore dependencies depending upon the chosen policy 
(defaulting to include third-party dependencies).  So when you're 
building on BSD or Linux, you can say "no third-party dependencies 
except for gtest", or choose everything, and on Windows where there is 
no package manager, you always build everything.  And on Windows you can 
build just the dependencies and reuse them later; it has support for 
using cached builds which we use on the CI side to cut down build times; 
we only rebuild the cache when the superbuild git tree hash changes; see 
the scripts/jenkins-build script


In addition to that, we have the means to build the first-party 
libraries in different ways


1. From source release tarball (last stable release)
2. From git (specify remote+branch as cmake options)
3. From a local git checkout (on whatever branch is currently checked out)

You can see the selection logic here: 
https://github.com/ome/ome-cmake-superbuild/blob/develop/packages/ome-files/superbuild.cmake#L4


In practice (1) is for end-users to build the whole thing, and (3) is 
what I use in practice to develop locally where I have a full set of git 
repos checked out locally, and I tell the superbuild to build them, 
along with all the third-party deps; (3) is also what we use on the CI 
system, with jenkins cloning all the individual repos into the 
workspace, then doing pretty much the same thing.  (2) is OK for one-off 
builds, but the need for a full git clone for every package is too much 
for routine use


And you can see how first- and third-party dependencies are handled 
here: 
https://github.com/ome/ome-cmake-superbuild/blob/develop/packages/ome-files/superbuild.cmake#L48


I might rearrange that so that the classification is in the dependency 
rather than the dependeee later on though.  It kind of evolved this way 
as we added additional features and needs a little cleanup to make it 
perfect.


Everything in the above repository is BSD licensed, so feel free to use 
it for inspiration or take what you like.  The main point I wanted to 
make was that with the superbuild *everything* can be an external 
project, including your own code.  And from that point you can add in 
features like being able to selectively build just the third-party or 
just your own code, rather than forcing them to be separate manual steps.



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

Re: [CMake] Imported targets and include ordering

[Roger Leigh]

On 11/08/2016 16:24, rle...@codelibre.net wrote:

I've come across an odd situation where I'm unsure what the most
portable and recommended solution would be.

I'm linking a program against the CURL and ICU libraries.  CURL has
traditional variables for the includes and libraries; ICU has imported
targets.

In FindICU:
  set_target_properties(${_ICU_imported_target} PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES "${ICU_INCLUDE_DIR}")

In my code:

find_package(CURL)
find_package(ICU COMPONENTS uc data)
[...]
list(APPEND libxerces_c_DEPS ${CURL_LIBRARIES})
include_directories(${CURL_INCLUDE_DIRS})
list(APPEND libxerces_c_DEPS ICU::uc ICU::data)

And the resulting includes on the compiler invocation:

/usr/bin/CC   -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -I.
-I/tmp/b2/xerces-source/src -Isrc -I/tmp/b2/xerces-source/tests -isystem
/tmp/b2/superbuild-install/include -msse2 -MD -MT
tests/CMakeFiles/XSValueTest.dir/src/XSValueTest/XSValueTest.cpp.o -MF
tests/CMakeFiles/XSValueTest.dir/src/XSValueTest/XSValueTest.cpp.o.d -o
tests/CMakeFiles/XSValueTest.dir/src/XSValueTest/XSValueTest.cpp.o -c
/tmp/b2/xerces-source/tests/src/XSValueTest/XSValueTest.cpp

The problem is this:
CURL is in /usr/local/include
ICU v55 is in /usr/local/include
ICU v57 is in /tmp/b2/superbuild-install/include with its libs in
/tmp/b2/superbuild-install/lib


Sorry, I noticed that the compiler invocation was from the wrong source 
file; it should have -I/usr/local/include right at the start, then 
-isystem /tmp/b2/superbuild-install/include at the end as above.


--

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.6.0-784-g0d7f858

[Roger Leigh]

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  0d7f858b7a6e8f1d0e49fadce08b57ea56eab062 (commit)
   via  1b41da0475c854d82d09d7b631112982984b282f (commit)
  from  ad634507d0155978a0744b5d3b896e696aecc5e1 (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=0d7f858b7a6e8f1d0e49fadce08b57ea56eab062
commit 0d7f858b7a6e8f1d0e49fadce08b57ea56eab062
Merge: ad63450 1b41da0
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Mon Jul 11 17:51:49 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon Jul 11 17:51:49 2016 -0400

Merge topic 'findicu' into next

1b41da04 FindICU: New module


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1b41da0475c854d82d09d7b631112982984b282f
commit 1b41da0475c854d82d09d7b631112982984b282f
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Sun Jul 10 17:34:39 2016 +
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Mon Jul 11 21:47:41 2016 +

FindICU: New module

diff --git a/Help/manual/cmake-modules.7.rst b/Help/manual/cmake-modules.7.rst
index 6ac5973..e905ef4 100644
--- a/Help/manual/cmake-modules.7.rst
+++ b/Help/manual/cmake-modules.7.rst
@@ -121,6 +121,7 @@ All Modules
/module/FindHTMLHelp
/module/FindIce
/module/FindIcotool
+   /module/FindICU
/module/FindImageMagick
/module/FindIntl
/module/FindITK
diff --git a/Help/module/FindICU.rst b/Help/module/FindICU.rst
new file mode 100644
index 000..ee3f4a9
--- /dev/null
+++ b/Help/module/FindICU.rst
@@ -0,0 +1 @@
+.. cmake-module:: ../../Modules/FindICU.cmake
diff --git a/Modules/FindICU.cmake b/Modules/FindICU.cmake
new file mode 100644
index 000..c9212cb
--- /dev/null
+++ b/Modules/FindICU.cmake
@@ -0,0 +1,359 @@
+#.rst:
+# FindICU
+# ---
+#
+# Find the International Components for Unicode (ICU) libraries and
+# programs.
+#
+# This module supports multiple components.
+# Components can include any of: ``data``, ``i18n``, ``io``, ``le``,
+# ``lx``, ``test``, ``tu`` and ``uc``.
+#
+# Note that on Windows ``data`` is named ``dt`` and ``i18n`` is named
+# ``in`; any of the names may be used, and the appropriate
+# platform-specific library name will be automatically selected.
+#
+# This module reports information about the ICU installation in
+# several variables.  General variables::
+#
+#   ICU_VERSION - ICU release version
+#   ICU_FOUND - true if the main programs and libraries were found
+#   ICU_LIBRARIES - component libraries to be linked
+#   ICU_INCLUDE_DIRS - the directories containing the ICU headers
+#
+# Imported targets::
+#
+#   ICU::
+#
+# Where  is the name of an ICU component, for example
+# ``ICU::i18n``.
+#
+# ICU programs are reported in::
+#
+#   ICU_GENCNVAL_EXECUTABLE - path to gencnval executable
+#   ICU_ICUINFO_EXECUTABLE - path to icuinfo executable
+#   ICU_GENBRK_EXECUTABLE - path to genbrk executable
+#   ICU_ICU-CONFIG_EXECUTABLE - path to icu-config executable
+#   ICU_GENRB_EXECUTABLE - path to genrb executable
+#   ICU_GENDICT_EXECUTABLE - path to gendict executable
+#   ICU_DERB_EXECUTABLE - path to derb executable
+#   ICU_PKGDATA_EXECUTABLE - path to pkgdata executable
+#   ICU_UCONV_EXECUTABLE - path to uconv executable
+#   ICU_GENCFU_EXECUTABLE - path to gencfu executable
+#   ICU_MAKECONV_EXECUTABLE - path to makeconv executable
+#   ICU_GENNORM2_EXECUTABLE - path to gennorm2 executable
+#   ICU_GENCCODE_EXECUTABLE - path to genccode executable
+#   ICU_GENSPREP_EXECUTABLE - path to gensprep executable
+#   ICU_ICUPKG_EXECUTABLE - path to icupkg executable
+#   ICU_GENCMN_EXECUTABLE - path to gencmn executable
+#
+# ICU component libraries are reported in::
+#
+#   ICU__FOUND - ON if component was found
+#   ICU__LIBRARIES - libraries for component
+#
+# Note that  is the uppercased name of the component.
+#
+# This module reads hints about search results from::
+#
+#   ICU_ROOT - the root of the ICU installation
+#
+# The environment variable ``ICU_ROOT`` may also be used; the
+# ICU_ROOT variable takes precedence.
+#
+# The following cache variables may also be set::
+#
+#   ICU__EXECUTABLE - the path to executable 
+#   ICU_INCLUDE_DIR - the directory containing the ICU headers
+#   ICU__LIBRARY - the library for component 
+#
+# .. note::
+#
+#   In most cases none of the above variables will require setting,
+#   unless multiple ICU versions are available and a specific version
+#   is required.
+#
+# Other variables one may set to control this module are::
+#
+#   ICU_DEBUG - Set to ON to enable debug output from FindICU

[Cmake-commits] CMake branch, next, updated. v3.6.0-754-g83acd62

[Roger Leigh]

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  83acd621676ea63da5d2789300a56ec54494f225 (commit)
   via  2ee9ca0c62312f1054ac59a7393d3d9cde81a912 (commit)
  from  4328891e82e4231f513a60aa77afad829c67f8bc (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=83acd621676ea63da5d2789300a56ec54494f225
commit 83acd621676ea63da5d2789300a56ec54494f225
Merge: 4328891 2ee9ca0
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Sun Jul 10 16:26:40 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sun Jul 10 16:26:40 2016 -0400

Merge topic 'findicu' into next

2ee9ca0c FindICU: Set imported target INTERFACE_INCLUDE_DIRECTORIES


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2ee9ca0c62312f1054ac59a7393d3d9cde81a912
commit 2ee9ca0c62312f1054ac59a7393d3d9cde81a912
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Sun Jul 10 20:22:46 2016 +
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Sun Jul 10 20:24:44 2016 +

FindICU: Set imported target INTERFACE_INCLUDE_DIRECTORIES

diff --git a/Modules/FindICU.cmake b/Modules/FindICU.cmake
index fd333bb..d8db681 100644
--- a/Modules/FindICU.cmake
+++ b/Modules/FindICU.cmake
@@ -250,7 +250,7 @@ if(ICU_FOUND)
   set("${_ICU_component_lib}" "${${_ICU_component_cache}}")
   if(NOT TARGET ${_ICU_imported_target})
 add_library(${_ICU_imported_target} UNKNOWN IMPORTED)
-if()
+if(ICU_INCLUDE_DIR)
   set_target_properties(${_ICU_imported_target} PROPERTIES
 INTERFACE_INCLUDE_DIRECTORIES "${ICU_INCLUDE_DIR}")
 endif()

---

Summary of changes:
 Modules/FindICU.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-commits] CMake branch, next, updated. v3.6.0-752-g4328891

[Roger Leigh]

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  4328891e82e4231f513a60aa77afad829c67f8bc (commit)
   via  a3ef069702fde5d688118031d938bc0774c348a5 (commit)
   via  aa0b737046e16fe873dc82e1bb8edbada6ac3b34 (commit)
  from  2f77bbd188fe154580f07070eb10bcec244e494a (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=4328891e82e4231f513a60aa77afad829c67f8bc
commit 4328891e82e4231f513a60aa77afad829c67f8bc
Merge: 2f77bbd a3ef069
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Sun Jul 10 14:52:20 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sun Jul 10 14:52:20 2016 -0400

Merge topic 'findicu' into next

a3ef0697 FindICU: Include modules from current list dir
aa0b7370 FindICU: Remove duplicate program list


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3ef069702fde5d688118031d938bc0774c348a5
commit a3ef069702fde5d688118031d938bc0774c348a5
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Sun Jul 10 18:51:03 2016 +
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Sun Jul 10 18:51:03 2016 +

FindICU: Include modules from current list dir

diff --git a/Modules/FindICU.cmake b/Modules/FindICU.cmake
index 7f64019..fd333bb 100644
--- a/Modules/FindICU.cmake
+++ b/Modules/FindICU.cmake
@@ -170,7 +170,7 @@ function(_ICU_FIND)
   HINTS ${icu_roots}
   PATH_SUFFIXES ${icu_library_suffixes}
   DOC "ICU ${component} library (debug)")
-include(SelectLibraryConfigurations)
+include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake)
 select_library_configurations(ICU_${component_upcase})
 mark_as_advanced("${component_cache_release}" "${component_cache_debug}")
 if(${component_cache})
@@ -224,7 +224,7 @@ endfunction()
 
 _ICU_FIND()
 
-include(FindPackageHandleStandardArgs)
+include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
 FIND_PACKAGE_HANDLE_STANDARD_ARGS(ICU
   FOUND_VAR ICU_FOUND
   REQUIRED_VARS ICU_INCLUDE_DIR

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aa0b737046e16fe873dc82e1bb8edbada6ac3b34
commit aa0b737046e16fe873dc82e1bb8edbada6ac3b34
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Sun Jul 10 18:48:26 2016 +
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Sun Jul 10 18:48:26 2016 +

FindICU: Remove duplicate program list

diff --git a/Modules/FindICU.cmake b/Modules/FindICU.cmake
index 0b8fdd9..7f64019 100644
--- a/Modules/FindICU.cmake
+++ b/Modules/FindICU.cmake
@@ -122,24 +122,6 @@ function(_ICU_FIND)
 endif()
   endif()
 
-  set(icu_programs
-gencnval
-icuinfo
-genbrk
-icu-config
-genrb
-gendict
-derb
-pkgdata
-uconv
-gencfu
-makeconv
-gennorm2
-genccode
-gensprep
-icupkg
-gencmn)
-
   # Find all ICU programs
   foreach(program ${icu_programs})
 string(TOUPPER "${program}" program_upcase)

---

Summary of changes:
 Modules/FindICU.cmake |   22 ++
 1 file changed, 2 insertions(+), 20 deletions(-)


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

[cmake-developers] [patch] Fix variable naming in FindTIFF unit test

[Roger Leigh]

Straightforward renaming, in 
https://gitlab.kitware.com/cmake/cmake/merge_requests/33 which is also 
merged into next for testing.



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

[Cmake-commits] CMake branch, next, updated. v3.6.0-749-g2f77bbd

[Roger Leigh]

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  2f77bbd188fe154580f07070eb10bcec244e494a (commit)
   via  7959d51847577e1411bde0cabb9e1ce687d60c6f (commit)
  from  45376cb2b6913a96691c36167361459df0d20939 (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=2f77bbd188fe154580f07070eb10bcec244e494a
commit 2f77bbd188fe154580f07070eb10bcec244e494a
Merge: 45376cb 7959d51
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Sun Jul 10 14:19:04 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sun Jul 10 14:19:04 2016 -0400

Merge topic 'tiff-typo' into next

7959d518 FindTIFF: Correct variable names in unit test


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7959d51847577e1411bde0cabb9e1ce687d60c6f
commit 7959d51847577e1411bde0cabb9e1ce687d60c6f
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Sun Jul 10 18:16:16 2016 +
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Sun Jul 10 18:16:16 2016 +

FindTIFF: Correct variable names in unit test

diff --git a/Tests/FindTIFF/Test/CMakeLists.txt 
b/Tests/FindTIFF/Test/CMakeLists.txt
index f17cda7..6985e3f 100644
--- a/Tests/FindTIFF/Test/CMakeLists.txt
+++ b/Tests/FindTIFF/Test/CMakeLists.txt
@@ -7,11 +7,11 @@ set(CMAKE_MODULE_PATH 
${CMAKE_CURRENT_SOURCE_DIR}/../../../Source/Modules)
 
 find_package(TIFF REQUIRED)
 
-add_executable(test_xercesc_tgt main.c)
-target_link_libraries(test_xercesc_tgt TIFF::TIFF)
-add_test(NAME test_xercesc_tgt COMMAND test_xercesc_tgt)
+add_executable(test_tiff_tgt main.c)
+target_link_libraries(test_tiff_tgt TIFF::TIFF)
+add_test(NAME test_tiff_tgt COMMAND test_tiff_tgt)
 
-add_executable(test_xercesc_var main.c)
-target_include_directories(test_xercesc_var PRIVATE ${TIFF_INCLUDE_DIRS})
-target_link_libraries(test_xercesc_var PRIVATE ${TIFF_LIBRARIES})
-add_test(NAME test_xercesc_var COMMAND test_xercesc_var)
+add_executable(test_tiff_var main.c)
+target_include_directories(test_tiff_var PRIVATE ${TIFF_INCLUDE_DIRS})
+target_link_libraries(test_tiff_var PRIVATE ${TIFF_LIBRARIES})
+add_test(NAME test_tiff_var COMMAND test_tiff_var)

---

Summary of changes:
 Tests/FindTIFF/Test/CMakeLists.txt |   14 +++---
 1 file changed, 7 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, next, updated. v3.6.0-747-g45376cb

[Roger Leigh]

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  45376cb2b6913a96691c36167361459df0d20939 (commit)
   via  4e7f2d49c7e12cdfc58940cf14d085d7f422e970 (commit)
   via  03a50961f338462acc65db876c59e0045f0754d9 (commit)
   via  325288455eb4a0e7dad9689b6ebac1afe7ef7cc3 (commit)
  from  5eaa0b9459487a8dccc8fd7b4202dfc8ac7c69d7 (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=45376cb2b6913a96691c36167361459df0d20939
commit 45376cb2b6913a96691c36167361459df0d20939
Merge: 5eaa0b9 4e7f2d4
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Sun Jul 10 14:16:56 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sun Jul 10 14:16:56 2016 -0400

Merge topic 'findicu' into next

4e7f2d49 FindICU: New module
03a50961 CMake Nightly Date Stamp
32528845 CMake Nightly Date Stamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4e7f2d49c7e12cdfc58940cf14d085d7f422e970
commit 4e7f2d49c7e12cdfc58940cf14d085d7f422e970
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Sun Jul 10 17:34:39 2016 +
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Sun Jul 10 18:10:18 2016 +

FindICU: New module

diff --git a/Help/manual/cmake-modules.7.rst b/Help/manual/cmake-modules.7.rst
index 6ac5973..e905ef4 100644
--- a/Help/manual/cmake-modules.7.rst
+++ b/Help/manual/cmake-modules.7.rst
@@ -121,6 +121,7 @@ All Modules
/module/FindHTMLHelp
/module/FindIce
/module/FindIcotool
+   /module/FindICU
/module/FindImageMagick
/module/FindIntl
/module/FindITK
diff --git a/Help/module/FindICU.rst b/Help/module/FindICU.rst
new file mode 100644
index 000..ee3f4a9
--- /dev/null
+++ b/Help/module/FindICU.rst
@@ -0,0 +1 @@
+.. cmake-module:: ../../Modules/FindICU.cmake
diff --git a/Modules/FindICU.cmake b/Modules/FindICU.cmake
new file mode 100644
index 000..0b8fdd9
--- /dev/null
+++ b/Modules/FindICU.cmake
@@ -0,0 +1,333 @@
+#.rst:
+# FindICU
+# ---
+#
+# Find the International Components for Unicode (ICU) libraries and
+# programs.
+#
+# This module supports multiple components.
+# Components can include any of: ``data``, ``i18n``, ``io``, ``le``,
+# ``lx``, ``test``, ``tu`` and ``uc``.
+#
+# This module reports information about the ICU installation in
+# several variables.  General variables::
+#
+#   ICU_VERSION - ICU release version
+#   ICU_FOUND - true if the main programs and libraries were found
+#   ICU_LIBRARIES - component libraries to be linked
+#   ICU_INCLUDE_DIRS - the directories containing the ICU headers
+#
+# Imported targets::
+#
+#   ICU::
+#
+# Where  is the name of an ICU component, for example
+# ``ICU::i18n``.
+#
+# ICU programs are reported in::
+#
+#   ICU_GENCNVAL_EXECUTABLE - path to gencnval executable
+#   ICU_ICUINFO_EXECUTABLE - path to icuinfo executable
+#   ICU_GENBRK_EXECUTABLE - path to genbrk executable
+#   ICU_ICU-CONFIG_EXECUTABLE - path to icu-config executable
+#   ICU_GENRB_EXECUTABLE - path to genrb executable
+#   ICU_GENDICT_EXECUTABLE - path to gendict executable
+#   ICU_DERB_EXECUTABLE - path to derb executable
+#   ICU_PKGDATA_EXECUTABLE - path to pkgdata executable
+#   ICU_UCONV_EXECUTABLE - path to uconv executable
+#   ICU_GENCFU_EXECUTABLE - path to gencfu executable
+#   ICU_MAKECONV_EXECUTABLE - path to makeconv executable
+#   ICU_GENNORM2_EXECUTABLE - path to gennorm2 executable
+#   ICU_GENCCODE_EXECUTABLE - path to genccode executable
+#   ICU_GENSPREP_EXECUTABLE - path to gensprep executable
+#   ICU_ICUPKG_EXECUTABLE - path to icupkg executable
+#   ICU_GENCMN_EXECUTABLE - path to gencmn executable
+#
+# ICU component libraries are reported in::
+#
+#   ICU__FOUND - ON if component was found
+#   ICU__LIBRARIES - libraries for component
+#
+# Note that  is the uppercased name of the component.
+#
+# This module reads hints about search results from::
+#
+#   ICU_ROOT - the root of the ICU installation
+#
+# The environment variable ``ICU_ROOT`` may also be used; the
+# ICU_ROOT variable takes precedence.
+#
+# The following cache variables may also be set::
+#
+#   ICU__EXECUTABLE - the path to executable 
+#   ICU_INCLUDE_DIR - the directory containing the ICU headers
+#   ICU__LIBRARY - the library for component 
+#
+# .. note::
+#
+#   In most cases none of the above variables will require setting,
+#   unless multiple ICU versions are available and a specific version
+#   is required.
+#
+# Other variables one may set to control this module are::
+#
+#   ICU_DEBUG - Set to ON to enable debug output from FindICU

[CMake] CMake with VS2015 C++ Build Tools and missing ucrtbased.dll

[Roger Leigh]

I'm doing some initial testing of CMake 3.6.0 with the newly-released 
Visual Studio 2015 Update 3 C++ Build Tools 
(http://landinghub.visualstudio.com/visual-cpp-build-tools).  I.e. the 
standalone compiler without the IDE.


I'm configuring with:

  cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug|Release [in an x64 native 
tools command prompt]

  cmake -G "Visual Studio 14 2015 Win64"

And then building and running the unit tests with ctest.

With a release build using either generator, all the tests run and pass. 
 With a debug build using either generator, every test fails with the 
message:


 - System Error
The program can't start because ucrtbased.dll is missing from your 
computer.  Try reinstalling the program to fix this problem.


The DLL *is* installed on the system:
/cygdrive/c/Program Files (x86)/Microsoft SDKs/Windows 
Kits/10/ExtensionSDKs/Microsoft.UniversalCRT.Debug/10.0.10240.0/Redist/Debug/arm/ucrtbased.dll
/cygdrive/c/Program Files (x86)/Microsoft SDKs/Windows 
Kits/10/ExtensionSDKs/Microsoft.UniversalCRT.Debug/10.0.10240.0/Redist/Debug/arm64/ucrtbased.dll
/cygdrive/c/Program Files (x86)/Microsoft SDKs/Windows 
Kits/10/ExtensionSDKs/Microsoft.UniversalCRT.Debug/10.0.10240.0/Redist/Debug/x64/ucrtbased.dll
/cygdrive/c/Program Files (x86)/Microsoft SDKs/Windows 
Kits/10/ExtensionSDKs/Microsoft.UniversalCRT.Debug/10.0.10240.0/Redist/Debug/x86/ucrtbased.dll

/cygdrive/c/Program Files (x86)/Windows Kits/10/bin/arm/ucrt/ucrtbased.dll
/cygdrive/c/Program Files (x86)/Windows Kits/10/bin/arm64/ucrt/ucrtbased.dll
/cygdrive/c/Program Files (x86)/Windows Kits/10/bin/x64/ucrt/ucrtbased.dll
/cygdrive/c/Program Files (x86)/Windows Kits/10/bin/x86/ucrt/ucrtbased.dll

And the environment:
INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\INCLUDE;C:\Program Files (x86)\Windows 
Kits\10\include\10.0.10240.0\ucrt;C:\Program Files (x86)\Windows 
Kits\8.1\include\shared;C:\Program Files (x86)\Windows 
Kits\8.1\include\um;C:\Program Files (x86)\Windows Kits\8.1\include\winrt;
LIB=C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\LIB\amd64;C:\Program Files (x86)\Windows 
Kits\10\lib\10.0.10240.0\ucrt\x64;C:\Program Files (x86)\Windows 
Kits\8.1\lib\winv6.3\um\x64;
LIBPATH=C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\LIB\amd64;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Windows\Microsoft.NET\Framework64\;References\CommonConfiguration\Neutral;\Microsoft.VCLibs\14.0\References\CommonConfiguration\neutral;
Path=c:\opt\bin;C:\Program Files (x86)\MSBuild\14.0\bin\amd64;C:\Program 
Files (x86)\Microsoft Visual Studio 
14.0\VC\BIN\amd64;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Windows\Microsoft.NET\Framework64\;C:\Program 
Files (x86)\Windows Kits\8.1\bin\x64;C:\Program Files (x86)\Windows 
Kits\8.1\bin\x86;C:\ProgramData\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program 
Files (x86)\PuTTY\;C:\Program Files (x86)\Windows Kits\8.1\Windows 
Performance Toolkit\;C:\Program 
Files\CMake\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Users\rleigh\AppData\Local\Programs\Git\cmd


But for some reason it's not on the PATH while the release version of 
the ucrtbase.dll is.  I'm not sure if this is a bug in the VS command 
prompt environment--"Windows Kits/8.1/bin/x64" is on the path, but not 
"Windows Kits/10/bin/x64", while both are in the include path...  Could 
this be a bug in the VS command prompt environment?  Or is this more 
likely to be a cmake issue?


The code in question is https://github.com/rleigh-dundee/xercesc-cmake 
(I'm working on a conversion of the autotools and VS project files to a 
cmake build), but I suspect this would happen with any project which 
wants to run a debug executable.



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

Re: [cmake-developers] Using a custom DSL compiler in CMake

[Roger Leigh]

On 21/06/2016 18:18, Chris Bieneman wrote:

Hello cmake-developers,

I’m trying to find a solution to a long running problem in our build. In LLVM 
we have a domain specific language named TableGen that we use to generate 
header files used throughout the project. Our current solution to work with 
this tool in CMake is pretty terrible for a number of reasons.

The biggest problem is that we don’t have good dependency handling around the 
inputs and outputs from the DSL. Some of this is caused by our CMake targets 
not being granular (which I know how to fix). The harder part is that our DSL 
supports C-like includes.

Our DSL compiler can generate .d files, but hooking that up to CMake is a 
harder problem. My thought was to try and treat TableGen as a language. There 
are some complications with that because we don’t actually have a compiler for 
it at configuration time.

Any thoughts and guidance would be greatly appreciated. I feel as if I’m about 
to fall into a deep and scary rabbit hole.


In one of the projects I maintain at work, we generate a lot of 
different C++ sources and headers using a custom generator tool.  It 
consumes an XML schema, and then processes it to turn that formal data 
model into a set of C++ classes, enums and serialisation functions, 
using a series of templates.


I needed to make this work seamlessly with CMake, and so I wrote a set 
of functions to introspect the dependencies and then generate all the 
necessary targets with appropriate dependencies.  While I can't claim 
this is going to be the best use of CMake in the world, it's quite 
functional and does its job well.



https://github.com/openmicroscopy/bioformats/blob/develop/cpp/cmake/XsdFu.cmake

This contains helper macros to do the introspection.  We basically run 
the generator twice for each "target" using --print-generated and 
--print-depends options.  These cause the corresponding files to be 
dumped to stdout.  We then use these file lists as the OUTPUT and 
DEPENDS lists for add_custom_command.  NB. This tool outputs multiple 
source files at once which all go into the OUTPUT.


You can then see those macros in use here:

https://github.com/openmicroscopy/bioformats/blob/develop/cpp/lib/ome/xml/CMakeLists.txt#L42
where we then add those outputs to a regular library target.

While I think this is too custom to be of direct use, it might be useful 
for inspiration.  The essential point is to introspect the dependencies 
and outputs as you run cmake (which can emit the includes you mentioned 
as dependencies), and then use that information to generate the 
appropriate custom commands.  Everything will then be built at build 
time, in parallel.  How you do the introspection is entirely up to you. 
I added support to the generator itself since it already had the 
relevant information (it's a python tool) and was quick and easy to add. 
 You could also parse the files directly with cmake, or with a custom 
script in any language you like.



Hope that's at least provided some ideas!


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

[cmake-developers] [patch] FindIce updates

[Roger Leigh]

I have opened a couple of merge requests here, and also merged these 
into next for testing:


https://gitlab.kitware.com/cmake/cmake/merge_requests/17
https://gitlab.kitware.com/cmake/cmake/merge_requests/19

The first adds support for the latest 3.6.x releases.
The second adds support for finding debug variants of the library, uses 
SelectLibraryConfigurations and adds support for release and debug 
variants to the imported targets.



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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc2-322-g947c899

[Roger Leigh]

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  947c899afda22a7b432c85cdf9bec6807b383311 (commit)
   via  86bcdbcde52988fe32e017700d2d0f759a2c2570 (commit)
   via  83ae79442c8bc16cca72977e0671845efe191696 (commit)
  from  e1f12493456067dac78ca8d612b379844a30ea38 (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=947c899afda22a7b432c85cdf9bec6807b383311
commit 947c899afda22a7b432c85cdf9bec6807b383311
Merge: e1f1249 86bcdbc
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Thu Jun 16 09:24:30 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Jun 16 09:24:30 2016 -0400

Merge topic 'ice-debug' into next

86bcdbcd FindIce: Support finding both release and debug libraries
83ae7944 CMake Nightly Date Stamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=86bcdbcde52988fe32e017700d2d0f759a2c2570
commit 86bcdbcde52988fe32e017700d2d0f759a2c2570
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Thu Jun 16 11:21:15 2016 +0100
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Thu Jun 16 12:23:37 2016 +0100

FindIce: Support finding both release and debug libraries

Search for both release and debug library variants, and use
SelectLibraryConfigurations to choose the appropriate
library.  Also add both release and debug libraries to the
imported targets.

diff --git a/Modules/FindIce.cmake b/Modules/FindIce.cmake
index 3fa6cab..4bd6d3c 100644
--- a/Modules/FindIce.cmake
+++ b/Modules/FindIce.cmake
@@ -360,12 +360,20 @@ function(_Ice_FIND)
   foreach(component ${Ice_FIND_COMPONENTS})
 string(TOUPPER "${component}" component_upcase)
 set(component_cache "Ice_${component_upcase}_LIBRARY")
+set(component_cache_release "${component_cache}_RELEASE")
+set(component_cache_debug "${component_cache}_DEBUG")
 set(component_found "${component_upcase}_FOUND")
-find_library("${component_cache}" "${component}"
+find_library("${component_cache_release}" "${component}"
   HINTS ${ice_roots}
   PATH_SUFFIXES ${ice_library_suffixes}
-  DOC "Ice ${component} library")
-mark_as_advanced("${component_cache}")
+  DOC "Ice ${component} library (release)")
+find_library("${component_cache_debug}" "${component}d"
+  HINTS ${ice_roots}
+  PATH_SUFFIXES ${ice_library_suffixes}
+  DOC "Ice ${component} library (debug)")
+include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake)
+select_library_configurations(Ice_${component_upcase})
+mark_as_advanced("${component_cache_release}" "${component_cache_debug}")
 if(${component_cache})
   set("${component_found}" ON)
   list(APPEND Ice_LIBRARY "${${component_cache}}")
@@ -438,6 +446,8 @@ if(Ice_FOUND)
   foreach(_Ice_component ${Ice_FIND_COMPONENTS})
 string(TOUPPER "${_Ice_component}" _Ice_component_upcase)
 set(_Ice_component_cache "Ice_${_Ice_component_upcase}_LIBRARY")
+set(_Ice_component_cache_release 
"Ice_${_Ice_component_upcase}_LIBRARY_RELEASE")
+set(_Ice_component_cache_debug 
"Ice_${_Ice_component_upcase}_LIBRARY_DEBUG")
 set(_Ice_component_lib "Ice_${_Ice_component_upcase}_LIBRARIES")
 set(_Ice_component_found "${_Ice_component_upcase}_FOUND")
 set(_Ice_imported_target "Ice::${_Ice_component}")
@@ -445,9 +455,29 @@ if(Ice_FOUND)
   set("${_Ice_component_lib}" "${${_Ice_component_cache}}")
   if(NOT TARGET ${_Ice_imported_target})
 add_library(${_Ice_imported_target} UNKNOWN IMPORTED)
-set_target_properties(${_Ice_imported_target} PROPERTIES
-  IMPORTED_LOCATION "${${_Ice_component_cache}}"
-  INTERFACE_INCLUDE_DIRECTORIES "${Ice_INCLUDE_DIR}")
+if()
+  set_target_properties(${_Ice_imported_target} PROPERTIES
+INTERFACE_INCLUDE_DIRECTORIES "${Ice_INCLUDE_DIR}")
+endif()
+if(EXISTS "${${_Ice_component_cache}}")
+  set_target_properties(${_Ice_imported_target} PROPERTIES
+IMPORTED_LINK_INTERFACE_LANGUAGES "CXX"
+IMPORTED_LOCATION "${${_Ice_component_cache}}")
+endif()
+if(EXISTS "${${_Ice_component_cache_debug}}")
+  set_property(TARGET ${_I

Re: [CMake] CMake and FindBoost cannot set the library variables

[Roger Leigh]

On 10/06/2016 13:50, Xi Shen wrote:

find_package(Boost REQUIRED COMPONENTS regex program_options)

add_executable(winotify winotify.cpp)

message(STATUS "xxx ${Boost_program_options_LIBRARY_DEBUG}")


Try Boost_PROGRAM_OPTIONS_LIBRARY_DEBUG


message(STATUS "xxx ${Boost_INCLUDE_DIR}")
message(STATUS "xxx ${Boost_LIBRARY_DIR}")


Try Boost_LIBRARY_DIRS

Even easier: use the Boost::program_options interface target

  target_link_libraries(winotify Boost::program_options)

and it will handle both the include dir and the library to link with 
transparently.  It's the way forward!



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

[cmake-developers] [patch] FindBZip2: Add additional debug library name

[Roger Leigh]

I noticed that FindBZip2.cmake was searching for the bzip2d debug 
library but not bz2d (it uses bz2 and bzip2 for the release library 
names).  While bzip2[d] is the common form on Windows, which is what the 
upstream nmake build creates, there are at least two CMake builds for 
bzip2 which use the bz2 form to match the Unix naming:


https://gitlab.kitware.com/ben.boeckel/common-superbuild/blob/master/projects/patches/bzip2-add-cmake.patch
https://github.com/ome/ome-cmake-superbuild/blob/develop/packages/bzip2/patches/cmake.diff

I've merged this bzip2-debug-names branch into next for testing.


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

Re: [CMake] Build, Make Install for multiple machines - Guidelines for Success

[Roger Leigh]

On 07/06/2016 12:10, B00083603 Michael O Brien wrote:

Hi all,

I have to build OpenCV on multiple machines and I was wondering if the
following was possible and advisable or should I use a different method?
I'm still learning about the cmake,make, make install way of software
installation

*Environment*

All the machines (vms) have access to the same shared storage and are
all are Ubuntu 14.04

*On vm1:* run "cmake" on the files stored on the shared storage with the
configuration I need then run "make -j$(nproc)" before using "make
install" to install OpenCV

*On vm 2 to vm n*: Can I just run make install (assuming all the
required software is already installed) or would I be advised to run
"cmake" and "make -j" commands again?


Also is there any issues (file locks for example) about running the
required commands in parallel on multple vms pointing to the same source
or would I be advised to run the commands in serial (vm by vm)?

Finally can I point "make install" to the directory where cmake created
the makefile (apologies if this isn't the correct term, but where cmake
did its work) so I can script the" make install" from outside the build
directory for a slightly cleaner script


So, I also use NFS (v4) mounted storage with all the sources on there, 
be it git repositories, unpacked source archives etc.  However, the 
difference is that I don't *build* on NFS.  I do it in /tmp, or some 
other local scratch space:


cd /tmp
mkdir build
cd build
cmake [options] /path/to/sources
make
[sudo] make install

This will have the following benefits:
- solves all your root-on-nfs permissions issues
- the builds will be vastly faster
- there won't be any timestamp clock skew issues to confound make
- there won't be any NFSv3 locking issues
- you can have a separate build tree per VM, so the source tree stays 
nice and pristine while you build on as many platforms as you desire; I 
do this with Linux, BSD and Windows VMs all building the same git repo 
branches


For the install, can't you just
  (cd "$builddir" && make install)
i.e. in a subshell?  Or
  cmake --build "$builddir" --target install
to be generator-agnostic?


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

Re: [CMake] Make install permissions advice for ubuntu 14.04 with cmake 2.8

[Roger Leigh]

On 06/06/2016 16:30, B00083603 Michael O Brien wrote:
> Is there a way to set things up so that I can streamline the install 
across all the vm's and ensure permissions are set correctly on each vm?

drwx-- 25 myaccount Domain Users 3072 Jun  5 14:47 /home/myaccount/


A simple "chmod 0755 /home/myaccount/" should be sufficient.  If it's 
NFS mounted, all the VMs will have the same permissions here.


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

Re: [CMake] Make install permissions advice for ubuntu 14.04 with cmake 2.8

[Roger Leigh]

On 05/06/2016 17:01, B00083603 Michael O Brien wrote:


sudo make install

When I run sudo make install I get the error
/bin/sh: 1: cd: can't cd to
/home/michael.obrien/setups/OpenCV/opencv-2.4.13/build
make[2]: *** [3rdparty/libtiff/CMakeFiles/libtiff.dir/depend] Error 2
make[1]: *** [3rdparty/libtiff/CMakeFiles/libtiff.dir/all] Error 2
make: *** [all] Error 2

If I run the command make install the build will complete but I get an
error "CMake Error at cmake_install.cmake:36 (FILE): file cannot create
directory /usr/local/include/opencv2. Maybe need administrative privileges

So I'm confused as to how I can resolve this if sudo can't cd to the
folder but I need su(do) to create the directories

Any pointers on how to solve this would be very welcome.


Can you do this:

  sudo -s
  cd /home/michael.obrien/setups/OpenCV/opencv-2.4.13/build

That will check that root has permission to cd there.  One thought for 
why this might fail: is your homedir on NFS with root_squash enabled? 
That might prevent root access.  What are the permissions on this 
directory, and its parents?


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

Re: [CMake] FindFreetype.cmake doesn't find debug library freetyped.lib

[Roger Leigh]

On 05/06/2016 09:14, Stuart Mentzer wrote:

On 6/5/2016 4:26 AM, Rolf Eike Beer wrote:

It's a reasonable addition, so if you can't come up with a patch
yourself I'll
have a look if I can do one next week which you can test.

Greetings,

Eike

Thanks Eike. The simplest, least invasive patch is just:

find_library(FREETYPE_LIBRARY
  NAMES
freetype
libfreetype
freetype219

to:

find_library(FREETYPE_LIBRARY
  NAMES
freetype
freetyped
libfreetype
freetype219

but I understand if you don't want to mix release and debug lib names
like that. If so let me know and I'll do it the way it is done for zlib.
Problem is that I don't know if freetype219 would also have a d suffix
since I'm not sure why that is in there ;-).


This won't behave correctly though--you might end up selecting the debug 
variant for release builds under some circumstances (and vice versa) and 
end up with a broken build.  It really needs to be separate.  You can 
simply add the "d" suffix to all the variants in the current list to the 
debug list for good measure.


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

Re: [CMake] FindFreetype.cmake doesn't find debug library freetyped.lib

[Roger Leigh]

On 04/06/2016 20:47, Stuart Mentzer wrote:

Hello,

FindFreetype.cmake is failing to find the debug library on Windows
because it is named freetype*d*.lib and freetyped isn't in the NAMES
list. Is there some variable I can set to get it found or can freetyped
get added to NAMES?


See how other modules handle this, e.g.

  https://github.com/Kitware/CMake/blob/master/Modules/FindZLIB.cmake#L77

Note the separate searches for the release and debug libs on lines 88-89 
and select_library_configurations on line 93.


If you adapt FindFreetype to use the same pattern, it will handle this 
properly.



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

[cmake-developers] [PATCH] FindBoost: Boost 1.61

[Roger Leigh]

Boost 1.61 was released today.  My boost-1.61 branch, merged into next, 
adds the updated dependency information for this release.  The version 
information was already added, so is unchanged.


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

[Cmake-commits] CMake branch, next, updated. v3.5.2-1399-g238b58f

[Roger Leigh]

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  238b58f12eaf04539a5e5d23aea474dfe3259b77 (commit)
   via  328eff90eb49a2c8e89405cd5427a2a3bcdad977 (commit)
  from  6a29f8cc449469c646fb0a063cf5796c0f569bca (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=238b58f12eaf04539a5e5d23aea474dfe3259b77
commit 238b58f12eaf04539a5e5d23aea474dfe3259b77
Merge: 6a29f8c 328eff9
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Fri May 13 15:05:48 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Fri May 13 15:05:48 2016 -0400

Merge topic 'boost-1.61' into next

328eff90 FindBoost: Update dependencies for Boost 1.61


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=328eff90eb49a2c8e89405cd5427a2a3bcdad977
commit 328eff90eb49a2c8e89405cd5427a2a3bcdad977
Author: Roger Leigh <r.le...@dundee.ac.uk>
AuthorDate: Fri May 13 19:37:10 2016 +0100
Commit: Roger Leigh <r.le...@dundee.ac.uk>
CommitDate: Fri May 13 19:39:41 2016 +0100

FindBoost: Update dependencies for Boost 1.61

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 3d573b8..59a1bff 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -709,7 +709,7 @@ function(_Boost_COMPONENT_DEPENDENCIES component _ret)
 set(_Boost_TIMER_DEPENDENCIES chrono system)
 set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono 
date_time atomic)
 set(_Boost_WSERIALIZATION_DEPENDENCIES serialization)
-  elseif(NOT Boost_VERSION VERSION_LESS 106000 AND Boost_VERSION VERSION_LESS 
106200)
+  elseif(NOT Boost_VERSION VERSION_LESS 106000 AND Boost_VERSION VERSION_LESS 
106100)
 set(_Boost_CHRONO_DEPENDENCIES system)
 set(_Boost_COROUTINE_DEPENDENCIES context system)
 set(_Boost_FILESYSTEM_DEPENDENCIES system)
@@ -723,6 +723,20 @@ function(_Boost_COMPONENT_DEPENDENCIES component _ret)
 set(_Boost_TIMER_DEPENDENCIES chrono system)
 set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono 
date_time atomic)
 set(_Boost_WSERIALIZATION_DEPENDENCIES serialization)
+  elseif(NOT Boost_VERSION VERSION_LESS 106100 AND Boost_VERSION VERSION_LESS 
106200)
+set(_Boost_CHRONO_DEPENDENCIES system)
+set(_Boost_CONTEXT_DEPENDENCIES thread chrono system date_time)
+set(_Boost_COROUTINE_DEPENDENCIES context system)
+set(_Boost_FILESYSTEM_DEPENDENCIES system)
+set(_Boost_IOSTREAMS_DEPENDENCIES regex)
+set(_Boost_LOG_DEPENDENCIES date_time log_setup system filesystem thread 
regex chrono atomic)
+set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 
math_tr1f math_tr1l atomic)
+set(_Boost_MPI_DEPENDENCIES serialization)
+set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization)
+set(_Boost_RANDOM_DEPENDENCIES system)
+set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic)
+set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono 
date_time atomic)
+set(_Boost_WSERIALIZATION_DEPENDENCIES serialization)
   else()
 message(WARNING "Imported targets not available for Boost version 
${Boost_VERSION}")
 set(_Boost_IMPORTED_TARGETS FALSE)

---

Summary of changes:
 Modules/FindBoost.cmake |   16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)


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

Re: [cmake-developers] [PATCH] FindBoost does not detect absence of header file

[Roger Leigh]

On 13/05/2016 14:36, Brad King wrote:

On 05/12/2016 03:49 PM, Roger Leigh wrote:

I have made the suggested changes above where this was possible, and
merged the boost-component-headers branch into next for testing.


Thanks.  It looks pretty good, but there is one problem:


+find_path(Boost_${UPPERCOMPONENT}_HEADER
+  NAMES ${Boost_${UPPERCOMPONENT}_HEADER_NAME}
+  HINTS ${Boost_INCLUDE_DIR}


This leaves a bunch of Boost_${UPPERCOMPONENT}_HEADER values in
the cache.  The names look public, and they are publicly visible.
We should not expose this implementation detail.

Also, the find_path() approach means it might find the header somewhere
other than Boost_INCLUDE_DIR.  If it is not there, we cannot be confident
that it will match the library found.

Can the check use just if(EXISTS) instead?


Dear Brad,

Thanks for looking over this.  We could definitely use if(EXISTS).  I've 
pushed a change which does this.



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

[Cmake-commits] CMake branch, next, updated. v3.5.2-1391-g3f70479

[Roger Leigh]

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  3f70479e1714a16cd505d2930e414cb7cd72a5a2 (commit)
   via  387ee29bc26fa445081d888fc6900182e9617c98 (commit)
  from  f4b43522ecd7880cd24b9f6895003342e476d06d (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=3f70479e1714a16cd505d2930e414cb7cd72a5a2
commit 3f70479e1714a16cd505d2930e414cb7cd72a5a2
Merge: f4b4352 387ee29
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Fri May 13 13:36:23 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Fri May 13 13:36:23 2016 -0400

Merge topic 'boost-component-headers' into next

387ee29b FindBoost: Check headers exist without find_path


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=387ee29bc26fa445081d888fc6900182e9617c98
commit 387ee29bc26fa445081d888fc6900182e9617c98
Author: Roger Leigh <r.le...@dundee.ac.uk>
AuthorDate: Fri May 13 18:26:24 2016 +0100
Commit: Roger Leigh <r.le...@dundee.ac.uk>
CommitDate: Fri May 13 18:31:20 2016 +0100

FindBoost: Check headers exist without find_path

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 2ec4925..777003b 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -1435,10 +1435,11 @@ foreach(COMPONENT ${Boost_FIND_COMPONENTS})
   _Boost_COMPONENT_HEADERS("${COMPONENT}" Boost_${UPPERCOMPONENT}_HEADER_NAME)
   # Look for a standard boost header file.
   if(Boost_${UPPERCOMPONENT}_HEADER_NAME)
-find_path(Boost_${UPPERCOMPONENT}_HEADER
-  NAMES ${Boost_${UPPERCOMPONENT}_HEADER_NAME}
-  HINTS ${Boost_INCLUDE_DIR}
-  )
+if(EXISTS "${Boost_INCLUDE_DIR}/${Boost_${UPPERCOMPONENT}_HEADER_NAME}")
+  set(Boost_${UPPERCOMPONENT}_HEADER ON)
+else()
+  set(Boost_${UPPERCOMPONENT}_HEADER OFF)
+endif()
   else()
 set(Boost_${UPPERCOMPONENT}_HEADER ON)
 message(WARNING "No header defined for ${COMPONENT}; skipping header 
check")

---

Summary of changes:
 Modules/FindBoost.cmake |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)


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

Re: [cmake-developers] [PATCH] FindBoost does not detect absence of header file

[Roger Leigh]

On 11/05/2016 19:43, rle...@codelibre.net wrote:

On 2016-05-11 19:30, Chuck Atkins wrote:

I guess it doesn't really matter but for the libraries that don't have
a single include header, should you be using these instead:

* container/container_fwd.hpp
* exception/all.hpp
* filesystem.hpp
* math_fwd.hpp (instead of math/quaternion.hpp)
* system/config.hpp
* type_erasure/config.hpp

They're "common" or "central" headers for the libraries instead of
specific headers.


Thanks for taking a look and making the suggestions.  I'll certainly
update some of these.  However, note that for some of these (e.g.
exception, filesystem), that common header didn't exist in earlier
releases and so was deliberately not used; in these cases I picked a
common header which is present in *all* Boost releases, back to 1.33
except for components which were introduced in later releases.
filesystem.hpp was introduced after the initial release with filesytem,
likewise exception/all.hpp for exception.


I have made the suggested changes above where this was possible, and 
merged the boost-component-headers branch into next for testing.



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

[Cmake-commits] CMake branch, next, updated. v3.5.2-1361-ge358f06

[Roger Leigh]

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  e358f069ec4a5d142ee2c8a877c65922201d649c (commit)
   via  71d2d6e565e9b9c9a4a653af84c67c540c41890d (commit)
  from  969ac90d3805db87e32929de3305d1af5470aba6 (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=e358f069ec4a5d142ee2c8a877c65922201d649c
commit e358f069ec4a5d142ee2c8a877c65922201d649c
Merge: 969ac90 71d2d6e
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Thu May 12 15:48:38 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu May 12 15:48:38 2016 -0400

Merge topic 'boost-component-headers' into next

71d2d6e5 FindBoost: Add checks for component-specific headers


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=71d2d6e565e9b9c9a4a653af84c67c540c41890d
commit 71d2d6e565e9b9c9a4a653af84c67c540c41890d
Author: Roger Leigh <rle...@dundee.ac.uk>
AuthorDate: Wed May 11 10:55:51 2016 +0100
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Thu May 12 20:46:25 2016 +0100

FindBoost: Add checks for component-specific headers

This supplements the existing library checks, to
cater for the possibility that the libraries are
present but the headers are not.  This can happen
when the Boost collections is split up into
multiple packages and not all are installed,
and will avoid the checks silently passing when
the build would subsequently fail.

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 3d573b8..2ec4925 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -310,7 +310,7 @@ macro(_Boost_ADJUST_LIB_VARS basename)
   set(Boost_${basename}_LIBRARIES ${Boost_${basename}_LIBRARY_RELEASE} )
 endif()
 
-if(Boost_${basename}_LIBRARY)
+if(Boost_${basename}_LIBRARY AND Boost_${basename}_HEADER)
   set(Boost_${basename}_FOUND ON)
 endif()
 
@@ -522,7 +522,9 @@ function(_Boost_COMPONENT_DEPENDENCIES component _ret)
   #
   # The output may be added in a new block below.  If it's the same as
   # the previous release, simply update the version range of the block
-  # for the previous release.
+  # for the previous release.  Also check if any new components have
+  # been added, and add any new components to
+  # _Boost_COMPONENT_HEADERS.
   #
   # This information was originally generated by running
   # BoostScanDeps.cmake against every boost release to date supported
@@ -740,6 +742,67 @@ function(_Boost_COMPONENT_DEPENDENCIES component _ret)
 endfunction()
 
 #
+# Get component headers.  This is the primary header (or headers) for
+# a given component, and is used to check that the headers are present
+# as well as the library itself as an extra sanity check of the build
+# environment.
+#
+# component - the component to check
+# _hdrs
+#
+function(_Boost_COMPONENT_HEADERS component _hdrs)
+  # Note: new boost components will require adding here.  The header
+  # must be present in all versions of Boost providing a library.
+  set(_Boost_ATOMIC_HEADERS  "boost/atomic.hpp")
+  set(_Boost_CHRONO_HEADERS  "boost/chrono.hpp")
+  set(_Boost_CONTAINER_HEADERS   "boost/container/container_fwd.hpp")
+  set(_Boost_CONTEXT_HEADERS "boost/context/all.hpp")
+  set(_Boost_COROUTINE_HEADERS   "boost/coroutine/all.hpp")
+  set(_Boost_EXCEPTION_HEADERS   "boost/exception/exception.hpp")
+  set(_Boost_DATE_TIME_HEADERS   "boost/date_time/date.hpp")
+  set(_Boost_FILESYSTEM_HEADERS  "boost/filesystem/path.hpp")
+  set(_Boost_GRAPH_HEADERS   "boost/graph/adjacency_list.hpp")
+  set(_Boost_GRAPH_PARALLEL_HEADERS  "boost/graph/adjacency_list.hpp")
+  set(_Boost_IOSTREAMS_HEADERS   "boost/iostreams/stream.hpp")
+  set(_Boost_LOCALE_HEADERS  "boost/locale.hpp")
+  set(_Boost_LOG_HEADERS "boost/log/core.hpp")
+  set(_Boost_LOG_SETUP_HEADERS   "boost/log/detail/setup_config.hpp")
+  set(_Boost_MATH_HEADERS"boost/math_fwd.hpp")
+  set(_Boost_MATH_C99_HEADERS"boost/math/tr1.hpp")
+  set(_Boost_MATH_C99F_HEADERS   "boost/math/tr1.hpp")
+  set(_Boost_MATH_C99L_HEADERS   "boost/math/tr1.hpp")
+  set(_Boost_MATH_TR1_HEADERS"boost/math/tr1.hpp")
+  set(_Boost_MATH_TR1F_HEADERS   "boost/math/tr1.hpp")
+  set(_Bo

[cmake-developers] [PATCH] Always define Boost::boost imported target

[Roger Leigh]

For https://cmake.org/Bug/view.php?id=16057 I have merged the 
boost-import-default branch into next for testing.  This includes a unit 
test to verify that the basic boost headers work in the absence of 
COMPONENTS being specified with find_package.



Regards,
Roger

--
Dr Roger Leigh -- Open Microscopy Environment
Wellcome Trust Centre for Gene Regulation and Expression,
School of Life Sciences, University of Dundee, Dow Street,
Dundee DD1 5EH Scotland UK   Tel: (01382) 386364
--

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.5.2-1018-g5155d7b

[Roger Leigh]

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  5155d7b2854231156b66e2359742585ce7b38973 (commit)
   via  2c1b720e643aafd725a8c0be11913834704d7269 (commit)
  from  c6ab628a0bbcd23229537a00fddbbc7bd9c617e9 (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=5155d7b2854231156b66e2359742585ce7b38973
commit 5155d7b2854231156b66e2359742585ce7b38973
Merge: c6ab628 2c1b720
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Tue Apr 19 17:17:18 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Apr 19 17:17:18 2016 -0400

Merge topic 'boost-import-default' into next

2c1b720e FindBoost: Define Boost::boost for all boost versions


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2c1b720e643aafd725a8c0be11913834704d7269
commit 2c1b720e643aafd725a8c0be11913834704d7269
Author: Roger Leigh <r.le...@dundee.ac.uk>
AuthorDate: Sun Apr 17 16:24:51 2016 +0100
Commit: Roger Leigh <r.le...@dundee.ac.uk>
CommitDate: Tue Apr 19 22:07:45 2016 +0100

FindBoost: Define Boost::boost for all boost versions

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 9e6083d..38ccf78 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -1573,7 +1573,7 @@ endif()
 #  Add imported targets
 # 
 
-if(Boost_FOUND AND _Boost_IMPORTED_TARGETS)
+if(Boost_FOUND)
   # For header-only libraries
   if(NOT TARGET Boost::boost)
 add_library(Boost::boost INTERFACE IMPORTED)
@@ -1584,7 +1584,7 @@ if(Boost_FOUND AND _Boost_IMPORTED_TARGETS)
   endif()
 
   foreach(COMPONENT ${Boost_FIND_COMPONENTS})
-if(NOT TARGET Boost::${COMPONENT})
+if(_Boost_IMPORTED_TARGETS AND NOT TARGET Boost::${COMPONENT})
   string(TOUPPER ${COMPONENT} UPPERCOMPONENT)
   if(Boost_${UPPERCOMPONENT}_FOUND)
 if(Boost_USE_STATIC_LIBS)
diff --git a/Tests/CFBundleTest/Localized.rsrc 
b/Tests/CFBundleTest/Localized.rsrc
index cbf3523..7973c1f 100644
Binary files a/Tests/CFBundleTest/Localized.rsrc and 
b/Tests/CFBundleTest/Localized.rsrc differ
diff --git a/Tests/FindBoost/CMakeLists.txt b/Tests/FindBoost/CMakeLists.txt
index 259ee26..0e9527d 100644
--- a/Tests/FindBoost/CMakeLists.txt
+++ b/Tests/FindBoost/CMakeLists.txt
@@ -8,3 +8,14 @@ add_test(NAME FindBoost.Test COMMAND
   --build-options ${build_options}
   --test-command ${CMAKE_CTEST_COMMAND} -V -C $
   )
+
+add_test(NAME FindBoost.TestHeaders COMMAND
+  ${CMAKE_CTEST_COMMAND} -C $
+  --build-and-test
+  "${CMake_SOURCE_DIR}/Tests/FindBoost/TestHeaders"
+  "${CMake_BINARY_DIR}/Tests/FindBoost/TestHeaders"
+  ${build_generator_args}
+  --build-project TestFindBoostHeaders
+  --build-options ${build_options}
+  --test-command ${CMAKE_CTEST_COMMAND} -V -C $
+  )
diff --git a/Tests/FindBoost/TestHeaders/CMakeLists.txt 
b/Tests/FindBoost/TestHeaders/CMakeLists.txt
new file mode 100644
index 000..d7be327
--- /dev/null
+++ b/Tests/FindBoost/TestHeaders/CMakeLists.txt
@@ -0,0 +1,10 @@
+cmake_minimum_required(VERSION 3.1)
+project(TestFindBoostHeaders CXX)
+include(CTest)
+
+find_package(Boost REQUIRED)
+
+add_executable(test_boost_headers_tgt main.cxx)
+target_link_libraries(test_boost_headers_tgt
+  Boost::boost)
+add_test(NAME test_boost_headers_tgt COMMAND test_boost_headers_tgt)
diff --git a/Tests/FindBoost/TestHeaders/main.cxx 
b/Tests/FindBoost/TestHeaders/main.cxx
new file mode 100644
index 000..0400d6d
--- /dev/null
+++ b/Tests/FindBoost/TestHeaders/main.cxx
@@ -0,0 +1,9 @@
+#include 
+
+int main() {
+  boost::any a;
+  a = 5;
+  a = std::string("A string");
+
+  return 0;
+}

---

Summary of changes:
 Modules/FindBoost.cmake|4 ++--
 Tests/CFBundleTest/Localized.rsrc  |  Bin 496 -> 472 bytes
 Tests/FindBoost/CMakeLists.txt |   11 +++
 Tests/FindBoost/TestHeaders/CMakeLists.txt |   10 ++
 Tests/FindBoost/TestHeaders/main.cxx   |9 +
 5 files changed, 32 insertions(+), 2 deletions(-)
 create mode 100644 Tests/FindBoost/TestHeaders/CMakeLists.txt
 create mode 100644 Tests/FindBoost/TestHeaders/main.cxx


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

[cmake-developers] #16013 merged for testing

[Roger Leigh]

Hi folks,

I've merged the branch boost-optional-indirect-deps into next for 
testing (for https://cmake.org/Bug/view.php?id=16013).



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

[Cmake-commits] CMake branch, next, updated. v3.5.0-453-geba1962

[Roger Leigh]

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  eba19623c552ec9fe6b073a821a4655d13d363b5 (commit)
   via  ca4a15406591c249b94e97695fcdfe713f9b8197 (commit)
  from  4d73f5367364a9104fa4a8b9d053a5ed2e48b748 (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=eba19623c552ec9fe6b073a821a4655d13d363b5
commit eba19623c552ec9fe6b073a821a4655d13d363b5
Merge: 4d73f53 ca4a154
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Tue Mar 15 05:22:42 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Mar 15 05:22:42 2016 -0400

Merge topic 'boost-optional-indirect-deps' into next

ca4a1540 FindBoost: Missing indirect dependencies are not a fatal error


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ca4a15406591c249b94e97695fcdfe713f9b8197
commit ca4a15406591c249b94e97695fcdfe713f9b8197
Author: Roger Leigh <rle...@dundee.ac.uk>
AuthorDate: Mon Mar 14 13:49:39 2016 +
Commit: Roger Leigh <rle...@dundee.ac.uk>
CommitDate: Mon Mar 14 13:49:39 2016 +

FindBoost: Missing indirect dependencies are not a fatal error

Depending upon the configuration, certain components may or may not
be installed, for example Boost.Regex, but other components may
still have header dependencies upon these components which will
obviously fail to work.  Since we can't make a sensible
determination with the hardcoded dependency information, we
choose to interpret these dependencies less strictly.

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index c3058ea..c6feda7 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -745,9 +745,10 @@ endfunction()
 # defined; FALSE if dependency information is unavailable).
 #
 # componentvar - the component list variable name
+# extravar - the indirect dependency list variable name
 #
 #
-function(_Boost_MISSING_DEPENDENCIES componentvar)
+function(_Boost_MISSING_DEPENDENCIES componentvar extravar)
   # _boost_unprocessed_components - list of components requiring processing
   # _boost_processed_components - components already processed (or currently 
being processed)
   # _boost_new_components - new components discovered for future processing
@@ -773,7 +774,10 @@ function(_Boost_MISSING_DEPENDENCIES componentvar)
 set(_boost_unprocessed_components ${_boost_new_components})
 unset(_boost_new_components)
   endwhile()
+  set(_boost_extra_components ${_boost_processed_components})
+  list(REMOVE_ITEM _boost_extra_components ${${componentvar}})
   set(${componentvar} ${_boost_processed_components} PARENT_SCOPE)
+  set(${extravar} ${_boost_extra_components} PARENT_SCOPE)
 endfunction()
 
 #
@@ -1306,7 +1310,7 @@ endif()
 
 # Additional components may be required via component dependencies.
 # Add any missing components to the list.
-_Boost_MISSING_DEPENDENCIES(Boost_FIND_COMPONENTS)
+_Boost_MISSING_DEPENDENCIES(Boost_FIND_COMPONENTS _Boost_EXTRA_FIND_COMPONENTS)
 
 # If thread is required, get the thread libs as a dependency
 list(FIND Boost_FIND_COMPONENTS thread _Boost_THREAD_DEPENDENCY_LIBS)
@@ -1484,6 +1488,8 @@ if(Boost_FOUND)
   list(APPEND _Boost_MISSING_COMPONENTS ${COMPONENT})
 endif()
   endforeach()
+  # Optional indirect dependencies are not counted as missing.
+  list(REMOVE_ITEM _Boost_MISSING_COMPONENTS ${_Boost_EXTRA_FIND_COMPONENTS})
 
   if(Boost_DEBUG)
 message(STATUS "[ ${CMAKE_CURRENT_LIST_FILE}:${CMAKE_CURRENT_LIST_LINE} ] 
Boost_FOUND = ${Boost_FOUND}")

---

Summary of changes:
 Modules/FindBoost.cmake |   10 --
 1 file changed, 8 insertions(+), 2 deletions(-)


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

Re: [cmake-developers] CMakeFindDependencyMacro limitations

[Roger Leigh]

On 24/02/2016 22:49, Roger Leigh wrote:

I've attached a patch for a very simple modification to find_dependency.
  I'm not proposing that it be merged, it's just a suggestion for
further discussion.  I've tested it with my own packages with multiple
find_dependency(Boost COMPONENTS ...) calls.  Some rationale and
thoughts follow:


Did anyone have any time to take a look at this?  Are there any 
objections or further questions arising from the approach taken here? 
Could it be submitted for inclusion if not?



Thanks,
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-developers

Re: [cmake-developers] CMakeFindDependencyMacro limitations

[Roger Leigh]

On 24/12/2015 12:07, Stephen Kelly wrote:

Roger Leigh wrote:


On 21/12/2015 15:07, Stephen Kelly wrote:

Roger Leigh wrote:

I can understand why REQUIRED and related
arguments are omitted--that is why find_dependency exists--but I'd quite
like to be able to specify COMPONENTS where needed e.g. with FindBoost,
and this is not currently possible.


I don't remember whether this was discussed when designing
find_dependency. Perhaps COMPONENTS could be added to the macro now.


Currently, for my own needs, COMPONENTS is the single missing piece.  If
it would be possible to add this, it would certainly be very useful.

I'd be happy to provide a patch for COMPONENTS if you like.


I think the reason that the macro does not support COMPONENTS is that I
don't understand how COMPONENTS is supposed to work. For example:

  find_package(Qt5 COMPONENTS Widgets)
  # Is Qt5_FOUND set to true or false?
  find_package(Qt5 COMPONENTS Quick)
  # ... what about now?

What does _FOUND ever mean if the find_package is called multiple
times with different components? Does it mean anything?


I would think that it would mean whether the last call succeeded or 
failed for the requested components at that time.  It wouldn't have any 
greater or more permanent meaning.  To the best of my knowledge, that's 
what the status quo is for find_package.



Should CMake disallow multiple use of find_package with the same package and
with different components?



If user code has

  find_package(Qt5 COMPONENTS Widgets)
  find_package(FooBar REQUIRED)

and FooBarConfig.cmake has

  find_dependency(Qt5 COMPONENTS Quick)

then the if(Qt5_FOUND) in the macro will mean it will not try to find the
Quick component.

So, there may be a need to establish a convention such as

  __FOUND

and check that for each component in the macro.


Right now, it's certainly possible for this to happen.  I'm seeing this 
myself with multiple packages (or individual components' config scripts) 
requiring different sets of Boost components.  Each invokes 
find_dependency with its own needed set of components.



You would also need to think through everything and find out whether that is
really a full solution. I haven't thought more deeply about it than the
above.

Note that the above example with Qt 5 can not currently happen in practice
because the find_dependency macro does not support COMPONENTS, so config
files must instead use

  find_dependency(Qt5Quick)

if they want to use the macro currently. This is a good thing.

So, I would like to know if

* adding COMPONENTS support to the find_dependency macro is the right thing
   to do
* or if the right thing to do is to move away from support for COMPONENTS
   generally because of its messy semantics
* or if find_package should change to not support multiple calls for the
   same package.

I really don't know the answer - I think someone needs to do deep thinking
about it.

I would prefer the macro not be changed before that deep thinking about
COMPONENTS generally is done.


I've attached a patch for a very simple modification to find_dependency. 
 I'm not proposing that it be merged, it's just a suggestion for 
further discussion.  I've tested it with my own packages with multiple 
find_dependency(Boost COMPONENTS ...) calls.  Some rationale and 
thoughts follow:


Regarding the messy semantics of find_package, I agree it's not ideal. 
However, I find the differing behaviour of find_dependency and 
find_package even less so.  Ideally I should be able to call both 
multiple times, or neither.  While as you mentioned for Qt5, it's 
possible to work around this by calling find_dependency for each 
component by hand, but that's not possible for all packages.  Boost for 
example does not work this way, making this a major blocker to using 
find_dependency with Boost.  I'm basically blocked by this right now, 
and the patch here removes the single call restriction and passes 
through COMPONENTS, making it work.  That would at the very least make 
things consistent and functional.


I don't think it's in general going to be possible to avoid multiple 
calls.  Complex projects including or depending upon other projects are 
going to do this inevitably, and they may have differing version 
requirements as well as different sets of components.  And it's already 
in established use.  I don't think for find_dependency that returning 
immediately if ${dep}_FOUND is true is correct behaviour--it skips the 
version check, and I think it should be calling find_package to do this 
check under all circumstances.  I think it's trading correctness for 
speed, but I really would prefer to have the version check performed 
correctly every time.


Regarding having __FOUND, I think this would be 
useful irrespective of any find_dependency changes.  And coupled with 
the above patch, find_dependency could be extended to return immediately 
if the version check is satisfied *and* all the requested components are 
found

Re: [cmake-developers] EXPORT dependency handling

[Roger Leigh]

On 20/01/2016 19:05, Brad King wrote:

On 01/20/2016 11:57 AM, rle...@codelibre.net wrote:

As an aside, I've found some limitations in the usability and utility of
EXPORT.  These are two of the missing pieces for making the exported
configuration functional:

1) is the need to manually call find_dependency for each of the interface
libraries being exported.  I work around this with wrapper scripts, for
example:

   
https://github.com/openmicroscopy/bioformats/blob/develop/cpp/lib/ome/bioformats/OMEBioFormatsConfig.cmake

Here we find our dependencies, then include the generated configuration.
The thing is, this is a duplication of our requirements from when we
called find_package for each of those dependencies.  If cmake could store
a mapping from imported name to the FindXXX file which created it, this
could also be automatically embedded in the exported file; it could even
include the minimum version we need.  And it also means the dependencies
can never become inconsistent as we change them.


The difficulty of this problem is why we defer responsibility to project
code to provide the imported targets for dependencies of exported targets.
There are so many ways of making imported targets available I don't think
it can be solved in general, but perhaps it can be made to work in common
cases (at least optionally) with some kind of mapping as you propose.


Agreed that it's not going to be possible to do the mapping 
automatically.  Maybe allowing it to be specified manually as a target 
property would be acceptable though.  We could have a property for the 
name to pass to find_dependency/find_package, and another for a minimum 
version, which EXPORT could use, if set, to automatically add 
find_dependency statements.  We could set these in the Find* modules 
when we create the imported interfaces, and they could also be set on 
targets in the source tree as needed.



2) the need to create the interface library target.


I don't understand what you're saying here.  What interface library target
needs to be created in what context?  Please provide an example.


Sorry for not being clear, it was at the end of the URL.  I'll copy the 
whole thing, since it's short (OMEBioFormatsConfig.cmake):


  include(CMakeFindDependencyMacro)
  find_dependency(OME REQUIRED COMPONENTS Common XML)
  find_dependency(Boost 1.46 REQUIRED COMPONENTS boost iostreams 
filesystem)

  find_dependency(TIFF REQUIRED)

  include(${CMAKE_CURRENT_LIST_DIR}/OMEBioFormatsInternal.cmake)

  add_library(OME::BioFormats INTERFACE IMPORTED)
  set_target_properties(OME::BioFormats PROPERTIES 
INTERFACE_LINK_LIBRARIES ome-bioformats)


It's the last two lines.  Internally, the target name is ome-bioformats, 
but I actually want it to be OME::BioFormats as the name of the imported 
interface.  I don't have any need for "ome-bioformats" to be exported at 
all, but EXPORT only allows a real target.  Unless I missed a 
workaround; I tried exporting ALIAS names and interface names, but 
without success.


Ideally, if these two issues can be resolved, it will be possible to 
emit a fully-functional exported configuration file which will work 
without the need for custom wrapper code to fix up these things.



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

Re: [cmake-developers] [patch] New find module FindXalanC

[Roger Leigh]

On 19/01/2016 19:14, Brad King wrote:

On 01/19/2016 12:02 PM, Roger Leigh wrote:

+find_package(XercesC 3.0.0 REQUIRED)


I think this is an assumption leaking from my own usage of it. I've
removed the version here.


Thanks.  The CMakeOnly.AllFindModules and FindModulesExecuteAll
tests fail when XercesC is not available.  It should be required
only if XalanC is required (XalanC_FIND_REQUIRED).


This should be fixed now.


Thanks,
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-developers

[Cmake-commits] CMake branch, next, updated. v3.4.2-2032-gda0dd89

[Roger Leigh]

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  da0dd89221bbf9a46dd6065c18023b9f62f682a2 (commit)
   via  3b61ef9dd48eaaacc2fa5123974d9cb9f68ae96d (commit)
  from  f0f0470cbf18cdea04873fd1ad67a6504f88a779 (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=da0dd89221bbf9a46dd6065c18023b9f62f682a2
commit da0dd89221bbf9a46dd6065c18023b9f62f682a2
Merge: f0f0470 3b61ef9
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Tue Jan 19 19:04:10 2016 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Jan 19 19:04:10 2016 -0500

Merge topic 'xalanc' into next

3b61ef9d FindXercesC: Pass REQUIRED flag to find_package conditionally


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3b61ef9dd48eaaacc2fa5123974d9cb9f68ae96d
commit 3b61ef9dd48eaaacc2fa5123974d9cb9f68ae96d
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Tue Jan 19 23:57:55 2016 +
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Wed Jan 20 00:00:44 2016 +

FindXercesC: Pass REQUIRED flag to find_package conditionally

diff --git a/Modules/FindXalanC.cmake b/Modules/FindXalanC.cmake
index bdb823a..016b7aa 100644
--- a/Modules/FindXalanC.cmake
+++ b/Modules/FindXalanC.cmake
@@ -110,7 +110,12 @@ unset(XalanC_VERSION_MAJOR)
 unset(XalanC_VERSION_MINOR)
 unset(XalanC_VERSION_PATCH)
 
-find_package(XercesC) # TODO: require if we are required
+unset(XalanC_XERCESC_REQUIRED)
+if(XalanC_FIND_REQUIRED)
+  set(XalanC_XERCESC_REQUIRED REQUIRED)
+endif()
+find_package(XercesC ${XalanC_XERCESC_REQUIRED})
+unset(XalanC_XERCESC_REQUIRED)
 
 include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
 FIND_PACKAGE_HANDLE_STANDARD_ARGS(XalanC

---

Summary of changes:
 Modules/FindXalanC.cmake |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)


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

[Roger Leigh]

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  867a79a332bd3bf9c48e3a713962ead9d96d04c2 (commit)
   via  6100263329ac590e489f9454840be8ee71ef02fb (commit)
  from  6ed6ba600f7852c34d917dd8fcdff14992201352 (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=867a79a332bd3bf9c48e3a713962ead9d96d04c2
commit 867a79a332bd3bf9c48e3a713962ead9d96d04c2
Merge: 6ed6ba6 6100263
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Tue Jan 19 10:57:03 2016 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Jan 19 10:57:03 2016 -0500

Merge topic 'xalanc' into next

61002633 FindXalanC: New module to find the Apache Xalan-C++ library


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6100263329ac590e489f9454840be8ee71ef02fb
commit 6100263329ac590e489f9454840be8ee71ef02fb
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Tue Jan 19 13:32:38 2016 +
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Tue Jan 19 15:53:04 2016 +

FindXalanC: New module to find the Apache Xalan-C++ library

diff --git a/Modules/FindXalanC.cmake b/Modules/FindXalanC.cmake
new file mode 100644
index 000..7599bd4
--- /dev/null
+++ b/Modules/FindXalanC.cmake
@@ -0,0 +1,150 @@
+#.rst:
+# FindXalanC
+# ---
+#
+# Find the Apache Xalan-C++ XSL transform processor headers and libraries.
+#
+# Imported targets
+# 
+#
+# This module defines the following :prop_tgt:`IMPORTED` targets:
+#
+# ``XalanC::XalanC``
+#   The Xalan-C++ ``xalan-c`` library, if found.
+#
+# Result variables
+# 
+#
+# This module will set the following variables in your project:
+#
+# ``XalanC_FOUND``
+#   true if the Xalan headers and libraries were found
+# ``XalanC_VERSION``
+#   Xalan release version
+# ``XalanC_INCLUDE_DIRS``
+#   the directory containing the Xalan headers; note
+#   ``XercesC_INCLUDE_DIRS`` is also required
+# ``XalanC_LIBRARIES``
+#   Xalan libraries to be linked; note ``XercesC_LIBRARIES`` is also
+#   required
+#
+# Cache variables
+# ^^^
+#
+# The following cache variables may also be set:
+#
+# ``XalanC_INCLUDE_DIR``
+#   the directory containing the Xalan headers
+# ``XalanC_LIBRARY``
+#   the Xalan library
+
+# Written by Roger Leigh <rle...@codelibre.net>
+
+#=
+# Copyright 2016 University of Dundee
+#
+# Distributed under the OSI-approved BSD License (the "License");
+# see accompanying file Copyright.txt for details.
+#
+# This software is distributed WITHOUT ANY WARRANTY; without even the
+# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+# See the License for more information.
+#=
+# (To distribute this file outside of CMake, substitute the full
+#  License text for the above reference.)
+
+function(_XalanC_GET_VERSION  version_hdr)
+file(STRINGS ${version_hdr} _contents REGEX "^[ \t]*#define 
XALAN_VERSION_.*")
+if(_contents)
+string(REGEX REPLACE "[^*]*#define XALAN_VERSION_MAJOR[ 
\t]+([0-9]+).*" "\\1" XalanC_MAJOR "${_contents}")
+string(REGEX REPLACE "[^*]*#define XALAN_VERSION_MINOR[ 
\t]+([0-9]+).*" "\\1" XalanC_MINOR "${_contents}")
+string(REGEX REPLACE "[^*]*#define XALAN_VERSION_REVISION[ 
\t]+([0-9]+).*" "\\1" XalanC_PATCH "${_contents}")
+
+if(NOT XalanC_MAJOR MATCHES "^[0-9]+$")
+message(FATAL_ERROR "Version parsing failed for 
XALAN_VERSION_MAJOR!")
+endif()
+if(NOT XalanC_MINOR MATCHES "^[0-9]+$")
+message(FATAL_ERROR "Version parsing failed for 
XALAN_VERSION_MINOR!")
+endif()
+if(NOT XalanC_PATCH MATCHES "^[0-9]+$")
+message(FATAL_ERROR "Version parsing failed for 
XALAN_VERSION_REVISION!")
+endif()
+
+set(XalanC_VERSION "${XalanC_MAJOR}.${XalanC_MINOR}.${XalanC_PATCH}" 
PARENT_SCOPE)
+else()
+message(FATAL_ERROR "Include file ${version_hdr} does not exist or 
does not contain expected version information")
+endif()
+endfunction()
+
+# Find include directory
+find_path(XalanC_INCLUDE_DIR
+  NAMES "xalanc/XalanTransformer/XalanTransformer.hpp"
+  DOC "Xalan-C++ include directory")
+mark_as_advanced(XalanC_INCLUDE_DIR)
+

[Cmake-commits] CMake branch, next, updated. v3.4.1-2021-g4af8e76

[Roger Leigh]

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  4af8e762a976e3602c477d05275db3f7156e7a5f (commit)
   via  a11c0e7716d57fa7042632868d808b35d9372bb2 (commit)
  from  f1bbd9719009f15afdbcf2a62c10c7779d5c1ace (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=4af8e762a976e3602c477d05275db3f7156e7a5f
commit 4af8e762a976e3602c477d05275db3f7156e7a5f
Merge: f1bbd97 a11c0e7
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Tue Jan 19 11:38:01 2016 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Jan 19 11:38:01 2016 -0500

Merge topic 'xalanc' into next

a11c0e77 FindXalanC: Correct versioning for Windows DLLs


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a11c0e7716d57fa7042632868d808b35d9372bb2
commit a11c0e7716d57fa7042632868d808b35d9372bb2
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Tue Jan 19 16:34:59 2016 +
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Tue Jan 19 16:37:39 2016 +

FindXalanC: Correct versioning for Windows DLLs

diff --git a/Modules/FindXalanC.cmake b/Modules/FindXalanC.cmake
index 7599bd4..58a68d8 100644
--- a/Modules/FindXalanC.cmake
+++ b/Modules/FindXalanC.cmake
@@ -71,6 +71,9 @@ function(_XalanC_GET_VERSION  version_hdr)
 endif()
 
 set(XalanC_VERSION "${XalanC_MAJOR}.${XalanC_MINOR}.${XalanC_PATCH}" 
PARENT_SCOPE)
+set(XalanC_VERSION_MAJOR "${XalanC_MAJOR}" PARENT_SCOPE)
+set(XalanC_VERSION_MINOR "${XalanC_MINOR}" PARENT_SCOPE)
+set(XalanC_VERSION_PATCH "${XalanC_PATCH}" PARENT_SCOPE)
 else()
 message(FATAL_ERROR "Include file ${version_hdr} does not exist or 
does not contain expected version information")
 endif()
@@ -90,19 +93,23 @@ if(NOT XalanC_LIBRARY)
   # Find all XalanC libraries
   find_library(XalanC_LIBRARY_RELEASE
NAMES "Xalan-C" "xalan-c"
- "Xalan-C_${XalanC_MAJOR}"
- "Xalan-C_${XalanC_MAJOR}_${XalanC_MINOR}"
+ "Xalan-C_${XalanC_VERSION_MAJOR}"
+ "Xalan-C_${XalanC_VERSION_MAJOR}_${XalanC_VERSION_MINOR}"
DOC "Xalan-C++ libraries (release)")
   find_library(XalanC_LIBRARY_DEBUG
NAMES "Xalan-CD" "xalan-cd"
- "Xalan-C_${XalanC_MAJOR}D"
- "Xalan-C_${XalanC_MAJOR}_${XalanC_MINOR}D"
+ "Xalan-C_${XalanC_VERSION_MAJOR}D"
+ "Xalan-C_${XalanC_VERSION_MAJOR}_${XalanC_VERSION_MINOR}D"
DOC "Xalan-C++ libraries (debug)")
   include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake)
   select_library_configurations(XalanC)
   mark_as_advanced(XalanC_LIBRARY_RELEASE XalanC_LIBRARY_DEBUG)
 endif()
 
+unset(XalanC_VERSION_MAJOR)
+unset(XalanC_VERSION_MINOR)
+unset(XalanC_VERSION_PATCH)
+
 find_package(XercesC 3.0.0 REQUIRED)
 
 include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)

---

Summary of changes:
 Modules/FindXalanC.cmake |   15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)


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

[cmake-developers] [patch] New find module FindXalanC

[Roger Leigh]

Merged into next from the staging branch "xalanc" for review and 
testing.  Includes a couple of unit tests to validate.  Since it depends 
on XercesC, I hope what I've done here for the imported and non-imported 
target cases is OK.


I've tested on Linux and Windows.


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

Re: [cmake-developers] [patch] New find module FindXalanC

[Roger Leigh]

On 19/01/2016 16:50, Brad King wrote:

On 01/19/2016 11:39 AM, Roger Leigh wrote:

Merged into next from the staging branch "xalanc" for review and
testing.  Includes a couple of unit tests to validate.  Since it depends
on XercesC, I hope what I've done here for the imported and non-imported
target cases is OK.


Thanks.  Please also add a Help/release/dev/FindXalanC.rst release note
that mentions the new module.


Done.  I can add more detail if needed here.


I've updated one of our nightly testing machines to enable the new test
for this topic.


+find_package(XercesC 3.0.0 REQUIRED)

>

Please add a comment here justifying use of this particular version number.
Explain that/why it does not depend on the XalanC version requested.


I think this is an assumption leaking from my own usage of it. I've 
removed the version here.



+# ``XalanC_LIBRARIES``
+# Xalan libraries to be linked; note ``XercesC_LIBRARIES`` is also
+# required


Our convention is to include dependencies in reported values automatically.
See FindPNG for its use of ZLIB, for example.


OK, I've updated this to match.


Thanks,
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-developers

[Cmake-commits] CMake branch, next, updated. v3.4.1-2025-g9641548

[Roger Leigh]

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  9641548007af875da7a25525037cae7447ae07dd (commit)
   via  a7940807d7ab684f201271441afa29095378b1c9 (commit)
   via  ca1e830693328c4162294b215bfd3d18c7860702 (commit)
   via  639104a6fedd90748151655d3cbfe36c2d1fa6f5 (commit)
  from  4af8e762a976e3602c477d05275db3f7156e7a5f (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=9641548007af875da7a25525037cae7447ae07dd
commit 9641548007af875da7a25525037cae7447ae07dd
Merge: 4af8e76 a794080
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Tue Jan 19 12:01:03 2016 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Jan 19 12:01:03 2016 -0500

Merge topic 'xalanc' into next

a7940807 Help: Document new FindXalanC module
ca1e8306 FindXercesC: Don't require a specific Xerces-C version
639104a6 FindXercesC: XalanC_INCLUDE_DIRS and XalanC_LIBRARIES include 
dependencies


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a7940807d7ab684f201271441afa29095378b1c9
commit a7940807d7ab684f201271441afa29095378b1c9
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Tue Jan 19 17:00:18 2016 +
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Tue Jan 19 17:00:18 2016 +

Help: Document new FindXalanC module

diff --git a/Help/release/dev/FindXalanC.rst b/Help/release/dev/FindXalanC.rst
new file mode 100644
index 000..1617253
--- /dev/null
+++ b/Help/release/dev/FindXalanC.rst
@@ -0,0 +1,5 @@
+FindXalanC
+--
+
+* A new module to find the Apache Xalan-C++ XSL transform processing
+  library.

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ca1e830693328c4162294b215bfd3d18c7860702
commit ca1e830693328c4162294b215bfd3d18c7860702
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Tue Jan 19 16:59:35 2016 +
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Tue Jan 19 16:59:35 2016 +

FindXercesC: Don't require a specific Xerces-C version

diff --git a/Modules/FindXalanC.cmake b/Modules/FindXalanC.cmake
index 6a9f114..99b31d1 100644
--- a/Modules/FindXalanC.cmake
+++ b/Modules/FindXalanC.cmake
@@ -110,7 +110,7 @@ unset(XalanC_VERSION_MAJOR)
 unset(XalanC_VERSION_MINOR)
 unset(XalanC_VERSION_PATCH)
 
-find_package(XercesC 3.0.0 REQUIRED)
+find_package(XercesC REQUIRED)
 
 include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
 FIND_PACKAGE_HANDLE_STANDARD_ARGS(XalanC

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=639104a6fedd90748151655d3cbfe36c2d1fa6f5
commit 639104a6fedd90748151655d3cbfe36c2d1fa6f5
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Tue Jan 19 16:59:14 2016 +
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Tue Jan 19 16:59:14 2016 +

FindXercesC: XalanC_INCLUDE_DIRS and XalanC_LIBRARIES include dependencies

diff --git a/Modules/FindXalanC.cmake b/Modules/FindXalanC.cmake
index 58a68d8..6a9f114 100644
--- a/Modules/FindXalanC.cmake
+++ b/Modules/FindXalanC.cmake
@@ -123,8 +123,8 @@ FIND_PACKAGE_HANDLE_STANDARD_ARGS(XalanC
   FAIL_MESSAGE "Failed to find XalanC")
 
 if(XalanC_FOUND)
-  set(XalanC_INCLUDE_DIRS "${XalanC_INCLUDE_DIR}")
-  set(XalanC_LIBRARIES "${XalanC_LIBRARY}")
+  set(XalanC_INCLUDE_DIRS "${XalanC_INCLUDE_DIR}" ${XercesC_INCLUDE_DIRS})
+  set(XalanC_LIBRARIES "${XalanC_LIBRARY}" ${XercesC_LIBRARIES})
 
   # For header-only libraries
   if(NOT TARGET XalanC::XalanC)
diff --git a/Tests/FindXalanC/Test/CMakeLists.txt 
b/Tests/FindXalanC/Test/CMakeLists.txt
index 56f6f48..b445e0e 100644
--- a/Tests/FindXalanC/Test/CMakeLists.txt
+++ b/Tests/FindXalanC/Test/CMakeLists.txt
@@ -12,6 +12,6 @@ target_link_libraries(test_xalanc_tgt XalanC::XalanC)
 add_test(NAME test_xalanc_tgt COMMAND test_xalanc_tgt)
 
 add_executable(test_xalanc_var main.cxx)
-target_include_directories(test_xalanc_var PRIVATE ${XalanC_INCLUDE_DIRS} 
${XercesC_INCLUDE_DIRS})
-target_link_libraries(test_xalanc_var PRIVATE ${XalanC_LIBRARIES} 
${XercesC_LIBRARIES})
+target_include_directories(test_xalanc_var PRIVATE ${XalanC_INCLUDE_DIRS})
+target_link_libraries(test_xalanc_var PRIVATE ${XalanC_LIBRARIES})
 add_test(NAME test_xalanc_var COMMAND test_xalanc_var)

---

Summary of changes:
 Help/release/dev/FindXalanC.rst  |5 +
 Modules/FindXalanC.cmake |6 +++---
 Tests/FindXalanC/Test/CMakeLists.txt |4 ++--
 3 files change

Re: [cmake-developers] CMakeFindDependencyMacro limitations

[Roger Leigh]

On 21/12/2015 15:07, Stephen Kelly wrote:

Roger Leigh wrote:


I've run into a few limitations in find_dependency.  I'm not sure if
these are by design or could be fixed, so this is really a request for
further explanation or design rationale.

The first issue is this:

if (NOT ${dep}_FOUND)

This seems to be making the assumption that the found variable matches
the dependency name, but the case used varies between modules and the
name is case sensitive, from my reading of cmake-language.  Is this
correct?


It is intentional, yes. See

  http://public.kitware.com/Bug/view.php?id=15412

The config-packages generated by cmake are canonical, so modules should set
the ExactCase_FOUND to be a 'correct module'.


OK.


The reason for stripping EXACT isn't clear.  If my package has a strict
requirement on another package, whether the caller has an exact
requirement for the version of my package has no bearing on the
requirements I have for my dependencies as far as I understand.  What's
the reason for the existing behaviour?


I don't know what you are referring to with 'stripping EXACT'. Perhaps you
are looking at CMake < 3.0. See commit v3.0.0-rc2~10^2 (find_dependency:
Don't propagate EXACT argument., 2014-03-06).


This one was me misreading the find_dependency macro--it's setting 
cmake_fd_exact_arg, so it is being passed.  My mistake.



I can understand why REQUIRED and related
arguments are omitted--that is why find_dependency exists--but I'd quite
like to be able to specify COMPONENTS where needed e.g. with FindBoost,
and this is not currently possible.


I don't remember whether this was discussed when designing find_dependency.
Perhaps COMPONENTS could be added to the macro now.


I was wondering if we could perhaps make find_dependency handle and pass
through /all/ find_package arguments, minus REQUIRED/QUIET, so that
find_dependency can expose the additional functionality offered by
find_package.  Some may not be useful, in which case they could be
omitted, but some like COMPONENTS may be required for the find_package
call to be useful.


It might be possible, but might not be a good idea. What else do you want to
pass in?


Currently, for my own needs, COMPONENTS is the single missing piece.  If 
it would be possible to add this, it would certainly be very useful.


The other arguments might be potentially useful, that was more of a 
general question of which other bits might have general utility in the 
context of calling find_dependency from a config script.


I'd be happy to provide a patch for COMPONENTS if you like.


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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1780-g1d104f2

[Roger Leigh]

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  1d104f29c75e8cb264b94bd1fa916ae769e4cb18 (commit)
   via  0a31fdabecd2724d456aef0664ad7da1ca28f359 (commit)
  from  ad8a17f8c2763e3ccabaf9c70580972fef0673a2 (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=1d104f29c75e8cb264b94bd1fa916ae769e4cb18
commit 1d104f29c75e8cb264b94bd1fa916ae769e4cb18
Merge: ad8a17f 0a31fda
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Thu Dec 17 16:58:58 2015 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Dec 17 16:58:58 2015 -0500

Merge topic 'boost-1.60' into next

0a31fdab FindBoost: Add support for Boost 1.60


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0a31fdabecd2724d456aef0664ad7da1ca28f359
commit 0a31fdabecd2724d456aef0664ad7da1ca28f359
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Thu Dec 17 21:46:58 2015 +
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Thu Dec 17 21:46:58 2015 +

FindBoost: Add support for Boost 1.60

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index e517a6a..edfed8e 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -707,6 +707,20 @@ function(_Boost_COMPONENT_DEPENDENCIES component _ret)
 set(_Boost_TIMER_DEPENDENCIES chrono system)
 set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono 
date_time atomic)
 set(_Boost_WSERIALIZATION_DEPENDENCIES serialization)
+  elseif(NOT Boost_VERSION VERSION_LESS 106000 AND Boost_VERSION VERSION_LESS 
106100)
+set(_Boost_CHRONO_DEPENDENCIES system)
+set(_Boost_COROUTINE_DEPENDENCIES context system)
+set(_Boost_FILESYSTEM_DEPENDENCIES system)
+set(_Boost_IOSTREAMS_DEPENDENCIES regex)
+set(_Boost_LOG_DEPENDENCIES date_time log_setup system filesystem thread 
regex chrono atomic)
+set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 
math_tr1f math_tr1l atomic)
+set(_Boost_MPI_DEPENDENCIES serialization)
+set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization)
+set(_Boost_RANDOM_DEPENDENCIES system)
+set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic)
+set(_Boost_TIMER_DEPENDENCIES chrono system)
+set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono 
date_time atomic)
+set(_Boost_WSERIALIZATION_DEPENDENCIES serialization)
   else()
 message(WARNING "Imported targets not available for Boost version 
${Boost_VERSION}")
 set(_Boost_IMPORTED_TARGETS FALSE)
@@ -807,7 +821,7 @@ else()
   # information in _Boost_COMPONENT_DEPENDENCIES.  See the
   # instructions at the top of _Boost_COMPONENT_DEPENDENCIES.
   set(_Boost_KNOWN_VERSIONS ${Boost_ADDITIONAL_VERSIONS}
-
+"1.60.0" "1.60"
 "1.59.0" "1.59" "1.58.0" "1.58" "1.57.0" "1.57" "1.56.0" "1.56" "1.55.0" 
"1.55"
 "1.54.0" "1.54" "1.53.0" "1.53" "1.52.0" "1.52" "1.51.0" "1.51"
 "1.50.0" "1.50" "1.49.0" "1.49" "1.48.0" "1.48" "1.47.0" "1.47" "1.46.1"

---

Summary of changes:
 Modules/FindBoost.cmake |   16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)


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

[cmake-developers] [PATCH] FindBoost: Boost 1.60 support

[Roger Leigh]

With the release of Boost 1.60, I've updated FindBoost to work with this 
version.


Pushed to 
https://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/boost-1.60 
and merged into next for review.


- Adds 1.60.0 and 1.60 as valid versions
- Adds dependency information for 1.60; this is the same as for 1.59 
except that for "set(_Boost_LOG_DEPENDENCIES date_time log_setup ..." 
the date_time and log_setup dependencies were swapped.  I don't think 
this will make any difference, but including it to be on the safe side 
(it's harmless).


I have tested on Ubuntu 15.10 and Windows with VS2013, with projects 
using FindBoost against a locally compiled Boost 1.60.  They found Boost 
1.60 and its components, and compiled and linked and passed their unit 
tests.



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

[cmake-developers] CMakeFindDependencyMacro limitations

[Roger Leigh]

I've run into a few limitations in find_dependency.  I'm not sure if 
these are by design or could be fixed, so this is really a request for 
further explanation or design rationale.


The first issue is this:

  if (NOT ${dep}_FOUND)

This seems to be making the assumption that the found variable matches 
the dependency name, but the case used varies between modules and the 
name is case sensitive, from my reading of cmake-language.  Is this 
correct?  Even if so, should this optimisation be put here rather than 
in find_package itself?  If case sensitivity/naming is an issue, could 
the _FOUND variable be passed in as an argument, leaving the existing 
behaviour as the default if unspecified?


The reason for stripping EXACT isn't clear.  If my package has a strict 
requirement on another package, whether the caller has an exact 
requirement for the version of my package has no bearing on the 
requirements I have for my dependencies as far as I understand.  What's 
the reason for the existing behaviour?


Support for find_package arguments is limited to the dependency name and 
optionally the version.  I can understand why REQUIRED and related 
arguments are omitted--that is why find_dependency exists--but I'd quite 
like to be able to specify COMPONENTS where needed e.g. with FindBoost, 
and this is not currently possible.


I was wondering if we could perhaps make find_dependency handle and pass 
through /all/ find_package arguments, minus REQUIRED/QUIET, so that 
find_dependency can expose the additional functionality offered by 
find_package.  Some may not be useful, in which case they could be 
omitted, but some like COMPONENTS may be required for the find_package 
call to be useful.



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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1698-gd3ccdd3

[Roger Leigh]

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  d3ccdd30915356d716d3de0e56129e6da36bed0e (commit)
   via  99afe23513054db4add5143de4aa3a826e8c6c75 (commit)
   via  611735e76e14807e2145d6b67efbb080d419f19f (commit)
  from  caa83f4e41630cd00e8e32f2330d2c1be045b95f (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=d3ccdd30915356d716d3de0e56129e6da36bed0e
commit d3ccdd30915356d716d3de0e56129e6da36bed0e
Merge: caa83f4 99afe23
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Thu Dec 10 18:11:09 2015 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Dec 10 18:11:09 2015 -0500

Merge topic 'gtest-imported-targets' into next

99afe235 Tests: Add tests for FindGTest
611735e7 FindGTest: Add imported targets and update documentation


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=99afe23513054db4add5143de4aa3a826e8c6c75
commit 99afe23513054db4add5143de4aa3a826e8c6c75
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Thu Dec 10 23:08:23 2015 +
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Thu Dec 10 23:09:16 2015 +

Tests: Add tests for FindGTest

diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 5d492cf..65bfb77 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1362,6 +1362,11 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P 
${CMake_SOURCE_DIR}/Utilities/Release
   if(CMake_TEST_FindGSL)
 add_subdirectory(FindGSL)
   endif()
+
+  if(CMake_TEST_FindGTest)
+add_subdirectory(FindGTest)
+  endif()
+
   if(CMake_TEST_FindJsonCpp)
 add_subdirectory(FindJsonCpp)
   endif()
diff --git a/Tests/FindGTest/CMakeLists.txt b/Tests/FindGTest/CMakeLists.txt
new file mode 100644
index 000..cbc92b1
--- /dev/null
+++ b/Tests/FindGTest/CMakeLists.txt
@@ -0,0 +1,10 @@
+add_test(NAME FindGTest.Test COMMAND
+  ${CMAKE_CTEST_COMMAND} -C $
+  --build-and-test
+  "${CMake_SOURCE_DIR}/Tests/FindGTest/Test"
+  "${CMake_BINARY_DIR}/Tests/FindGTest/Test"
+  ${build_generator_args}
+  --build-project TestFindGTest
+  --build-options ${build_options}
+  --test-command ${CMAKE_CTEST_COMMAND} -V -C $
+  )
diff --git a/Tests/FindGTest/Test/CMakeLists.txt 
b/Tests/FindGTest/Test/CMakeLists.txt
new file mode 100644
index 000..99368ac
--- /dev/null
+++ b/Tests/FindGTest/Test/CMakeLists.txt
@@ -0,0 +1,17 @@
+cmake_minimum_required(VERSION 3.1)
+project(TestFindGTest CXX)
+include(CTest)
+
+# CMake does not actually provide FindGTest publicly.
+set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/../../../Source/Modules)
+
+find_package(GTest REQUIRED)
+
+add_executable(test_gtest_tgt main.cxx)
+target_link_libraries(test_gtest_tgt GTest::Main)
+add_test(NAME test_gtest_tgt COMMAND test_gtest_tgt)
+
+add_executable(test_gtest_var main.cxx)
+target_include_directories(test_gtest_var PRIVATE ${GTEST_INCLUDE_DIRS})
+target_link_libraries(test_gtest_var PRIVATE ${GTEST_BOTH_LIBRARIES} 
${CMAKE_THREAD_LIBS_INIT})
+add_test(NAME test_gtest_var COMMAND test_gtest_var)
diff --git a/Tests/FindGTest/Test/main.cxx b/Tests/FindGTest/Test/main.cxx
new file mode 100644
index 000..0572a5d
--- /dev/null
+++ b/Tests/FindGTest/Test/main.cxx
@@ -0,0 +1,6 @@
+#include 
+
+TEST(FindCMake, LinksAndRuns)
+{
+  ASSERT_TRUE(true);
+}

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=611735e76e14807e2145d6b67efbb080d419f19f
commit 611735e76e14807e2145d6b67efbb080d419f19f
Author: Roger Leigh <rle...@dundee.ac.uk>
AuthorDate: Thu Dec 10 15:52:07 2015 +
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Thu Dec 10 23:09:08 2015 +

FindGTest: Add imported targets and update documentation

diff --git a/Modules/FindGTest.cmake b/Modules/FindGTest.cmake
index eb7abfd..ca49e4a 100644
--- a/Modules/FindGTest.cmake
+++ b/Modules/FindGTest.cmake
@@ -4,88 +4,89 @@
 #
 # Locate the Google C++ Testing Framework.
 #
-# Defines the following variables:
+# Imported targets
+# 
 #
-# ::
-#
-#GTEST_FOUND - Found the Google Testing framework
-#GTEST_INCLUDE_DIRS - Include directories
+# This module defines the following :prop_tgt:`IMPORTED` targets:
 #
+# ``GTest::GTest``
+#   The Google Test ``gtest`` library, if found; adds Thread::Thread
+#   automatically
+# ``GTest::Main``
+#   The Google Test ``gtest_main`` library, if found
 #
 #
-# Also defines the library variables below as normal variables.  These
-# contain debug/optimized keywords when a debugging library is found.
-#
-# ::
+# Result variables
+# 
 #
-#GTEST_BO

Re: [cmake-developers] [PATCH] FindTIFF: Add imported targets

[Roger Leigh]

On 02/12/2015 17:31, rle...@codelibre.net wrote:

- Add TIFF::TIFF imported target
- Document imported target
- Add testcase to test the standard variables and the imported
   target

Also:

- Add TIFF_INCLUDE_DIRS to match common practice
- Update documentation generally, including documenting
   TIFF_INCLUDE_DIRS


I hope this is now staged correctly for review.  I've pushed a 
tiff-imported-target topic branch and merged into next:


amys% ssh g...@cmake.org stage cmake merge -b next tiff-imported-target
Fetching upstream next
Merge topic 'tiff-imported-target' into next

09f36344 Help: Document addition of FindTIFF imported targets
a237b26d FindTIFF: Add imported targets and update documentation

Auto-merging Tests/CMakeLists.txt
Pushing upstream next


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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1588-g203efca

[Roger Leigh]

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  203efca5072f27271f5403f0188afc0bb0df767a (commit)
   via  09f36344eaa6adee6a238ae1320d57352eaee8f0 (commit)
   via  a237b26d6c9821464856db283e0f83152409465b (commit)
  from  26d765cf6b6c6a08b03b8643cd7b408dc29a373b (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=203efca5072f27271f5403f0188afc0bb0df767a
commit 203efca5072f27271f5403f0188afc0bb0df767a
Merge: 26d765c 09f3634
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Thu Dec 3 19:08:42 2015 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Dec 3 19:08:42 2015 -0500

Merge topic 'tiff-imported-target' into next

09f36344 Help: Document addition of FindTIFF imported targets
a237b26d FindTIFF: Add imported targets and update documentation


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=09f36344eaa6adee6a238ae1320d57352eaee8f0
commit 09f36344eaa6adee6a238ae1320d57352eaee8f0
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Thu Dec 3 23:46:44 2015 +
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Thu Dec 3 23:46:44 2015 +

Help: Document addition of FindTIFF imported targets

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

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a237b26d6c9821464856db283e0f83152409465b
commit a237b26d6c9821464856db283e0f83152409465b
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Wed Dec 2 17:20:24 2015 +
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Thu Dec 3 23:44:40 2015 +

FindTIFF: Add imported targets and update documentation

- Add TIFF::TIFF imported target
- Document imported target
- Add testcase to test the standard variables and the imported
  target

Also:

- Add TIFF_INCLUDE_DIRS to match common practice
- Update documentation generally, including documenting
  TIFF_INCLUDE_DIRS

diff --git a/Modules/FindTIFF.cmake b/Modules/FindTIFF.cmake
index ed092ea..e49a00d 100644
--- a/Modules/FindTIFF.cmake
+++ b/Modules/FindTIFF.cmake
@@ -2,24 +2,43 @@
 # FindTIFF
 # 
 #
-# Find TIFF library
+# Find the TIFF library (libtiff).
 #
-# Find the native TIFF includes and library This module defines
+# Imported targets
+# 
 #
-# ::
+# This module defines the following :prop_tgt:`IMPORTED` targets:
 #
-#   TIFF_INCLUDE_DIR, where to find tiff.h, etc.
-#   TIFF_LIBRARIES, libraries to link against to use TIFF.
-#   TIFF_FOUND, If false, do not try to use TIFF.
+# ``TIFF::TIFF``
+#   The TIFF library, if found.
 #
-# also defined, but not for general use are
+# Result variables
+# 
 #
-# ::
+# This module will set the following variables in your project:
 #
-#   TIFF_LIBRARY, where to find the TIFF library.
+# ``TIFF_FOUND``
+#   true if the TIFF headers and libraries were found
+# ``TIFF_INCLUDE_DIR``
+#   the directory containing the TIFF headers
+# ``TIFF_INCLUDE_DIRS``
+#   the directory containing the TIFF headers
+# ``TIFF_LIBRARIES``
+#   TIFF libraries to be linked
+#
+# Cache variables
+# ^^^
+#
+# The following cache variables may also be set:
+#
+# ``TIFF_INCLUDE_DIR``
+#   the directory containing the TIFF headers
+# ``TIFF_LIBRARY``
+# the path to the TIFF library
 
 #=
 # Copyright 2002-2009 Kitware, Inc.
+# Copyright 2015 University of Dundee
 #
 # Distributed under the OSI-approved BSD License (the "License");
 # see accompanying file Copyright.txt for details.
@@ -65,7 +84,35 @@ FIND_PACKAGE_HANDLE_STANDARD_ARGS(TIFF
   VERSION_VAR TIFF_VERSION_STRING)
 
 if(TIFF_FOUND)
-  set( TIFF_LIBRARIES ${TIFF_LIBRARY} )
+  set(TIFF_LIBRARIES ${TIFF_LIBRARY})
+  set(TIFF_INCLUDE_DIRS "${TIFF_INCLUDE_DIR}")
+
+  if(NOT TARGET TIFF::TIFF)
+add_library(TIFF::TIFF UNKNOWN IMPORTED)
+if(TIFF_INCLUDE_DIRS)
+  set_target_properties(TIFF::TIFF PROPERTIES
+INTERFACE_INCLUDE_DIRECTORIES "${TIFF_INCLUDE_DIRS}")
+endif()
+if(EXISTS "${TIFF_LIBRARY}")
+  set_target_properties(TIFF::TIFF PROPERTIES
+IMPORTED_LINK_INTERFACE_L

[Cmake-commits] CMake branch, next, updated. v3.4.1-1590-g28b3454

[Roger Leigh]

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  28b34545ee7e2e8de7ef8f4dbac33ae28b9d6401 (commit)
   via  d85228770a8062b40392e26a066954f6efd4f517 (commit)
  from  203efca5072f27271f5403f0188afc0bb0df767a (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=28b34545ee7e2e8de7ef8f4dbac33ae28b9d6401
commit 28b34545ee7e2e8de7ef8f4dbac33ae28b9d6401
Merge: 203efca d852287
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Thu Dec 3 19:33:12 2015 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Thu Dec 3 19:33:12 2015 -0500

Merge topic 'tiff-imported-target' into next

d8522877 FindTIFF: Correct definition list indent


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d85228770a8062b40392e26a066954f6efd4f517
commit d85228770a8062b40392e26a066954f6efd4f517
Author: Roger Leigh <rle...@codelibre.net>
AuthorDate: Fri Dec 4 00:32:32 2015 +
Commit: Roger Leigh <rle...@codelibre.net>
CommitDate: Fri Dec 4 00:32:32 2015 +

FindTIFF: Correct definition list indent

diff --git a/Modules/FindTIFF.cmake b/Modules/FindTIFF.cmake
index e49a00d..e600498 100644
--- a/Modules/FindTIFF.cmake
+++ b/Modules/FindTIFF.cmake
@@ -34,7 +34,7 @@
 # ``TIFF_INCLUDE_DIR``
 #   the directory containing the TIFF headers
 # ``TIFF_LIBRARY``
-# the path to the TIFF library
+#   the path to the TIFF library
 
 #=
 # Copyright 2002-2009 Kitware, Inc.

---

Summary of changes:
 Modules/FindTIFF.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] Best way to handle application data path for local run vs. installation

[Roger Leigh]

On 30/11/2015 02:10, Dmitry Marakasov wrote:

Hi!

This question bugs me for a long time so I though maybe someone has
a solution. I have a project which includes an application and some
data for it. An application needs to know path to its data files, so
I pass it via compiler definition: ADD_DEFINITIONS(-DDATADIR="...")

The problem is that this path is different based on whether I want to
run the application from build directory:

ADD_DEFINITIONS(-DDATADIR="${PROJECT_SOURCE_DIR}/data")

or want to install it systemwide:

ADD_DEFINITIONS(-DDATADIR="${CMAKE_INSTALL_PREFIX}/share/myapp")

I want my project to both run from build directory and to be
installable systemwide, without the need to rebuild or specify extra
options.

Any ideas?


I don't claim this is a universal solution, but it works for me.  It's 
also likely to be further improved--this is the first functional 
implementation.



https://github.com/openmicroscopy/bioformats/blob/dev_5_1/cpp/lib/ome/common/module.cpp

While you can configure and use hardcoded install paths, it will also 
optionally introspect itself at runtime and compute the install paths 
dynamically.  This means you can have a relocatable installation and it 
will discover this on the fly.  Lastly, you can overrride each path 
component with an environment variable.  This is used to run inside the 
install tree where the path layout doesn't match the installed layout. 
It's also useful for testing or overriding things after installation, if 
needed, or overriding the autodetection on platforms where autodetection 
doesn't work.


This approach requires this source file to be in a shared library 
(Linux/FreeBSD/MacOS X - using dlopen(3)/dladdr(3)) or in a DLL (Windows 
- uses GetModuleHandleExW()/GetModuleFileNameW()).  It would also work 
in an executable compiled with -rdynamic with suitable adjustment for 
the install path computation.  Other platforms could be added, but this 
covers all my needs at the present.  Basically we get the path to the 
.so/.dylib/.dll, then remove the library runtime path to get the 
installation root, then add on any relative path we need, e.g. the 
datadir or anything else.  This works for system installations or 
relocatable installs anywhere.


This uses the CMake GNUInstallDirs module variables via a generated 
header to store all the paths.



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

Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

[Roger Leigh]

On 18/11/2015 11:27, rle...@codelibre.net wrote:

On 11/16/2015 09:26 AM, Florent Castelli wrote:

But one there’s one thing that comes to mind. Some compiled libraries
have dependencies on other compiled libraries.
Don’t you think it would make sense to teach FindBoost about those
so we link everything properly?

And also maybe add the native dependencies for some modules that
have one like maybe pthread or openssl.
Though, this might be hard to get right in a cross platform way.


Please look at adding these.  The imported targets should come
with all usage requirements as if they were provided by upstream
Boost.  It may be tricky to get right on all platforms but if we
do not do it then application code will have to do it instead.


I have made a first attempt at this.  I suspect it will need some
refinement, but hopefully useful as a starting point.  Please see the
attached patch.  I'd certainly be very appreciative of any comments.


[...]

Did anyone have a chance to look at this yet?  I'd very much like to get 
this to a state where it can be included.  The performance is something 
I'd like to improve, and I hope someone might have a suggestion for 
speeding up the parsing overhead.



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

Re: [cmake-developers] [PATCH] Imported targets for XercesC

[Roger Leigh]

On 19/11/2015 16:15, Brad King wrote:

On 11/18/2015 12:07 PM, rle...@codelibre.net wrote:

Patch attached to add imported target (XercesC::XercesC),
along with a unit test.


Looks good, but please also update the module documentation.
We'll also need a release note, e.g.

 $ cat Help/release/dev/FindXercesC-imported-targets.rst
 FindXercesC-imported-targets
 

 * The :module:`FindXercesC` module now provides imported targets.


No problem, I've done this in the attached patch.

Thanks,
Roger

>From ff9ee3e81010e3db81cbcee95b1a15d28117789c Mon Sep 17 00:00:00 2001
From: Roger Leigh <r.le...@dundee.ac.uk>
Date: Wed, 18 Nov 2015 16:45:54 +
Subject: [PATCH] XercesC: Add imported targets and unit test

---
 Help/release/dev/FindXercesC-imported-targets.rst |  4 ++
 Modules/FindXercesC.cmake | 67 +++
 Tests/CMakeLists.txt  |  4 ++
 Tests/FindXercesC/CMakeLists.txt  | 10 
 Tests/FindXercesC/Test/CMakeLists.txt | 17 ++
 Tests/FindXercesC/Test/main.cxx   |  7 +++
 6 files changed, 99 insertions(+), 10 deletions(-)
 create mode 100644 Help/release/dev/FindXercesC-imported-targets.rst
 create mode 100644 Tests/FindXercesC/CMakeLists.txt
 create mode 100644 Tests/FindXercesC/Test/CMakeLists.txt
 create mode 100644 Tests/FindXercesC/Test/main.cxx

diff --git a/Help/release/dev/FindXercesC-imported-targets.rst 
b/Help/release/dev/FindXercesC-imported-targets.rst
new file mode 100644
index 000..69cec5c
--- /dev/null
+++ b/Help/release/dev/FindXercesC-imported-targets.rst
@@ -0,0 +1,4 @@
+FindXercesC-imported-targets
+
+
+* The :module:`FindXercesC` module now provides imported targets.
diff --git a/Modules/FindXercesC.cmake b/Modules/FindXercesC.cmake
index cf84826..a4b80e5 100644
--- a/Modules/FindXercesC.cmake
+++ b/Modules/FindXercesC.cmake
@@ -4,23 +4,42 @@
 #
 # Find the Apache Xerces-C++ validating XML parser headers and libraries.
 #
-# This module reports information about the Xerces installation in
-# several variables.  General variables::
+# Imported targets
+# 
 #
-#   XercesC_FOUND - true if the Xerces headers and libraries were found
-#   XercesC_VERSION - Xerces release version
-#   XercesC_INCLUDE_DIRS - the directory containing the Xerces headers
-#   XercesC_LIBRARIES - Xerces libraries to be linked
+# This module defines the following :prop_tgt:`IMPORTED` targets:
 #
-# The following cache variables may also be set::
+# ``XercesC::XercesC``
+#   The Xerces-C++ ``xerces-c`` library, if found.
 #
-#   XercesC_INCLUDE_DIR - the directory containing the Xerces headers
-#   XercesC_LIBRARY - the Xerces library
+# Result variables
+# 
+#
+# This module will set the following variables in your project:
+#
+# ``XercesC_FOUND``
+#   true if the Xerces headers and libraries were found
+# ``XercesC_VERSION``
+#   Xerces release version
+# ``XercesC_INCLUDE_DIRS``
+#   the directory containing the Xerces headers
+# ``XercesC_LIBRARIES``
+#   Xerces libraries to be linked
+#
+# Cache variables
+# ^^^
+#
+# The following cache variables may also be set:
+#
+# ``XercesC_INCLUDE_DIR``
+#   the directory containing the Xerces headers
+# ``XercesC_LIBRARY``
+#   the Xerces library
 
 # Written by Roger Leigh <rle...@codelibre.net>
 
 #=
-# Copyright 2014 University of Dundee
+# Copyright 2014-2015 University of Dundee
 #
 # Distributed under the OSI-approved BSD License (the "License");
 # see accompanying file Copyright.txt for details.
@@ -90,4 +109,32 @@ FIND_PACKAGE_HANDLE_STANDARD_ARGS(XercesC
 if(XercesC_FOUND)
   set(XercesC_INCLUDE_DIRS "${XercesC_INCLUDE_DIR}")
   set(XercesC_LIBRARIES "${XercesC_LIBRARY}")
+
+  # For header-only libraries
+  if(NOT TARGET XercesC::XercesC)
+add_library(XercesC::XercesC UNKNOWN IMPORTED)
+if(XercesC_INCLUDE_DIRS)
+  set_target_properties(XercesC::XercesC PROPERTIES
+INTERFACE_INCLUDE_DIRECTORIES "${XercesC_INCLUDE_DIRS}")
+endif()
+if(EXISTS "${XercesC_LIBRARY}")
+  set_target_properties(XercesC::XercesC PROPERTIES
+IMPORTED_LINK_INTERFACE_LANGUAGES "CXX"
+IMPORTED_LOCATION "${XercesC_LIBRARY}")
+endif()
+if(EXISTS "${XercesC_LIBRARY_DEBUG}")
+  set_property(TARGET XercesC::XercesC APPEND PROPERTY
+IMPORTED_CONFIGURATIONS DEBUG)
+  set_target_properties(XercesC::XercesC PROPERTIES
+IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "CXX"
+IMPORTED_LOCATION_DEBUG "${XercesC_LIBRARY_DEBUG}")
+endif()
+if(EXISTS "${XercesC_LIBRARY_RELEASE}")
+  set_property(TARGET XercesC::XercesC APPEND PROPERTY
+IMPORTED_CONFIGURATI

Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

[Roger Leigh]

On 17/11/2015 07:53, Ruslan Baratov wrote:

On 16-Nov-15 21:01, rle...@codelibre.net wrote:

I have attached a patch to add imported targets to FindBoost, in the form
of Boost:: (e.g. Boost::date_time) or Boost::Boost as a
generic
interface library for header-only components.

Since it's `Boost::date_time` I expect that it will be `Boost::boost`
(lowercase).


Yes, I've merged most of the previous work Brad pointed to yesterday, 
and this included this change.



On 16-Nov-15 21:39, Brad King wrote:

On 11/16/2015 09:26 AM, Florent Castelli wrote:

But one there’s one thing that comes to mind. Some compiled libraries
have dependencies on other compiled libraries.
Don’t you think it would make sense to teach FindBoost about those
so we link everything properly?

And also maybe add the native dependencies for some modules that
have one like maybe pthread or openssl.
Though, this might be hard to get right in a cross platform way.

Please look at adding these.  The imported targets should come
with all usage requirements as if they were provided by upstream
Boost.  It may be tricky to get right on all platforms but if we
do not do it then application code will have to do it instead.



One tricky part about it is that dependency can be optional. I.e.
Boost::iostreams may or may not depends on ZLIB/BZip2. Such information
is known only by build procedure. I.e. should be installed by b2 itself
or by wrapped ExternalProject_Add instructions.


For the specific case of the zlib/bzip2 dependencies, this is only the 
case when using the static libraries?  It's not exposed via the headers 
is it?


Looking at the information embedded in the sources for use with 
autolinking, we could certainly process the headers for the requested 
components and pull out the referenced libraries.  This would get us all 
of the header dependencies without hardcoding anything ourselves, which 
would make it work with arbitrary versions of boost without having to 
hardcode the differences between Boost versions.


Fully supporting static linking would be much more difficult.  As you 
say, it depends upon how Boost was built.  Full support here would need 
to wait for the upstream to generate this data at build time?



I'll have a look at doing the above and should have an updated patch soon.


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

[CMake] Creating relocatable export files

[Roger Leigh]

Hi,

I'm wanting to create -config scripts for my libraries so that dependent 
projects can find them with find_package and use them transparently.  I 
have a number of header-only and shared/static libs, and I'd like to 
retain their relationships, plus any additional libraries they are 
linked with.


I was previously using hand-crafted templates, e.g. with this type of 
generated structure:


---
set(OME_COMMON_FOUND TRUE)

set(OME_COMMON_VERSION "5.2.0-pre0-7-gfc53ca3")
set(OME_COMMON_VERSION_MAJOR "5")
set(OME_COMMON_VERSION_MINOR "2")
set(OME_COMMON_VERSION_PATCH "0")
set(OME_COMMON_VERSION_EXTRA "-pre0-7-gfc53ca3")

find_path(OME_COMMON_INCLUDE_DIR ome/common/module.h HINTS 
"/tmp/split/include")
find_library(OME_COMMON_LIBRARY NAMES ome-common libome-common HINTS 
"/tmp/split/lib")

---

They unfortuately did not handle interface targets or public library 
dependencies required by use in the headers.  I've switched to using 
install(EXPORT):


https://github.com/rleigh-dundee/ome-common-cpp/blob/develop/lib/ome/common/CMakeLists.txt#L123
---
target_link_libraries(ome-common ome-compat
  ${Boost_LOG_SETUP_LIBRARY_RELEASE}
  ${Boost_LOG_LIBRARY_RELEASE}
  ${Boost_FILESYSTEM_LIBRARY_RELEASE}
  ${Boost_SYSTEM_LIBRARY_RELEASE}
  ${LibDl_LIBRARIES}
  ${XercesC_LIBRARIES})

set_target_properties(ome-common PROPERTIES LINKER_LANGUAGE CXX)
set_target_properties(ome-common PROPERTIES VERSION ${OME_VERSION_SHORT})

install(TARGETS ome-common
EXPORT ome-common-config
RUNTIME DESTINATION ${CMAKE_INSTALL_FULL_BINDIR}
LIBRARY DESTINATION ${CMAKE_INSTALL_FULL_LIBDIR}
ARCHIVE DESTINATION ${CMAKE_INSTALL_FULL_LIBDIR})
install(EXPORT ome-common-config
DESTINATION ${CMAKE_INSTALL_FULL_LIBDIR}/cmake/ome-common)
---

This does a much better job of the dependencies.  It's preserving the 
dependencies for the internal targets, plus the external libraries. 
However, it's lacking:


- any setting of the include path via FOO_INCLUDE_DIR, unless it's just 
not done in an obvious manner
- it's hardcoded the absolute paths of the various boost and xerces 
libs; I'd like it to be relocatable so it can work in a superbuild and 
continue to work after moving elsewhere
- it doesn't appear to recursively find needed import targets, e.g. I 
need to find_package(ome-compat) before find_package(ome-common); it 
would be nice if this was transparent so the user doesn't need to do this


I'd be interested to know if anyone else has run into these issues, and 
if so what your solutions were?  I'm quite new to this part of cmake, so 
it may well just be I'm not doing things exactly as expected.


Would it be easier to construct the template myself and then call 
find_package for the external libs to avoid hardcoding the paths?  Is it 
safe to recursively call find_package inside find_package?



Thanks all,
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

Re: [CMake] Unable to locate the project's shared library when running the tests

[Roger Leigh]

On 02/09/2015 08:40, Yaron Cohen-Tal wrote:

Hi,

My project is a shared library, and my tests are linked to that shared
library. When I try to run the tests, they fail because they can't find
the DLL of the project. The "CMakeLists.txt" of the tests is in a
different folder ("test/") than that of the shared lib ("src/"), and
therefore they're built in different directories. Currently I'm using
Visual Studio, and the DLL of the project is built in "src\Debug\", and
the executables of the tests are built in "test\Debug\"; That is, for a
debug build of course. What would be the best solution to b able to run
the tests? I'm currently with Visual Studio but I guess the same problem
would arise on Linux and OS X, and it should work there too.


On Linux/BSD/MacOS it's using rpath so it works without any special 
effort on your part.


On Windows, you do need to set the test environment so it can find all 
the DLLs.  To do this, I did this for libtiff:



macro(tiff_test_reader name command infile)
  add_test(NAME "${name}"
   COMMAND "${CMAKE_COMMAND}"
   [... other options...]
   "-DTIFFINFO=$"
   "-DLIBTIFF=$"
   -P "${CMAKE_CURRENT_SOURCE_DIR}/TiffTest.cmake")
endmacro()

where TIFFINFO is an executable run by the test and LIBTIFF is the 
library used by this executable.  Note we pass these options as 
generator expressions so you can run "ctest -C Debug|Release" and have 
it use the executable and library from the debug or release build.


TiffTest.cmake is a wrapper to run the test.  It's doing this:

# Add the directory containing libtiff to the PATH (Windows only)
if(WIN32)
  get_filename_component(LIBTIFF_DIR "${LIBTIFF}" DIRECTORY)
  file(TO_NATIVE_PATH "${LIBTIFF_DIR}" LIBTIFF_DIR)
  set(ENV{PATH} "${LIBTIFF_DIR};$ENV{PATH}")
endif()

and then it runs the test command and specified options via 
execute_process().


i.e. we've added a level of indirection when running the tests via a 
standalone cmake script.


There may be better ways of doing this.  I'd certainly be keen to 
simplify things!



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

Re: [cmake-developers] FindZLIB module should find debug and release variants

[Roger Leigh]

On 23/08/2015 10:07, Michael Scott wrote:

Carrying on in the list of open issues to look at for contributing to
CMake, I've had a look at issue 15280 - FindZLIB module should find
debug and release variants. I've made some changes to the FindZLIB
module which should make it so that debug and release variants are found
as separate libraries, if they're both found then they're provided in
ZLIB_LIBRARIES and ZLIB::ZLIB's imported location properties. Attached
is the patch for FindZLIB.cmake.

With this, I noticed that the Windows DLL's use different file names for
the release and debug variants, but I couldn't tell if this is true on
UNIX, it didn't seem to be the case. As the change to FinZLIB is based
on the two variants having different names, I'm not sure these changes
will have any effect on UNIX, is this expected or am I missing
something/going about it the wrong way?


I don't think so.  The debug suffix is a Windows-ism which you don't see 
on UNIX.


One criticism of the patch: It's not using SelectLibraryConfigurations 
to choose between the release and debug variants.  Could it be updated 
to do that for consistency?  See FindPNG.cmake as an example.  This 
should make the patch quite a bit simpler.



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

[cmake-developers] [patch] Support for Boost 1.59

[Roger Leigh]

The attached patch adds Boost 1.59.0/1.59 to the list of supported 
versions in the FindBoost module.


Tested on: Ubuntu 14.04 and Windows with VS2013 with Boost 1.59.0.

Regards,
Roger
From 0419a7bd7f1da27bcbf9eaba424fda99cc030867 Mon Sep 17 00:00:00 2001
From: Roger Leigh rle...@codelibre.net
Date: Thu, 13 Aug 2015 23:34:39 +0100
Subject: [PATCH] FindBoost: Add support for Boost 1.59

---
 Modules/FindBoost.cmake | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 05b552a..33e6a49 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -512,13 +512,15 @@ else()
   # The user has not requested an exact version.  Among known
   # versions, find those that are acceptable to the user request.
   set(_Boost_KNOWN_VERSIONS ${Boost_ADDITIONAL_VERSIONS}
-1.58.0 1.58 1.57.0 1.57 1.56.0 1.56 1.55.0 1.55 1.54.0 1.54
-1.53.0 1.53 1.52.0 1.52 1.51.0 1.51
+
+1.59.0 1.59 1.58.0 1.58 1.57.0 1.57 1.56.0 1.56 1.55.0 1.55
+1.54.0 1.54 1.53.0 1.53 1.52.0 1.52 1.51.0 1.51
 1.50.0 1.50 1.49.0 1.49 1.48.0 1.48 1.47.0 1.47 1.46.1
 1.46.0 1.46 1.45.0 1.45 1.44.0 1.44 1.43.0 1.43 1.42.0 1.42
 1.41.0 1.41 1.40.0 1.40 1.39.0 1.39 1.38.0 1.38 1.37.0 1.37
 1.36.1 1.36.0 1.36 1.35.1 1.35.0 1.35 1.34.1 1.34.0
 1.34 1.33.1 1.33.0 1.33)
+
   set(_boost_TEST_VERSIONS)
   if(Boost_FIND_VERSION)
 set(_Boost_FIND_VERSION_SHORT ${Boost_FIND_VERSION_MAJOR}.${Boost_FIND_VERSION_MINOR})
-- 
2.4.6

-- 

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] Making and using static and shared libraries on Windows with Visual Studio

[Roger Leigh]

Hi folks,

This might not be a problem with CMake, it's probably due to my lack of 
familiarity with Windows either in CMakeLists.txt or in the code itself. 
 I have a large C++ codebase which uses CMake to build on 
Linux/Unix/MacOS X.  I'm currently porting it to use a superbuild 
infrastructure to build on Windows.  The superbuild works fine, but I'm 
running into odd linking errors.


I've tried to create a minimal testcase to demonstrate the problem. 
This is here: https://github.com/rleigh-dundee/dlltest

(test-vs201n.bat will run cmake and the builds automatically)

This creates a few libraries which contain classes using std::string or 
std::vectorstd::string and then links them into test programs.  It's 
really trivial, and works fine on non-Windows systems, but fails when 
linking static libs on Windows.


With Windows, I see this:

   Shared  Static
  VS2012   FailFail
  VS2013   WorksFail
  VS2015   Warns   Fail

VS2012 has problems parsing the code, which looks like a VS2012 bug 
needing workaround, and the VS2015 DLL warning looks like some change in 
the internal implementation details of string and vector.  What's 
concerning me is that I'm getting link errors along the lines of:


c.lib(c.obj) : error LNK2019: unresolved external symbol public: static 
unsigned __int64 const std:: basic_stringchar,struct 
std::char_traitschar,class std::allocatorchar ::npos 
(?npos@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@2_KB) referenced 
in function class std::basic_stringchar,struct 
std::char_traitschar,class std::allocatorchar  * __cdecl 
std::_Uninit_copyclass std::basic_stringchar,struct 
std::char_traitschar,class std::allocatorchar  const *,class 
std::basic_stringchar,struct std::char_traitschar,class 
std::allocatorchar  *,class std::allocator
class std::basic_stringchar,struct std::char_traitschar,class 
std::allocatorchar   (class std::basic_stringchar,struct 
std::char_traitschar,class std::allocatorchar  const *,class 
std::basic_stringchar,struct std::char_traitschar,class 
std::allocatorchar  const *,class std::basic_stringchar,struct 
std::char_traitschar,class std::allocatorchar  *,struct 
std::_Wrap_allocclass std::allocatorclass 
std::basic_stringchar,struct std::char_traitschar,class 
std::allocatorchar,struct std::_Nonscalar_ptr_iterator_tag) 
(??$_Uninit_copy@PEBV?$basic_string@DU?$char_traits 
@D@std@@V?$allocator@D@2@@std@@PEAV12@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@YAPEAV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@0@PEBV10@0PEAV10@AEAU?$_Wrap_alloc@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@std@@@0@U_Nonscalar_ptr_iterator_tag@0@@Z) 
[C:\Users\rleigh\libtest\2013s\testc.vcxproj]
c.lib(c2.obj) : error LNK2001: unresolved external symbol public: 
static unsigned __int64 const std::basic_stringchar,struct 
std::char_traitschar,class std::allocatorchar ::npos 
(?npos@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@2_KB) [C:\Users\rleigh\libtest\2013s\testc.vcxproj]


The odd thing: this only occurs for libraries c and d using 
std::vectorstd::string while libraries a and b using std::string 
work just fine--I'm not sure what exactly is using npos unless it's part 
of the vector default construction of string.


Could any CMake users with Windows expertise possibly suggest what I'm 
doing wrong or missing here, either in the CMake logic or in the code. 
I thought I had all the template instantiations right for DLL export, 
but thought static libraries would Just Work!



Many thanks,
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