[Cmake-commits] CMake branch, master, updated. v3.15.4-1347-g6050eca

2019-10-08 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  6050eca0a416f8ad8278a3c4797236721aeb237a (commit)
  from  48edbb6d42f1d091d56ea21e1b57c428d9863768 (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=6050eca0a416f8ad8278a3c4797236721aeb237a
commit 6050eca0a416f8ad8278a3c4797236721aeb237a
Author: Kitware Robot 
AuthorDate: Wed Oct 9 00:01:06 2019 -0400
Commit: Kitware Robot 
CommitDate: Wed Oct 9 00:01:06 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 2580bd2..6e83c83 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 16)
-set(CMake_VERSION_PATCH 20191008)
+set(CMake_VERSION_PATCH 20191009)
 #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

[CMake] CMake and Ninja, RERUN_CMAKE useless?

2019-10-08 Thread Nagurne, James via CMake 
Hi all,

My question comes from a Ninja generator build system, and is specifically 
about an internal rule generated by cmake.
What is the purpose of the RERUN_CMAKE rule generated by CMake with a Ninja 
generator?

In the current repo, the only reference to this rule is in 
WriteTargetRebuildManifest 
here
At line 1285, the rule is written out, seemingly as-is.

According to lines 1274 to 1284, the only actual behavior of this command, 
which is executed whenever the source CMakeLists.txt file, files included from 
the CMakeLists, and some other CMake installation files change, is:
cmake -S  -B 

This seems completely insufficient for "re-running" cmake. The most obvious 
flaw is the absence of the generator. When I've seen this rule fire, my Ninja 
build system adds a useless Makefile to the build system, and then (hopefully) 
continues building as if nothing had been done at all, without so much as 
inspecting that Makefile.

What about command-line arguments like -D?

Am I missing the purpose of this rule or potentially doing something 
non-standard? The reason I send an email is because this behavior is sending my 
project into a cmake loop where it detects build.ninja is out of date, re-runs 
cmake to generate a Makefile instead of a ninja build system, and then 
infinitely repeats because it never actually re-ran anything.

Thanks,
JB
Code Generation
Texas Instruments
-- 

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] ?==?utf-8?q? ?==?utf-8?q? ?= Looking for an explanation: What exactly means "install" in cmake language

2019-10-08 Thread Cornelis Bockemühl 

After stripping down the question to "can I install an imported target"? - with 
the purpose to copy the shared libraries also into the lib directory of the 
importing project - I could actually also use Google and look for an answer 
that somebody else might have been asked.

And indeed: this seems to be a rather common question!

And the "official answer" seems to be something like "this bug is a feature". 
It must have been a change request already years ago, and it was refused with 
different arguments, like:

1) proper RPATH handling is not possible in this case, because CMake cannot 
know the way how the shared library was built initially, so it is not able to 
manipulate it.

At first this looks plausible, but then I was thinking that in Linux you always 
deal with ELF binaries, and there you have tools to manipulate RPATH/RUNPATH 
easily, and in Windows there is nothing similar - and others I don't know...

2) the target is already installed, so it makes no sense to install it again; 
it would only be a waste of disk space.

Well, in my case it would make a lot of sense, and also for any kind of 
packager that might use the install directory it would be much easier if all 
the stuff is already in one location.

3...) maybe others - I did not follow further.

In any case the conclusion is: It's like it is, and all my confusion came 
basically from this strange behaviour - that "install" is not always really 
"install" (but now I know at least when and why!). And the only way around - if 
I want to avoid the configure_file solution - would be to do some proper 
install(FILES...) instead - together with a little hacking regarding what the 
right files actually are.

Best regards, Cornelis
-- 

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.4-1346-g48edbb6

2019-10-08 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  48edbb6d42f1d091d56ea21e1b57c428d9863768 (commit)
   via  3f3dbaf90b83e595f39e84969aae21e922b64eb6 (commit)
   via  5fa1315b0382d0aa73aa624c35bbdedc7643a817 (commit)
   via  94aa511d4e888a732ef4623923d13f2ddb79d62b (commit)
   via  6bcc8c1c312ac150b8985f38a137222e4cf04d4c (commit)
   via  f356345dcfe0be0d056cfe7b2eb868bcf24be5cf (commit)
   via  dec3e9363e2ced84ef4c3a3972272c27d90a8766 (commit)
   via  9df56ece79a6267ca556fd42b904de4c1642de14 (commit)
   via  ac1a1bf18bd3d395fd17eddbc5a38e710e737664 (commit)
   via  04e5f30ad3f15d47939f5d7a8f53a7f390c6a3f5 (commit)
   via  6cecb2c3d68190c0af7e5cbf7eba3ce9f2889ae5 (commit)
   via  bfd65c11817bb1aeedeea68adf45c9325125755c (commit)
   via  f1fb63b306ad06a8931ca5a00a2b9ce9e66bc12e (commit)
   via  638fa41234fe2935a471377f8493718cd92f42c1 (commit)
  from  ab54653afd8f6671c462742dee089a2e12b2d7dc (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=48edbb6d42f1d091d56ea21e1b57c428d9863768
commit 48edbb6d42f1d091d56ea21e1b57c428d9863768
Merge: 3f3dbaf f356345
Author: Brad King 
AuthorDate: Tue Oct 8 11:26:26 2019 -0400
Commit: Brad King 
CommitDate: Tue Oct 8 11:26:26 2019 -0400

Merge branch 'release-3.16'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3f3dbaf90b83e595f39e84969aae21e922b64eb6
commit 3f3dbaf90b83e595f39e84969aae21e922b64eb6
Merge: 5fa1315 dec3e93
Author: Brad King 
AuthorDate: Tue Oct 8 11:25:54 2019 -0400
Commit: Brad King 
CommitDate: Tue Oct 8 11:25:54 2019 -0400

Merge branch 'release-3.15'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5fa1315b0382d0aa73aa624c35bbdedc7643a817
commit 5fa1315b0382d0aa73aa624c35bbdedc7643a817
Merge: 94aa511 f1fb63b
Author: Brad King 
AuthorDate: Tue Oct 8 15:24:58 2019 +
Commit: Kitware Robot 
CommitDate: Tue Oct 8 11:25:08 2019 -0400

Merge topic 'file-GENERATE-earlier'

f1fb63b306 file(GENERATE): Create output file structures even earlier

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=94aa511d4e888a732ef4623923d13f2ddb79d62b
commit 94aa511d4e888a732ef4623923d13f2ddb79d62b
Merge: 6bcc8c1 638fa41
Author: Brad King 
AuthorDate: Tue Oct 8 15:23:27 2019 +
Commit: Kitware Robot 
CommitDate: Tue Oct 8 11:23:48 2019 -0400

Merge topic 'apple-asm-deployment-target'

638fa41234 Apple: Set Clang ASM compiler features

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6bcc8c1c312ac150b8985f38a137222e4cf04d4c
commit 6bcc8c1c312ac150b8985f38a137222e4cf04d4c
Merge: ab54653 9df56ec
Author: Brad King 
AuthorDate: Tue Oct 8 15:22:47 2019 +
Commit: Kitware Robot 
CommitDate: Tue Oct 8 11:22:55 2019 -0400

Merge topic 'vs-16.4-global-targets'

9df56ece79 Merge branch 'backport-vs-16.4-global-targets'
ac1a1bf18b VS: Tell VS 16.4 not to verify CMake-provided custom command 
outputs
04e5f30ad3 VS: Tell VS 16.4 not to verify CMake-provided custom command 
outputs

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dec3e9363e2ced84ef4c3a3972272c27d90a8766
commit dec3e9363e2ced84ef4c3a3972272c27d90a8766
Merge: b21e4e4 ac1a1bf
Author: Brad King 
AuthorDate: Mon Oct 7 17:49:17 2019 -0400
Commit: Brad King 
CommitDate: Mon Oct 7 17:51:51 2019 -0400

Merge branch 'backport-vs-16.4-global-targets' into release-3.15

Merge-request: !3896


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9df56ece79a6267ca556fd42b904de4c1642de14
commit 9df56ece79a6267ca556fd42b904de4c1642de14
Merge: 04e5f30 ac1a1bf
Author: Brad King 
AuthorDate: Mon Oct 7 17:48:47 2019 -0400
Commit: Brad King 
CommitDate: Mon Oct 7 17:48:47 2019 -0400

Merge branch 'backport-vs-16.4-global-targets'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ac1a1bf18bd3d395fd17eddbc5a38e710e737664
commit ac1a1bf18bd3d395fd17eddbc5a38e710e737664
Author: Brad King 
AuthorDate: Mon Oct 7 17:35:53 2019 -0400
Commit: Brad King 
CommitDate: Mon Oct 7 17:44:32 2019 -0400

VS: Tell VS 16.4 not to verify CMake-provided custom command outputs

Extend the fix from commit 0578239d3a (VS: Tell VS 16.4 not to verify
SYMBOLIC custom command outputs, 2019-09-23, v3.15.4~2^2) to apply to
outputs in CMake-provided targets like `install`.  Simply mark these
outputs as `SYMBOLIC` too since they are not actually generated.

[Cmake-commits] CMake branch, release, updated. v3.15.4-1337-gf356345

2019-10-08 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, release has been updated
   via  f356345dcfe0be0d056cfe7b2eb868bcf24be5cf (commit)
   via  04e5f30ad3f15d47939f5d7a8f53a7f390c6a3f5 (commit)
   via  6cecb2c3d68190c0af7e5cbf7eba3ce9f2889ae5 (commit)
   via  bfd65c11817bb1aeedeea68adf45c9325125755c (commit)
   via  f1fb63b306ad06a8931ca5a00a2b9ce9e66bc12e (commit)
   via  638fa41234fe2935a471377f8493718cd92f42c1 (commit)
   via  4c29297495b53e07f61a6de1f5f689ddd6bab7bd (commit)
   via  e7ef66abd02dbd9b05358ffb09c11263f5c0fcc7 (commit)
  from  16613bc05074e6c895f6b86567f5c92111346d62 (commit)

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

- Log -
---

Summary of changes:
 Help/release/dev/0-sample-topic.rst|  7 +++
 Help/release/index.rst |  2 ++
 .../{Apple-Clang-C.cmake => Apple-Clang-ASM.cmake} |  2 +-
 Source/CMakeVersion.cmake  |  4 ++--
 Source/cmGlobalGenerator.cxx   |  9 +
 Source/cmGlobalGenerator.h |  2 --
 Source/cmLocalGenerator.cxx| 14 +-
 Source/cmLocalGenerator.h  |  1 +
 Source/cmLocalVisualStudio7Generator.cxx   |  4 
 9 files changed, 27 insertions(+), 18 deletions(-)
 create mode 100644 Help/release/dev/0-sample-topic.rst
 copy Modules/Platform/{Apple-Clang-C.cmake => Apple-Clang-ASM.cmake} (51%)


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

[CMake] cmake end user vs. developer rpath handling

2019-10-08 Thread DIXON, MARK C. 
Hi,

I install lots of software packages under Linux and, increasingly, they 
use cmake instead of other methods (congratulations!)

Frustratingly for me, I seem to keep ending up in a fight with the various 
developer's cmake config files over what rpath should be set, among other 
things. Obviously, I think I know best, so would like to know how to win 
please :)

Sometimes, this does the trick. When it does, I'm very happy:

   cmake -D CMAKE_INSTALL_RPATH="/my/rpath" source_dir

I'm currently looking at a package 
(https://github.com/PointCloudLibrary/pcl) where this has no bearing on 
the rpath of the installed software - I seem to get something set by the 
developer.

Is there a way to reliably add to, or at least override, the developer's 
rpath in any cmake-built software?

Thanks,

Mark
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS

2019-10-08 Thread Brad King via cmake-developers 
On 10/8/19 8:10 AM, Alexander wrote:
> I found that CMake ignores /DEF: option in CMAKE_SHARED_LINKER_FLAGS.
> I would like to know if this is an expected behaviour or a bug.

A module definition file can be passed as a normal source file and
CMake will automatically add `/DEF:...` to the link line as needed.

-Brad
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] extending CMAKE__LINK_EXECUTABLE

2019-10-08 Thread Fred Baksik 

On Tue, Oct 8, 2019, at 9:08 AM, Setzer Sebastian (CM-CI2/ECS2) via CMake wrote:
> Dear list,

> I need to run a tool after building an executable, which will modify the 
> executable itself.

> I intend to extend the toolchain for this, because it shall be done for every 
> executable on this particular operating system.

> 

> I think for this purpose, I need to change the rule 
> CMAKE__LINK_EXECUTABLE.

> And I think I can’t put multiple commands into that rule, so I need to write 
> a wrapper which will be called instead of the normal linker, and the calls 
> the normal linker and then that special tool.

> 

> Right, so far?

> 

> Now I’d like to pass a few additional parameters to this tool, which I’d like 
> to get from a special target property.

> 

> The rule currently looks like this:

> set(CMAKE_C_LINK_EXECUTABLE "   
>   -o  ")

> 

> And I wonder what these placeholders in angle brackets mean, and if there are 
> more placeholders available. The manual doesn’t say anything about this, 
> unfortunately:

> https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_LINK_EXECUTABLE.html

> 

> Is there, for example, a way to access arbitrary target properties?

> Or do I need to hide my special parameters somewhere in the LINK_OPTIONS 
> property?

> 

> Regards,

> Sebastian

> -- 
> 

I don't see how running arbitrary commands is possible in this way.

If you want to avoid the boilerplate of adding a post-build custom command use 
a macro that performs the add_executable() and add_custom_command(). Then use 
the macro for each of the executable.

Those markers aren't specified because it is part of implementation details of 
the Makefile (and Ninja?) generator and these items tend not to be documented 
for that reason (at least that is what I have come to understand from comments 
made on gitlab and developers mailing list).

--
Fred-- 

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] ?==?utf-8?q? ?==?utf-8?q? ?= Looking for an explanation: What exactly means "install" in cmake language

2019-10-08 Thread Cornelis Bockemühl 

Actually I implemented yesterday a way how to copy the shared libs - with 
configure_file() and a lot of frickling around with the lib names myself, like 
finding out the extension on Linux and Windows, etc.

Now I tried to include the following command in the "shlibbiConfig.cmake.in" 
file:

install(TARGETS shlibbi::SHLIBbi
    EXPORT
    shlibbi-targets
    LIBRARY DESTINATION
    ${CMAKE_INSTALL_LIBDIR})

With this, I would expect that I am not "copying files", but "installing 
targets" - so actually a more abstract and powerful level - if it works! Since 
the generated shlibbiConfig.cmake would finally run in the context of the 
importing project, i.e. during a find_package() call, it should actually 
transfer the lib files from that imported target into the CMAKE_INSTALL_LIBDIR 
of the calling project - so exactly what I need.

However, the result is an error message:
 
install TARGETS given target "shlibbi::SHLIBbi" which does not exist.
Well, it exists, because it is generated in the auto-generated 
shlibbiTargets.cmake file like this:

add_library(shlibbi::SHLIBbi SHARED IMPORTED)

and that shlibbiTargets.cmake was called inside shlibbiConfig.cmake BEFORE the 
above install(TARGETS...) call.

Conclusion: "imported targets" are not "fully valid targets", because while I 
can now refer to that imported target, like with an #include ... in my source 
code, or with a successful link to the library, but obviously I cannot 
"install" that target.

So my question can be even more specified now: Is there a way around this 
"install blockage" that would allow me to do the required transfer of the 
shared library into the lib folder of the calling project - and then even 
further also to the caller's calling project? I mean: with the effect of first 
moving libshlibbi.so to the lib directory of the shlibbu project, and then both 
the libshlibbi.so and the libshlibbu.so to the example project - of course 
including the required adaptation of the RPATH

Because that is what I learned: doing the transfer with install() instead of a 
file copy through configure_file gives me not only the more abstract level of 
project organization, but also takes care of the RPATH...

Best regards,
Cornelis

Am Dienstag, Oktober 08, 2019 14:07 CEST, cornelis  
schrieb:
 Thanks for that hint! But for me the RPATH stuff is only a supplement, because 
in the context of a Paraview based project, most of my shared libs are plugins, 
and for these PV comes with its own mechanism to find them. But then all the 
more important is the question about actually copying the libs - to a specific 
location where the plugin finding procedure finds them! Regards, Cornelis
-- 

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

2019-10-08 Thread Setzer Sebastian (CM-CI2/ECS2) via CMake 
Dear list,
I need to run a tool after building an executable, which will modify the 
executable itself.
I intend to extend the toolchain for this, because it shall be done for every 
executable on this particular operating system.

I think for this purpose, I need to change the rule 
CMAKE__LINK_EXECUTABLE.
And I think I can't put multiple commands into that rule, so I need to write a 
wrapper which will be called instead of the normal linker, and the calls the 
normal linker and then that special tool.

Right, so far?

Now I'd like to pass a few additional parameters to this tool, which I'd like 
to get from a special target property.

The rule currently looks like this:
set(CMAKE_C_LINK_EXECUTABLE"  
   -o  ")

And I wonder what these placeholders in angle brackets mean, and if there are 
more placeholders available. The manual doesn't say anything about this, 
unfortunately:
https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_LINK_EXECUTABLE.html

Is there, for example, a way to access arbitrary target properties?
Or do I need to hide my special parameters somewhere in the LINK_OPTIONS 
property?

Regards,
Sebastian
-- 

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] ?= Looking for an explanation: What exactly means "install" in cmake language

2019-10-08 Thread cornelis 
  
  
Thanks for that hint! But for me the RPATH stuff is only a supplement, because 
in   the context of a Paraview based project, most of my shared libs are 
plugins, and for these PV comes with its own mechanism to find them.
  

  
But then all the more important is the question about actually copying the libs 
- to a specific location where the plugin finding procedure finds them!
  

  
Regards, Cornelis
  

  
  

  
  
  
  
  
>   
> On 08.10.2019 at 13:10, Eric Noulardwrote:
>   
>   
>   
>
>   
>   
>   
> Le   mar. 8 oct. 2019 à   12:52, Cornelis Bockemühl   
>  a écrit   :
>   
> >  One more finding: the "magic" that QtCreator does to start example also 
> > without any additional fiddling with the RPATH: it already contains a 
> > RUNPATH, and this points to the shared library libshlibbu.so in it's build 
> > tree location, not in the installed location - and the same with 
> > libshlibbu.so.
> >   
> >  And the "install" process indeed handles the RPATH/RUNPATH: it simply 
> > removes it!
> >   
> >  Meaning: it I want to end up what I initially expected, I have to do two 
> > additional things manually (or maybe there is an automatic way??):
> >   
> >  1) copy the shared libraries to the "example" install directory tree
> >  2) add some RPATH or RUNPATH setting to all the binaries that need it
>   
>
>   
> You should read how RPATH handling is done with CMake.
>   
> see:   
> https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling
>   
>
>   
> As you already noted there is a build RPATH and an install RPATH.
>   
> The first is used when building the second replace the first after 
> installation takes place.
>   
>   
>
>  --
>   
>   
>   
>   
>   
> 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

Re: [CMake] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS

2019-10-08 Thread Alexander 
Hi Craig,
Thank you for this information. I never tried this way with the own
CMakeLists.txt and I should try it. I found one efficient workaround
however which is the option
-DCMAKE_CXX_STANDARD_LIBRARIES=/DEF:additionalDefFile.def. It turned that
the content of CMAKE_CXX_STANDARD_LIBRARIES is pushed to the linking
command without any preprocessing which is exactly what I wanted
(reference:
https://cmake.cmake.narkive.com/UuC3PGkF/how-to-append-arbitrary-linker-options).
What about stripping of the /DEF:option from CMAKE_SHARED_LINKER_FLAGS I
see I would better ask CMake developers (cmake-develop...@cmake.org) or
submit a bug.

--
Best Regards,
Alexander

On Sat, 5 Oct 2019 at 10:33, Craig Scott  wrote:

>
>
> On Sat, Oct 5, 2019 at 12:59 AM Alexander 
> wrote:
>
>> Dear Cristian,
>>
>> It would better for me not modifying CMakeFiles.txt, because as I wrote
>> it is 3rd party stuff (we just download it and build, but some different
>> way).
>> My concern is why the command line option -DCMAKE_SHARED_LINKER_FLAGS
>> deliberately ignores /DEF: option. It this behavior expected? What is the
>> logic behind this behavior? Why not simply allow /DEF in
>> CMAKE_SHARED_LINKER_FLAGS and not cut it?
>>
>
>
> You don't have to modify the third party CMakeLists.txt file to achieve
> what Cristian suggested. You can call target_sources() on the third party
> target from your own CMakeLists.txt file to add .def files to their
> target. You don't have to be in the same directory scope as the target to
> use target_sources() on it.
>
> I'm not familiar with why CMake is stripping out the /DEF: option in your
> case, but I suspect it would be related to the way CMake expects to add
> such options based on .def files given as sources.
>
>
>
>> On Fri, 4 Oct 2019 at 16:54, Cristian Adam 
>> wrote:
>>
>>> Hi,
>>>
>>> You should simply add the my_defs.def file as a source files to
>>> add_library/add_executable.
>>> CMake will automagically pass /DEF: to the linker with my_defs.def
>>>
>>> Cheers,
>>> Cristian.
>>>
>>> On Fri, Oct 4, 2019 at 4:45 PM Alexander 
>>> wrote:
>>>
 Hello,

 I would like to add an extra .defs file for linking of a DLL on
 Windows. I want to use the CMake command line option
 -DCMAKE_SHARED_LINKER_FLAGS="/DEF:my_defs.defs". I expect that besides the
 automatically generated
 /bin/.dir/Release/exports.def i see additionally
 /DEF:my_defs.defs in the resulting linking command, but it does not happen.

 What is especially irritating that CMake deliberately removes namely
 /DEF: from CMAKE_SHARED_LINKER_FLAGS. Any other word combinations (if I
 write  /DEF111:my_defs.def for example) are accepted and I see them the
 linking command.

 I tried to reach the same goal using a CMakeLists.txt like this:

 set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /DEF:my_defs.def")

 but it did not help - the same way CMake removes my /DEF: option.

 Could you please open a ticket to fix this behavior to not cut /DEF:
 option from CMAKE_***_LINKER_FLAGS?

 On my opinion CMake should not interpret or modify the content of
 CMAKE_SHARED_LINKER_FLAGS value, but should put it entirely as the user
 specified it. If you have another opinion, please provide any other
 possibility to pass an arbitrary arguments to the linking command "as is"
 so that they are not modified.

 Any workaround is highly appreciated (better command-line, because we
 build 3rd party software and it would not really fine to change
 CMakeLists.txt)

 --
 Best Regards,
 Alexander Samoilov
 Build & Integration Engineer
 Compart AG, 71034 Böblingen Germany

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

Re: [CMake] ?= Looking for an explanation: What exactly means "install" in cmake language

2019-10-08 Thread Eric Noulard 
Le mar. 8 oct. 2019 à 12:52, Cornelis Bockemühl  a
écrit :

> One more finding: the "magic" that QtCreator does to start example also
> without any additional fiddling with the RPATH: it already contains a
> RUNPATH, and this points to the shared library libshlibbu.so in it's build
> tree location, not in the installed location - and the same with
> libshlibbu.so.
>
> And the "install" process indeed handles the RPATH/RUNPATH: it simply
> removes it!
>
> Meaning: it I want to end up what I initially expected, I have to do two
> additional things manually (or maybe there is an automatic way??):
>
> 1) copy the shared libraries to the "example" install directory tree
> 2) add some RPATH or RUNPATH setting to all the binaries that need it
>

You should read how RPATH handling is done with CMake.
see:
https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling

As you already noted there is a build RPATH and an install RPATH.
The first is used when building the second replace the first after
installation takes place.

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

Re: [CMake] ?==?utf-8?q? ?==?utf-8?q? ?= Looking for an explanation: What exactly means "install" in cmake language

2019-10-08 Thread Cornelis Bockemühl 

One more finding: the "magic" that QtCreator does to start example also without 
any additional fiddling with the RPATH: it already contains a RUNPATH, and this 
points to the shared library libshlibbu.so in it's build tree location, not in 
the installed location - and the same with libshlibbu.so.

And the "install" process indeed handles the RPATH/RUNPATH: it simply removes 
it!

Meaning: it I want to end up what I initially expected, I have to do two 
additional things manually (or maybe there is an automatic way??):

1) copy the shared libraries to the "example" install directory tree
2) add some RPATH or RUNPATH setting to all the binaries that need it

Regards, Cornelis
-- 

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] ?==?utf-8?q? ?==?utf-8?q? ?= Looking for an explanation: What exactly means "install" in cmake language

2019-10-08 Thread Cornelis Bockemühl 

The missing link to my "cmake teacher web page": 
https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/

Regards, Cornelis
-- 

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