Re: [CMake] set_target_properties ( INTERFACE_INCLUDE_DIRECTORIES ...)

2019-09-12 Thread Theodore Hall 
On Thu, Sep 12, 2019 at 6:31 PM Craig Scott  wrote:

OPTION A: Put quotes around a semi-colon separated string if using
> set_target_properties():
>

Many thanks.  I had tried quotes, and I had tried a semi-colon, and I
thought that I had tried them together, but evidently I missed that
permutation.

I'm actually sticking with OPTION B anyway -- it seems cleaner.  But I was
mystified looking for OPTION A.

-- 

Ted Hall
-- 

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

[Cmake-commits] CMake branch, master, updated. v3.15.3-1015-g729c928

2019-09-12 Thread Kitware Robot via Cmake-commits 
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  729c928c7b59919a9d379891973bda22665c75da (commit)
  from  9602bcfc62d50d7bb302b02ae3b1f9afe941bae7 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=729c928c7b59919a9d379891973bda22665c75da
commit 729c928c7b59919a9d379891973bda22665c75da
Author: Kitware Robot 
AuthorDate: Fri Sep 13 00:01:11 2019 -0400
Commit: Kitware Robot 
CommitDate: Fri Sep 13 00:01:11 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index fc86b56..e9cca30 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 15)
-set(CMake_VERSION_PATCH 20190912)
+set(CMake_VERSION_PATCH 20190913)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

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


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

Re: [CMake] set_target_properties ( INTERFACE_INCLUDE_DIRECTORIES ...)

2019-09-12 Thread Craig Scott 
On Fri, Sep 13, 2019 at 8:24 AM Theodore Hall  wrote:

> Greetings,
>
>   set_target_properties(target PROPERTIES
> IMPORTED_LOCATION location
> IMPORTED_IMPLIB implib
> INTERFACE_INCLUDE_DIRECTORIES directory+
>   )
>
> Is there a way to assign more than one directory to
> INTERFACE_INCLUDE_DIRECTORIES ?  The property name is plural, but every
> attempt I've made to specify more than one directory has failed.  CMake
> complains that either: I've passed the wrong number of arguments; or
> concatenates all of them into one path which of course doesn't exist.
>

> I've found a work-around using
>
>   target_include_directories (target
> INTERFACE directory1
> INTERFACE directory2
>   )
>
> It just seems odd that a property with a plural name accepts only a
> singular value.  I feel like I'm missing something.  I've tried wrapping
> multiple directories in various kinds of brackets and quotes and separating
> them with ; or , instead of whitespace.  (This is Windows, so : isn't a
> path separator; the system PATH variable uses ; as the separator.)
>


OPTION A: Put quotes around a semi-colon separated string if using
set_target_properties():

set_target_properties(target PROPERTIES
IMPORTED_LOCATION location
IMPORTED_IMPLIB implib
INTERFACE_INCLUDE_DIRECTORIES "directory1;directory2"
  )

OPTION B: List multiple directories after just one INTERFACE keyword if
using target_include_directories():

  target_include_directories (target
INTERFACE directory1 directory2
  )

Either option should work for all platforms, but note that option A will
overwrite any previous contents of INTERFACE_INCLUDED_DIRECTORIES whereas
option B will append to any previous contents. For that reason, I'd
generally recommend option B.

>
-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide 
Consulting services (CMake, C++, build/release processes):
https://crascit.com/services
-- 

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

[CMake] set_target_properties ( INTERFACE_INCLUDE_DIRECTORIES ...)

2019-09-12 Thread Theodore Hall 
Greetings,

  set_target_properties(target PROPERTIES
IMPORTED_LOCATION location
IMPORTED_IMPLIB implib
INTERFACE_INCLUDE_DIRECTORIES directory+
  )

Is there a way to assign more than one directory to
INTERFACE_INCLUDE_DIRECTORIES ?  The property name is plural, but every
attempt I've made to specify more than one directory has failed.  CMake
complains that either: I've passed the wrong number of arguments; or
concatenates all of them into one path which of course doesn't exist.

I've found a work-around using

  target_include_directories (target
INTERFACE directory1
INTERFACE directory2
  )

It just seems odd that a property with a plural name accepts only a
singular value.  I feel like I'm missing something.  I've tried wrapping
multiple directories in various kinds of brackets and quotes and separating
them with ; or , instead of whitespace.  (This is Windows, so : isn't a
path separator; the system PATH variable uses ; as the separator.)

Thanks for any enlightenment.

-- 

Ted Hall
-- 

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

[CMake] compile_commands.json question

2019-09-12 Thread 15 knots 
Hi all,

this is more a question to the cmake developers.

Older versions (3.15.0) of cmake produced short file names w/o spaces
on windows, when the path of the compiler executable contained spaces.
Now I have an issue [1] where compiler executable path contains spaces
with cmake 3.15.2.
Can anyone confirm whether the spaces are caused by changes made to
cmake after version 3.15.0?
Or could a user-supplied toolchain file cause the spaces?

Kind regards,
 Martin



[1] https://github.com/15knots/cmake4eclipse/issues/119#issuecomment-528716815
-- 

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] Setting RPATH lookup on macOS

2019-09-12 Thread Juan Sanchez 
I never suggested copying files into the build tree.  The original
question was about how to locate libraries at runtime.  You don't
necessarily have to use @rpath, @executable_path is also a valid
option.  Another valid option one is to strip out @rpath and use
DYLD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH.

If you want to set an rpath from cmake, you can also use target properties like:
INSTALL_RPATH
BUILD_WITH_INSTALL_RPATH

where BUILD_WITH_INSTALL_RPATH is useful if you don't want to use
CMake's install system.

Regards,

Juan

On Thu, Sep 12, 2019 at 10:56 AM Michael Jackson
 wrote:
>
> On macOS you really should _not_ have to copy the libraries into the build 
> tree. I have never had to do that in 10 years of our product (Windows is a 
> different story). The trick is setting the correct options to add in the 
> paths to the libraries into the RPATH of the executable/library. (at least on 
> macOS & Linux systems).
>
>
>
> --
>
> Mike Jackson
>
>
>
>
>
> From: Juan Sanchez 
> Date: Thursday, September 12, 2019 at 11:35 AM
> To: Michael Jackson 
> Cc: CMake 
> Subject: Re: [CMake] Setting RPATH lookup on macOS
>
>
>
> The macOS install_name_tool can be used to change the RPATH of your binaries. 
>  It can also be used to set the path for each of the libraries to be loaded.  
> For a python module I compile, I copy each of its dylib into the appropriate 
> directory relative to my shared library.  I then use the install_name_tool to 
> change from an absolute path to a path relative to @loader_path.
>
>
>
> install_name_tool -change $j "@loader_path/../gcc/`basename $j`" $i
>
> where $j is the full path output from "otool -L" and "@loader_path/../gcc" 
> would point to a directory "gcc" relative to the directory containing my 
> python module.
>
> For a binary executable, I would explore placing required dylib files into a 
> directory relative to @executable_path.
>
> Regards,
>
>
>
> Juan
>
>
>
> On Wed, Sep 11, 2019 at 4:33 PM Michael Jackson  
> wrote:
>
> Already looked on google and at the CMake documentation but everything listed 
> does not seem to work so here is the setup.
>
> I am using MKL and I have a home grown FindMKL since there isn’t an official 
> one. Inside that is the typical find_library() calls which will find the 
> libraries just fine. One of those libraries is a dynamic library (.dylib). 
> Using otool -L on that library the install_name is encoded as @rpath.
>
> Now I have my add_executable(foo…) and target_link_libraries (Foo 
> ${MKL_LIBRARIES} ).
>
> Everything compiles and links fine. The issue is at runtime. The app will not 
> launch because libmkl_rt.dylib is not loaded because the path to that library 
> is not encoded into the executable.
>
> 639:[mjackson@ferb:ifort-release]$ otool -l 
> Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
>  name @rpath/libEbsdLib.dylib (offset 24)
>  name @rpath/libmkl_rt.dylib (offset 24)
>  name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset 24)
>  name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset 24)
>  name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent (offset 
> 24)
>  name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset 24)
>  name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
>  name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
>  path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib (offset 
> 12)
>  path /Users/Shared/EMsoft_SDK-ifort/Qt5.12.3/5.12.3/clang_64/lib 
> (offset 12)
>
>
> Oddly the Qt libraries and one of my own libraries do get their rpaths 
> encoded. I feel like I need to append to the RPATH that gets encoded into the 
> executable but I am not really figuring out how to do that.
>
> Help
>
> --
> Michael Jackson | Owner, President
>   BlueQuartz Software
> [e] mike.jack...@bluequartz.net
> [w] www.bluequartz.net 
>
>
> --
>
> 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
-- 

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

Re: [CMake] Setting RPATH lookup on macOS

2019-09-12 Thread Michael Jackson 
On macOS you really should _not_ have to copy the libraries into the build 
tree. I have never had to do that in 10 years of our product (Windows is a 
different story). The trick is setting the correct options to add in the paths 
to the libraries into the RPATH of the executable/library. (at least on macOS & 
Linux systems).

 

--

Mike Jackson

 

 

From: Juan Sanchez 
Date: Thursday, September 12, 2019 at 11:35 AM
To: Michael Jackson 
Cc: CMake 
Subject: Re: [CMake] Setting RPATH lookup on macOS

 

The macOS install_name_tool can be used to change the RPATH of your binaries.  
It can also be used to set the path for each of the libraries to be loaded.  
For a python module I compile, I copy each of its dylib into the appropriate 
directory relative to my shared library.  I then use the install_name_tool to 
change from an absolute path to a path relative to @loader_path.

 

install_name_tool -change $j "@loader_path/../gcc/`basename $j`" $i
where $j is the full path output from "otool -L" and "@loader_path/../gcc" 
would point to a directory "gcc" relative to the directory containing my python 
module.

For a binary executable, I would explore placing required dylib files into a 
directory relative to @executable_path.

Regards,

 

Juan


 

On Wed, Sep 11, 2019 at 4:33 PM Michael Jackson  
wrote:

Already looked on google and at the CMake documentation but everything listed 
does not seem to work so here is the setup.

I am using MKL and I have a home grown FindMKL since there isn’t an official 
one. Inside that is the typical find_library() calls which will find the 
libraries just fine. One of those libraries is a dynamic library (.dylib). 
Using otool -L on that library the install_name is encoded as @rpath. 

Now I have my add_executable(foo…) and target_link_libraries (Foo 
${MKL_LIBRARIES} ).

Everything compiles and links fine. The issue is at runtime. The app will not 
launch because libmkl_rt.dylib is not loaded because the path to that library 
is not encoded into the executable.

639:[mjackson@ferb:ifort-release]$ otool -l 
Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
 name @rpath/libEbsdLib.dylib (offset 24)
 name @rpath/libmkl_rt.dylib (offset 24)
 name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset 24)
 name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset 24)
 name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent (offset 24)
 name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset 24)
 name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
 name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
 path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib (offset 12)
 path /Users/Shared/EMsoft_SDK-ifort/Qt5.12.3/5.12.3/clang_64/lib 
(offset 12)


Oddly the Qt libraries and one of my own libraries do get their rpaths encoded. 
I feel like I need to append to the RPATH that gets encoded into the executable 
but I am not really figuring out how to do that.

Help

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net 


-- 

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

-- 

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] Setting RPATH lookup on macOS

2019-09-12 Thread Juan Sanchez 
The macOS install_name_tool can be used to change the RPATH of your
binaries.  It can also be used to set the path for each of the libraries to
be loaded.  For a python module I compile, I copy each of its dylib into
the appropriate directory relative to my shared library.  I then use the
install_name_tool to change from an absolute path to a path relative to
@loader_path.

install_name_tool -change $j "@loader_path/../gcc/`basename $j`" $i
where $j is the full path output from "otool -L" and "@loader_path/../gcc"
would point to a directory "gcc" relative to the directory containing my
python module.

For a binary executable, I would explore placing required dylib files into
a directory relative to @executable_path.

Regards,

Juan



On Wed, Sep 11, 2019 at 4:33 PM Michael Jackson 
wrote:

> Already looked on google and at the CMake documentation but everything
> listed does not seem to work so here is the setup.
>
> I am using MKL and I have a home grown FindMKL since there isn’t an
> official one. Inside that is the typical find_library() calls which will
> find the libraries just fine. One of those libraries is a dynamic library
> (.dylib). Using otool -L on that library the install_name is encoded as
> @rpath.
>
> Now I have my add_executable(foo…) and target_link_libraries (Foo
> ${MKL_LIBRARIES} ).
>
> Everything compiles and links fine. The issue is at runtime. The app will
> not launch because libmkl_rt.dylib is not loaded because the path to that
> library is not encoded into the executable.
>
> 639:[mjackson@ferb:ifort-release]$ otool -l
> Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
>  name @rpath/libEbsdLib.dylib (offset 24)
>  name @rpath/libmkl_rt.dylib (offset 24)
>  name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset 24)
>  name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset 24)
>  name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent
> (offset 24)
>  name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset 24)
>  name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
>  name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
>  path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib
> (offset 12)
>  path /Users/Shared/EMsoft_SDK-ifort/Qt5.12.3/5.12.3/clang_64/lib
> (offset 12)
>
>
> Oddly the Qt libraries and one of my own libraries do get their rpaths
> encoded. I feel like I need to append to the RPATH that gets encoded into
> the executable but I am not really figuring out how to do that.
>
> Help
>
> --
> Michael Jackson | Owner, President
>   BlueQuartz Software
> [e] mike.jack...@bluequartz.net
> [w] www.bluequartz.net 
>
>
> --
>
> 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
>
-- 

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

[Cmake-commits] CMake branch, master, updated. v3.15.3-1014-g9602bcf

2019-09-12 Thread Kitware Robot via Cmake-commits 
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  9602bcfc62d50d7bb302b02ae3b1f9afe941bae7 (commit)
   via  1a1508c8b840ae016dc8db9da6be4cbe59d5f1aa (commit)
   via  d83bff86409c0e414046d2aeb75946037e0d2de3 (commit)
   via  a3cfb66543d307e644e4df207f2e1305200ced02 (commit)
   via  d25a5a7ec91bfa072d3cf1a302830a54506c88c0 (commit)
   via  8a18bb7cdf2478d68e11a5e532b5134ea92b3678 (commit)
  from  5bdff304847995f474797b757fe7a2755de0c1fb (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9602bcfc62d50d7bb302b02ae3b1f9afe941bae7
commit 9602bcfc62d50d7bb302b02ae3b1f9afe941bae7
Merge: 1a1508c a3cfb66
Author: Brad King 
AuthorDate: Thu Sep 12 13:15:31 2019 +
Commit: Kitware Robot 
CommitDate: Thu Sep 12 09:16:56 2019 -0400

Merge topic 'compile-msvc-permissive-off'

a3cfb66543 Add compatibility with the cl.exe /permissive- compiler option

Acked-by: Kitware Robot 
Merge-request: !3803


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1a1508c8b840ae016dc8db9da6be4cbe59d5f1aa
commit 1a1508c8b840ae016dc8db9da6be4cbe59d5f1aa
Merge: d83bff8 d25a5a7
Author: Brad King 
AuthorDate: Thu Sep 12 13:15:09 2019 +
Commit: Kitware Robot 
CommitDate: Thu Sep 12 09:15:38 2019 -0400

Merge topic 'modernize-use-auto'

d25a5a7ec9 clang-tidy: modernize-use-auto

Acked-by: Kitware Robot 
Merge-request: !3783


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d83bff86409c0e414046d2aeb75946037e0d2de3
commit d83bff86409c0e414046d2aeb75946037e0d2de3
Merge: 5bdff30 8a18bb7
Author: Brad King 
AuthorDate: Thu Sep 12 13:14:38 2019 +
Commit: Kitware Robot 
CommitDate: Thu Sep 12 09:14:48 2019 -0400

Merge topic 'free-find-commands'

8a18bb7cdf cmFind*: Port away from cmCommand

Acked-by: Kitware Robot 
Merge-request: !3800


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3cfb66543d307e644e4df207f2e1305200ced02
commit a3cfb66543d307e644e4df207f2e1305200ced02
Author: Alexej Harm 
AuthorDate: Wed Sep 11 15:26:20 2019 +0200
Commit: Alexej Harm 
CommitDate: Wed Sep 11 15:26:20 2019 +0200

Add compatibility with the cl.exe /permissive- compiler option

diff --git a/Source/cmUVStreambuf.h b/Source/cmUVStreambuf.h
index 873352b..0737629 100644
--- a/Source/cmUVStreambuf.h
+++ b/Source/cmUVStreambuf.h
@@ -61,7 +61,7 @@ public:
   cmBasicUVStreambuf* close();
 
 protected:
-  typename cmBasicUVStreambuf::int_type underflow() override;
+  typename cmBasicUVStreambuf::int_type underflow() override;
   std::streamsize showmanyc() override;
 
   // FIXME: Add write support
diff --git a/Utilities/Release/WiX/CustomAction/detect_nsis_overwrite.cpp 
b/Utilities/Release/WiX/CustomAction/detect_nsis_overwrite.cpp
index 4b17875..593822a 100644
--- a/Utilities/Release/WiX/CustomAction/detect_nsis_overwrite.cpp
+++ b/Utilities/Release/WiX/CustomAction/detect_nsis_overwrite.cpp
@@ -10,7 +10,8 @@ std::wstring get_property(MSIHANDLE msi_handle, std::wstring 
const& name)
 {
   DWORD size = 0;
 
-  UINT status = MsiGetPropertyW(msi_handle, name.c_str(), L"", );
+  WCHAR value_buffer[] = L"";
+  UINT status = MsiGetPropertyW(msi_handle, name.c_str(), value_buffer, );
 
   if (status == ERROR_MORE_DATA) {
 std::vector buffer(size + 1);

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d25a5a7ec91bfa072d3cf1a302830a54506c88c0
commit d25a5a7ec91bfa072d3cf1a302830a54506c88c0
Author: Regina Pfeifer 
AuthorDate: Wed Sep 4 22:17:22 2019 +0200
Commit: Regina Pfeifer 
CommitDate: Tue Sep 10 22:21:41 2019 +0200

clang-tidy: modernize-use-auto

Set the MinTypeNameLength option to an impossibly high value in order
to limit the diagnostics to iterators.  Leave new expressions and cast
expressions for later.

diff --git a/.clang-tidy b/.clang-tidy
index a6378e0..a240e9c 100644
--- a/.clang-tidy
+++ b/.clang-tidy
@@ -12,7 +12,6 @@ misc-*,\
 modernize-*,\
 -modernize-avoid-c-arrays,\
 -modernize-deprecated-headers,\
--modernize-use-auto,\
 -modernize-use-nodiscard,\
 -modernize-use-noexcept,\
 -modernize-use-transparent-functors,\
@@ -33,4 +32,6 @@ CheckOptions:
 value: '1'
   - key:   modernize-use-equals-default.IgnoreMacros
 value: '0'
+  - key:   modernize-use-auto.MinTypeNameLength
+value: '80'
 ...
diff --git a/Source/CPack/IFW/cmCPackIFWGenerator.cxx 
b/Source/CPack/IFW/cmCPackIFWGenerator.cxx
index d1ffcef..94530c1 100644
--- a/Source/CPack/IFW/cmCPackIFWGenerator.cxx
+++ b/Source/CPack/IFW/cmCPackIFWGenerator.cxx
@@ -77,8 +77,7 @@ int cmCPackIFWGenerator::PackageFiles()
 
 if

Re: [CMake] Packaging a directory with CPack RPM

2019-09-12 Thread Eric Noulard 
Le jeu. 12 sept. 2019 à 02:27, Ashish Sadanandan <
ashish.sadanan...@gmail.com> a écrit :

> Hello,
> I'm using CPack to create RPMs for an application. I have this working but
> the CPack step is quite slow. While investigating this, I noticed that all
> files in a directory I'm packaging, which contains a large number of small
> files, is being listed in the spec file.
>
> For instance, say I have
>
> set(CPACK_PACKAGING_INSTALL_PREFIX /opt/myapp)
> install(DIRECTORY ${CMAKE_BINARY_DIR}/myapp/foo
> DESTINATION foo
> COMPONENT myapp
> )
>
> In the %files section I see
>
> %files
> %dir /opt/myapp/foo
> " /opt/myapp/foo/file1"
> " /opt/myapp/foo/file2"
> ...
> " /opt/myapp/foo/file6"
>
> If I were writing the spec file by hand, this entire section could be
> replaced by a single line
>
> %files
> /opt/myapp/foo
>

CPack has no idea that the list of files are coming from an installed
*directory*, because CPack is not doing the install CMake is.
Thus CPackRPM and other CPack generators collect all installed bits inside
a given [temporary] prefix directory.

Now may be you can tell CPack to ignore some of you installed
files/directory by using: CPACK_RPM_USER_FILELIST

https://cmake.org/cmake/help/v3.15/cpack_gen/rpm.html#cpack_gen:CPack%20RPM%20Generator



> RPM will package all files within the directory if you specify the
> directory under %files (
> http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html - the
> "The %dir Directive" section)
> Is there an option to list just the directory instead of recursively
> listing all contained files within the directory?
>

AFAIK, No there is not.


I'm not claiming this is the reason for CPack being slow, I came across
> this while investigating performance and if nothing else, this will result
> in a cleaner looking spec file.
>

For performance sake you can
try CPACK_RPM_USER_BINARY_SPECFILE,
CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE
and handcraft your "user" spec file in order to see if it helps the
packaging performance.
and/or you can set CPACK_RPM_PACKAGE_DEBUG to 1 in order to get more timed
traces of CPackRPM execution.


-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] can not import target external lib before being build

2019-09-12 Thread Stéphane Ancelot 

Hi,

I am using this cmake snippet in order to build an external library


# -- QGLViewer --
set(QGLVIEWER_FILES 
${CMAKE_BINARY_DIR}/libQGLViewer-2.7.1/QGLViewer/qglviewer.h)


get_target_property (QT_QMAKE_EXECUTABLE Qt5::qmake IMPORTED_LOCATION)

add_custom_command(OUTPUT ${QGLVIEWER_FILES}
  COMMAND  tar xzf 
"${CMAKE_CURRENT_SOURCE_DIR}/libQGLViewer-2.7.1.tar.gz" --strip 1

  COMMAND ${QT_QMAKE_EXECUTABLE} -o QMakefile
  COMMAND make -f QMakefile
#  COMMAND ${CMAKE_COMMAND} -E touch ${LIBFOO_TAR_HEADERS}
  WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/libQGLViewer-2.7.1"
  DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/libQGLViewer-2.7.1.tar.gz"
  COMMENT "Unpacking libQGLViewer-2.7.1.tar.gz"
  VERBATIM
)

add_custom_target(qglviewer_untar DEPENDS ${QGLVIEWER_FILES})

add_library(qglviewer SHARED IMPORTED)
add_dependencies(qglviewer qglviewer_untar)

# link qglviewer
set_target_properties(qglviewer PROPERTIES
  IMPORTED_LOCATION 
"${CMAKE_CURRENT_BINARY_DIR}/libQGLViewer-2.7.1/QGLViewer/libQGLViewer-qt5.so"
  INTERFACE_INCLUDE_DIRECTORIES 
"${CMAKE_CURRENT_BINARY_DIR}/libQGLViewer-2.7.1")



Unfortunately, cmake replies with the next error when configuring :


CMake Error in API_COLLISION/CMakeLists.txt:
  Imported target "qglviewer" includes non-existent path

"/tmp/OK/BASE_SILFAX_SAFETY/build/API_COLLISION/libQGLViewer-2.7.1"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.



CMake Error in API_COLLISION/CMakeLists.txt:
  Imported target "qglviewer" includes non-existent path

"/tmp/OK/BASE_SILFAX_SAFETY/build/API_COLLISION/libQGLViewer-2.7.1"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.




-- 

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