Re: [CMake] Contribute Find-module to CMake vs Config-file to upstream

[rleigh]

On 2018-05-21 18:39, Mateusz Loskot wrote:

I've been recently trying to update/add Find-modules to CMake:
updated FindJPEG, proposed FindODBC and most recently FindLZ4.

[…]

The FindLZ4 discussion basically ended with suggestion from Brad that,
instead of adding Find-module to CMake, I should approach LZ4 project
and add Config-file to the library itself.
Then I argued taht Config-files are more complex and I don't feel like
asking projects, which I don't maintain myself, to accept the extra 
complexity.
Finally, Brad replied that CMake doesn't need LZ4 itself and yet for 
some
reason is expected to know all about it: versions, headers, libraries, 
etc.
and that it's not scalable to teach CMake about every project in the 
world.


It really doesn't scale.  I've contributed and provided ongoing fixes 
for a few Find modules out of practical necessity, for projects which 
are effectively incapable of adding a Config-file, either because the 
project was stagnant with no new releases (Xerces, Xalan), or where the 
project was so complex that it was effectively impossible to add 
(Boost).  However, that work should have been done by the upstream.  The 
ongoing maintenance cost has been moved from the upstream development, 
where it belongs, to a volunteer (me).  It's work which I do because it 
provides value to me and my employer so I can use CMake with the 
projects I work on, but is otherwise unjustifiable.  You simply can't 
expect every Find module to keep pace with upstream development without 
a small army of volunteers to keep them all up to date.  If they are 
provided with the upstream releases, they are de facto always up to date 
because they are directly matched to the library.


Note that for several of these projects (e.g. Xerces, libtiff), I have 
actually provided upstream CMake build systems which install 
Config-files, so in the future the Find modules can be deprecated and 
users can move to the Config-file as these releases make their way into 
distributions.  That's semi-altruistic.  I've spent a lot of effort up 
front to make CMake infrastructure in these projects maintainable for 
the long term, and something which can be delegated to others for 
ongoing maintenance.



This opinion does not surprise me and I understand the rationale.
I argue that CMake does need to know about every project in the world,
or every project that CMake users wish to use, directly or indirectly.
Without the knowledge CMake would simply be useless.


Not useless, that's going a bit far.  It's requiring a little bit of 
extra work to be functional.  For libraries without Find modules, you 
can usually write your own in a couple of dozen lines.  At that point 
your options are:


- to upstream it as a Config-file template to the upstream developers
- to maintain it independently in your project
- to upstream it to cmake.git

Depending upon the library in question, I've done all three at various 
times.


As a CMake user, I expect to be able to install CMake and get my 
dependencies

recognised by CMake as CMake's responsibility


If a library is strictly GNU Autoconf, I'm on lost position trying to 
convince
maitnainers to accept CMake stuff and even if they do, they won't be 
willing to

maintain it - broken Config-files may be deployed with new packages.
That puts users of CMake and such library on lost position:
CMake says no to Find-module, the library does not care either.


If it's using Autoconf, then it can still provide and install CMake 
configuration files.  It can use @var@ substitutions in the 
Config-file.in template and then install it.  Just like for pkg-config 
templates.


Individual projects may have their own policies, and some might not want 
to have CMake support.  In general though, if you were to provide a 
tested patch that creates the Config-file in AC_OUTPUT and then install 
as e.g. cmake_pkgconfig_DATA in Makefile.am, add a distcheck hook and/or 
CI logic to test it, and most projects are in my experience willing to 
accept the patch.  The only way to find out is to create and submit the 
patch, and have a conversation with them about the cost/benefit of 
including it.  Some might be worried about the maintenance burden, so 
explain the value of it and maybe commit to maintaining it as required.  
Since you'd likely be maintaining it /anyway/, it's not a big task.


As CMake user I don't want to be left to the discretion of package 
maintainers.

Packages may ignore CMake Config-file existence.
Packages of libraries which provide CMake and alternative build 
configurations

may not deploy Config-files or Find-modules.

IMHO, CMake should encourage contributions of new Find-modules.


As with all things, in my opinion this really comes down to these 
questions: "who is going to do the work", and "who is paying for their 
time".  Contribution also has implied ongoing maintenance obligations.  
If Find modules are contributed and then not maintained, they will 
become broken over 

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

[rleigh]

On 2017-08-10 10:28, rle...@codelibre.net wrote:

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.


Looking at the NuGet packages, I can see Ice++11 on Windows; it's named 
Ice37++11[d].lib.  Helpfully not following the existing conventions on 
the other platforms and previous Ice releases, but I think I've worked 
around this now.



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.

Regarding C++11, their approach here is certainly a bit unorthodox as
well as being inconsistent between platforms, and FindIce will need to
deal with that unfortunate situation.  Since the old and new APIs are
incompatible, and you have to explicitly opt-in to using the new one,
I don't think that using "-std=c++11" on its own is sufficient reason
to select the C++11 library?  Can you use the old API with a C++11
compiler?  It might be best to have a set of C++11 component names,
and map these to the appropriate library names on Linux (separate
libs) and Windows (not separate), if that would make the intent of the
user clear and unambiguous.

I will try to look at this, but I'm a little busy with other things at
the moment, and so it's not at top of my list.  If you wanted to
propose a change an/or open a merge request that would certainly be
welcome.


I have done some preliminary work here:

  https://gitlab.kitware.com/rleigh/cmake/commits/ice-3.7.0

It's working on Linux, but not yet finding the libraries on Windows when 
using the NuGet distribution of the libraries.  This is likely some 
minor bug which I need to identify; it's using all the correct paths and 
suffixes that I can see.


If you would like to give this a go and help fix the detection on 
Windows, that would be really helpful.  I've left some extra debugging 
messages in to trace how find_library is working.  If you set 
CMAKE_PREFIX_PATH to the location where the NuGet packages live, it 
should automatically detect the package name.  Do we have any existing 
conventions within CMake for finding libraries within such packages?  
Should the package be listed specifically on CMAKE_PREFIX_PATH, or is 
finding the package itself on the path acceptable?  Or should both be 
supported?



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

[rleigh]

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.

Regarding C++11, their approach here is certainly a bit unorthodox as 
well as being inconsistent between platforms, and FindIce will need to 
deal with that unfortunate situation.  Since the old and new APIs are 
incompatible, and you have to explicitly opt-in to using the new one, I 
don't think that using "-std=c++11" on its own is sufficient reason to 
select the C++11 library?  Can you use the old API with a C++11 
compiler?  It might be best to have a set of C++11 component names, and 
map these to the appropriate library names on Linux (separate libs) and 
Windows (not separate), if that would make the intent of the user clear 
and unambiguous.


I will try to look at this, but I'm a little busy with other things at 
the moment, and so it's not at top of my list.  If you wanted to propose 
a change an/or open a merge request that would certainly be welcome.



Kind regards,
Roger Leigh

--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to add project files?

[rleigh]

On 2017-07-14 03:33, Florian Lindner wrote:

Now, in the docs I everywhere read not to add the files using GLOB.
However, I have found no definitive guide how to add
project files in a large project with subdirs like that.

How would you do it in cmakeish fashion?


List each file explicitly.  For example, see 
https://github.com/apache/xerces-c/blob/trunk/src/CMakeLists.txt


No potential for inclusion of a stray file which gets globbed 
unintentionally, and any change to the lists will force cmake to be 
re-run, and the targets rebuilt.



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] Proper way to find system copy of libxml2 on macOS

[rleigh]

On 2016-10-12 15:28, Konstantin Tokarev wrote:

Hello,

In my cmake project I need to use system version of libxml2 on macOS
(/usr/lib/libxml2.dylib), however in case it is installed in MacPorts
the latter version is picked by find_package. On the other hand I'd
like to avoid hardcoding absolute path, just in case Apple changes
some path or file name in future OS version.

I've tried

find_package(LibXml2 2.8.0 REQUIRED PATHS "/usr" NO_DEFAULT_PATH)

however it fails to find anything at all. Any ideas?


Use

  find_package(LibXml2 2.8.0 REQUIRED)

and then use CMAKE_PREFIX_PATH to define the search locations (in your
environment or on the command-line; not in the script).  If you
hardcode paths in the script, you make it break on other systems.
That might not be a consideration in this case, but the less
assumptions you make, the more flexible it will be.


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] No response so far. -- Looking for fixed contract help building Library with CMake.

[rleigh]

On 2016-08-12 15:50, Ken Boulange wrote:

I am a one man company that needs to get a Library built from C/C++
source using CMake.

My system is windows 7 Professional.  I am running MVS 8 (Microsoft
Visual Studios 8)  I need the following library built from the below
URL (It's a DICOM image Library):

http://dicom.offis.de/dcmtk.php.en

It's configured to be built by CMake.   I've come close, but not close
enough.


What are the problems are you having with it?

I'm afraid I don't have this version of Visual Studio; I only have 12 
and 14.  But I tried building with 14 + Ninja and it built without 
trouble and passed all the unit tests.  The optional dependencies like 
libtiff, libpng are also buildable with cmake, and I build these on 
Windows daily, so building the collection should certainly be 
achievable.




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] Imported targets and include ordering

[rleigh]

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


CMAKE_PREFIX_PATH is set appropriately, and all the Find module checks 
are correct.  The problem is that the ICU INTERFACE_INCLUDE_DIRECTORIES 
is treated as a system include.  This would be OK, if it were not for 
the fact that the CURL includes are placed before it.


The problem is that it's not a system path.  However, the CURL path 
*is*.  And this leads to it building against the ICU55 headers, and then 
failing to link against the ICU57 libraries.  But that's just the 
situation on this specific (FreeBSD) system; the situation could be 
reversed on another with a locally built CURL and a system ICU and CURL.


I see that I could use NO_SYSTEM_FROM_IMPORTED for the imported target, 
and/or use BEFORE|AFTER SYSTEM with [target_]include_directories.  
However, none of these feel appropriate.  They would require knowledge I 
don't have as the cmake script author--either of these libraries could 
be using system or non-system paths; I don't have the foreknowledge to 
make that determination.


How could an end user override what are system paths and what are not 
without hand-editing the script?


It seems (being naive) that the hardcoded behaviour of treating 
INTERFACE_INCLUDE_DIRECTORIES as system includes isn't a universally 
useful default, and while I can override the behaviour, that's a 
explicit action on the part of the script author, and might be 
inappropriate for the user's system.  Whether a path is a system include 
or not seems to be something the end user should be able to tune, since 
the script author and cmake find module authors have no idea what the 
local situation is for any arbitrary system.  For example, it wouldn't 
hurt for cmake to "know" that /usr/local/include is a system path as a 
built-in default, and allow additional paths to be added, and then if a 
random find module adds it such that it's used by a target as a 
non-system include we know we can ignore it and just use it as a system 
include instead.  Unless I'm misunderstanding the situation and making 
this work is already possible.



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] Make install permissions advice for ubuntu 14.04 with cmake 2.8

[rleigh]

On 2016-06-06 16:39, B00083603 Michael O Brien wrote:

Hi Roger,

When I run sudo -s I get bash:  /home/myaccount/ : Permission denied
but I get a root prompt on the terminal. I get a permission denied
when I try to cd into anything deeper than /home/myaccount/

Yes the /home/ is an NFS mount as its common across all the vm's I'm
assigned to but  there isn't an etc/exports file
In /proc/mount the mount details don't mention root_squash just that
its nfs rw relatime vers3


The root squashing is in the exports on the server side.  This maps uid 
0 to nobody,
which is why the access is denied.  One solution: make all the files 
readable by
other and the directories are readable and executable by other.  
However, since this
is generally the default it's not clear why this is happening.  You 
didn't show us
the permissions as I asked, so it's not possible to do more than 
speculate.  What does

this show (with any typos fixed)?

ls -ld / /home /home/michael.obrien /home/michael.obrien/setups 
/home/michael.obrien/setups/OpenCV 
/home/michael.obrien/setups/OpenCV/opencv-2.4.12 
/home/michael.obrien/setups/OpenCV/opencv-2.4.12/build


I'll hazard a guess that your homedir is 0700 or 0750; if so it'll need
to be 0755 (so that any user can access it, including nobody); likewise
for any other directories which you want root to read.


Regards,
Roger
--

Powered by www.kitware.com

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

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

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

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

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

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

[rleigh]

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

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

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

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


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



Regards,
Roger
--

Powered by www.kitware.com

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

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

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

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

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

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

[rleigh]

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

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

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

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


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



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] [PATCH] FindBoost does not detect absence of header file

[rleigh]

On 2016-04-12 11:22, Joachim Wuttke wrote:

FindBoost does not detect absence of header files.

To be specific: Run the following under cmake version 3.5.1:

set(Boost_NO_BOOST_CMAKE ON) # prevent shortcut
set(Boost_USE_STATIC_LIBS OFF)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME OFF)
add_definitions(-DBOOST_ALL_DYN_LINK) # line is needed for MSVC
#add_definitions(-DBOOST_LIB_DIAGNOSTIC) # shows during compilation
auto-linked libraries
if(WIN32)
set(boost_libraries_required date_time chrono program_options zlib
bzip2 iostreams system filesystem regex thread)
else()
set(boost_libraries_required date_time chrono program_options
iostreams system filesystem regex thread)
endif()
find_package(Boost 1.48.0 COMPONENTS ${boost_libraries_required} 
REQUIRED)

message(STATUS "--> Boost_INCLUDE_DIRS: ${Boost_INCLUDE_DIRS}")
message(STATUS "Boost_LIBRARY_DIRS: ${Boost_LIBRARY_DIRS}")
message(STATUS "Boost_LIBRARIES: ${Boost_LIBRARIES}")

It will pass, even if files like /usr/include/boost/date_time.hpp  
are removed

from the system.


Attached is a patch to add this extra checking.

For each library component, there is a corresponding header which has 
been present in all versions of boost to date which provide the library; 
the list used to validate this is also attached.  I have also validated 
that each component works with find_package for Boost 1.58 and 1.60.


If your system contains both the libraries and headers, then FindBoost 
will behave exactly as before.  But if you have the libraries without 
the headers, FindBoost will now fail, rather than passing and then 
having the build subsequently fail when it tries to use the nonexistent 
headers.  So it's essentially adding an additional header check per 
component, which will identify situations where the user has an 
incomplete Boost installation e.g. no all the -dev packages are 
installed.


I can merge this into next for testing, but if anyone wanted to have an 
initial play with it to verify that it's still functional and that the 
approach is sound, I can wait off for now.



Regards,
RogerFrom 724084194b6be8b0a3fb752b265b140db79487f2 Mon Sep 17 00:00:00 2001
From: Roger Leigh 
Date: Wed, 11 May 2016 10:55:51 +0100
Subject: [PATCH] FindBoost: Add checks for component-specific headers

This supplements the existing library checks, to
cater for the possibility that the libraries are
present but the headers are not.  This can happen
when the Boost collections is split up into
multiple packages and not all are installed,
and will avoid the checks silently passing when
the build would subsequently fail.
---
 Modules/FindBoost.cmake | 87 ++---
 1 file changed, 83 insertions(+), 4 deletions(-)

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

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

[rleigh]

On 2016-04-12 11:22, Joachim Wuttke wrote:

FindBoost does not detect absence of header files.

To be specific: Run the following under cmake version 3.5.1:

set(Boost_NO_BOOST_CMAKE ON) # prevent shortcut
set(Boost_USE_STATIC_LIBS OFF)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME OFF)
add_definitions(-DBOOST_ALL_DYN_LINK) # line is needed for MSVC
#add_definitions(-DBOOST_LIB_DIAGNOSTIC) # shows during compilation
auto-linked libraries
if(WIN32)
set(boost_libraries_required date_time chrono program_options zlib
bzip2 iostreams system filesystem regex thread)
else()
set(boost_libraries_required date_time chrono program_options
iostreams system filesystem regex thread)
endif()
find_package(Boost 1.48.0 COMPONENTS ${boost_libraries_required} 
REQUIRED)

message(STATUS "--> Boost_INCLUDE_DIRS: ${Boost_INCLUDE_DIRS}")
message(STATUS "Boost_LIBRARY_DIRS: ${Boost_LIBRARY_DIRS}")
message(STATUS "Boost_LIBRARIES: ${Boost_LIBRARIES}")

It will pass, even if files like /usr/include/boost/date_time.hpp  
are removed

from the system.


Attached is a patch to add this extra checking.

For each library component, there is a corresponding header which has 
been present in all versions of boost to date which provide the library; 
the list used to validate this is also attached.  I have also validated 
that each component works with find_package for Boost 1.58 and 1.60.


If your system contains both the libraries and headers, then FindBoost 
will behave exactly as before.  But if you have the libraries without 
the headers, FindBoost will now fail, rather than passing and then 
having the build subsequently fail when it tries to use the nonexistent 
headers.  So it's essentially adding an additional header check per 
component, which will identify situations where the user has an 
incomplete Boost installation e.g. no all the -dev packages are 
installed.


I can merge this into next for testing, but if anyone wanted to have an 
initial play with it to verify that it's still functional and that the 
approach is sound, I can wait off for now.



Regards,
RogerFrom 724084194b6be8b0a3fb752b265b140db79487f2 Mon Sep 17 00:00:00 2001
From: Roger Leigh 
Date: Wed, 11 May 2016 10:55:51 +0100
Subject: [PATCH] FindBoost: Add checks for component-specific headers

This supplements the existing library checks, to
cater for the possibility that the libraries are
present but the headers are not.  This can happen
when the Boost collections is split up into
multiple packages and not all are installed,
and will avoid the checks silently passing when
the build would subsequently fail.
---
 Modules/FindBoost.cmake | 87 ++---
 1 file changed, 83 insertions(+), 4 deletions(-)

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

Re: [cmake-developers] [PATCH] FindPNG: Create an imported PNG::PNG target

[rleigh]

> On 01/19/2016 12:43 PM, Sam Thursfield wrote:
>> Imported targets are now the recommended way of dealing with external
>> library dependencies.
>
> Thanks!  Applied with minor doc format fixup and merged to 'next'
> for testing:
>
>  FindPNG: Create an imported PNG::PNG target (#15911)
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9451ea5a
>
>> + INTERFACE_LIBRARIES "${PNG_LIBRARIES}")
>
> Shouldn't this refer to zlib instead of png libraries again?

I would have expected something like

  set_target_properties(PNG::PNG PROPERTIES INTERFACE_LINK_LIBRARIES
ZLIB::ZLIB)

after all of the "if(EXISTS... add imported link interface/location"
blocks, so you get the appropriate zlib library.  Certainly, I don't think
PNG_LIBRARIES is appropriate to use for any of the imported targets,
otherwise the system-specific zlib library path is going to get embedded
in exported configuration when you call install(... EXPORT) to export the
library configuration for find_package.  I'd just use PNG_LIBRARY here and
then add the dependencies as imported targets.

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

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

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

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

2) the need to create the interface library target.  We export a target,
not an interface name, and so the internal target name in our project is
exposed to the user of the library.  It would be nice if we could specify
the friendly interface name we expect the user to use when we do the
export, and ignore the internal target name for the generated output
entirely.


Kind regards,
Roger

-- 

Powered by www.kitware.com

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

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

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

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

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

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

[rleigh]

> - Add unit test to test imported targets and existing variables

I should mention that to run the unit test, you must define the GTEST_ROOT
environment variable to point to the gtest build, due to gtest being
annoyingly crippled to be uninstallable for dubious reasons.  You can pass
-DGTEST_ROOT, but since the cmake build can't pass it through without
further changes, the environment variable is the only way to run the test
with the existing patches.


Regards,
Roger

-- 

Powered by www.kitware.com

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

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

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

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

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

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

[rleigh]

> - Adds GTest::GTest and GTest::Main imported targets (including
> Thread::Thread dependency for GTest::GTest and GTest::GTest for
> GTest::Main; the latter might not be appropriate and could be removed if
> needed--but I'm unaware of any situation where you would want to use
> GTest::Main without GTest::GTest)

Double-checking the gtest_main symbol table, it depends on symbols from
gtest, so the dependency is actually required, so please ignore the
above--it's definitely appropriate.

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [PATCH] Imported targets for FindGTest

[rleigh]

Pushed to

  https://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/gtest-
imported-targets

and merged into next for review and testing.

- Adds GTest::GTest and GTest::Main imported targets (including
Thread::Thread dependency for GTest::GTest and GTest::GTest for
GTest::Main; the latter might not be appropriate and could be removed if
needed--but I'm unaware of any situation where you would want to use
GTest::Main without GTest::GTest)
- Document imported targets
- Update documentation, adding sections, description lists and updated
examples
- Add unit test to test imported targets and existing variables


Kind regards,
Roger

-- 

Powered by www.kitware.com

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

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

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

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

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

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

[rleigh]

> On 12/01/2015 05:11 PM, Roger Leigh wrote:
>> Attached.  I also attached the BoostScanDeps raw output and after
>> search-and-replace to make into valid cmake conditionals, and then after
>> simplifying where following release dependencies are unchanged, so you
>> can see where the logic in FindBoost comes from.
>
> Thanks.  That is a nice breakdown.
>
> Please revies the "FindBoost: Embed component dependency table" commit
> message to explain the steps used to run the script and ultimately get
> the content added by the commit.
>
>> + # Note: When adding a new Boost release, also update the dependency
>> + # information in _Boost_COMPONENT_DEPENDENCIES
>
> This is a good note.  Please extend it with a reference to instructions
> somewhere on how to actually perform the update.

I have updated both as requested, please find the updated patch attached.


Regards,
Roger
>From 3db45dbf0f41279dbf1b5288167cb96a84bef3fe Mon Sep 17 00:00:00 2001
From: Roger Leigh 
Date: Tue, 1 Dec 2015 21:53:50 +
Subject: [PATCH 2/5] FindBoost: Embed component dependency table

The function _Boost_COMPONENT_DEPENDENCIES is used to query the
library dependencies for a given component for a given version of
Boost.  This covers Boost releases from 1.33 to 1.59, using the
information generated by Utilities/Scripts/BoostScanDeps.cmake.
---
 Modules/FindBoost.cmake | 221 
 1 file changed, 221 insertions(+)

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 33e6a49..41b728d 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -472,6 +472,223 @@ function(_Boost_GUESS_COMPILER_PREFIX _ret)
 endfunction()
 
 #
+# Get component dependencies.  Requires the dependencies to have been
+# defined for the Boost release version.
+#
+# component - the component to check
+# _ret - list of library dependencies
+#
+function(_Boost_COMPONENT_DEPENDENCIES component _ret)
+  # Note: to add a new Boost release, run
+  #
+  #   % cmake -DBOOST_DIR=/path/to/boost/source -P Utilities/Scripts/BoostScanDeps.cmake
+  #
+  # The output may be added in a new block below.  If it's the same as
+  # the previous release, simply update the version range of the block
+  # for the previous release.
+  #
+  # This information was originally generated by running
+  # BoostScanDeps.cmake against every boost release to date supported
+  # by FindBoost:
+  #
+  #   % for version in /path/to/boost/sources/*
+  # do
+  #   cmake -DBOOST_DIR=$version -P Utilities/Scripts/BoostScanDeps.cmake
+  # done
+  #
+  # The output was then updated by search and replace with these regexes:
+  #
+  # - Strip message(STATUS) prefix dashes
+  #   s;^-- ;;
+  # - Indent
+  #   s;^set(;set(;;
+  # - Add conditionals
+  #   s;Scanning /path/to/boost/sources/boost_\(.*\)_\(.*\)_\(.*);  elseif(NOT Boost_VERSION VERSION_LESS \10\20\3 AND Boost_VERSION VERSION_LESS );
+  #
+  # This results in the logic seen below, but will require the 
+  # replacing with the following Boost release version (or the next
+  # minor version to be released, e.g. 1.59 was the latest at the time
+  # of writing, making 1.60 the next, so 106000 is the needed version
+  # number).  Identical consecutive releases were then merged together
+  # by updating the end range of the first block and removing the
+  # following redundant blocks.
+  #
+  # Running the script against all historical releases should be
+  # required only if the BoostScanDeps.cmake script logic is changed.
+  # The addition of a new release should only require it to be run
+  # against the new release.
+  set(_Boost_IMPORTED_TARGETS TRUE)
+  if(NOT Boost_VERSION VERSION_LESS 103300 AND Boost_VERSION VERSION_LESS 103500)
+set(_Boost_IOSTREAMS_DEPENDENCIES regex thread)
+set(_Boost_REGEX_DEPENDENCIES thread)
+set(_Boost_WAVE_DEPENDENCIES filesystem thread)
+set(_Boost_WSERIALIZATION_DEPENDENCIES serialization)
+  elseif(NOT Boost_VERSION VERSION_LESS 103500 AND Boost_VERSION VERSION_LESS 103600)
+set(_Boost_FILESYSTEM_DEPENDENCIES system)
+set(_Boost_IOSTREAMS_DEPENDENCIES regex)
+set(_Boost_MPI_DEPENDENCIES serialization)
+set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization)
+set(_Boost_WAVE_DEPENDENCIES filesystem system thread)
+set(_Boost_WSERIALIZATION_DEPENDENCIES serialization)
+  elseif(NOT Boost_VERSION VERSION_LESS 103600 AND Boost_VERSION VERSION_LESS 103800)
+set(_Boost_FILESYSTEM_DEPENDENCIES system)
+set(_Boost_IOSTREAMS_DEPENDENCIES regex)
+set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l)
+set(_Boost_MPI_DEPENDENCIES serialization)
+set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization)
+set(_Boost_WAVE_DEPENDENCIES filesystem system thread)
+set(_Boost_WSERIALIZATION_DEPENDENCIES serialization)
+  elseif(NOT Boost_VERSION VERSION_LESS 103800 AND Boost_VERSION VERSION_LESS 104300)
+   

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

[rleigh]

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

Also:

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

Patch attached.


Regards,
Roger>From d8f52434e7b86f55bdcdc4b2ca588f6d5f7daafa Mon Sep 17 00:00:00 2001
From: Roger Leigh 
Date: Wed, 2 Dec 2015 17:20:24 +
Subject: [PATCH] FindTIFF: Add imported targets and update documentation

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

Also:

- Add TIFF_INCLUDE_DIRS to match common practice
- Update documentation generally, including documenting
  TIFF_INCLUDE_DIRS
---
 Modules/FindTIFF.cmake | 67 --
 Tests/CMakeLists.txt   |  4 +++
 Tests/FindTIFF/CMakeLists.txt  | 10 ++
 Tests/FindTIFF/Test/CMakeLists.txt | 17 ++
 Tests/FindTIFF/Test/main.c | 12 +++
 5 files changed, 100 insertions(+), 10 deletions(-)
 create mode 100644 Tests/FindTIFF/CMakeLists.txt
 create mode 100644 Tests/FindTIFF/Test/CMakeLists.txt
 create mode 100644 Tests/FindTIFF/Test/main.c

diff --git a/Modules/FindTIFF.cmake b/Modules/FindTIFF.cmake
index ed092ea..e49a00d 100644
--- a/Modules/FindTIFF.cmake
+++ b/Modules/FindTIFF.cmake
@@ -2,24 +2,43 @@
 # FindTIFF
 # 
 #
-# Find TIFF library
+# Find the TIFF library (libtiff).
 #
-# Find the native TIFF includes and library This module defines
+# Imported targets
+# 
 #
-# ::
+# This module defines the following :prop_tgt:`IMPORTED` targets:
 #
-#   TIFF_INCLUDE_DIR, where to find tiff.h, etc.
-#   TIFF_LIBRARIES, libraries to link against to use TIFF.
-#   TIFF_FOUND, If false, do not try to use TIFF.
+# ``TIFF::TIFF``
+#   The TIFF library, if found.
 #
-# also defined, but not for general use are
+# Result variables
+# 
 #
-# ::
+# This module will set the following variables in your project:
 #
-#   TIFF_LIBRARY, where to find the TIFF library.
+# ``TIFF_FOUND``
+#   true if the TIFF headers and libraries were found
+# ``TIFF_INCLUDE_DIR``
+#   the directory containing the TIFF headers
+# ``TIFF_INCLUDE_DIRS``
+#   the directory containing the TIFF headers
+# ``TIFF_LIBRARIES``
+#   TIFF libraries to be linked
+#
+# Cache variables
+# ^^^
+#
+# The following cache variables may also be set:
+#
+# ``TIFF_INCLUDE_DIR``
+#   the directory containing the TIFF headers
+# ``TIFF_LIBRARY``
+# the path to the TIFF library
 
 #=
 # Copyright 2002-2009 Kitware, Inc.
+# Copyright 2015 University of Dundee
 #
 # Distributed under the OSI-approved BSD License (the "License");
 # see accompanying file Copyright.txt for details.
@@ -65,7 +84,35 @@ FIND_PACKAGE_HANDLE_STANDARD_ARGS(TIFF
   VERSION_VAR TIFF_VERSION_STRING)
 
 if(TIFF_FOUND)
-  set( TIFF_LIBRARIES ${TIFF_LIBRARY} )
+  set(TIFF_LIBRARIES ${TIFF_LIBRARY})
+  set(TIFF_INCLUDE_DIRS "${TIFF_INCLUDE_DIR}")
+
+  if(NOT TARGET TIFF::TIFF)
+add_library(TIFF::TIFF UNKNOWN IMPORTED)
+if(TIFF_INCLUDE_DIRS)
+  set_target_properties(TIFF::TIFF PROPERTIES
+INTERFACE_INCLUDE_DIRECTORIES "${TIFF_INCLUDE_DIRS}")
+endif()
+if(EXISTS "${TIFF_LIBRARY}")
+  set_target_properties(TIFF::TIFF PROPERTIES
+IMPORTED_LINK_INTERFACE_LANGUAGES "C"
+IMPORTED_LOCATION "${TIFF_LIBRARY}")
+endif()
+if(EXISTS "${TIFF_LIBRARY_DEBUG}")
+  set_property(TARGET TIFF::TIFF APPEND PROPERTY
+IMPORTED_CONFIGURATIONS DEBUG)
+  set_target_properties(TIFF::TIFF PROPERTIES
+IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "C"
+IMPORTED_LOCATION_DEBUG "${TIFF_LIBRARY_DEBUG}")
+endif()
+if(EXISTS "${TIFF_LIBRARY_RELEASE}")
+  set_property(TARGET TIFF::TIFF APPEND PROPERTY
+IMPORTED_CONFIGURATIONS RELEASE)
+  set_target_properties(TIFF::TIFF PROPERTIES
+IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "C"
+IMPORTED_LOCATION_RELEASE "${TIFF_LIBRARY_RELEASE}")
+endif()
+  endif()
 endif()
 
 mark_as_advanced(TIFF_INCLUDE_DIR TIFF_LIBRARY)
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 5fd7159..a040ec0 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1367,6 +1367,10 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release
 add_subdirectory(FindOpenSSL)
   endif()
 
+  if(CMake_TEST_FindTIFF)
+add_subdirectory(FindTIFF)
+  endif()
+
   if(CMake_TEST_FindXercesC)
 add_subdirectory(FindXercesC)
   endif()
diff --git a/Tests/FindTIFF/CMakeLists.txt b/Tests/FindTIFF/CMakeLists.txt
new file mode 100644
index 000..c4e0c6a
--- /dev/null
+++ b/Tests/FindTIFF/CMakeLists.txt
@@ -0,0 +1,10 @@
+add_test(NAME FindTIFF.Test COMMAND
+  ${CMAKE_CTEST_COMMAND} -C $
+  

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

[rleigh]

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

Also:

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

Patch actually attached this time...


Regards,
Roger>From d8f52434e7b86f55bdcdc4b2ca588f6d5f7daafa Mon Sep 17 00:00:00 2001
From: Roger Leigh 
Date: Wed, 2 Dec 2015 17:20:24 +
Subject: [PATCH] FindTIFF: Add imported targets and update documentation

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

Also:

- Add TIFF_INCLUDE_DIRS to match common practice
- Update documentation generally, including documenting
  TIFF_INCLUDE_DIRS
---
 Modules/FindTIFF.cmake | 67 --
 Tests/CMakeLists.txt   |  4 +++
 Tests/FindTIFF/CMakeLists.txt  | 10 ++
 Tests/FindTIFF/Test/CMakeLists.txt | 17 ++
 Tests/FindTIFF/Test/main.c | 12 +++
 5 files changed, 100 insertions(+), 10 deletions(-)
 create mode 100644 Tests/FindTIFF/CMakeLists.txt
 create mode 100644 Tests/FindTIFF/Test/CMakeLists.txt
 create mode 100644 Tests/FindTIFF/Test/main.c

diff --git a/Modules/FindTIFF.cmake b/Modules/FindTIFF.cmake
index ed092ea..e49a00d 100644
--- a/Modules/FindTIFF.cmake
+++ b/Modules/FindTIFF.cmake
@@ -2,24 +2,43 @@
 # FindTIFF
 # 
 #
-# Find TIFF library
+# Find the TIFF library (libtiff).
 #
-# Find the native TIFF includes and library This module defines
+# Imported targets
+# 
 #
-# ::
+# This module defines the following :prop_tgt:`IMPORTED` targets:
 #
-#   TIFF_INCLUDE_DIR, where to find tiff.h, etc.
-#   TIFF_LIBRARIES, libraries to link against to use TIFF.
-#   TIFF_FOUND, If false, do not try to use TIFF.
+# ``TIFF::TIFF``
+#   The TIFF library, if found.
 #
-# also defined, but not for general use are
+# Result variables
+# 
 #
-# ::
+# This module will set the following variables in your project:
 #
-#   TIFF_LIBRARY, where to find the TIFF library.
+# ``TIFF_FOUND``
+#   true if the TIFF headers and libraries were found
+# ``TIFF_INCLUDE_DIR``
+#   the directory containing the TIFF headers
+# ``TIFF_INCLUDE_DIRS``
+#   the directory containing the TIFF headers
+# ``TIFF_LIBRARIES``
+#   TIFF libraries to be linked
+#
+# Cache variables
+# ^^^
+#
+# The following cache variables may also be set:
+#
+# ``TIFF_INCLUDE_DIR``
+#   the directory containing the TIFF headers
+# ``TIFF_LIBRARY``
+# the path to the TIFF library
 
 #=
 # Copyright 2002-2009 Kitware, Inc.
+# Copyright 2015 University of Dundee
 #
 # Distributed under the OSI-approved BSD License (the "License");
 # see accompanying file Copyright.txt for details.
@@ -65,7 +84,35 @@ FIND_PACKAGE_HANDLE_STANDARD_ARGS(TIFF
   VERSION_VAR TIFF_VERSION_STRING)
 
 if(TIFF_FOUND)
-  set( TIFF_LIBRARIES ${TIFF_LIBRARY} )
+  set(TIFF_LIBRARIES ${TIFF_LIBRARY})
+  set(TIFF_INCLUDE_DIRS "${TIFF_INCLUDE_DIR}")
+
+  if(NOT TARGET TIFF::TIFF)
+add_library(TIFF::TIFF UNKNOWN IMPORTED)
+if(TIFF_INCLUDE_DIRS)
+  set_target_properties(TIFF::TIFF PROPERTIES
+INTERFACE_INCLUDE_DIRECTORIES "${TIFF_INCLUDE_DIRS}")
+endif()
+if(EXISTS "${TIFF_LIBRARY}")
+  set_target_properties(TIFF::TIFF PROPERTIES
+IMPORTED_LINK_INTERFACE_LANGUAGES "C"
+IMPORTED_LOCATION "${TIFF_LIBRARY}")
+endif()
+if(EXISTS "${TIFF_LIBRARY_DEBUG}")
+  set_property(TARGET TIFF::TIFF APPEND PROPERTY
+IMPORTED_CONFIGURATIONS DEBUG)
+  set_target_properties(TIFF::TIFF PROPERTIES
+IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "C"
+IMPORTED_LOCATION_DEBUG "${TIFF_LIBRARY_DEBUG}")
+endif()
+if(EXISTS "${TIFF_LIBRARY_RELEASE}")
+  set_property(TARGET TIFF::TIFF APPEND PROPERTY
+IMPORTED_CONFIGURATIONS RELEASE)
+  set_target_properties(TIFF::TIFF PROPERTIES
+IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "C"
+IMPORTED_LOCATION_RELEASE "${TIFF_LIBRARY_RELEASE}")
+endif()
+  endif()
 endif()
 
 mark_as_advanced(TIFF_INCLUDE_DIR TIFF_LIBRARY)
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 5fd7159..a040ec0 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1367,6 +1367,10 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release
 add_subdirectory(FindOpenSSL)
   endif()
 
+  if(CMake_TEST_FindTIFF)
+add_subdirectory(FindTIFF)
+  endif()
+
   if(CMake_TEST_FindXercesC)
 add_subdirectory(FindXercesC)
   endif()
diff --git a/Tests/FindTIFF/CMakeLists.txt b/Tests/FindTIFF/CMakeLists.txt
new file mode 100644
index 000..c4e0c6a
--- /dev/null
+++ b/Tests/FindTIFF/CMakeLists.txt
@@ -0,0 +1,10 @@
+add_test(NAME FindTIFF.Test COMMAND
+  

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

[rleigh]

> On 11/30/2015 11:54 AM, rle...@codelibre.net wrote:
>> I do worry about the maintenance burden of hardcoding the information in
>> the script.
>
> I do too.  We already have to update the script for each Boost release.
> This is among the reasons the work is better integrated with upstream
> Boost instead.

I'd definitely like to see this for future Boost releases, though for
historical releases we're a bit stuck.  I'll revisit the work I pointed to
and see if I can figure out bjam/boost-build and integrate this, since it
would effectively give us CMake configuration "for free" off the back of
the autolink data, and would also come directly from the compiler so
wouldn't require parsing all the headers by hand.

>> How should this cater for dependency changes between boost releases?
>> How far back in time does this dependency information need to go?
>
> One would need to fill out tables per version and then detect the
> version to populate the info.  Just don't provide imported targets
> if the version does not have dependency info available.  If someone
> needs it they can run something to fill out the tables for their
> version and submit a patch.

I've attached an updated version of the patch which does this.  The
behaviour is otherwise identical to the earlier patches.  It's less awful
than I expected--the information for many Boost releases was the same so
it could be reduced in size significantly.  This also includes a utility
script to do the parsing, so it can be potentially used for future Boost
releases as well.  I've run the script against all versions of Boost
supported by the script, and it's verified with the unit test for some of
the components.

Just FYI, the boost components in 1.59 are as follows:

Header  Library Mismatched name
--- --- ---
archive serialization   *
archive wserialization  *
atomic  atomic
chrono  chrono
container   container
context context
coroutine2  coroutine   *
coroutine   coroutine
date_time   date_time
endian  endian
filesystem  filesystem
iostreams   iostreams
locale  locale
log date_time   (*)
log log
log log_setup
mathmath_c99*
mathmath_c99f   *
mathmath_c99l   *
mathmath_tr1*
mathmath_tr1f   *
mathmath_tr1l   *
mpi mpi
mpi mpi_python  *
program_options program_options
python  python
random  random
regex   regex
serialization   serialization
signals signals
system  system
testprg_exec_monitor*
testtest_exec_monitor   *
testunit_test_framework *
thread  thread
timer   timer
wavewave

The dependency parsing handles the case where the component library name
matches the include directory name.  For most cases, this is correct, but
there are cases marked * where it isn't.  These cases require the user to
request the appropriate component name by hand with find_package (since
the include directory name isn't a valid component name).  For most cases
we can't make the assumption since e.g. if you use  we have
no idea which serialisation library to use; and if you use  we
don't know which of the math_* libraries you /might/ use.  We have to
leave that up to the user.  Likewise for .  For these
libraries we also need to special-case the dependency info since we can't
easily get it via the headers; currently only mpi_python needed handling
in this way; the others have no dependencies.

The above isn't really a problem, it's just something to be aware of which
limits just how user-friendly we can make things.  The granularity of the
FindBoost component selection means the user will need to know which
libraries they need when they use certain headers; but this was already
the case for the variables, and is no different for the imported targets.


Regards,
Roger>From cbfb157c60ab7bdc22833db1534d1663f869ae4e Mon Sep 17 00:00:00 2001
From: Roger Leigh 
Date: Mon, 16 Nov 2015 13:21:33 +
Subject: [PATCH] FindBoost: Add imported targets

---
 Modules/FindBoost.cmake | 295 
 Tests/CMakeLists.txt|   4 +
 Tests/FindBoost/CMakeLists.txt  |  10 ++
 Tests/FindBoost/Test/CMakeLists.txt |  18 +++
 Tests/FindBoost/Test/main.cxx   |  26 
 Utilities/Boost/ScanDeps.cmake  | 156 +++
 6 files changed, 509 insertions(+)
 create mode 100644 Tests/FindBoost/CMakeLists.txt
 create mode 100644 Tests/FindBoost/Test/CMakeLists.txt
 create mode 100644 Tests/FindBoost/Test/main.cxx
 create mode 100644 Utilities/Boost/ScanDeps.cmake

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 33e6a49..a3e8474 

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

[rleigh]

> On 11/30/2015 11:26 AM, rle...@codelibre.net wrote:
>> I have improved the parsing speed somewhat and added some progress
>> diagnostics to inform the user what's happening to compensate for the
>> time
>> it takes to process the dependencies.  It's still slower than I'd
>> ideally
>> like, but it's a bit better.  If there's any way to make it even faster
>> I'd be interested.  I think what's there is technically correct though.
>
> I'm sorry I didn't have a chance to look at this sooner.
>
> Parsing dependencies out of the header files is far too heavy-weight
> for a find module.  We should memorize the known dependencies as
> is done for other find modules that provide imported targets.  If
> that is not tractable then the FindBoost module is the wrong place
> to solve this problem.

I do worry about the maintenance burden of hardcoding the information in
the script.  But if that's what's required I can look at doing this.

How should this cater for dependency changes between boost releases?
How far back in time does this dependency information need to go?

I can certainly write a script to manually trawl the headers for this
information, as done in this patch, and then embed that in FindBoost.cmake
(or put it in an ancillary script--might be easier to cater for multiple
versions this way?).

> FWIW, I think effort would be better spent working with Boost
> folks to get cmake package files provided.  They don't have to
> build with CMake to do this.  Qt5 for example builds without
> CMake but still provides CMake package files.

I already did some work towards this goal five years ago:

  https://svn.boost.org/trac/boost/ticket/1094

See the attached patches.  This was a proof of concept to introspect the
headers for generation of pkg-config files during the boost build (it uses
the compiler to dump the dependencies directly), but it could be trivially
updated for cmake configuration generation.  If I had any clue regarding
bjam internals, it would have been completed years ago, but I don't have
the expertise to integrate it to complete the task.

If there's anyone at all here who understands bjam, your help here would
be greatly appreciated by many 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-developers

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

[rleigh]

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

Regards,
Roger

0001-XercesC-Add-imported-targets-and-unit-test.patch
Description: Binary data
-- 

Powered by www.kitware.com

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

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

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

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

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

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

[rleigh]

> Thanks for working on this.  Please read through this mailing list
> thread:
>
>  IMPORTED targets for some Find modules
>  https://cmake.org/pipermail/cmake-developers/2014-June/010694.html

Done.

> On 11/16/2015 09:26 AM, Florent Castelli wrote:
>> But one there’s one thing that comes to mind. Some compiled libraries
>> have dependencies on other compiled libraries.
>> Don’t you think it would make sense to teach FindBoost about those
>> so we link everything properly?
>>
>> And also maybe add the native dependencies for some modules that
>> have one like maybe pthread or openssl.
>> Though, this might be hard to get right in a cross platform way.
>
> Please look at adding these.  The imported targets should come
> with all usage requirements as if they were provided by upstream
> Boost.  It may be tricky to get right on all platforms but if we
> do not do it then application code will have to do it instead.

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

I considered whether we would need to hardcode all the dependencies, since
some are known.  But since they can change from release to release, and we
don't know the complete set, I opted to do this automatically to ensure
it's correct (for some definition of correct) for any arbitrary Boost
release.

- This will iteratively discover all the potential dependencies for each
component via the header defines which would trigger autolinking on
Windows.  This is very aggressive and not all the discovered libraries may
be required under all circumstances, if e.g. a particular set of #defines
and headers must be used to pull in another component dependency, we will
pull it in anyway.  However, it is almost always going to link
successfully as a result.
- Any missing dependencies are automatically added to the component list
and as imported targets.

This makes linking correctly much simpler and much more transparent, as
demonstrated by the added testcase.

Problems and missing features:

- Scanning all the headers line-by-line is slow, and this is noticeable;
if I have read a file into a variable and converted it to a list, if there
was a way of filtering the list in a single pass, that would be a big
improvement.  We basically just want the #includes and library names, but
don't want to run two regexes on every line.
- I've had to special-case boost_bzip2 and boost_zlib since they don't
work under all (most?) circumstances.
- I've made boost_thread link with Thread::Thread automatically.  I'm not
a heavy user of all Boost library components, so other dependencies will
also require adding.
- Header-only components with implicit dependencies on components with
libraries are not currently handled; these could be added as imported
targets as a future improvement.
- You can now disable autolinking and enable shared libraries with
imported targets.  (Personally, I've never had autolinking work ever--it
can never find the libs!  Once the dependency discovery is fully
functional, we could potentially always disable it when using the imported
targets to give consistent linking behaviour on all platforms.)

In the mailing list thread you pointed to, there was some question over
FindBoost being compatible with the future modularised Boost libraries and
with Boost using CMake in the future.  These are reasonable concerns, but
personally I'd rather have something that works now with current and
previous Boost releases, since progress upstream is somewhat unpredictable
and leaves us in limbo waiting on them otherwise.  So long as the
modularised Boost cmake config files are compatible with the variables and
targets defined here, and to be backward compatible they would have to be,
won't they be automatically used instead of FindBoost when installed? 
Unless I'm missing something, upstream could make the modularisation
completely transparent if they care to be backward compatible with what is
already in wide use.


Regards,
Roger>From 0a15cd57d0d2924f77372b65985f5b5c0ee477c1 Mon Sep 17 00:00:00 2001
From: Roger Leigh 
Date: Mon, 16 Nov 2015 13:21:33 +
Subject: [PATCH] FindBoost: Add imported targets

---
 Modules/FindBoost.cmake | 216 
 Tests/CMakeLists.txt|   6 +-
 Tests/FindBoost/CMakeLists.txt  |  10 ++
 Tests/FindBoost/Test/CMakeLists.txt |  18 +++
 Tests/FindBoost/Test/main.cxx   |  26 +
 5 files changed, 275 insertions(+), 1 deletion(-)
 create mode 100644 Tests/FindBoost/CMakeLists.txt
 create mode 100644 Tests/FindBoost/Test/CMakeLists.txt
 create mode 100644 Tests/FindBoost/Test/main.cxx

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 33e6a49..d688734 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -54,6 +54,33 @@
 #   Boost__LIBRARY_DEBUG   - Component  

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

[rleigh]

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

If this type of patch is acceptable, I would like to do this for a number
of other modules for which I would like to be able to use so I export
generic configurations for my own libraries, including XercesC, PNG, TIFF
and a few others.  If that's OK, I'll follow up with patches for these
modules.


Regards,
Roger Leigh>From 2fd86f82b12569c990dd2befbfb82d3d8103d374 Mon Sep 17 00:00:00 2001
From: Roger Leigh 
Date: Mon, 16 Nov 2015 13:21:33 +
Subject: [PATCH] FindBoost: Add imported targets

---
 Modules/FindBoost.cmake | 58 +
 1 file changed, 58 insertions(+)

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 33e6a49..b5f5e22 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -34,6 +34,11 @@
 #information about Boost's automatic linking
 #displayed during compilation
 #
+# The following :prop_tgt:`IMPORTED` targets are also defined::
+#
+#   Boost::Boost   - Target for header-only dependencies
+#   Boost:: - Library target for specific component dependency
+#
 # This module reads hints about search locations from variables::
 #
 #   BOOST_ROOT - Preferred installation prefix
@@ -142,6 +147,14 @@
 # add_executable(foo foo.cc)
 #   endif()
 #
+# Example to find Boost libraries and use imported targets::
+#
+#   find_package(Boost 1.56 REQUIRED COMPONENTS
+#date_time filesystem system iostreams)
+#   add_executable(foo foo.cc)
+#   target_link_libraries(foo Boost::date_time Boost::filesystem
+# Boost::system Boost::iostreams)
+#
 # Example to find Boost headers and some *static* libraries::
 #
 #   set(Boost_USE_STATIC_LIBSON) # only find static libs
@@ -1222,6 +1235,51 @@ else()
 endif()
 
 # 
+#  Add imported targets
+# 
+
+if(Boost_FOUND)
+  # For header-only libraries
+  if(NOT TARGET Boost::Boost)
+add_library(Boost::Boost INTERFACE IMPORTED)
+if(Boost_INCLUDE_DIRS)
+  set_target_properties(Boost::Boost PROPERTIES
+INTERFACE_INCLUDE_DIRECTORIES "${Boost_INCLUDE_DIRS}")
+endif()
+  endif()
+
+  foreach(COMPONENT ${Boost_FIND_COMPONENTS})
+string(TOUPPER ${COMPONENT} UPPERCOMPONENT)
+if(Boost_${UPPERCOMPONENT}_FOUND)
+  add_library(Boost::${COMPONENT} UNKNOWN IMPORTED)
+  if(Boost_INCLUDE_DIRS)
+set_target_properties(Boost PROPERTIES
+  INTERFACE_INCLUDE_DIRECTORIES "${Boost_INCLUDE_DIRS}")
+  endif()
+  if(EXISTS "${Boost_${UPPERCOMPONENT}_LIBRARY}")
+set_target_properties(Boost::${COMPONENT} PROPERTIES
+  IMPORTED_LINK_INTERFACE_LANGUAGES "CXX"
+  IMPORTED_LOCATION "${Boost_${UPPERCOMPONENT}_LIBRARY}")
+  endif()
+  if(EXISTS "${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG}")
+set_property(TARGET Boost::${COMPONENT} APPEND PROPERTY
+  IMPORTED_CONFIGURATIONS DEBUG)
+set_target_properties(Boost::${COMPONENT} PROPERTIES
+  IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "CXX"
+  IMPORTED_LOCATION_DEBUG "${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG}")
+  endif()
+  if(EXISTS "${Boost_${UPPERCOMPONENT}_LIBRARY_RELEASE}")
+set_property(TARGET Boost::${COMPONENT} APPEND PROPERTY
+  IMPORTED_CONFIGURATIONS RELEASE)
+set_target_properties(Boost::${COMPONENT} PROPERTIES
+  IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "CXX"
+  IMPORTED_LOCATION_RELEASE "${Boost_${UPPERCOMPONENT}_LIBRARY_RELEASE}")
+  endif()
+endif()
+  endforeach()
+endif()
+
+# 
 #  Notification to end user about what was found
 # 
 
-- 
2.1.4
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Fragile behaviour of msbuild when using Visual Studio solution/project generators

[rleigh]

I encountered an unexpected build failure in a superbuild project today,
and after investigation with the help of ngladitz on #cmake, we got to the
bottom of the problem.

http://blogs.msdn.com/b/dsvc/archive/2012/02/29/output-from-exec-task-resulting-in-build-failure.aspx

When cmake runs an external command in the build, if that command outputs
to stdout the strings "Error:" or "error:" this will *fail the build*
irrespective of the exit status of that command (!).  Looks like a
horrible design flaw in msbuild, but the implication is that this makes
the build quite fragile since any output at all, including test output,
output from custom tools and scripts etc., can all cause a build failure.

Examples:

http://pastebin.ca/3211683 - build failure due to "Error:" and "error:"
http://pastebin.ca/3211759 - build success with the output adjusted to
remove these strings
In both these cases, the tests all pass and ctest returns a zero exit status.

The msbuild  task can use IgnoreStandardErrorWarningFormat="true" to
suppress this behaviour.  It would probably be appropriate to enable this
for all uses other than maybe compiling and linking.  We seem to use
's  rather than ; if the flag works for both
elements that would be great, but I'm afraid I'm not an expert in the
internals of msbuild and I couldn't find any obvious documentation for
.  If this could be made to ignore what's on stdout/err when
running unit tests and other non-build/link tasks that would be really
great.


Regards,
Roger

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [patch] Support debug libraries for TIFF and Xerces-C libraries

[rleigh]

 On 08/07/2015 09:59 AM, rle...@codelibre.net wrote:
 Please find attached two patches which allow these libraries to detect
 debug versions of the libraries on Windows.  I copied the behaviour from
 the PNG module as suggested on #cmake.

 Thanks.  Here are some comments:

 +if(NOT TIFF_LIBRARY)
 +  find_library(TIFF_LIBRARY_RELEASE NAMES ${TIFF_NAMES})
 +  find_library(TIFF_LIBRARY_DEBUG NAMES ${TIFF_NAMES_DEBUG})
 +  include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake)
 +  mark_as_advanced(TIFF_LIBRARY_RELEASE TIFF_LIBRARY_DEBUG)
 +endif()

 This appears to be missing a call to select_library_configurations.

Oops, yes.  I've attached an updated patch adding this.

 -# Find all XercesC libraries
 -find_library(XercesC_LIBRARY NAMES xerces-c xerces-c_3 xerces-c_2
 -  DOC Xerces-C++ libraries)
 -mark_as_advanced(XercesC_LIBRARY)
 +if(NOT XercesC_LIBRARY)
 +  # Find all XercesC libraries
 +  find_library(XercesC_LIBRARY_RELEASE
 +   NAMES xerces-c xerces-c_3
 +   DOC Xerces-C++ libraries (release))
 +  find_library(XercesC_LIBRARY_DEBUG
 +   NAMES xerces-cd xerces-c_3D xerces-c_3_1D
 +   DOC Xerces-C++ libraries (debug))
 +  include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake)
 +  select_library_configurations(XercesC)
 +  mark_as_advanced(XercesC_LIBRARY_RELEASE XercesC_LIBRARY_DEBUG)
 +endif()

 This changes the set of version numbers considered.  Please start
 with a patch to do just the debug libraries for the same version
 numbers and then add the new versions as a separate patch.

Done.  Note that this is due to how the upstream Visual Studio project
files default to building the debug libraries--for reasons only known to
themselves, the release and debug numbering scheme differs.

Regards,
Roger

0001-FindTIFF-Find-debug-libraries.patch
Description: Binary data


0001-FindXercesC-Find-debug-libraries.patch
Description: Binary data


biny1hcvwWvN0.bin
Description: Binary data
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Bug: CMakePackageConfigHelpers can't cope with empty install prefix

[rleigh]

I often configure projects with an empty install prefix and install with
DESTDIR set.  This works for most projects and they are relocatable. 
However, the configure_package_config_file function breaks if this is
done:

CMake Error at cmake/CMakePackageConfigHelpers.cmake:254 (file):
  file RELATIVE_PATH must be passed a full path to the file:
Call Stack (most recent call first):
  CMakeLists.txt:157 (configure_package_config_file)

It can't cope with this case.  It would be nice if it was able to cope
with this situation since the work it's doing is intended to make the
configuration relocatable.


Regards,
Roger Leigh

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [patch] Support debug libraries for TIFF and Xerces-C libraries

[rleigh]

Please find attached two patches which allow these libraries to detect
debug versions of the libraries on Windows.  I copied the behaviour from
the PNG module as suggested on #cmake.


Kind regards,
Roger Leigh

0001-FindTIFF-Find-debug-libraries.patch
Description: Binary data


0001-FindXercesC-Find-debug-libraries.patch
Description: Binary data
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Making and using static and shared libraries on Windows with Visual Studio

[rleigh]

It turns out this was my fault: removing the instantiation/export of

  std::char_traitschar

was sufficient to correct the linker errors.

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

[rleigh]

 Did you try to remove all the explicit template exports? I never had to do
 it and compiled many static and shared libraries on Windows. Of course VS
 is going to complain about exporting template classes but as long as you
 don't try to mix VS versions I think you can safely ingore those warnings.

Thanks for the suggestions.  The above seems true, though I think I'll
likely retain it for DLL builds and lose it for static builds.  If nothing
else it removes the warnings and will hopefully make it safer for
corner-case failures by end users of the library?  Hopefully MSVC is
clever enough to elide duplicate instantiations when it links the DLL?

Relating to CMake, the guidance from Microsoft for correctly exporting
templates here: https://support.microsoft.com/en-us/kb/168958
uses an foo_EXPORT_TEMPLATE macro in addition to foo_EXPORT.  This is
basically empty in the DLL for export, and extern for imports.  I wonder
if this is something that GenerateExportHeader should be generating in
addition to the typical export macro?


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