Re: [CMake] Shared library for a executable

[Raymond Wan]

Hi Tamás,


On Mon, Jan 25, 2016 at 7:02 PM, Tamás Kenéz  wrote:
> Gonzalo, Ray,
>
> I think your approaches are not in accordance with some CMake best practices
> (or at least what I believe they are).


Thank you for looking over my web site!  I welcome comments since I am
learning as I go along and I also don't know what "CMake best
practices" are.  There seems to be a lot of flexibility and a lot of
ways to get things wrong.


> Please take a look at Ray's example after a heavy refactor:
> https://github.com/tamaskenez/cmake-2016-jan-21-shared-lib-exe


Thanks for refactoring it!  I just realized I probably should have put
my example on GitHub.  Perhaps I'll do it instead of having just a
tar.gz file.


> These are the things I changed:
>
> - In your test executables don't compile the source files of the
> library-under-test into your test. Instead, link to the library. Reason (1)
> ODR, (2) this way you'll test the linking operation, too.


That's an excellent point!  Thanks!


> - Don't reach out from a subdirectory ('B') to include a sibling ('A'). It
> creates harmful coupling between the subdirectories. All information that
> 'B' needs to know about 'A' should be concentrated in the properties of the
> target 'A'. So you need to use commands like target_include_directories().
> - Unnecessary verbosity makes it harder to read and debug the CMakeLists.


The verbosity was a bit on purpose.  To help others follow the example
and to help me follow months after I look at it!  But, another reason
is that I have many CMakeLists.txt that are very similar.  And the
only part that is different are the filenames.  So, I do copy and
paste my CMakeLists.txt and change just all the filenames in one
place.

Perhaps it is hard to read and debug, but when almost all of my
CMakeLists.txt are the same, then it is actually a bit easier.


> - you can build and test 'A' standalone
> - you can build and test 'A', 'B' and 'X' in one project using the top-level
> CMakeLists.txt
> - you can't build 'B' standalone or can't build 'X' without 'A' and 'B'
> being there. If you need that feature, we need to add an install step to 'A'
> and 'B' and use find_package() in 'B' and 'X' on demand


Hm, I see.

However, the last point isn't what I was trying to achieve.  And I
mentioned it on the "Summary" page.

I was playing with this for a long time and did try what you suggest
above.  But, in one project, I had tree-like dependencies that
stretched for more than two levels.  (i.e., it wasn't just X needed A,
X needed B, X needed C, etc.).  So, I could have installed them into
the system, but I only needed it to compile X and cluttering a user's
system with libraries didn't seem like a good idea.

BUT, I now see a way around it.  I suppose I can install them into an
install path within the build tree.  And apply find_package () to just
within the build tree.

That would satisfy all of these criteria:

1)  A and B are independent,
2)  B can be built stand-alone,
3)  A and B are installed within the build tree,
4)  A and B are to be found with find_package (), and
5)  Only X is installed in the system-level directory (since that is
the only program that a user should run).

I think this sounds fine...  I will give it a try.  Thank you for your comments!

Ray
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0015934]: There's no way to test whether a given *linker* flag works

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15934 
== 
Reported By:Guy Harris
Assigned To:
== 
Project:CMake
Issue ID:   15934
Category:   CMake
Reproducibility:N/A
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-01-26 02:58 EST
Last Modified:  2016-01-26 02:58 EST
== 
Summary:There's no way to test whether a given *linker* flag
works
Description: 
There are macros to test whether a given *compiler* flag works, such as
CHECK_C_COMPILER_FLAG and CHECK_CXX_COMPILER_FLAG.

There is no macro to test whether a given *linker* flag works.

Furthermore, there does not appear to be a way to do a CHECK_C_SOURCE_RUNS with
a given *linker* flag, so there does not appear to be a way to *write* a macro
to test whether a given linker flag works.  Setting CMAKE_REQUIRED_FLAGS does
*not* affect what flags are used with, for example, the Xcode generator; it
works with the Unix makefile generator, but that's not sufficient to support
multiple build systems.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-26 02:58 Guy Harris New Issue
==

-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, master, updated. v3.4.3-908-ge7eab0e

[Kitware Robot]

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  e7eab0ec40f19a1fc81920bdd0dcf356a5b362d4 (commit)
  from  c4e1bc6ed24d57ef3136756802aa575642927ff1 (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=e7eab0ec40f19a1fc81920bdd0dcf356a5b362d4
commit e7eab0ec40f19a1fc81920bdd0dcf356a5b362d4
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Tue Jan 26 00:01:13 2016 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Tue Jan 26 00:01:13 2016 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 87792d1..18f52bf 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 4)
-set(CMake_VERSION_PATCH 20160125)
+set(CMake_VERSION_PATCH 20160126)
 #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
http://public.kitware.com/mailman/listinfo/cmake-commits

[CMake] How to override CMAKE_C_IMPLICIT_LINK_LIBRARIES

[陆秋文]

I have the need to link a shared library to all the targets without
modifying the CMakeLists.txt(for example, tcmalloc.so). I used the command:

# cmake -DCMAKE_C_IMPLICIT_LINK_LIBRARIES:STRING=tcmalloc

However, It didn't work. I used the message() command to print the
CMAKE_C_IMPLICIT_LINK_LIBRARIES, It show:

-- CMAKE_C_IMPLICIT_LINK_LIBRARIES=c

Can someone point me why this happens? Thanks very much!

Qiuwen Lu
luqiu...@gmail.com
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Shared library for a executable

[Raymond Wan]

Hi Gonzalo,


On Mon, Jan 25, 2016 at 5:22 PM, Gonzalo  wrote:
>
>
> El 22/01/16 a las 10:50, Raymond Wan escribió:
>>
>> Hi Gonzalo,
>>
>> I recently tried doing this and wrote it up as a record for myself.
>> Of course, I don't know if it's the right way, but I'm doing it this
>> way until I figure out a better way...
>>
>> See if this helps and let me know if you figure out something better:
>>
>> http://www.rwanwork.info/sysdocs/cmake/overview/
>>
>> Ray
>
> Thanks, Ray.  Your approach is exactly the same as mine.  We already found
> out that the problem I was having with v3.4.2 is a bug in cmake, which has
> been fixed in the git repository.


You're welcome!  I wasn't following the discussion about the v3.4.2
bug so I didn't realize that was the cause.

Nevertheless, I'm glad it helped and I'll be sure to skip v3.4.2 -- thank you!

Ray
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to override CMAKE_C_IMPLICIT_LINK_LIBRARIES

[Nils Gladitz]

On 01/26/2016 06:35 AM, 陆秋文 wrote:
I have the need to link a shared library to all the targets without 
modifying the CMakeLists.txt(for example, tcmalloc.so). I used the 
command:


# cmake -DCMAKE_C_IMPLICIT_LINK_LIBRARIES:STRING=tcmalloc

However, It didn't work. I used the message() command to print the 
CMAKE_C_IMPLICIT_LINK_LIBRARIES, It show:


-- CMAKE_C_IMPLICIT_LINK_LIBRARIES=c

Can someone point me why this happens? Thanks very much!


Implicit link libraries are those that the compiler (not CMake) itself 
implicitly links.
They are detected by CMake and stored in the variable; the variable is 
not meant to be modified.


I can't think of any way to portably link libraries without modifying 
the project.
(There are linker flag variables e.g. CMAKE_EXE_LINKER_FLAGS but they 
are inserted before object files on the command line which will not work 
for many toolsets)


link_libraries() [1] might have the smallest impact if you do end up 
having to modify the project.


Nils

[1] https://cmake.org/cmake/help/v3.4/command/link_libraries.html
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] FIND_PROGRAM fails to find file without 'r' bit set

[Brad King]

On 01/25/2016 08:27 AM, Ben Boeckel wrote:
> It's both :) . FileExists is implemented using access() rather than
> something like lstat(), so that would indeed be not a "program" since
> the file doesn't "exist".
> 
> It was on my list to fix, but the backwards compatibility argument
> (IIRC) made it near impossible to change.

There are related issues here:

 https://cmake.org/Bug/view.php?id=14022
 https://cmake.org/Bug/view.php?id=10468

The main compatibility concern is not about find_program, but just about
other uses of FileExists.  Each time this has come up before we've
determined the full solution requires a non-trivial audit of all uses
of FileExists.  That lost sight of the immediate find_program problem,
so instead we could look at fixing just that.

Since then we've gained the cmSystemTools::TestFileAccess() function.
One could look at porting find_program to use it with TEST_FILE_EXECUTE.
The Tests/RunCMake/find_program test could be extended to cover this
once it is fixed.

-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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [CMake] PROPERTY for list of link libraries

[Tom Kacvinsky]

Thanks.  Upgrading cmake right now is problematic.

On Mon, Jan 25, 2016 at 4:33 AM, Tamás Kenéz  wrote:

> I think you need something like CMakeExpandImportedTargets.cmake (
> https://cmake.org/cmake/help/latest/module/CMakeExpandImportedTargets.html).
> But that module has been deprecated for a while and does not support some
> newer CMake features.
>
> Instead, feel free to try out my fork:
> https://gist.github.com/tamaskenez/ef98237fff654c6d28b5 . This fork adds
> support for IMPORTED_IMPLIB, INTERFACE_LINK_LIBRARIES and $
> expressions.
>
> It recursively resolves all dependencies for the given configuration
> (Debug, Release, ...)
>
> Tamas
>
>
> On Fri, Jan 22, 2016 at 11:01 PM, Tom Kacvinsky <
> tom.kacvin...@vectorcast.com> wrote:
>
>> Ah yes, that was it.  Switching to 3.3.2 did the trick.  Time to upgrade
>> cmake.
>>
>> On Fri, Jan 22, 2016 at 4:40 PM, Tom Kacvinsky <
>> tom.kacvin...@vectorcast.com> wrote:
>>
>>> I am now having a problem with transitive dependencies.  I need all
>>> libraries that are linked in.  I am missing the ones that are linked in
>>> transitively.  Modified code is, ignoring J. Decker's suggestion about
>>> using generator expressions to get the path to the target's output.
>>>
>>> get_property(libs TARGET a_target PROPERTY LINK_LIBRARIES)
>>> foreach(lib ${libs})
>>>   if(TARGET ${lib})
>>> # If this is a library, get its transitive dependencies
>>> get_property(trans TARGET ${lib} PROPERTY INTERFACE_LINK_LIBRARIES)
>>> foreach(tran ${trans})
>>>   if(TARGET ${tran})
>>> get_property(path TARGET ${tran} PROPERTY LOCATION)
>>> file(APPEND "${CMAKE_BINARY_DIR/libs.txt" "${path}\n")
>>>   endif()
>>> endforeach()
>>> get_property(path TARGET ${lib} PROPERTY LOCATION)
>>> file(APPEND "${CMAKE_BINARY_DIR}/libs.txt" "${path}\n")
>>>   else()
>>> file(APPEND "${CMAKE_BINARY_DIR}/libs.txt" "${lib}\n")
>>>   endif()
>>> endforeach()
>>>
>>> I am using cmake 2.8.11.2, perhaps this property doesn't do what I
>>> thought it would with this version of cmake?
>>>
>>> Thanks,
>>>
>>> Tom
>>>
>>> On Fri, Jan 22, 2016 at 9:23 AM, Tom Kacvinsky <
>>> tom.kacvin...@vectorcast.com> wrote:
>>>
 I have need for a cross platform methods of getting libraries linked
 into an executable.

 Say for instance, we have

 add_library(foo STATIC a.c)
 add_exceutable(bar b.c)
 target_link_libraries(bar foo)

 So I know for that bar has a dependency on foo.lib (on Windows) and
 libfoo.a on Linux.

 And so forth.  What I would like to do is after everything is set up,
 query the properties of bar
 and find the list of libraries linked into bar in such a fashion I get
 that platform's specific library name (instead of the library's target
 name).

 IS this possible?  I read the docs and didn't see a property for
 getting this list.  Did I miss something?  If so I plan on using
 either get_property of get_target_property.

 Thanks.

>>>
>>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>>
>
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] FIND_PROGRAM fails to find file without 'r' bit set

[Ben Boeckel]

On Mon, Jan 25, 2016 at 16:06:47 +0300, Vyacheslav Barinov wrote:
> I try to detect paths to some tools using CMake and got the following problem:
> if the tool I try to check has 611 (-rw--x--x) rights FIND_PROGRAM reports the
> file does not exists.
> 
> For instance my /bin/mount in Gentoo has such setup and therefore I can use it
> from shell but can't detect it from CMakeLists.txt.
> 
> Is it bug or normal behavior for CMake?

It's both :) . FileExists is implemented using access() rather than
something like lstat(), so that would indeed be not a "program" since
the file doesn't "exist".

It was on my list to fix, but the backwards compatibility argument
(IIRC) made it near impossible to change.

--Ben
-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.4.2-2097-g26aec99

[Brad King]

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, next has been updated
   via  26aec99782f958f3a048e7074be1f5b9e8592426 (commit)
   via  f9cc671364d86a33399f7293aae9b145d7f90d94 (commit)
   via  7b8bec7a944acbebb71adf6ef1d6a561a3444076 (commit)
  from  a0771e09b7d1fa613ffa19dfb5d3dadf6014fc7e (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=26aec99782f958f3a048e7074be1f5b9e8592426
commit 26aec99782f958f3a048e7074be1f5b9e8592426
Merge: a0771e0 f9cc671
Author: Brad King 
AuthorDate: Mon Jan 25 09:50:08 2016 -0500
Commit: Brad King 
CommitDate: Mon Jan 25 09:50:08 2016 -0500

Merge branch 'master' into next


---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, release, updated. v3.4.2-2-g7b8bec7

[Brad King]

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  7b8bec7a944acbebb71adf6ef1d6a561a3444076 (commit)
   via  d7e863c1c1f4962f589e53b42a87a66cf5ab00b7 (commit)
  from  6506dcaa20a7d17737517dbcba6102be564d8d66 (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/variable/CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION.rst |3 ++-
 Source/cmGlobalVisualStudio14Generator.cxx |9 +
 Source/cmGlobalVisualStudio14Generator.h   |2 +-
 3 files changed, 8 insertions(+), 6 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.4.2-908-gf9cc671

[Brad King]

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  f9cc671364d86a33399f7293aae9b145d7f90d94 (commit)
   via  7b8bec7a944acbebb71adf6ef1d6a561a3444076 (commit)
  from  0586f1798e5dde39c18f70fb5c411902c2bf5357 (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:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] add_library object argument question

[Petr Kmoch]

Hi,

the name given after the : in the TARGET_OBJECTS generator expression is
the logical (CMake) name of a target. There's no scoping in target names,
they're all at the same global scope. So if you have this:

add_library(A OBJECT ...)

then you will access its objects like this:

add_library(... $ ...)

regardless of whether this happens in the same CMakeList or an entirely
different one (parent, child, sibling, it makes not difference).

Which also means there's no need for progressively going up levels: just
use all the A, B, C, D directly in the toplevel add_library call.

Petr

On Mon, Jan 25, 2016 at 3:34 PM, Vania Joloboff 
wrote:

> Hi
>
> In a library project there are two level of subdirectories that contain
> modules
> to be included into the main library.
> In other words, directory lib contains subdirectories foo and bar
> Subdirectory foo contains A and B.
> Subdirectory bar contains C and D.
> All of the objects from A, B, C and D must belong to the library
>
> I understand I can use at the bottom levels A, B, C, D
>  add_library() with the OBJECT argument
> and I should be able to use add_library() in the top directory
> to collect all of the object files from the subdirectories
>
> add_library(... $ ...)
>
> for each of the sub directories. But the documentation is unclear
> about the naming schema to use. What is the syntax/meaning of some_name ?
>
> add_library(... $ $
> $ $ ...)
>
> Or I need to gather at level foo and bar the objects from bottom layer
> and recursively make them go up one level by one level ?
>
> Thanks
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake] FIND_PROGRAM fails to find file without 'r' bit set

[Vyacheslav Barinov]

Hello,

I try to detect paths to some tools using CMake and got the following problem:
if the tool I try to check has 611 (-rw--x--x) rights FIND_PROGRAM reports the
file does not exists.

For instance my /bin/mount in Gentoo has such setup and therefore I can use it
from shell but can't detect it from CMakeLists.txt.

Is it bug or normal behavior for CMake?

Best Regards,
Vyacheslav Barinov
-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.4.2-2100-g9b24c2f

[Brad King]

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, next has been updated
   via  9b24c2fbefae8427a67392ca1f92a733c60496d9 (commit)
   via  52cf1c99ad32867d810a895c3f37a61beb71a750 (commit)
   via  0aef6f2412177a236deb292654402518777f3cb0 (commit)
  from  26aec99782f958f3a048e7074be1f5b9e8592426 (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=9b24c2fbefae8427a67392ca1f92a733c60496d9
commit 9b24c2fbefae8427a67392ca1f92a733c60496d9
Merge: 26aec99 52cf1c9
Author: Brad King 
AuthorDate: Mon Jan 25 09:51:45 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Jan 25 09:51:45 2016 -0500

Merge topic 'test-release' into next

52cf1c99 Merge branch 'release' into test-release
0aef6f24 CMake 3.4.3


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=52cf1c99ad32867d810a895c3f37a61beb71a750
commit 52cf1c99ad32867d810a895c3f37a61beb71a750
Merge: f9cc671 0aef6f2
Author: Brad King 
AuthorDate: Mon Jan 25 09:51:21 2016 -0500
Commit: Brad King 
CommitDate: Mon Jan 25 09:51:21 2016 -0500

Merge branch 'release' into test-release


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0aef6f2412177a236deb292654402518777f3cb0
commit 0aef6f2412177a236deb292654402518777f3cb0
Author: Brad King 
AuthorDate: Mon Jan 25 09:50:47 2016 -0500
Commit: Brad King 
CommitDate: Mon Jan 25 09:50:47 2016 -0500

CMake 3.4.3

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 4b3e7f7..41da437 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 4)
-set(CMake_VERSION_PATCH 2)
+set(CMake_VERSION_PATCH 3)
 #set(CMake_VERSION_RC 0)

---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[cmake-developers] CMake 3.5 feature freeze on 2016-02-01

[Brad King]

Hi Folks,

The feature freeze in 'master' for CMake 3.5 will be on Feb 1, 2016.
In order to get 'master' ready to branch for 3.5, 'next' is now frozen
to new features.  After 3.5 is branched I'll announce when post-3.5
development in 'next' is open.

Meanwhile the following types of changes are still welcome in 'next':

* Documentation updates
* Regression fixes
* Fixes for bugs in features new to 3.5

Thanks,
-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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Cmake-commits] CMake branch, master, updated. v3.4.2-904-g9722f8f

[Brad King]

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  9722f8f9a5b1c1ec24b6cb6edf5edd59922e90a5 (commit)
   via  b94e855d5fbf5cae975034ce5d7836425c8ad87f (commit)
  from  b9dadca90b2b10a71ffca87a308dcbfef5058f3c (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=9722f8f9a5b1c1ec24b6cb6edf5edd59922e90a5
commit 9722f8f9a5b1c1ec24b6cb6edf5edd59922e90a5
Merge: b9dadca b94e855
Author: Brad King 
AuthorDate: Mon Jan 25 09:47:08 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Jan 25 09:47:08 2016 -0500

Merge topic 'FindBoost-1.61'

b94e855d FindBoost: Add support for Boost 1.61


---

Summary of changes:
 Modules/FindBoost.cmake |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.4.2-906-g0586f17

[Brad King]

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  0586f1798e5dde39c18f70fb5c411902c2bf5357 (commit)
   via  d7e863c1c1f4962f589e53b42a87a66cf5ab00b7 (commit)
  from  9722f8f9a5b1c1ec24b6cb6edf5edd59922e90a5 (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=0586f1798e5dde39c18f70fb5c411902c2bf5357
commit 0586f1798e5dde39c18f70fb5c411902c2bf5357
Merge: 9722f8f d7e863c
Author: Brad King 
AuthorDate: Mon Jan 25 09:47:11 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Mon Jan 25 09:47:11 2016 -0500

Merge topic 'vs-win10-sdk'

d7e863c1 VS: Do not fail on Windows 10 with VS 2015 if no SDK is available 
(#15929)


---

Summary of changes:
 Help/variable/CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION.rst |3 ++-
 Source/cmGlobalVisualStudio14Generator.cxx |9 +
 Source/cmGlobalVisualStudio14Generator.h   |2 +-
 3 files changed, 8 insertions(+), 6 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.4.2-2094-ga0771e0

[Brad King]

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, next has been updated
   via  a0771e09b7d1fa613ffa19dfb5d3dadf6014fc7e (commit)
   via  0586f1798e5dde39c18f70fb5c411902c2bf5357 (commit)
   via  9722f8f9a5b1c1ec24b6cb6edf5edd59922e90a5 (commit)
   via  b9dadca90b2b10a71ffca87a308dcbfef5058f3c (commit)
   via  490483b947fe3fcefc73af3e899b47dcf0eddbde (commit)
   via  4a3fa1e8a09ef1fa674d36c1188bb73aed0de231 (commit)
  from  e9ac370789a1020b85e7a928ffd97673cf79afad (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=a0771e09b7d1fa613ffa19dfb5d3dadf6014fc7e
commit a0771e09b7d1fa613ffa19dfb5d3dadf6014fc7e
Merge: e9ac370 0586f17
Author: Brad King 
AuthorDate: Mon Jan 25 09:47:28 2016 -0500
Commit: Brad King 
CommitDate: Mon Jan 25 09:47:28 2016 -0500

Merge branch 'master' into next


---

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
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [cmake-developers] CMake daemon for user tools

[Vladimir Prus]

On 10-Jan-16 2:10 PM, Stephen Kelly wrote:


Hello,

I've been working on adding a daemon mode for cmake to provide
information to user tools - such as IDEs - about the buildsystem.

Following the discussion about providing metadata for IDEs to consume
I proposed creating a long-running process which would provide a protocol
to access information about the buildsystem, and about the content of the
cmake files themselves:

  
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=13004


Hi Stephen,

this sounds very much like what I has proposed for Boost.Build, see:

http://vladimirprus.com/talks/boosting-cdt-builds/


I am scheduled to give a talk at FOSDEM about the feature and how user
tools can interact with it:

  https://fosdem.org/2016/schedule/event/enabling_gui_tools_for_cmake_code

...

Is anyone interested enough in this potential cmake feature to
join the development effort?


You can guess I'm not very interested in cmake, but maybe we can discuss the 
protocol,
so that an IDE can work with different build systems? Think we can
have a chat at FOSDEM?


--
Vladimir Prus
http://vladimirprus.com

--

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, dashboard, updated. cb56d71de1bd40e06db17cb0266d1fbeabea75a3

[Brad King]

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, dashboard has been updated
   via  cb56d71de1bd40e06db17cb0266d1fbeabea75a3 (commit)
   via  3fc78bb9738930ed6eed5f2be3eeb5e0cecc1b0f (commit)
   via  aa516480fd7b593ab004be7037b114d4191a (commit)
   via  3159d3f588e2842e3d0eb85b410c985203423e2d (commit)
   via  99d55e896516cdadafd6b926921cdf59c2e09fa3 (commit)
  from  182b93635464ee35100522dec811abb76b55c742 (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=cb56d71de1bd40e06db17cb0266d1fbeabea75a3
commit cb56d71de1bd40e06db17cb0266d1fbeabea75a3
Author: Brad King 
AuthorDate: Thu Jan 21 10:27:11 2016 -0500
Commit: Brad King 
CommitDate: Thu Jan 21 10:30:37 2016 -0500

cmake_common: Fix use of ctest_empty_binary_directory

Make the build directory after using ctest_empty_binary_directory
because the command reports an error if asked to delete a directory
that exists but does not contain `CMakeCache.txt`.

Reported-by: Raffi Enficiaud 

diff --git a/cmake_common.cmake b/cmake_common.cmake
index 322424b..ff91ad1 100644
--- a/cmake_common.cmake
+++ b/cmake_common.cmake
@@ -313,11 +313,12 @@ ${dashboard_cache}
 endmacro(write_cache)
 
 # Start with a fresh build tree.
-file(MAKE_DIRECTORY "${CTEST_BINARY_DIRECTORY}")
-if(NOT "${CTEST_SOURCE_DIRECTORY}" STREQUAL "${CTEST_BINARY_DIRECTORY}")
+if(EXISTS "${CTEST_BINARY_DIRECTORY}" AND
+NOT "${CTEST_SOURCE_DIRECTORY}" STREQUAL "${CTEST_BINARY_DIRECTORY}")
   message("Clearing build tree...")
   ctest_empty_binary_directory(${CTEST_BINARY_DIRECTORY})
 endif()
+file(MAKE_DIRECTORY "${CTEST_BINARY_DIRECTORY}")
 
 set(dashboard_continuous 0)
 if("${dashboard_model}" STREQUAL "Continuous")

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3fc78bb9738930ed6eed5f2be3eeb5e0cecc1b0f
commit 3fc78bb9738930ed6eed5f2be3eeb5e0cecc1b0f
Author: Brad King 
AuthorDate: Fri Aug 28 09:08:52 2015 -0400
Commit: Brad King 
CommitDate: Thu Jan 21 10:30:05 2016 -0500

cmake_common: Use CTEST_TEST_ARGS for ctest_memcheck() call

The ctest_memcheck step should run the same tests as the ctest_test
step.

diff --git a/cmake_common.cmake b/cmake_common.cmake
index 9af724a..322424b 100644
--- a/cmake_common.cmake
+++ b/cmake_common.cmake
@@ -384,7 +384,7 @@ while(NOT dashboard_done)
   ctest_coverage()
 endif()
 if(dashboard_do_memcheck)
-  ctest_memcheck()
+  ctest_memcheck(${CTEST_TEST_ARGS})
 endif()
 if(NOT dashboard_no_submit)
   ctest_submit()

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aa516480fd7b593ab004be7037b114d4191a
commit aa516480fd7b593ab004be7037b114d4191a
Author: Brad King 
AuthorDate: Tue May 20 11:44:07 2014 -0400
Commit: Brad King 
CommitDate: Tue May 20 11:44:07 2014 -0400

cmake_common: Enable launchers and make program for Ninja generator

diff --git a/cmake_common.cmake b/cmake_common.cmake
index 7b9d91b..9af724a 100644
--- a/cmake_common.cmake
+++ b/cmake_common.cmake
@@ -116,8 +116,8 @@ endif()
 if(dashboard_bootstrap)
   # Launchers do not work during bootstrap: no ctest available.
   set(CTEST_USE_LAUNCHERS 0)
-elseif(NOT "${CTEST_CMAKE_GENERATOR}" MATCHES "Make")
-  # Launchers work only with Makefile generators.
+elseif(NOT "${CTEST_CMAKE_GENERATOR}" MATCHES "Make|Ninja")
+  # Launchers work only with Makefile and Ninja generators.
   set(CTEST_USE_LAUNCHERS 0)
 elseif(NOT DEFINED CTEST_USE_LAUNCHERS)
   # The setting is ignored by CTest < 2.8 so we need no version test.
@@ -293,7 +293,7 @@ set(ENV{LC_ALL} C)
 macro(write_cache)
   set(cache_build_type "")
   set(cache_make_program "")
-  if(CTEST_CMAKE_GENERATOR MATCHES "Make")
+  if(CTEST_CMAKE_GENERATOR MATCHES "Make|Ninja")
 set(cache_build_type CMAKE_BUILD_TYPE:STRING=${CTEST_BUILD_CONFIGURATION})
 if(CMAKE_MAKE_PROGRAM)
   set(cache_make_program CMAKE_MAKE_PROGRAM:FILEPATH=${CMAKE_MAKE_PROGRAM})

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3159d3f588e2842e3d0eb85b410c985203423e2d
commit 3159d3f588e2842e3d0eb85b410c985203423e2d
Author: Brad King 
AuthorDate: Tue May 20 11:43:53 2014 -0400
Commit: Brad King 
CommitDate: Tue May 20 11:43:53 2014 -0400

cmake_common: Add dashboard_configure_args option

diff --git a/cmake_common.cmake b/cmake_common.cmake
index a7b83a0..7b9d91b 100644
--- a/cmake_common.cmake
+++ b/cmake_common.cmake
@@ -364,7 +364,7 @@ 

[CMake] add_library object argument question

[Vania Joloboff]

Hi

In a library project there are two level of subdirectories that contain 
modules

to be included into the main library.
In other words, directory lib contains subdirectories foo and bar
Subdirectory foo contains A and B.
Subdirectory bar contains C and D.
All of the objects from A, B, C and D must belong to the library

I understand I can use at the bottom levels A, B, C, D
 add_library() with the OBJECT argument
and I should be able to use add_library() in the top directory
to collect all of the object files from the subdirectories

add_library(... $ ...)

for each of the sub directories. But the documentation is unclear
about the naming schema to use. What is the syntax/meaning of some_name ?

add_library(... $ $ 
$ $ ...)


Or I need to gather at level foo and bar the objects from bottom layer
and recursively make them go up one level by one level ?

Thanks
--

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake annotated tag, v3.4.3, created. v3.4.3

[Robert Maynard]

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 annotated tag, v3.4.3 has been created
at  a1ecc5d06c1f86f31da8a0b3a8d58c06aa77417f (tag)
   tagging  0aef6f2412177a236deb292654402518777f3cb0 (commit)
  replaces  v3.4.2
 tagged by  Brad King
on  Mon Jan 25 09:54:04 2016 -0500

- Log -
CMake 3.4.3
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABAgAGBQJWpjcMAAoJEC0s7xA0khaEKwsP/iWSM84qMWbZqeLsg6lkN9sz
a/Hk/eXJEPz8XqbNq9dz6n+j3fBSlFGAe8PTobee+Cv+qndOnnRqjYc7t9r5rxWz
tolaKNFoH9vBjz5bELe5DH/Loc7NEzkvY6qVwT0zXU2B9Tn/c8s1YGEkzTGszJZ0
8IGQiPBDbl7OnuB6KwbubIfGXnyPMfaZ0I9mEeWAD8ZPoliLGsTWLyQQTE+ih7/a
/4BgQQca8BZq9OM1R3Hr3ZgfWQB8MrCKPazwdRFBjZHI7HI1WsisQL/cxRtHdONH
QMENkB0mVLeL+Z/etl7CaihmiPJ7ntjAMUzyXGR/kVssChXCYCE7XAydTgZi+OUF
VvPYCB4pbnjVNr+f8/ccsG6pwCcZ3i9C6s+ulUWScQ/4TRXslpadFgffaqfVgTgl
NKftB14VKxKE74N+wtmCcbS0AafVOv2cZ99mZ27YadZ7K33xjLQ8OnGrKmnT/HYq
eCNz7w91mAdmeAkPYDlz6FmdhJH4Q9wpekAq89FSZFcqFH3+wSvg0mkooYHOGGIe
YfOFOFQlP5wCrvFTjMm9SmWtmTA96Q8abNBJtiBawDWcI074YlZ5tl5/8WSWGCLp
q0E4GjVzpMd/a40U2fe0wYvUXf6QAtjuLjHZaR/vG1NKZbdqFkZcWV2otw/J47zs
GL+cbH3lMX5Pcjr3R1UY
=3N0v
-END PGP SIGNATURE-

Brad King (3):
  VS: Do not fail on Windows 10 with VS 2015 if no SDK is available (#15929)
  Merge branch 'vs-win10-sdk' into release
  CMake 3.4.3

---


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[CMake] making a custom target like add_library()

[Tom Kacvinsky]

I create a DLL and import library via custom commands, but for my purposes
right now, I need these libraries to be treated as if they were generated
with add_library() (for the project I am workingon where I get transitive
dependencies);

I read this

http://stackoverflow.com/questions/31274577/custom-target-as-a-target-library-in-cmake

but I am not sure if this will invoke the MS linker tools and wreal havoc
with the specialized build of the DLL.  Also, this is for a DLL, not a
static archive, so in the line

add_library(lib2 STATIC IMPORTED GLOBAL)

would I change STATIC to SHARED?

Thanks,

Tom
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [ANNOUNCE] CMake 3.4.3 available for download

[Robert Maynard]

We are pleased to announce that CMake 3.4.3 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.4.3 since 3.4.2:

Brad King (2):
VS: Do not fail on Windows 10 with VS 2015 if no SDK is available (#15929)
CMake 3.4.3
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] [ANNOUNCE] CMake 3.4.3 available for download

[Robert Maynard]

We are pleased to announce that CMake 3.4.3 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.4.3 since 3.4.2:

Brad King (2):
VS: Do not fail on Windows 10 with VS 2015 if no SDK is available (#15929)
CMake 3.4.3
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [ANNOUNCE] cmake-unit - A new unit testing framework for CMake

[Sam Spilsbury]

Hi all,

By way of introduction you might remember me as a maintainer of Compiz
between 2009 and 2012, which is the window and compositing manager
still used by Ubuntu today. We used CMake quite heavily in Compiz and
so I've learned a great deal about it.

Over the last two years I've been working on a new unit testing
framework for CMake. I started this project because I've been writing
some other fairly complex CMake modules and I kept making mistakes
which would take me hours to debug weeks down the line. I would have
announced the project's existence a lot earlier, though I became
hesitant of doing so when I rewrote it earlier last year. Now that I
see there are discussions about potentially changing CMake's scripting
language, I figure it is probably better later than never.

The project is, rather unimaginatively, called cmake-unit. The key
difference between this and the RunCMake framework that's used by
CMake internally is that cmake-unit more closely resembles an xUnit
architecture. It has support for a generic assert_that function and
matchers, test-case autodiscovery, coverage report generation and
allows you to keep all your tests together in a single file. The only
downside so far is that it runs a fair bit slower than RunCMake does.
Presumably this is because under the hood it uses a lot of
indirection. On the upside, I have been finding optimisations to help
speed things up, so hopefully performance won't be a problem in the
future.

So far I have it hosted as a third party module on GitHub[0] and it
can be added as a dependency to biicode projects[1]. I also wrote a
blog post which gives a little bit more detail as to how it all works
[2]. The project has reached a relatively mature state by this point
and I have used it in several of my own projects successfully. I'd
like to reach out to a broader audience and get some more feedback to
keep things moving forward.

One thing I'm not sure about is whether this is an appropriate kind of
project to integrate into the CMake mainline. If that were to occur,
it'd have the upside of bringing the functionality to many more users.
The immediate problems I foresee are dealing with how this framework
would interact with RunCMake and also dealing with some of the hacks
that cmake-unit uses internally. In particular, calling arbitrary
functions is done by abusing variable_watch, which works, but isn't
exactly ideal.

Feedback and patches definitely appreciated,

Best Regards,

Sam Spilsbury.

[0] http://github.com/polysquare/cmake-unit
[1] http://biicode.com/smspillaz/cmake-unit
[2] 
https://smspillaz.wordpress.com/2016/01/25/a-unit-testing-framework-for-cmake/

-- 
Sam Spilsbury
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake daemon for user tools

[James Johnston]

> -Original Message-
> From: Milian Wolff [mailto:m...@milianw.de]
> Sent: Saturday, January 23, 2016 15:41
> To: cmake-developers@cmake.org
> Cc: James Johnston
> Subject: Re: [cmake-developers] CMake daemon for user tools
> 
> You are aware that modern std::string is SSO'ed? I'm running on such a
> system.
> Another reason why you should not reinvent the wheel and keep relying on
> the STL wherever possible.
>

> Qt has such a class, it's called QVarLengthArray, and I've also been able
to
> apply it in multiple occasions to good effect. That said, when you look at

Yeah, but std::string is platform dependent, and the size of the buffer is
also platform dependent.  Maybe it tends to be optimal for CMake.  Then
again, maybe a larger buffer is needed.  I don't know.  The flexible option
would be something that does exactly like QVarLengthArray.  Different
variables might have different optimal sizes.

Some sample small strings for gcc/clang/VC++:
http://stackoverflow.com/a/28003328/562766
Note that none of them are large enough to store an absolute path, which are
maybe common (???) in CMake.  Also there's a fair bit of variation; if CMake
wants consistent performance in a section of code across compilers, it would
need a way to explicitly specify the small string size.  For example, some
are large enough to store typical target sizes - and some maybe are not.

There is also boost::container::small_vector in addition to QVarLengthArray:
http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_vector.h
tml

> Just run cmake (or the daemon) through a profiler and check the results.
> Doing so for the daemon (built with RelWithDebInfo) on the LLVM build dir
> and recording it with `perf --call-graph lbr` I get these hotspots when
looking
> at the results with `perf report -g graph --no-children`:
> 
> +8.67%  cmake  cmake[.]
> cmGlobalGenerator::FindGeneratorTargetImpl
> +4.21%  cmake  libc-2.22.so [.] _int_malloc
> +2.67%  cmake  cmake[.] cmCommandArgument_yylex
> +2.09%  cmake  libc-2.22.so [.] _int_free
> +2.06%  cmake  libc-2.22.so [.] __memcmp_sse4_1
> +1.84%  cmake  libc-2.22.so [.] malloc
> 
> This already shows you that you can gain a lot by reducing the number of
> allocations done. Heaptrack is a good tool for that.

Next question would be: who is calling malloc?  Or rather, what % of callers
are std::string, std::vector, other STL classes vs custom data structures?
Next question would be: what is the size of those mallocs, for each caller?

(Sorry I don't currently have an environment set up with a profiler to test
this myself at the moment.) 

> Similarly, someone should
> investigate cmGlobalGenerator::FindGeneratorTargetImpl. That does a lot of
> string comparisons to find targets from my quick glance, so indeed could
be
> sped up with a smarter string class.
> 
> But potentially you could also get a much quicker lookup by storing a hash
> map of target name to cmGeneratorTarget.

Indeed; there has got to be a way to reduce the complexity of that function
in number of targets compared, if not the low-level string comparison itself
as well.  For example, if target names are short-ish, the string class has
large enough SSO, and the underlying string class made use of vector CPU
instructions for comparison, there is probably very little to be gained
without such a hash map.  (On the other hand, if some of the previous
assumptions are not true on some common CMake platforms) 

> Seems like there's more than enough areas one could (and should) optimize
> CMake.

Indeed.  Another idea - probably unrelated to the string allocations issue,
but still - that came to mind: what if link-time code
generation/optimization is turned on?  IIRC this is not default in CMake.
Maybe CMake is sufficiently well-organized (e.g. small functions
implementations moved to header files) such that what needs to be inlined
across units, is already being inlined.  Then again, maybe it's not.  I've
seen other projects rely on this feature to keep clean organization by
keeping implementations in .CPP files without sacrificing performance, and
when you turn off LTCG performance takes a major hit... 

Also IIRC there are still a few optimizations that are turned off when CMake
is built with RelWithDebInfo instead of Release.  I forget the exact
specifics at the moment but e.g. on Visual C++ when you ask it to turn on
debug symbols, it will change the default values of some optimization flags.
So a cursory examination of the flags wouldn't reveal all cases.

However, one of my bigger performance gripes, being a primarily Windows
developer right now, is the process creation overhead, especially during
configuration.  I think that is completely dominating over any CMake code
being run internally.  It would be nice if that could be parallelized on my
6-core hyper-threaded CPU, but doing so properly 

[Cmake-commits] CMake branch, release, updated. v3.4.2-3-g0aef6f2

[Brad King]

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  0aef6f2412177a236deb292654402518777f3cb0 (commit)
  from  7b8bec7a944acbebb71adf6ef1d6a561a3444076 (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:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.4.2-910-gc4e1bc6

[Brad King]

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  c4e1bc6ed24d57ef3136756802aa575642927ff1 (commit)
   via  0aef6f2412177a236deb292654402518777f3cb0 (commit)
  from  f9cc671364d86a33399f7293aae9b145d7f90d94 (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:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.4.2-2102-gc220f4e

[Brad King]

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, next has been updated
   via  c220f4e80728c2b39db6d375c0a8d9667769cd08 (commit)
   via  c4e1bc6ed24d57ef3136756802aa575642927ff1 (commit)
  from  9b24c2fbefae8427a67392ca1f92a733c60496d9 (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=c220f4e80728c2b39db6d375c0a8d9667769cd08
commit c220f4e80728c2b39db6d375c0a8d9667769cd08
Merge: 9b24c2f c4e1bc6
Author: Brad King 
AuthorDate: Mon Jan 25 13:23:15 2016 -0500
Commit: Brad King 
CommitDate: Mon Jan 25 13:23:15 2016 -0500

Merge branch 'master' into next


---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] [ANNOUNCE] CMake 3.4.3 available for download

[Gonzalo Garramuño]

On 25/01/2016 04:36 p.m., Robert Maynard wrote:

We are pleased to announce that CMake 3.4.3 is now available for download.

Please use the latest release from our download page:
   https://cmake.org/download/


Brad,

Does this one have the fix for the FLTK_WRAP_UI?

--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Anyone going to FOSDEM?

[Stephen Kelly]

Benjamin Eikel wrote:

> Hi Gregor,
> 
> Am Mittwoch, 30. Dezember 2015, 14:33:08 schrieb Gregor Jasny via cmake-
> developers:
>> Hello,
>> 
>> I wonder if any of you CMake Developers go to FOSDEM [1] this year?
> 
> I am not a CMake developer, but, more or less, an advanced user, but I
> will go to FOSDEM next year. ;-)
> At least Stephen Kelly [2] will be there, too.

Yep. Maybe we could arrange to meet in the Sunday evening. I leave on the 
Monday.

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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [CMake] Library target names and the ExternalProject_Add command

[Nicholas Braden]

ExternalProject makes no assumptions about what is being built. It
could just be a collection of executables, or maybe nothing is built
at all. It is up to the project being built to provide facilities for
accessing its targets in a platform-independent way. For example, the
external project can install an export file that you can include to
get the imported targets. Or, it could have a traditional
FindXXX.cmake script that you can use. Either way, ExternalProject
doesn't know about any of that - it just downloads and builds stuff.

Alternatively, you could include the external library as part of your
project and use add_subdirectory to just build it with the rest of
your project, thus giving you direct access to the targets you want.

On Mon, Jan 25, 2016 at 4:22 AM, Cedric Doucet  wrote:
>
> Hello,
>
> I use the ExternalProject_Add command to download and build a static library
> called 'foo.a'.
> I build another library 'bar' which depends on 'foo.a'.
>
> For the moment, I use the target_link_libraries command to create a link
> between foo and bar:
>
> target_link_libraries(bar ${FOO_INSTALL_DIR}/lib/foo.a)
>
> However, this approach is not portable, especially if I want foo to be a
> shared library.
> Indeed, the extension of such libraries is plateform dependent.
>
> Therefore, I tried to replace the path to foo by its name 'foo' from the
> call to the ExternalProject_Add command:
>
> target_link_libraries(bar foo)
>
> However, it does not work and I get the following error message:
>
> Target "foo" of type UTILITY may not be linked into another target.
> One may link only to STATIC or SHARED libraries, or to executables with
> the
> ENABLE_EXPORTS property set.
>
> I guess I understand that foo has the wrong type UTILITY and it would work
> only if I had defined my target like this:
>
> add_library(foo blablabla)
>
> However, I need to use the ExternalProject_Add command.
>
> Is there a way to create a library target name 'foo' in this case?
>
> Thank you!
>
> Cédric
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Shared library for a executable

[Gonzalo]

El 22/01/16 a las 10:50, Raymond Wan escribió:

Hi Gonzalo,

I recently tried doing this and wrote it up as a record for myself.
Of course, I don't know if it's the right way, but I'm doing it this
way until I figure out a better way...

See if this helps and let me know if you figure out something better:

http://www.rwanwork.info/sysdocs/cmake/overview/

Ray
Thanks, Ray.  Your approach is exactly the same as mine.  We already 
found out that the problem I was having with v3.4.2 is a bug in cmake, 
which has been fixed in the git repository.


--
Gonzalo Garramuño
ggarr...@gmail.com

--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] PROPERTY for list of link libraries

[Tamás Kenéz]

I think you need something like CMakeExpandImportedTargets.cmake (
https://cmake.org/cmake/help/latest/module/CMakeExpandImportedTargets.html).
But that module has been deprecated for a while and does not support some
newer CMake features.

Instead, feel free to try out my fork:
https://gist.github.com/tamaskenez/ef98237fff654c6d28b5 . This fork adds
support for IMPORTED_IMPLIB, INTERFACE_LINK_LIBRARIES and $
expressions.

It recursively resolves all dependencies for the given configuration
(Debug, Release, ...)

Tamas


On Fri, Jan 22, 2016 at 11:01 PM, Tom Kacvinsky <
tom.kacvin...@vectorcast.com> wrote:

> Ah yes, that was it.  Switching to 3.3.2 did the trick.  Time to upgrade
> cmake.
>
> On Fri, Jan 22, 2016 at 4:40 PM, Tom Kacvinsky <
> tom.kacvin...@vectorcast.com> wrote:
>
>> I am now having a problem with transitive dependencies.  I need all
>> libraries that are linked in.  I am missing the ones that are linked in
>> transitively.  Modified code is, ignoring J. Decker's suggestion about
>> using generator expressions to get the path to the target's output.
>>
>> get_property(libs TARGET a_target PROPERTY LINK_LIBRARIES)
>> foreach(lib ${libs})
>>   if(TARGET ${lib})
>> # If this is a library, get its transitive dependencies
>> get_property(trans TARGET ${lib} PROPERTY INTERFACE_LINK_LIBRARIES)
>> foreach(tran ${trans})
>>   if(TARGET ${tran})
>> get_property(path TARGET ${tran} PROPERTY LOCATION)
>> file(APPEND "${CMAKE_BINARY_DIR/libs.txt" "${path}\n")
>>   endif()
>> endforeach()
>> get_property(path TARGET ${lib} PROPERTY LOCATION)
>> file(APPEND "${CMAKE_BINARY_DIR}/libs.txt" "${path}\n")
>>   else()
>> file(APPEND "${CMAKE_BINARY_DIR}/libs.txt" "${lib}\n")
>>   endif()
>> endforeach()
>>
>> I am using cmake 2.8.11.2, perhaps this property doesn't do what I
>> thought it would with this version of cmake?
>>
>> Thanks,
>>
>> Tom
>>
>> On Fri, Jan 22, 2016 at 9:23 AM, Tom Kacvinsky <
>> tom.kacvin...@vectorcast.com> wrote:
>>
>>> I have need for a cross platform methods of getting libraries linked
>>> into an executable.
>>>
>>> Say for instance, we have
>>>
>>> add_library(foo STATIC a.c)
>>> add_exceutable(bar b.c)
>>> target_link_libraries(bar foo)
>>>
>>> So I know for that bar has a dependency on foo.lib (on Windows) and
>>> libfoo.a on Linux.
>>>
>>> And so forth.  What I would like to do is after everything is set up,
>>> query the properties of bar
>>> and find the list of libraries linked into bar in such a fashion I get
>>> that platform's specific library name (instead of the library's target
>>> name).
>>>
>>> IS this possible?  I read the docs and didn't see a property for
>>> getting this list.  Did I miss something?  If so I plan on using
>>> either get_property of get_target_property.
>>>
>>> Thanks.
>>>
>>
>>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake Daemon blog

[Tamás Kenéz]

That's great and really does open a new world for IDEs!
Tamas

On Sun, Jan 24, 2016 at 11:44 PM, Stephen Kelly  wrote:

> Hi,
>
> I just made a blog and video about the advanced features and possibilities
> that a daemon mode for CMake can bring:
>
>  https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/
>
> I'll make the code available by the end of the week. I still want to clean
> it up a little bit first :).
>
> 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:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] Library target names and the ExternalProject_Add command

[Cedric Doucet]

Hello,

I use the ExternalProject_Add command to download and build a static library 
called 'foo.a'.
I build another library 'bar' which depends on 'foo.a'.

For the moment, I use the target_link_libraries command to create a link 
between foo and bar:

target_link_libraries(bar ${FOO_INSTALL_DIR}/lib/foo.a)
However, this approach is not portable, especially if I want foo to be a shared 
library.
Indeed, the extension of such libraries is plateform dependent.

Therefore, I tried to replace the path to foo by its name 'foo' from the call 
to the ExternalProject_Add command:

target_link_libraries(bar foo)
However, it does not work and I get the following error message:

Target "foo" of type UTILITY may not be linked into another target.
One may link only to STATIC or SHARED libraries, or to executables with the
ENABLE_EXPORTS property set.

I guess I understand that foo has the wrong type UTILITY and it would work only 
if I had defined my target like this:
  
add_library(foo blablabla)

However, I need to use the ExternalProject_Add command.

Is there a way to create a library target name 'foo' in this case?

Thank you!

Cédric

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Shared library for a executable

[Tamás Kenéz]

Gonzalo, Ray,

I think your approaches are not in accordance with some CMake best
practices (or at least what I believe they are).

Please take a look at Ray's example after a heavy refactor:
https://github.com/tamaskenez/cmake-2016-jan-21-shared-lib-exe

These are the things I changed:

- In your test executables don't compile the source files of the
library-under-test into your test. Instead, link to the library. Reason (1)
ODR, (2) this way you'll test the linking operation, too.
- Don't reach out from a subdirectory ('B') to include a sibling ('A'). It
creates harmful coupling between the subdirectories. All information that
'B' needs to know about 'A' should be concentrated in the properties of the
target 'A'. So you need to use commands like target_include_directories().
- Unnecessary verbosity makes it harder to read and debug the CMakeLists.

With my changes:

- you can build and test 'A' standalone
- you can build and test 'A', 'B' and 'X' in one project using the
top-level CMakeLists.txt
- you can't build 'B' standalone or can't build 'X' without 'A' and 'B'
being there. If you need that feature, we need to add an install step to
'A' and 'B' and use find_package() in 'B' and 'X' on demand

Tamas



On Mon, Jan 25, 2016 at 10:22 AM, Gonzalo  wrote:

>
>
> El 22/01/16 a las 10:50, Raymond Wan escribió:
>
>> Hi Gonzalo,
>>
>> I recently tried doing this and wrote it up as a record for myself.
>> Of course, I don't know if it's the right way, but I'm doing it this
>> way until I figure out a better way...
>>
>> See if this helps and let me know if you figure out something better:
>>
>> http://www.rwanwork.info/sysdocs/cmake/overview/
>>
>> Ray
>>
> Thanks, Ray.  Your approach is exactly the same as mine.  We already found
> out that the problem I was having with v3.4.2 is a bug in cmake, which has
> been fixed in the git repository.
>
> --
> Gonzalo Garramuño
> ggarr...@gmail.com
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

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

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

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

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

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