[Cmake-commits] CMake branch, master, updated. v3.14.1-609-g52fb35b

2019-04-04 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  52fb35bd69ec2fa1a5307695cb22c3f125debf4f (commit)
  from  8c28e63cb4da99dbb894573a996c27e260b5baeb (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=52fb35bd69ec2fa1a5307695cb22c3f125debf4f
commit 52fb35bd69ec2fa1a5307695cb22c3f125debf4f
Author: Kitware Robot 
AuthorDate: Fri Apr 5 00:01:07 2019 -0400
Commit: Kitware Robot 
CommitDate: Fri Apr 5 00:01:07 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 3ba392e..f4dacb4 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 14)
-set(CMake_VERSION_PATCH 20190404)
+set(CMake_VERSION_PATCH 20190405)
 #set(CMake_VERSION_RC 1)

---

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] Setting permissions with CPack/WiX installer

2019-04-04 Thread Cook, Steven (G)
Hi all,

I would like to set the permissions on some files and directories in my WiX 
installer. It looks like the CPACK_WIX_ACL property should be suitable, but I 
can't get it to work. There are examples of its usage in this project:
https://github.com/ngladitz/cmake-wix-testsuite/tree/master/properties

Typically something like this:
  set_property(INSTALL
empty_directory_with_property
non_empty_directory_with_property
PROPERTY CPACK_WIX_ACL "Everyone=GenericRead,GenericWrite,CreateFile"
  )

but this example doesn't work for me with cmake 3.14.0. None of the .wxs files 
that are produced contain the expected Permission property. After adding some 
debugging to cmake, I found that 
cmCPackWIXGenerator::AddDirectoryAndFileDefinitions calls GetInstalledFile, 
which always returns NULL. This prevents the ACL from being applied.

As an alternative, I've tried to use CPACK_WIX_PATCH_FILE to specify the 
Permission property for the relevant fragments, but the patch does not get 
applied to the fragments where directories are created. In any case, I think 
CPACK_WIX_ACL would be preferable if I could get it to work.

Can anyone provide a minimal working example that uses CPACK_WIX_ACL?

Thanks
Steve
-- 

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] Eclipse generator question

2019-04-04 Thread Benjamin Shadwick
Ah, it seems my CMake is too old to produce compile_commands.json. Maybe
this is part of why other IDEs are working better at home on Ubuntu MATE
LTS.

Unfortunately Red Hat ships CMake 2.8.12.2 even in recent RHEL releases,
which is now approaching 5 years old (yikes!). Apparently they ship CMake
3.13.4 as a 'cmake3' package and I didn't catch it - will see if I can
upgrade at least some of my machines.

On Thu, Apr 4, 2019 at 2:07 PM Martin Weber 
wrote:

> Am Mittwoch, 3. April 2019, 23:52:38 CEST schrieben Sie:
> > On Wed, Apr 3, 2019 at 2:18 PM Martin Weber 
> >
> > wrote:
> > > Am Mittwoch, 3. April 2019, 22:26:59 CEST schrieb Benjamin Shadwick:
> > > > I tried cmake4eclipse, and it's a mixed bag. It requires a lot of
> > >
> > > tweaking
> > >
> > > Really? Just set _CMake Builder (portable)_ as the current builder and
> > > build.
> >
> > It required a lot more tweaking than that for an out of source build,
>
> cmake4eclipse enforces out of source build by default, with the build
> directory below project root.
>
> > including manually enabling the CMAKE includes and defines providers.
>
> cmake4eclipse is not a tool to configure your project. Aside from that,
> the
> CDT API does not allow to fully configure a project programatically.
>
> >
> > > > of the Eclipse project after you create it, and I'm pretty sure it
> > >
> > > suffers
> > >
> > > > from the same problem of leaving you with an Eclipse project whose
> > > > source
> > > > tree reflects what is in the filesystem rather than what is defined
> in
> > >
> > > the
> > >
> > > > CMake project.
> > >
> > > What does that mean: _an Eclipse project whose source tree reflects
> what
> > > is in
> > > the filesystem rather than what is defined in the CMake project._ ??
> >
> > This is exactly what I'm getting at: People have marinated so much in the
> > way Eclipse works by default that what I'm saying sounds like a non
> > sequitur.
> >
> > I'll try to explain:
> > - I have a repository with a large source tree that contains hundreds of
> > leaf directories.
> > - Each leaf directory contains source that needs to be built into a
> shared
> > library or an executable binary.
> > - The source tree contains a superset of the functionality that is needed
> > by all configurations.
> > - Any particular configuration of the CMake project will result in only a
> > subset of the libraries and/or binaries being built.
> > - The subset being built is defined via CMake option() commands that set
> > (or don't) cache variables that control which subdirectories are added to
> > the CMake project.
> >
> > What I want from Eclipse:
> > - Only show in the project tree and Open Resource dialog the subset of
> > source files that belong to the current configuration of the CMake
> project,
> > so that developers don't get confused about what is relevant or not to
> the
> > configuration of CMake they are working in.
> > - Only index the subset of source files that belong to the current
> > configuration of the CMake project, so that resources are not wasted
> > indexing irrelevant sources, and so that developers are not flooded with
> > irrelevant indexer errors.
> > - Show header files that are assigned to a target, including custom
> > header-only targets ("custom_target(... SOURCES)"), as is done by other
> > IDEs.
> >
> > > If the IDE indexing all source files takes too long, I would say it is
> a
> > > problem with the IDE; but not a problem of cmake's IDE project
> generator
> > > (as
> > > the topic states).
> >
> > Time is only one aspect (see above), although it's particularly bad with
> > the out-of-box Eclipse project generated by CMake's default settings
> > because it indexes every source file 3 times.
>
> Well, that's CDT. If you press 'Apply and Close' in the project property
> dialog, if write the file 2 times to disk :-[
>
> >
> > > That's the only way to go in your case. How should the CDT4 project
> > > generator
> > > know about all your source files that do not take part in a build?
> >
> > The point I'm trying to make is that I *don't* want Eclipse to know about
> > source files that are *not* being built, but it *does* know about them
> > because all solutions (CMake generator, cmake4eclipse) just point Eclipse
> > at the source tree *in the filesystem*, and not at the conceptual project
> > tree defined via the CMakeLists.txt hierarchy. Remember that for me, the
>
> OK, I see your point. CDT indeed has no concept of 'conceptual project
> tree'
> as you name it.
> But it has filters for files in the source tree! And these seem to operate
> on
> a per-configuration-base.
> And cmake4eclipse already has a parser for the compile_commands.json file
> produces by cmake. That file lists each file in the build.
>
> My idea to ease your problem is to have a menu action in the UI that
> configures the source file filter of the project based on the files listed
> in
> the compile_commands.json file.
> ...
> > - Any particular configuration of the 

Re: [CMake] Fake dependencies of executables to static libs

2019-04-04 Thread Francis Giraldeau
Maybe the problem is related to Cotire? I see that it is used in
mredis. I tried to reproduce the issue, and it behaves correctly. You
might want to try to reproduce using the following minimal repo:

  https://gitlab.com/fgiraldeau/cotire-demo

Francis

Le jeu. 4 avr. 2019 à 03:17, Stephan Menzel  a écrit :
>
> Hello Paul and Shoaib,
>
> I'm answering to the both of you.
>
> On Thu, Apr 4, 2019 at 7:13 AM Paul Smith  wrote:
>>
>> Now although I don't understand the exact reasons behind that, over the 
>> years came to accept that depedencies between the lib and the resulting 
>> artifcats are not working. Like, when I change a source file to mylib, the 
>> lib will get rebuilt but the resulting test tool won't be relinked.
>>
>>
>> This is definitely not true, as stated. I feel like I must be missing 
>> something about your stated environment because this is really basic, 
>> fundamental CMake behavior, which has always worked.
>
>
> First of all, thanks for the information. I was not aware that this is 
> supposed to work. As I said, I've been struggling with this issue for years 
> now and I recall posting this to this list too but the only explanation I 
> ever found was something along the lines of "dependencies would exist to 
> objects inside the lib, not the lib as it is a static archive". But I'm 
> pulling this out of my 'memory' now, nothing to rely on. All I remembered is 
> that this is not supposed to work. But now you say the opposite, which gives 
> me a little hope.
>
>>
>> If in your environment you are not seeing executables rebuilt when libraries 
>> they depend on are updated, then there is something more complex about it 
>> than the straightforward case you provide above.
>
>
> I have seen this in two major projects I have been working on in the last 
> years. Both were Linux and Windows, MSVC 14 and 15 on Windows. And I do 
> believe the issue is on Windows. I am not sure which CMake version I have 
> seen this first on. Let's make it 3.10.x cause this was when I posted this to 
> the list last time but by then I was already having the problem for a longer 
> time.
>
> Today I am using CMake version 3.13.2 but I have been using many different 
> versions up to this one.
>
> Both projects were large but not huge, having about 10 - 15 targets plus 
> additional 50 unit tests plus another 5 test tools. Unfortunately I cannot 
> publish the projects themselves but one that I currently see the issue with 
> is mredis (https://github.com/MrMoose/mredis) which, among others, is pulled 
> in as a submodule. C++ only, some protobuf code generation is involved but 
> not in the targets that I'm talking about.
>
> Since the issue has been persisting for so long now, the projects and 
> CMakeLists have substantially changed many times, so it's really hard to come 
> up with something I would consider 'strange' or 'different' as a possible 
> explanation.
>
> --
>
> 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.14.1-608-g8c28e63

2019-04-04 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  8c28e63cb4da99dbb894573a996c27e260b5baeb (commit)
   via  78ac8cb04a0723b10a9225e97a9e04c126a38a99 (commit)
  from  56abc31270cbe60845021107383f1cede0ed075e (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=8c28e63cb4da99dbb894573a996c27e260b5baeb
commit 8c28e63cb4da99dbb894573a996c27e260b5baeb
Merge: 56abc31 78ac8cb
Author: Brad King 
AuthorDate: Thu Apr 4 16:51:34 2019 +
Commit: Kitware Robot 
CommitDate: Thu Apr 4 12:51:41 2019 -0400

Merge topic 'if-EXISTS-doc'

78ac8cb04a Help: clarify if(EXISTS) operation for symlinks

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=78ac8cb04a0723b10a9225e97a9e04c126a38a99
commit 78ac8cb04a0723b10a9225e97a9e04c126a38a99
Author: Shoaib Meenai 
AuthorDate: Wed Apr 3 17:25:52 2019 -0700
Commit: Shoaib Meenai 
CommitDate: Wed Apr 3 17:25:52 2019 -0700

Help: clarify if(EXISTS) operation for symlinks

if(EXISTS) resolves symlinks; note this explicitly in its documentation.

diff --git a/Help/command/if.rst b/Help/command/if.rst
index a48a0fa..b79fd6c 100644
--- a/Help/command/if.rst
+++ b/Help/command/if.rst
@@ -88,7 +88,9 @@ Possible conditions are:
 
 ``if(EXISTS path-to-file-or-directory)``
  True if the named file or directory exists.  Behavior is well-defined
- only for full paths.
+ only for full paths. Resolves symbolic links, i.e. if the named file or
+ directory is a symbolic link, returns true if the target of the
+ symbolic link exists.
 
 ``if(file1 IS_NEWER_THAN file2)``
  True if ``file1`` is newer than ``file2`` or if one of the two files doesn't

---

Summary of changes:
 Help/command/if.rst | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)


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


Re: [CMake] Remove compilation flags for a given target

2019-04-04 Thread Mateusz Loskot
On Thu, 4 Apr 2019 at 14:47, Benjamin Orgogozo  wrote:
>
> If I'm right (I'm far from being a cmake expert) there are two ways to
> define "global" compilation flags:
> 1- set the CXX_COMPILE_FLAGS variable;
> 2- use add_compile_options($<$:-WMyFavouriteWarning).

The list should rather be, in preference/priority order

1. https://cmake.org/cmake/help/latest/command/target_compile_options.html
2. add_compile_options

And, if you really, really need
3. append to CMAKE_CXX_FLAGS

> Since I don't want to *add* a compilation flags but remove one, I would
> like to retrieve the properties of the target
> (get_target_property(my_compilation_flags TARGET COMPILE_FLAGS)), and
> then modify those and use it to set the properties of the target.
>
> Two questions for me remain:
> 1- How do I get *all* the compilation flags used for a target?
> get_target_property doesn't return flags is CXX_COMPILE_FLAGS nor those
> added by add_compile_options.

Are you certain you've got the variable name right?
https://cmake.org/cmake/help/latest/search.html?q=CXX_COMPILE_FLAGS

> 2- How do I *replace* compilation flags and don't *add* compilation
> flags? Both target_compile_options and set_target_properties seems to
> *add* flags and don't replace.

See  https://cmake.org/pipermail/cmake/2018-December/068716.html

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.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


[Cmake-commits] CMake branch, master, updated. v3.14.1-606-g56abc31

2019-04-04 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  56abc31270cbe60845021107383f1cede0ed075e (commit)
   via  a6324490e501154dba620a2495afd6f09eea8167 (commit)
   via  cf70b871438f1ae8a40a4d3822376f75151af258 (commit)
   via  5c1ead795d3fc003908a515565842cf1815eb111 (commit)
   via  192aa506c66d5269e10d87f1a67df5397325a9af (commit)
   via  d2473769e77f9cf9802c71effadb5e1469fcd625 (commit)
   via  33ee7793300f6ef9f5206e5a0539c192affa3d23 (commit)
   via  456e0fb64f5c70191145c34104d6f25bd24b7b37 (commit)
   via  f28e7fc1a51d5dfa81e2844c51eb811835e99583 (commit)
   via  d8cf8380fb9a539b3b2b6876f2eb34fc9bddbdac (commit)
  from  85b26a7254ce66404227f2b715fd4e29c64668f6 (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=56abc31270cbe60845021107383f1cede0ed075e
commit 56abc31270cbe60845021107383f1cede0ed075e
Merge: a632449 456e0fb
Author: Brad King 
AuthorDate: Thu Apr 4 15:48:44 2019 +
Commit: Kitware Robot 
CommitDate: Thu Apr 4 11:48:55 2019 -0400

Merge topic 'improve-documentation'

456e0fb64f Help: Improve documentation formating

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6324490e501154dba620a2495afd6f09eea8167
commit a6324490e501154dba620a2495afd6f09eea8167
Merge: cf70b87 192aa50
Author: Brad King 
AuthorDate: Thu Apr 4 11:46:03 2019 -0400
Commit: Brad King 
CommitDate: Thu Apr 4 11:46:03 2019 -0400

Merge branch 'release-3.14'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cf70b871438f1ae8a40a4d3822376f75151af258
commit cf70b871438f1ae8a40a4d3822376f75151af258
Merge: 5c1ead7 f28e7fc
Author: Brad King 
AuthorDate: Thu Apr 4 15:43:24 2019 +
Commit: Kitware Robot 
CommitDate: Thu Apr 4 11:44:02 2019 -0400

Merge topic 'armcc-compiler-id'

f28e7fc1a5 ARMCC: Do not identify ARMClang as ARMCC

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5c1ead795d3fc003908a515565842cf1815eb111
commit 5c1ead795d3fc003908a515565842cf1815eb111
Merge: 85b26a7 33ee779
Author: Brad King 
AuthorDate: Thu Apr 4 15:43:09 2019 +
Commit: Kitware Robot 
CommitDate: Thu Apr 4 11:43:18 2019 -0400

Merge topic 'vs2019-redist'

33ee779330 IRSL: Fix discovery of VS 2019 v142 toolset redistributables
d8cf8380fb MSVC: Fix MSVC_TOOLSET_VERSION for VS 2019 v142 toolset

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=456e0fb64f5c70191145c34104d6f25bd24b7b37
commit 456e0fb64f5c70191145c34104d6f25bd24b7b37
Author: Bartosz Kosiorek 
AuthorDate: Mon Apr 1 15:14:27 2019 +0200
Commit: Bartosz Kosiorek 
CommitDate: Thu Apr 4 15:13:58 2019 +0200

Help: Improve documentation formating

diff --git a/Help/command/get_cmake_property.rst 
b/Help/command/get_cmake_property.rst
index 58bf741..96764a3 100644
--- a/Help/command/get_cmake_property.rst
+++ b/Help/command/get_cmake_property.rst
@@ -9,7 +9,7 @@ Get a global property of the CMake instance.
 
 Gets a global property from the CMake instance.  The value of
 the  is stored in the variable .
-If the property is not found,  will be set to ``"NOTFOUND"``.
+If the property is not found,  will be set to ``NOTFOUND``.
 See the :manual:`cmake-properties(7)` manual for available properties.
 
 See also the :command:`get_property` command ``GLOBAL`` option.
diff --git a/Help/command/get_target_property.rst 
b/Help/command/get_target_property.rst
index 4327681..11e07ea 100644
--- a/Help/command/get_target_property.rst
+++ b/Help/command/get_target_property.rst
@@ -11,7 +11,7 @@ Get a property from a target.  The value of the property is 
stored in
 the variable ``VAR``.  If the target property is not found, the behavior
 depends on whether it has been defined to be an ``INHERITED`` property
 or not (see :command:`define_property`).  Non-inherited properties will
-set ``VAR`` to "NOTFOUND", whereas inherited properties will search the
+set ``VAR`` to ``NOTFOUND``, whereas inherited properties will search the
 relevant parent scope as described for the :command:`define_property`
 command and if still unable to find the property, ``VAR`` will be set to
 an empty string.
diff --git a/Help/command/if.rst b/Help/command/if.rst
index a48a0fa..f377f2c 100644
--- a/Help/command/if.rst
+++ b/Help/command/if.rst
@@ -227,7 +227,7 @@ above.  The result is ``OFF`` which is false.  However, if 
we remove the
 
   if(var2)
 
-which is true because ``var2`` is defined to "var1" 

[Cmake-commits] CMake branch, release, updated. v3.14.1-5-g192aa50

2019-04-04 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  192aa506c66d5269e10d87f1a67df5397325a9af (commit)
   via  d2473769e77f9cf9802c71effadb5e1469fcd625 (commit)
   via  33ee7793300f6ef9f5206e5a0539c192affa3d23 (commit)
   via  f28e7fc1a51d5dfa81e2844c51eb811835e99583 (commit)
   via  d8cf8380fb9a539b3b2b6876f2eb34fc9bddbdac (commit)
  from  3c9dec0bdc11a69afcbaa93a0e61dc71cddd5491 (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:
 Modules/Compiler/ARMCC-DetermineCompiler.cmake |  2 +-
 Modules/InstallRequiredSystemLibraries.cmake   | 23 ++-
 Modules/Platform/Windows-MSVC.cmake|  5 -
 3 files changed, 19 insertions(+), 11 deletions(-)


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


[Cmake-commits] CMake branch, master, updated. v3.14.1-596-g85b26a7

2019-04-04 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  85b26a7254ce66404227f2b715fd4e29c64668f6 (commit)
   via  a15ed54dca5ebd2535a737b7200677c945c5c082 (commit)
   via  d48bf97fd3ec9c6cc818d32978122f019e35f638 (commit)
   via  14c7396fb940d04f2afd3e9a7230fa6d4fac8145 (commit)
  from  0dfb056cd3fa655ddf3cabb6b3ce0309b3037ca1 (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=85b26a7254ce66404227f2b715fd4e29c64668f6
commit 85b26a7254ce66404227f2b715fd4e29c64668f6
Merge: a15ed54 14c7396
Author: Brad King 
AuthorDate: Thu Apr 4 15:33:19 2019 +
Commit: Kitware Robot 
CommitDate: Thu Apr 4 11:34:43 2019 -0400

Merge topic 'FindGLEW-lib-suffixes'

14c7396fb9 FindGLEW: fix CMAKE_FIND_LIBRARY_SUFFIXES

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a15ed54dca5ebd2535a737b7200677c945c5c082
commit a15ed54dca5ebd2535a737b7200677c945c5c082
Merge: 0dfb056 d48bf97
Author: Brad King 
AuthorDate: Thu Apr 4 15:32:46 2019 +
Commit: Kitware Robot 
CommitDate: Thu Apr 4 11:33:37 2019 -0400

Merge topic 'FindBoost-clang-cl'

d48bf97fd3 FindBoost: Consider boost suffixes suitable for clang-cl

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d48bf97fd3ec9c6cc818d32978122f019e35f638
commit d48bf97fd3ec9c6cc818d32978122f019e35f638
Author: Douman 
AuthorDate: Fri Mar 29 22:45:47 2019 +0300
Commit: Brad King 
CommitDate: Wed Apr 3 14:30:11 2019 -0400

FindBoost: Consider boost suffixes suitable for clang-cl

When compiling with `clang-cl` we can use either the MSVC- or
Clang-built boost libraries.

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 6e7d3db..1231ff1 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -465,7 +465,7 @@ function(_Boost_GUESS_COMPILER_PREFIX _ret)
 endif()
   elseif (GHSMULTI)
 set(_boost_COMPILER "-ghs")
-  elseif("x${CMAKE_CXX_COMPILER_ID}" STREQUAL "xMSVC")
+  elseif("x${CMAKE_CXX_COMPILER_ID}" STREQUAL "xMSVC" OR 
"x${CMAKE_CXX_SIMULATE_ID}" STREQUAL "xMSVC")
 if(MSVC_TOOLSET_VERSION GREATER_EQUAL 141)
   set(_boost_COMPILER "-vc141;-vc140")
 elseif(MSVC_TOOLSET_VERSION GREATER_EQUAL 80)
@@ -477,6 +477,12 @@ function(_Boost_GUESS_COMPILER_PREFIX _ret)
 else() # VS 6.0 Good luck!
   set(_boost_COMPILER "-vc6") # yes, this is correct
 endif()
+
+if("x${CMAKE_CXX_COMPILER_ID}" STREQUAL "xClang")
+  string(REPLACE "." ";" VERSION_LIST "${CMAKE_CXX_COMPILER_VERSION}")
+  list(GET VERSION_LIST 0 CLANG_VERSION_MAJOR)
+  set(_boost_COMPILER "-clangw${CLANG_VERSION_MAJOR};${_boost_COMPILER}")
+endif()
   elseif (BORLAND)
 set(_boost_COMPILER "-bcb")
   elseif(CMAKE_CXX_COMPILER_ID STREQUAL "SunPro")

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=14c7396fb940d04f2afd3e9a7230fa6d4fac8145
commit 14c7396fb940d04f2afd3e9a7230fa6d4fac8145
Author: Claudio Fantacci 
AuthorDate: Tue Apr 2 09:43:34 2019 +0200
Commit: Claudio Fantacci 
CommitDate: Wed Apr 3 09:06:16 2019 +0200

FindGLEW: fix CMAKE_FIND_LIBRARY_SUFFIXES

FindGLEW temporarily changes the content of CMAKE_FIND_LIBRARY_SUFFIXES
to look for static and dynamic GLEW library.
However, it wasn't storing and restoring the initial content of such
variable, causing possible issues in user project.

diff --git a/Modules/FindGLEW.cmake b/Modules/FindGLEW.cmake
index 34ee873..2e9a052 100644
--- a/Modules/FindGLEW.cmake
+++ b/Modules/FindGLEW.cmake
@@ -117,6 +117,8 @@ else()
 endif()
 
 
+set(__GLEW_CURRENT_FIND_LIBRARY_SUFFIXES ${CMAKE_FIND_LIBRARY_SUFFIXES})
+
 __glew_set_find_library_suffix(SHARED)
 
 find_library(GLEW_SHARED_LIBRARY_RELEASE
@@ -142,6 +144,9 @@ find_library(GLEW_STATIC_LIBRARY_DEBUG
  PATH_SUFFIXES lib lib64
  PATHS ENV GLEW_ROOT)
 
+set(CMAKE_FIND_LIBRARY_SUFFIXES ${__GLEW_CURRENT_FIND_LIBRARY_SUFFIXES})
+unset(__GLEW_CURRENT_FIND_LIBRARY_SUFFIXES)
+
 include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake)
 
 select_library_configurations(GLEW_SHARED)

---

Summary of changes:
 Modules/FindBoost.cmake | 8 +++-
 Modules/FindGLEW.cmake  | 5 +
 2 files changed, 12 insertions(+), 1 deletion(-)


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


[Cmake-commits] CMake branch, master, updated. v3.14.1-592-g0dfb056

2019-04-04 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  0dfb056cd3fa655ddf3cabb6b3ce0309b3037ca1 (commit)
   via  7795b3f2bfe3dbab35a494ceee37745eaff110f4 (commit)
   via  dc6b76d1e751224c60aba5489fb62228cd8a6bad (commit)
   via  d1c2f8787ceb0cb5e30d433e05f774bbdd910ef9 (commit)
   via  a63a50c77af65092d82b9c3a6de3ea34c63605d4 (commit)
   via  8a2f62cc18ece0ebfed0ff6abf53d419d43d2fa1 (commit)
   via  18f7b2ed2111ff9dac5ef83d8bbf20b826b8bbe9 (commit)
   via  5fb122ff75f0fac2c421a6cba6c78a2123e3fd49 (commit)
   via  b32e18fb88434d3f9d58447212ee33a51430c144 (commit)
   via  5431395d68a44d42149fb93692636f4138ddf6ed (commit)
   via  78eccc7836e068652ea772ec65614bc446f23b14 (commit)
   via  30bb14c65777bad02b3360797bf9c7b0fbe3280e (commit)
   via  abbb8a7b1d40b98fb1841a76efb676eea7771cf0 (commit)
   via  11338389e5f89a58b18d63e29e21c099cfbf407e (commit)
   via  076118694995c19de7637156322818f3994de76a (commit)
  from  3d6d7c170ca9ad291a0deedd125b8f9ce82d15bb (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=0dfb056cd3fa655ddf3cabb6b3ce0309b3037ca1
commit 0dfb056cd3fa655ddf3cabb6b3ce0309b3037ca1
Merge: 7795b3f 0761186
Author: Brad King 
AuthorDate: Thu Apr 4 15:31:48 2019 +
Commit: Kitware Robot 
CommitDate: Thu Apr 4 11:32:41 2019 -0400

Merge topic 'pr.projectbefore'

0761186949 project: Add variable CMAKE_PROJECT_INCLUDE_BEFORE

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7795b3f2bfe3dbab35a494ceee37745eaff110f4
commit 7795b3f2bfe3dbab35a494ceee37745eaff110f4
Merge: dc6b76d 30bb14c
Author: Brad King 
AuthorDate: Thu Apr 4 15:30:15 2019 +
Commit: Kitware Robot 
CommitDate: Thu Apr 4 11:30:54 2019 -0400

Merge topic 'modernize-raw-string-literal'

30bb14c657 Modernize: Enable modernize-raw-string-literal in clang-tidy

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dc6b76d1e751224c60aba5489fb62228cd8a6bad
commit dc6b76d1e751224c60aba5489fb62228cd8a6bad
Merge: d1c2f87 18f7b2e
Author: Brad King 
AuthorDate: Thu Apr 4 15:29:22 2019 +
Commit: Kitware Robot 
CommitDate: Thu Apr 4 11:29:51 2019 -0400

Merge topic 'autogen_keywords_class'

18f7b2ed21 Autogen: Add more frequently used keywords to Keywords class
5fb122ff75 Autogen: Add `AUTO*_EXECUTABLE` strings to Keywords class
b32e18fb88 Autogen: Remove static const generator name strings from 
cmQtAutoGen
5431395d68 Autogen: Add cmQtAutogenGlobalInitializer::Keywords class
78eccc7836 Autogen: Remove lowercase generator name from generator 
variables class

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d1c2f8787ceb0cb5e30d433e05f774bbdd910ef9
commit d1c2f8787ceb0cb5e30d433e05f774bbdd910ef9
Merge: a63a50c 8a2f62c
Author: Brad King 
AuthorDate: Thu Apr 4 15:28:41 2019 +
Commit: Kitware Robot 
CommitDate: Thu Apr 4 11:28:49 2019 -0400

Merge topic 'FindPython-handle-virtual-env'

8a2f62cc18 FindPython*: Add capability to control virtual env handling.

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a63a50c77af65092d82b9c3a6de3ea34c63605d4
commit a63a50c77af65092d82b9c3a6de3ea34c63605d4
Merge: 3d6d7c1 abbb8a7
Author: Brad King 
AuthorDate: Thu Apr 4 15:27:18 2019 +
Commit: Kitware Robot 
CommitDate: Thu Apr 4 11:27:28 2019 -0400

Merge topic 'remove_duplicates'

abbb8a7b1d Genex: Add $
11338389e5 Help: Fix description in cmake-generator-expressions(7) manual

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8a2f62cc18ece0ebfed0ff6abf53d419d43d2fa1
commit 8a2f62cc18ece0ebfed0ff6abf53d419d43d2fa1
Author: Marc Chevrier 
AuthorDate: Mon Apr 1 11:19:54 2019 +0200
Commit: Marc Chevrier 
CommitDate: Wed Apr 3 09:16:17 2019 +0200

FindPython*: Add capability to control virtual env handling.

Fixes: #19097

diff --git a/Help/release/dev/FindPython-virtual-env.rst 
b/Help/release/dev/FindPython-virtual-env.rst
new file mode 100644
index 000..5489dc2
--- /dev/null
+++ b/Help/release/dev/FindPython-virtual-env.rst
@@ -0,0 +1,5 @@
+FindPython-virtual-env
+--
+
+* Modules :module:`FindPython3`, :module:`FindPython2` and :module:`FindPython`
+  gain capability to control how virtual environments are handled.
diff --git 

[CMake] Android Cross Compilation with Xamarin

2019-04-04 Thread Daniel Wynne


   Hi All!

   Wwe would like to set up a Android cross compilation project for
   Visual Studio using the Xamarin Framework.

   Could you please give us a few hints on what would be the best
   approach to achieve this?

   Another question is, why the NVidia Tegra Plugin is mandatory for
   Visual Studio and no self-provided NDK/Toolchain is supported when
   it comes to Visual Studio and Android development?

   Thank you very much!

   Kind Regards

   Daniel Wynne

   -- 
   This e-mail was sent from a contact form on CMake (https://cmake.org)


-- 

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] Remove compilation flags for a given target

2019-04-04 Thread Benjamin Orgogozo
Hello,

in our code base we would like to add a warning compilation flags.
Nevertheless, this flag prevents us from compiling a few targets so we
would like to remove this flag for the given targets.

If I'm right (I'm far from being a cmake expert) there are two ways to
define "global" compilation flags:
1- set the CXX_COMPILE_FLAGS variable;
2- use add_compile_options($<$:-WMyFavouriteWarning).

Since I don't want to *add* a compilation flags but remove one, I would
like to retrieve the properties of the target
(get_target_property(my_compilation_flags TARGET COMPILE_FLAGS)), and
then modify those and use it to set the properties of the target.

Two questions for me remain:
1- How do I get *all* the compilation flags used for a target?
get_target_property doesn't return flags is CXX_COMPILE_FLAGS nor those
added by add_compile_options.
2- How do I *replace* compilation flags and don't *add* compilation
flags? Both target_compile_options and set_target_properties seems to
*add* flags and don't replace.

Everything is tested under linux and cmake 3.13.3.

Thanks for you help, any pointer to a ressource that might contain
useful information for this problem would be really appreciated.

Regards,

-- 
 Benjamin Orgogozo
-- 

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] dll artifacts - Runtime or Library Output

2019-04-04 Thread Kerstin Keller
On Windows, a .dll is considered by CMake to be a "RUNTIME" Output artifact
if it was added with the `add_library(my_liib SHARED my_lib.cpp), however
if it was added with the MODULE keyword, it is considered to be a "LIBRARY"
output, as stated in the documentation
https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#runtime-output-artifacts

I just discovered this behavior and it seems quite unintuitive to me.
If I dynamically load a library with LoadLibrary without specying an
absolute path, Windows will still use the default search path logic for
Windows, which means first same directory as the executable loading the
module, e.g. the RUNTIME output directory.
(See also
https://docs.microsoft.com/en-us/windows/desktop/api/libloaderapi/nf-libloaderapi-loadlibrarya
)

Can you please elaborate on this?

Thanks, Kerstin
-- 

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] Fake dependencies of executables to static libs

2019-04-04 Thread Stephan Menzel
Hello Paul and Shoaib,

I'm answering to the both of you.

On Thu, Apr 4, 2019 at 7:13 AM Paul Smith  wrote:

> Now although I don't understand the exact reasons behind that, over the
> years came to accept that depedencies between the lib and the resulting
> artifcats are not working. Like, when I change a source file to mylib, the
> lib will get rebuilt but the resulting test tool won't be relinked.
>
>
> This is definitely not true, as stated. I feel like I must be missing
> something about your stated environment because this is really basic,
> fundamental CMake behavior, which has always worked.
>

First of all, thanks for the information. I was not aware that this is
supposed to work. As I said, I've been struggling with this issue for years
now and I recall posting this to this list too but the only explanation I
ever found was something along the lines of "dependencies would exist to
objects inside the lib, not the lib as it is a static archive". But I'm
pulling this out of my 'memory' now, nothing to rely on. All I remembered
is that this is not supposed to work. But now you say the opposite, which
gives me a little hope.


> If in your environment you are not seeing executables rebuilt when
> libraries they depend on are updated, then there is something more complex
> about it than the straightforward case you provide above.
>

I have seen this in two major projects I have been working on in the last
years. Both were Linux and Windows, MSVC 14 and 15 on Windows. And I do
believe the issue is on Windows. I am not sure which CMake version I have
seen this first on. Let's make it 3.10.x cause this was when I posted this
to the list last time but by then I was already having the problem for a
longer time.

Today I am using CMake version 3.13.2 but I have been using many different
versions up to this one.

Both projects were large but not huge, having about 10 - 15 targets plus
additional 50 unit tests plus another 5 test tools. Unfortunately I cannot
publish the projects themselves but one that I currently see the issue with
is mredis (https://github.com/MrMoose/mredis) which, among others, is
pulled in as a submodule. C++ only, some protobuf code generation is
involved but not in the targets that I'm talking about.

Since the issue has been persisting for so long now, the projects and
CMakeLists have substantially changed many times, so it's really hard to
come up with something I would consider 'strange' or 'different' as a
possible explanation.
-- 

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] Fake dependencies of executables to static libs

2019-04-04 Thread Paul Smith
On Thu, 2019-04-04 at 06:56 +0100, Stephan Menzel wrote:
> add_library(mylib STATIC mysources)
> add_excecutable(mytest mytest.cpp)
> target_link_libraries(mytest mylib)
> 
> Now although I don't understand the exact reasons behind that, over
> the years came to accept that depedencies between the lib and the
> resulting artifcats are not working. Like, when I change a source
> file to mylib, the lib will get rebuilt but the resulting test tool
> won't be relinked.

This is definitely not true, as stated.  I feel like I must be missing
something about your stated environment because this is really basic,
fundamental CMake behavior, which has always worked.

If in your environment you are not seeing executables rebuilt when
libraries they depend on are updated, then there is something more
complex about it than the straightforward case you provide above.

Rather than try to find a workaround it would be better to find the
root cause.  If you can provide a sample setup that behaves as you
describe perhaps we could explain what's happening.

Also please let us know which version of CMake you're using.
-- 

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] Fake dependencies of executables to static libs

2019-04-04 Thread Shoaib Meenai
Could you share more details about your CMake version, the platform you're on, 
and the generator you're using?

I haven't run into this issue (and it's pretty counter to how I'd expect CMake 
to behave). The only similar setting I'm aware of is 
https://cmake.org/cmake/help/latest/prop_tgt/LINK_DEPENDS_NO_SHARED.html, but 
that's for shared libraries, not static libraries.

As an experiment, I used the following CMakeLists.txt:

cmake_minimum_required(VERSION 3.4.3)
project(cmtest C)
add_library(mylib STATIC source.c)
add_executable(mytest test.c)
target_link_libraries(mytest mylib)

I'm running CMake 3.12.3 on macOS 10.14.1, and I tried both the Makefile and 
Ninja generators. With both, any modification to source.c causes mytest to be 
rebuilt, as I'd expect (and unlike what you're seeing).

If you're able to provide a small self-contained CMakeLists.txt that reproduces 
the issue, that'd also be helpful for debugging.

Thanks,
Shoaib Meenai

From: CMake  on behalf of Stephan Menzel 

Date: Wednesday, April 3, 2019 at 10:56 PM
To: cmake 
Subject: Re: [CMake] Fake dependencies of executables to static libs

Hello again,

no ideas so far? Perhaps I can elaborate. I have tried multiple approaches over 
the years. Most recently adding the source files of the lib explicitly as 
dependencies to the created executable.

Like this:

set (SRC
MySource1.cpp
MySource2.cpp
)

set (HDR
MySource1.hpp
MySource2.hpp
)

add_library(mylib STATIC ${SRC} ${HDR})

add_executable(myexecutable main.cpp)
target_link_libraries(myexecutable
mylib
)

add_dependencies(myexecutable ${SRC})

This leads to errors though:

CMake Error at CMakeLists.txt:79 (add_dependencies):
  The dependency target "MySource1.cpp" of target "myexecutable" does not exist.

Obviously, I cannot simply state a filename and treat it as a target. I have 
however seen something similar been done when it comes to code generation. I 
have also seen explicit subtargets for files being created and then depend on 
those subtargets. But I don't really know how to do this the right way.

Alternatively I would also appreciate input about what exactly the problem with 
depending on static libs is. The explanations I remember from my last efforts 
to tackle this weren't really satisfying. If I understood in more detail why 
this isn't possible I may be able to better craft a workaround on my own.

Really, anything helps. I am losing time and nerve every day because of this 
and have been paying this price for so many years that I think it really is 
time to come up with a solution.

Cheers,
Stephan






On Tue, Apr 2, 2019 at 5:54 AM Stephan Menzel 
mailto:stephan.men...@gmail.com>> wrote:
Hello List,

In our projects we are using static linkage on Windows (MSVC) and Linux. A 
number of static libs are created and then linked into executables, such as 
unit tests, tools and the actual production artifacts. Very normal stuff.

add_library(mylib STATIC mysources)
add_excecutable(mytest mytest.cpp)
target_link_libraries(mytest mylib)

Now although I don't understand the exact reasons behind that, over the years 
came to accept that depedencies between the lib and the resulting artifcats are 
not working. Like, when I change a source file to mylib, the lib will get 
rebuilt but the resulting test tool won't be relinked.
For test driven development or busy change cycles that can put quite a strain 
on effort, especially on windows. My normal workflow is that I always click in 
mytest.cpp, add and remove a space to mark it dirty as quickly as possible and 
thereby cause the rebuild. But sometimes I forget this and this caused me quite 
a bit of extra work.
My question is, can I fake that dependency somehow? Perhaps by some hack or 
using some workaround?

What I want to achieve is that when I change the lib, the unit test (or any 
other test tool using it) that depends on it will be relinked, even if it has 
not changed.

Is that possible somehow?

Cheers,
Stephan
-- 

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