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] 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] 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 
 Date: 07/01/2018  13:58  (GMT+00:00) To: Roger Leigh 
 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
 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] 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] 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

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

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

Re: [CMake] what options

[Roger Leigh]

On 13/12/2015 19:44, Owen Hogarth II wrote:

If you have a cmake project, what's the way to see what type of
configuration options are available?

For example I know that I can pass -DCMAKE_PREFIX_PATH the set where the
project will be installed.

Sometimes project creators add other things, such as building static or
share libraries, SSE, NEON or other flags like those.

Is there a way to have cmake show all of those that the current project
has exposed?


cmake -L[A][H] .

Lists the cache variables to set, optionally including advanced options 
and help text.


See "List non-advanced cached variables" in 
https://cmake.org/cmake/help/v3.4/manual/cmake.1.html


These are also shown with cmake-gui, which lists them in the user interface.


Regards,
Roger
--

Powered by www.kitware.com

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

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

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

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

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

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

[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

[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::vector 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_stringstd::char_traits,class std::allocator >::npos 
(?npos@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@2_KB) referenced 
in function "class std::basic_stringstd::char_traits,class std::allocator > * __cdecl 
std::_Uninit_copystd::char_traits,class std::allocator > const *,class 
std::basic_string,class 
std::allocator > *,class std::allocator<
class std::basic_string,class 
std::allocator > > >(class std::basic_stringstd::char_traits,class std::allocator > const *,class 
std::basic_string,class 
std::allocator > const *,class std::basic_stringstd::char_traits,class std::allocator > *,struct 
std::_Wrap_allocstd::basic_string,class 
std::allocator > > > &,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_stringstd::char_traits,class std::allocator >::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::vector 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

Re: [CMake] Behaviour of CACHE PATH variables

[Roger Leigh]

On Wed, Mar 25, 2015 at 11:29:28AM -0400, Brad King wrote:
> On 03/25/2015 10:15 AM, Roger Leigh wrote:
> > Question: Why is TESTDIR2 transformed from "t2" to
> > "/home/rleigh/pathtest/test/t2" (which is
> > "$PROJECT_BINARY_DIR/$TESTDIR2)?
> 
> It looks like the behavior has been this way since 2003:
> 
>  ENH: When fixing cache value with uninitialized type, collapse
>  full paths for PATH and FILEPATH. Closes Bug #82 - Specifying
>  relative path when entering path can break things
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6567329
> 
> but was added without documentation back in our wild west days.
> 
> > Copying the GNUInstallDirs behaviour of wrapping in an "if (NOT DEFINED 
> > foo)" test
> > mitigates the problem.
> > 
> > For my usage, I'm defining project-specific install dirs derived from the
> > toplevel GNUInstallDirs dirs.  I'd quite like to be able to specify a 
> > relative
> > (or absolute) path, and then later prepend the install prefix / appropriate
> > GNUInstallDirs toplevel variable.  Having the current working directory 
> > added
> > by default screws this up quite badly!
> 
> From the commit message above I think the intended behavior is
> exactly to transform relative paths.  The behavior has been this
> way for so long I don't think we can change it now.  We can update
> the documentation to describe the behavior, but I think using the
> approach in GNUInstallDirs is the solution for you.

OK.  It's a shame this can't be fixed, but entirely understandable.

A comment explaining the behaviour would be appreciated; it will certainly
save the next person encountering this special case from a good bit of
headscratching!


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
-- 

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] Check whether C++ headers are self-sufficient

[Roger Leigh]

On Sat, Mar 14, 2015 at 01:19:21PM +0100, Christoph Grüninger wrote:
> Dear CMakers,
> I want to have all my C++ headers self-sufficient (self-contained),
> i.e., a header can be included without additional includes. This is not
> only handy but also part of Google's C++ styleguide [2].
> 
> It would be great to have a make target (let's call it headercheck),
> that can check for this, by compiling a simple test.cc file for each
> current_header.h:
>   #include 
>   #include "current_header.h"
>   #include "current_header.h"
> 
> Additionally it would be great to have such a target for every folder
> (checking all headers recursively) and every header that is explicitly
> passed as an argument.
> 
> We tried this with CMake: We generate a test.cc file per header and
> create a library for every cc file. The problem is, that we get hundreds
> of additional targets, we generate a lot of folders and files which can
> increase our build directory size by an order of magnitude and it does
> not work properly on a per file or per directory basis.

I've taken exactly your approach.  However:

- I'm not testing the double include at present
- I generate a single target per library, collecting all the object files
  into a single testcase
- I compile each header *twice*, so in addition to catching errors in the
  include guards, I also catch errors where I might have accidentally
  defined a global or static member in the header and this will trigger a
  link error

For anyone two wants to reuse it:
https://github.com/openmicroscopy/bioformats/blob/develop/cpp/cmake/HeaderTest.cmake
(it uses gtest but that's easily excised if not required)

To use, in your source directory:

https://github.com/openmicroscopy/bioformats/blob/develop/cpp/lib/ome/bioformats/CMakeLists.txt#L182
header_include_list_write(STATIC_HEADERS_VAR GENERATED_HEADERS_VAR 
header-test-name dest-dir)

And in your test directory (if different)
https://github.com/openmicroscopy/bioformats/blob/develop/cpp/test/ome-bioformats/CMakeLists.txt#L45
header_test_from_file(bin-name library-name test-name)


While these were written for this particular project, if there's
interest in having a similar thing in cmake, I'd be happy to clean
it up and improve it for general use.


Kind regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
-- 

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] Behaviour of CACHE PATH variables

[Roger Leigh]

Hi folks,

I've come across some odd behaviour when setting CACHE variables of
type PATH, which I didn't spot in the documentation.


With the following minimal testcase:

---
cmake_minimum_required(VERSION 2.8.12)
cmake_policy(VERSION 2.8.12)

include(GNUInstallDirs)

if (NOT DEFINED TESTDIR1)
  set(TESTDIR1 "test1"
  CACHE PATH "Test path 1")
endif()
  set(TESTDIR2 "test2"
  CACHE PATH "Test path 2")


message(STATUS "sbindir: ${CMAKE_INSTALL_SBINDIR}")
message(STATUS "testdir1: ${TESTDIR1}")
message(STATUS "testdir2: ${TESTDIR2}")
---

% cmake ..
-- sbindir: sbin
-- testdir1: test1
-- testdir2: test2

% cmake -DTESTDIR1=t1 -DTESTDIR2=t2 -DCMAKE_INSTALL_SBINDIR=priv ..
-- sbindir: priv
-- testdir1: t1
-- testdir2: /home/rleigh/pathtest/test/t2

% cmake -DTESTDIR1:PATH=t1 -DTESTDIR2:PATH=t2 -DCMAKE_INSTALL_SBINDIR=priv ..
-- sbindir: priv
-- testdir1: t1
-- testdir2: t2

This is with cmake 2.8.12.2 (Linux); same behaviour with 3.1.3 (FreeBSD).


Question: Why is TESTDIR2 transformed from "t2" to
"/home/rleigh/pathtest/test/t2" (which is
"$PROJECT_BINARY_DIR/$TESTDIR2)?

This behaviour seems quite undesirable and also inconsistent:

- It's originally set using a relative path with "set(foo CACHE PATH)", and is 
not
  canonicalised to an absolute path
- If I set it with :PATH using a relative path, it's also not canonicalised to
  an absolute path
- BUT, if I use "set(foo CACHE PATH)" AND I previously set the path *without* a
  :type specifier (i.e. UNINITIALIZED) then this unwanted conversion takes 
place.
  Since the cache variable was already set, I would have expected this to be a
  no-op.  Given the behaviour in the above two points, I can't see why this is
  happening.

Copying the GNUInstallDirs behaviour of wrapping in an "if (NOT DEFINED foo)" 
test
mitigates the problem.

For my usage, I'm defining project-specific install dirs derived from the
toplevel GNUInstallDirs dirs.  I'd quite like to be able to specify a relative
(or absolute) path, and then later prepend the install prefix / appropriate
GNUInstallDirs toplevel variable.  Having the current working directory added
by default screws this up quite badly!


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
-- 

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] Qt automoc (CMAKE_AUTOMOC) failure with name clashes

[Roger Leigh]

On Sun, Dec 14, 2014 at 07:29:38PM +, Roger Leigh wrote:
> Compilation inevitably fails due to it including the generated source
> files twice.  It's discarded the path information.
> 
> - is this a known issue?
> - is there any way to get automoc support to add the full pathname to
>   the generated sources e.g. moc_gl_Axis2D.cpp and moc_gl_v20_Axis2D.cpp.
> - any workarounds known for this issue?

Looks like this might be fixable in Source/cmQtAutoGenerators.cxx
where it's running moc and outputting the main file with the
includes in GenerateMoc and RunAutogen, if these were used to
generate the sources in subdirectories rather than only at the
toplevel?


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
-- 

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] Qt automoc (CMAKE_AUTOMOC) failure with name clashes

[Roger Leigh]

I have a source directory layout like this:
├── gl
│   ├── Axis2D.h
│   ├── Grid2D.h
│   ├── Image2D.h
│   └── v20
│   ├── Axis2D.h
│   ├── Grid2D.h
│   └── Image2D.h
├── GLContainer.h
├── glsl
│   └── v110
│   ├── GLFlatShader2D.h
│   ├── GLImageShader2D.h
│   └── GLLineShader2D.h
├── GLUtil.h
├── GLView2D.h
├── GLWindow.h
└── TexelProperties.h

And use this cmake configuration:

  set(CMAKE_AUTOMOC ON)
  set(CMAKE_INCLUDE_CURRENT_DIR ON)
  set(QTWIDGETS_GL_HEADERS
  gl/Axis2D.h
  gl/Grid2D.h
  gl/Image2D.h)
  set(QTWIDGETS_GL_V20_HEADERS
  gl/v20/Axis2D.h
  gl/v20/Grid2D.h
  gl/v20/Image2D.h)

As you can see, the names are duplicated in the two subdirectories.
Unfortunately, automoc generates this:

/* This file is autogenerated, do not edit*/
#include "moc_GLContainer.cpp"
#include "moc_GLView2D.cpp"
#include "moc_GLWindow.cpp"
#include "moc_Axis2D.cpp"
#include "moc_Grid2D.cpp"
#include "moc_Image2D.cpp"
#include "moc_Axis2D.cpp"
#include "moc_Grid2D.cpp"
#include "moc_Image2D.cpp"
#include "moc_GLFlatShader2D.cpp"
#include "moc_GLImageShader2D.cpp"
#include "moc_GLLineShader2D.cpp"

Compilation inevitably fails due to it including the generated source
files twice.  It's discarded the path information.

- is this a known issue?
- is there any way to get automoc support to add the full pathname to
  the generated sources e.g. moc_gl_Axis2D.cpp and moc_gl_v20_Axis2D.cpp.
- any workarounds known for this issue?


Many thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
-- 

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] read imageJ ROI to matlab

[Roger Leigh]

On Thu, Nov 20, 2014 at 05:45:55AM +0800, WangPing wrote:
> sorry list, I am not sure if I could ask a different question: does anyone 
> know how to read an ROI from ImageJ to matlab?  Or how to save the ImageJ ROI 
> to a file (such as nifti format)?

You might want to ask this question on the ImageJ mailing list ;-)

As an initial hint, you can save ROIs to a file using the ROI Manager.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
-- 

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] Autotools->cmake: Are these checks really needed anymore?

[Roger Leigh]

On Sat, Aug 30, 2014 at 04:30:15PM +0200, Rolf Eike Beer wrote:
> Am Samstag, 30. August 2014, 09:18:26 schrieb Richard Shaw:
> 
> > #AC_C_RESTRICT
> > #AC_C_VOLATILE
> 
> I'm not sure if you should even think of using them. Especially volatile is 
> often something that means "you are doing something scary".

If you're a strict C99 programmer, you might well be using restrict
routinely.  I certainly did before I migrated to mainly using C++,
and if you look at the prototypes used by e.g. glibc you'll see
restrict is used throughout.

volatile is a little more scary, but you might well find you need
it e.g. in signal handlers.


The merits of either aside, these are standard language features
and like all the other features in the list, they will be present
if you're using a conforming compiler.  As someone who made the
same switch from autotools to cmake last year (and who wrote some
of the C99 checks for autoconf in the first place!), I can't help
but feel that autoconf is still trying to solve portability
problems from two decades ago which have now been long solved.  I
stopped worrying about these details--all current compilers (modulo
MSVC and C99 support) support all these features, so unless you
really care about some long obsolete unsupported system, all this
stuff is wasted effort except for maybe / in
which case you can do something like:

https://github.com/openmicroscopy/bioformats/blob/develop/cpp/lib/ome/compat/cstdint.h
https://github.com/openmicroscopy/bioformats/blob/develop/cpp/lib/ome/compat/config.h.in
https://github.com/openmicroscopy/bioformats/blob/develop/cpp/cmake/CompilerChecks.cmake


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
-- 

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] Behaviour of FindPythonInterp appears suboptimal

[Roger Leigh]

I thought using FindPythonInterp would be more portable than
simply invoking "python" directly (i.e. using $PYTHON_EXECUTABLE).
However, this does not appear to be the case.  I'd be interested to
know if this is intentional or if I'm doing something wrong.

I've tried using "find_package(PythonInterp 2.6.0 REQUIRED)" on a
variety of systems.  The software in question works with any
python 2.6 or 2.7 version.

On Debian, with the default python 2.7 installed, it picked up
python 2.6.8 (from python2.6-minimal) which lacked all the
required modules.  /usr/bin/python was 2.7 and matched the
version requirement, and had all the required modules
available.

On Windows, with an active virtualenv, it doesn't use the
virtualenv python on the path, but an entirely different version
without the modules I need available.

Similar problems seen for Ubuntu.

I think the general problem here is that it tries to be too
clever, and tries to find a lower version in preference to
a perfectly suitable newer version, and even the version on
the path.  This includes using virtualenv, where I've
carefully gone to the effort of setting up a custom
environment for the purpose only to have it be ignored.

I would have expected that if the default path contained
"python", "python2" or "python2.7", these should all be
preferred (in order) over "python2.6" or any autodetected
version not on the path, if the version meets the requirement
from find_package.  The current behaviour gets it wrong in
almost every situation except where there's only a single
version to choose from!


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
-- 

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] Announcing CMake BASIS, a set of CMake based project interoperability and automation tools

[Roger Leigh]

On Thu, Jan 23, 2014 at 10:40:54AM +0100, Stephen Kelly wrote:
> Andreas Schuh wrote:
> 
> > On a side note, just today a co-worker asked me why the compiler cannot
> > find the header files when they were provided as additional arguments to
> > the add_executable command. Indeed this was a reasonable assumption, I
> > think. Why the need for an additional include_directories when I already
> > specified where the header files are located ? This is not something BASIS
> > is taking care of yet either, but would certainly be one of the things I
> > would consider adding.
> 
> This is the kind of concrete feedback *about cmake* that I'm looking for in 
> this discussion. It's self contained, refers to existing cmake 
> functionality, it's easy to imagine the 'user story' and what the user code 
> would look like etc.
> 
> I don't have any comment about the viability of adding such functionality to 
> cmake add_* commands though.

I'm not sure this can ever be viable because it makes assumptions that are
guaranteed to break for different use cases.

If I add a header, cmake can have no knowledge of how the sources use the
header.  Is it an absolute or relative include?  Does the relative include
also include a path?

In my projects, I have both static and generated headers.  All the sources
use absolute includes i.e  and the CMakeLists.txt are located
at multiple levels inside the structure.  Other projects have the sources
and headers located separately and may not have any code generation (the
generated sources here are passed as absolute paths to add_executable).
Some projects have a mixture of public and private headers which use
absolute and relative paths.

I think the general sentiment that having add_executable remove a redundant
include_directories statement is a good one.  I'm just unconvinced that this
is doable in practice.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
-- 

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

Re: [CMake] Inter-target dependencies on autogenerated headers

[Roger Leigh]

On Wed, Dec 18, 2013 at 11:54:15PM +, Roger Leigh wrote:
>   set(a_static_headers …)
>   set(b_static_sources …)
>   add_custom_command(OUTPUT ${a_generated_headers}
> ${a_generated_sources} COMMAND ${custom_tool} DEPENDS
> ${tool_dependencies)
>   set(a_headers ${a_generated_headers} ${a_static_headers})
>   set(a_sources ${a_generated_sources} ${a_static_sources})
>   add_library(a SHARED ${a_sources} ${a_headers})
> 
> Module b:
>   set(b_headers …)
>   set(b_sources …)
>   add_library(b SHARED ${b_sources} ${b_headers})
>   target_link_libraries(b a)
> 
> The code generation, compiling and linking of module a works fine,
> and the code is regenerated if the dependencies are touched.  This
> works building serially or in parallel.
> 
> The compiling and linking of module b works fine only if building
> serially.  If building in parallel, the ${b_sources} which include
> any headers from module a's ${a_generated_headers} will fail if they
> are built before header generation in module a occurs.  This is
> inherently racy.

Sorry for the noise, I found that I did in fact have some missing
target_link_libraries in some autogenerated tests (too much
autogeneration going on...).  Adding target_link_libraries for
everything fixes the dependencies and parallel building then
works just fine.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
--

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

[CMake] Inter-target dependencies on autogenerated headers

[Roger Leigh]

Hi folks,

In the bioformats project, we make use of a custom tool to generate 
classes from an xml schema during the build.  This is working correctly, 
but breaks if building in parallel (with unix makefiles and make -j8).


For reference, this is the library built using a combination of static 
and generated sources¹. A second library is built against the first 
libraries headers and linked against it (and also contains its own 
generated code)².  Both use common cmake functions to do this³.  The 
problem is that when building in parallel, the second library is being 
compiled before the headers are generated in the first, and this causes 
obvious breakage--the compile fails outright.


To simplify the problem, what we have is two separate CMakeLists in two 
subdirectories:


Module a:
  set(a_generated_headers …)
  set(a_generated_sources …)
  set(a_static_headers …)
  set(b_static_sources …)
  add_custom_command(OUTPUT ${a_generated_headers} 
${a_generated_sources} COMMAND ${custom_tool} DEPENDS ${tool_dependencies)

  set(a_headers ${a_generated_headers} ${a_static_headers})
  set(a_sources ${a_generated_sources} ${a_static_sources})
  add_library(a SHARED ${a_sources} ${a_headers})

Module b:
  set(b_headers …)
  set(b_sources …)
  add_library(b SHARED ${b_sources} ${b_headers})
  target_link_libraries(b a)

The code generation, compiling and linking of module a works fine, and 
the code is regenerated if the dependencies are touched.  This works 
building serially or in parallel.


The compiling and linking of module b works fine only if building 
serially.  If building in parallel, the ${b_sources} which include any 
headers from module a's ${a_generated_headers} will fail if they are 
built before header generation in module a occurs.  This is inherently racy.


I'm at a bit of a loss for how to describe the needed dependency with 
cmake.  We have the correct library dependency with 
target_link_libraries, but this only appears to affect linking; I need 
to have a dependency which affects compiling.  I don't want any source 
files in module b compiling until the header generation in module a is 
complete (or to take it to the extreme, until module a is linked).  Is 
it possible to describe such a dependency with cmake?  Just making each 
of ${b_sources} depend upon "a" would be a workable solution.


Since these are in separate subdirectories, module b doesn't know about 
the custom command in module a, so it can't trigger source generation, 
and we don't have any explicit dependencies on any files in module a 
even if we could do that--module b doesn't have any special knowledge of 
the source layout to be able to do that.



I'd be very grateful for any suggestions.  Googling showed several 
questions and answers for source generation, but my problem here isn't 
really with the source generation (which works fine), but with 
preventing compiling until the generated files exist for targets which 
need the generated files indirectly.



Many thanks,
Roger


1. 
https://github.com/rleigh-dundee/bioformats/blob/cpp-bioformats-metadata/cpp/lib/ome/xml/CMakeLists.txt
2. 
https://github.com/rleigh-dundee/bioformats/blob/cpp-bioformats-metadata/cpp/lib/ome/bioformats/CMakeLists.txt
3. 
https://github.com/rleigh-dundee/bioformats/blob/cpp-bioformats-metadata/cpp/cmake/XsdFu.cmake



--
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 
4083 E800

--

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

[CMake] Versioning and release/distribution management with cmake and git

[Roger Leigh]

Hi,

For a number of years, I've been using autoconf/automake with a custom
extension for managing version numbering with git,including releasing
and distribution of the software directly in git.
(http://anonscm.debian.org/gitweb/?p=buildd-tools/schroot.git;a=blob;f=scripts/git-dist.mk;hb=refs/heads/schroot-1.6)

Over the last couple of weeks, I've been converting this project to use
cmake to replace the existing autoconf/automake build system.  I plan to
have both running in parallel for a period.  However, I've rewritten
the above as a cmake script which I have further generalised to make it
more generally usable (attached).  I've written some documentation for
how it all works at the start of the script, so I'll not repeat it
unnecessarily here.

To summarise its use, version numbering is handled externally from the
source tree in git tags.  These are found when cmake runs.  When it
comes to releasing, a git-release target handles tagging the git
repository, which also sets the version number in the release tag.  It
also handles distribution creation on a separate git branch, and will
embed the version number on the branch so it will work outside git with
e.g. tar/zip files; this branch is exportable to a release tar/zipfile.
This allows flexible and automated control over making releases without
any manual work in the source tree, so that it can integrate with CI
systems such as jenkins quite easily.

Example:
git://anonscm.debian.org/buildd-tools/schroot.git (development + release tags)
git://anonscm.debian.org/buildd-tools/schroot-dist.git (distribution +
distribution tags)
If you add both as remotes, you can see how the distribution and release
history ties together for each major release series with e.g. gitk.

While the script is currently functional, it's not yet perfect.  I'd like
to contribute it to the cmake project as a module once it's in a better
state, but prior to that I'd really appreciate some review in case I'm not
doing things the "cmake way".  In particular, reuse of the script as both
a module and standalone script is not too elegant with the use of a
generated script to pass configuration parameters.

I'd also like to allow end users to extend the creating of the distribution
directory with an automake-like "dist-hook" target or equivalent.  But I'm
unsure how to write a generic target with cmake which will invoke the
registered hooks.  Examples are to add generated files to the releases
(e.g. docs, translations) and perform pre-release sanity checks.  Are there
any examples of such hook uses?

Another minor annoyance I've run into is that when I define a function and
make use of a global variable, it appears to expand the variable during
definition, rather than evaluating it when I call the function.  Is it
possible to make the function evaluate the variable lazily at
invocation time rather than when defined?


Kind regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.
# Copyright © 2009-2013  Roger Leigh 
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see
# <http://www.gnu.org/licenses/>.
#
#

# Versioning, releasing and distribution management with git and cmake
# 
#
# This facility is a cmake reimplementation of an earlier
# autoconf/automake version from
# 
http://anonscm.debian.org/gitweb/?p=buildd-tools/schroot.git;a=blob;f=scripts/git-dist.mk;hb=refs/heads/schroot-1.6
# but is further generalised and is rather more configurable, and
# integrates quite seamlessly with cmake.
#
# Most projects currently handle versioning by hardcoding the version
# number in the source repository in some form, for example in the
# cmake scripts, or in the sources or some other file.  This script
# handles release versioning using the metadata in git tags, and for
# distributed release archives, it embeds a generated file so that git
# isn't required to retrieve the release metadata.
#
# This script also handles release and distribution of a project
# entirely within git, which is described in more detai

Re: [CMake] Getting add_custom_command to work with multiple outputs

[Roger Leigh]

On Sat, Aug 03, 2013 at 11:20:53AM +0100, Roger Leigh wrote:
> 
> I am trying to cmake-ify a build where the bulk of the sources are
> generated.  I have a tool (python script) which reads a set of
> templates and then generates many source and header files (~250).
> I don't know in advance what the source files will be--it's
> dependent upon the templates.  I've done this:
> 
> set(GEN_DIR gen)
> set(GENERATOR path/to/script)
> set(TEMPLATES template1 template2 template3)
> 
> execute_process(COMMAND ${GENERATOR} -d -o ${GEN_DIR} ${TEMPLATES}
>   OUTPUT_VARIABLE GENERATED_SOURCES)

string(REPLACE "\n" ";" GENERATED_SOURCES ${GENERATED_SOURCES})

seems to be the missing part here, which turns the multiline
string into a list of strings.  I was expecting this to behave
like make's $(shell ...) but the additional transform step is
no big deal.  All seems to be working well now!


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature
--

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Getting add_custom_command to work with multiple outputs

[Roger Leigh]

Hi folks,

I'm very new to cmake, so apologies if this is an obvious question,
but I haven't found a way to do this after reading the documentation,
and a lot of googling.

I am trying to cmake-ify a build where the bulk of the sources are
generated.  I have a tool (python script) which reads a set of
templates and then generates many source and header files (~250).
I don't know in advance what the source files will be--it's
dependent upon the templates.  I've done this:

set(GEN_DIR gen)
set(GENERATOR path/to/script)
set(TEMPLATES template1 template2 template3)

execute_process(COMMAND ${GENERATOR} -d -o ${GEN_DIR} ${TEMPLATES}
  OUTPUT_VARIABLE GENERATED_SOURCES)

execute_process(COMMAND ${CMAKE} -E echo ${GENERATED_SOURCES})

This part works, running the generator in "dry run" mode to output
a list of files which will be generated, but not actually doing any
generation.  Running cmake gives me output like this:
gen/ome/xml/model/OME.cpp
gen/ome/xml/model/OME.h
gen/ome/xml/model/BinaryOnly.cpp
gen/ome/xml/model/BinaryOnly.h
gen/ome/xml/model/Image.cpp
gen/ome/xml/model/Image.h
gen/ome/xml/model/Pixels.cpp
gen/ome/xml/model/Pixels.h
gen/ome/xml/model/Plane.cpp
gen/ome/xml/model/Plane.h
gen/ome/xml/model/Channel.cpp
gen/ome/xml/model/Channel.h
gen/ome/xml/model/MetadataOnly.cpp
gen/ome/xml/model/MetadataOnly.h

So far, so good.  I've then tried to make the source generation occur
with a custom command.  This includes the templates as dependencies so
that the source will be regenerated if the templates change.

add_custom_command(OUTPUT ${GENERATED_SOURCES}
  COMMAND {GENERATOR} -o ${GEN_DIR} ${TEMPLATES}
  DEPENDS ${TEMPLATES}
  COMMENT Generate sources)

add_library(test SHARED ${GENERATED_SOURCES})

But this results in a broken Makefile.

gen/ome/xml/model/OME.cpp
gen/ome/xml/model/OME.h
gen/ome/xml/model/BinaryOnly.cpp
gen/ome/xml/model/BinaryOnly.h
gen/ome/xml/model/Image.cpp
gen/ome/xml/model/Image.h
gen/ome/xml/model/Pixels.cpp
gen/ome/xml/model/Pixels.h
[…]
: template1

i.e. the rules are broken due to being split over multiple lines.

I'm obviously doing something quite wrong here, but I'm not sure what.
Or indeed, if I'm approaching this from the right direction--maybe I
should be doing this completely differently.

Any thoughts and suggestions would be greatly appreciated!


Many thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature
--

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake