Re: [CMake] Building third party libraries along with normal targets

[Tamás Kenéz]

[about shell script portability]

We do use shell-scripts on Windows since git-bash comes with git for free.
Our workflow is centered around the command-line (git-bash for Windows) and
you can run shell scripts in git-bash, that's why compatibility is not a
problem. All our scripts and workflows are the same on all our platforms
(windows, linux, mac).

This is an issue only if you're not using git on Windows so adding git-bash
to the workflow would be an extra hassle.


On Thu, Mar 30, 2017 at 3:45 PM, Robert Dailey <rcdailey.li...@gmail.com>
wrote:

> On Thu, Mar 30, 2017 at 3:42 AM, Tamás Kenéz <tamas.ke...@gmail.com>
> wrote:
> > An alternative to the CMake superbuild: leave your actual project intact.
> > Simply create a separate shell script which builds all the dependencies
> (by
> > running cmake commands). Or, if you do like the ExternalProject stuff,
> > create a superbuild which builds only the dependencies.
>
> Problem with that is that it's not a portable solution. The #1 benefit
> of using CMake superbuilds (supplied with CMake build solution for the
> target library) is that it will function correctly on all platforms.
>
-- 

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] Building third party libraries along with normal targets

[Tamás Kenéz]

An alternative to the CMake superbuild: leave your actual project intact.
Simply create a separate shell script which builds all the dependencies (by
running cmake commands). Or, if you do like the ExternalProject stuff,
create a superbuild which builds only the dependencies.

Tamas

On Thu, Mar 30, 2017 at 5:01 AM, Florent Castelli <
florent.caste...@gmail.com> wrote:

> On 30/03/2017 04:38, Robert Dailey wrote:
>
>> At the end of the day, I've solved the Boost problem but I have many
>> other libraries I still manually build: openssl, libpng, zlib, etc.
>> It's as you said, maintaining build scripts for all of these will be
>> challenging but I think that's the proper way to go in my specific
>> situation (multi platform). It'll be less maintenance than rebuilding
>> binaries 3x per each.
>>
>> Do you know how to set up the boost cmake project I linked on github
>> to work with superbuild? And do you prefer your superbuild execution
>> to happen during cmake generate (basically cmake invokes itself for
>> the superbuild) or do you prefer a separate external run, independent
>> of the normal one (basically 2x cmake invocations)?
>>
>> Do you know of similar projects for other libraries I mentioned? Could
>> hand write my own, but seems better to piggyback on someone else's
>> efforts.
>>
>> Thanks for your feedback!
>>
>
> Only a few libraries are tricky to build, libpng or zlib are trivial for
> example.
>
> A super-build is just having one big project and defining all the targets
> directly in there, using external CMake build scripts through
> add_subdirectory() for example. There is just one CMake invocation.
> This is how my Boost CMake project (yes, I'm the one being it) works. As
> for the Boost dependencies, are you really using them? If you're not, then
> you don't need to build the parts of Boost using them, most are optional.
> If you do, then you can provide Find*.cmake scripts returning targets
> you've built yourself currently. Feel free to create issues on the bug
> tracker if you need assistance with that.
>
> I don't know on the top of my head similar projects for all libraries, but
> I know there are many people writing CMake build scripts for all kind of
> libraries, so just search on the web :)
>
> /Florent
>
>
> --
>
> 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/opensou
> rce/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] Interfacing cmake with 3rdparties package manager, and exclude them from ninja clean

[Tamás Kenéz]

Maybe executing your script in configure time (execute_process)?

On Fri, Jan 20, 2017 at 4:36 PM,  wrote:

> Hello,
>
> I'm working on a project where some of our libs depend on custom build of
> some external libraries.
> Those external libraries are managed through a repository manager similar
> to rpm (redhat package manager) which allows us to retrieve pre-compiled
> versions with related header files. (similar to devel packages)
>
> The catch is we want libraries to be downloaded automatically to a shared
> (multiple users) local dir __AND__ we don't want them to be cleaned.
> (because another user could be using it).
>
> I've tried add_custom_command but files disappear with make clean.
> I've tried to set NO_CUSTOM_CLEAN, that works with make but not with ninja.
>
> I've tried to chain add_custom_target to download the file and
> add_dependencies, again, this works with make but not with ninja (ninja
> does not know how to create protocol buffer compiler "protoc" for example
> since it's not the output of any command he knows)
>
> I've tried externalproject_add with BUILD_BYPRODUCTS but it looks like
> ninja still clean the downloaded files.
>
> Any idea on how to make ninja not clean those downloaded files (we use
> generators like protoc, libraries and header files)
>
> With regards
>
> David
>
> PS : in my add_custom_command/add_custom_target, I invoke "cmake -P" on a
> custom cmake script with 2 args. The first arg is a file to test for
> existence, the second one is the parameter to our custom "rpm" to download
> the package.
>
> --
>
> 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] Creating dependencies between static imported targets.

[Tamás Kenéz]

In my company we're doing this all the time: cmakefying thirdparty
packages. Which means one of these things: (1) fixing existing cmake
support (2) converting autotools build to cmake (3) adding cmake driver to
autotools build.


On Sun, Aug 21, 2016 at 8:56 PM, Yaron Cohen-Tal <yaro...@gmail.com> wrote:

> That would have been ideal, however it seems to me not many packages ship
> with cmake config module files..
>
> On Sun, Aug 21, 2016 at 9:52 PM, Tamás Kenéz <tamas.ke...@gmail.com>
> wrote:
>
>> Defining the dependencies of an imported target should be done by the
>> target's config-module (or a file invoked by the config-module, usually
>> generated with install(EXPORT...) )
>>
>> On Sun, Aug 21, 2016 at 4:23 PM, Yaron Cohen-Tal <yaro...@gmail.com>
>> wrote:
>>
>>> Thanx!
>>>
>>> I think it would b nice though if the "target_XXX" commands would also
>>> work for imported targets, e.g.. by adding the dependency to
>>> "INTERFACE_LINK_LIBRARIES'. That way I sometimes can use the same command
>>> without checking if the depentent is imported.
>>>
>>> --
>>>
>>> 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] Creating dependencies between static imported targets.

[Tamás Kenéz]

Defining the dependencies of an imported target should be done by the
target's config-module (or a file invoked by the config-module, usually
generated with install(EXPORT...) )

On Sun, Aug 21, 2016 at 4:23 PM, Yaron Cohen-Tal  wrote:

> Thanx!
>
> I think it would b nice though if the "target_XXX" commands would also
> work for imported targets, e.g.. by adding the dependency to
> "INTERFACE_LINK_LIBRARIES'. That way I sometimes can use the same command
> without checking if the depentent is imported.
>
> --
>
> 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] Private dependencies of static libraries exported as targets

[Tamás Kenéz]

Ivan,

> But, if library `foo` is built as static, then its clients suddenly
> become required to link to `bar` as well, and this information is not
> recorded anywhere!

I changed the cmake_minimum_required version in your projects from 2.8 to
3.0 which fixed the issue.
(I tried it with cmake 3.6.1)

Tamas

On Wed, Aug 17, 2016 at 2:55 PM, Ivan Shapovalov 
wrote:

> On 2016-08-17 at 05:19 -0500, Nicholas Braden wrote:
> > Huh, this is weird. It seems to be an issue with the export/import
> > mechanism. If you make a project where everything is in the same
> > CMakeLists.txt and there is no install step, there is no include
> > directory pollution. See my attached project for example. On my
> > system
> > I run this to build:
> >
> > mkdir build && cd build && cmake -G "MinGW Makefiles" .. && cmake
> > --build . -- VERBOSE=1
> >
> > When it builds main:
> >
> > C:\MinGW\bin\g++.exe@CMakeFiles/main.dir/includes_CXX.rsp
> > -std=gnu++14 -o CMakeFiles\main.dir\main.cpp.obj -c
> > C:\Users\LB\Code\cmake-private-static-dependencies\main.cpp
> >
> > The entirety of the includes_CXX.rsp file:
> >
> > -IC:/Users/LB/Code/cmake-private-static-dependencies/c
> >
> > The project you provided definitely has the include directory
> > pollution problem - the client includes_CXX.rsp file contains an
> > -isystem directive for bar. It looks like the generated
> > FooTargets-noconfig.cmake contains this line (setting properties on
> > foo):
> >
> > IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG "bar"
> >
> > I'm not fully sure but I think this is wrong because it is saying
> > that
> > bar is a public dependency. This seems to be an oversight in CMake,
> > as
> > there is no 'private' alternative of the above variable for imported
> > targets - that is, there is no IMPORTED_LINK_LIBRARIES_NOCONFIG, thus
> > there is no way for CMake to provide special treatment as in my
> > example. It seems CMake literally converts private dependencies of
> > static libraries to public dependencies only when using the export
> > functionality.
> >
> > ...and that's as much as I can figure right now. Can you confirm that
> > my attached example doesn't exhibit the problem? If it doesn't have
> > the include directory pollution problem, I'd be inclined to say it's
> > a
> > bug with the export/import functionality.
>
> Indeed, your sample project does not exhibit include path bloat. So
> this really looks like a limitation of CMake import/export mechanism
> (I say limitation, not bug, because there are simply no target
> properties detailed enough to allow this behavior).
>
> There is a property IMPORTED_LINK_DEPENDENT_LIBRARIES_ which is
> _almost_ what we want, but just for shared libraries.
>
> --
> Ivan Shapovalov / intelfx /
>
> --
>
> 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] Why is target installation done in 2 separate steps?

[Tamás Kenéz]

I believe you can install and assign multiple targets in different
subdirectories to a single export:

/foo/CMakeLists.txt:
install(TARGETS foo EXPORT mylib-targets ...)

/bar/CMakeLists.txt
install(TARGETS bar EXPORT mylib-targets ...)

/CMakeLists.txt
install(EXPORT mylib-targets ...)

On Mon, Jul 11, 2016 at 12:26 AM, Robert Dailey 
wrote:

> Documentation states, that to export a file that imports your targets,
> you must do roughly:
>
> install(TARGETS fubar EXPORT fubar-targets)
> install(EXPORT fubar-targets DESTINATION lib/cmake/fubar)
>
> Why is this done in two steps? Based on reading the install()
> documentation, I don't see how the install(TARGETS) command is useful
> without the corresponding install(EXPORT).
>
> Can someone explain why these are separate commands instead of 1
> complete command? Thanks in advance.
> --
>
> 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] Setting properties from within a function

[Tamás Kenéz]

Okay, I see. The problem is that the ${DEF} is quoted so it won't fall
apart into separate arguments.
Tamás

On Wed, Apr 13, 2016 at 4:54 AM, Michael Surette <mjsure...@gmail.com>
wrote:

> On 2016-04-12 06:57 PM, Tamás Kenéz wrote:
>
>> I don't get how come the macro works because
>> `target_compile_definitions` needs at least 3 parameters. The second one
>> must be PRIVATE|PUBLIC|INTERFACE.
>> Tamas
>>
>> On Tue, Apr 12, 2016 at 7:43 AM, Michael Surette
>> <mjsure...@gmail.com
>> <mailto:mjsure...@gmail.com>> wrote:
>>
>> I would like to use set target properties from within a function.  ie
>>
>> function(MINE TGT DEF)
>>target_compile_definitions("${TGT}" "${DEF}")
>> endfunction(MINE TGT DEF)
>>
>> This doesn't work.  If I change it to a macro, it does.
>>
>> macro(MINE TGT DEF)
>>target_compile_definitions("${TGT}" "${DEF}")
>> endmacro(MINE TGT DEF)
>>
>> Is there a way to extend the scope of TGT in the function so that
>> the function variant works?
>>
>
> Good catch.
>
> Actually, I have the (usually PRIVATE) part as the beginning of ${DEF}.
>
> To clarify, this is a question about scoping.  If the command in the
> function was a "set" I could do
>
> set("${TGT}" "${DEF}" PARENT_SCOPE)
>
> In my example, what I want to do is set the target_compile_definitions of
> the name "${TGT}".  A function is preferable to a macro so I can avoid
> namespace collisions.
>
> This is not all that this function does of course, or I would just call
> target_compile_definitions directly, but I cut out the other stuff to
> simplify the example.
>
> Upon further thought, perhaps you are on to something, let me do some
> testing.
>
> In the meantime, any more thoughts would be appreciated.
>
>
> Mike
>
> --
>
> 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] Setting properties from within a function

[Tamás Kenéz]

I don't get how come the macro works because `target_compile_definitions`
needs at least 3 parameters. The second one must be
PRIVATE|PUBLIC|INTERFACE.
Tamas

On Tue, Apr 12, 2016 at 7:43 AM, Michael Surette 
wrote:

> I would like to use set target properties from within a function.  ie
>
> function(MINE TGT DEF)
>   target_compile_definitions("${TGT}" "${DEF}")
> endfunction(MINE TGT DEF)
>
> This doesn't work.  If I change it to a macro, it does.
>
> macro(MINE TGT DEF)
>   target_compile_definitions("${TGT}" "${DEF}")
> endmacro(MINE TGT DEF)
>
> Is there a way to extend the scope of TGT in the function so that the
> function variant works?
>
> TIA
>
> Mike
>
> --
>
> 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] Emit link commands to file?

[Tamás Kenéz]

For the "Unix Makefiles" generator, there's already a link.txt in
/CMakeFiles/.dir

Tamas
-- 

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] -isystem suppresses warnings from user header

[Tamás Kenéz]

Thanks! I missed that property.
Tamas

On Thu, Apr 7, 2016 at 4:13 PM, Brad King <brad.k...@kitware.com> wrote:

> On 04/07/2016 10:03 AM, Tamás Kenéz wrote:
> > CMake uses "-isystem" on the compiler command line for the
> > INTERFACE_INCLUDE_DIRECTORIES of imported libraries.
> >
> > Question: is this the intended behaviour?
>
> Yes.  See discussion here:
>
> * http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7533
>
> and implementation here:
>
> * Always consider includes from IMPORTED targets to be SYSTEM.
>   https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a63fcbcb
>
> > Can I force the -I flag somehow for my library?
>
> Look at these:
>
> *
> https://cmake.org/cmake/help/v3.5/variable/CMAKE_NO_SYSTEM_FROM_IMPORTED.html
> * https://cmake.org/cmake/help/v3.5/prop_tgt/NO_SYSTEM_FROM_IMPORTED.html
>
> -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-developers] -isystem suppresses warnings from user header

[Tamás Kenéz]

Environment: CMake 3.5, linux, g++

CMake uses "-isystem" on the compiler command line for the
INTERFACE_INCLUDE_DIRECTORIES of imported libraries.

Unfortunately including a header via an isystem path suppresses warnings
emitted from the header, such as warnings caused by expansions of macros
defined in that header.

Example: I have a printf-like LOG(...) macro which expands to a function
marked as printf-like. The -Wformat warnings are suppressed if the
containing log.h is found on isystem path.

Question: is this the intended behaviour? Can I force the -I flag somehow
for my library? (I'm aware of CMAKE_INCLUDE_SYSTEM_FLAG_CXX but I don't
want to modify all the client projects that uses my library.)

Or is it bug?

Thanks,
Tamas
-- 

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] Building a tool immediately so it can be used later in same CMake run

[Tamás Kenéz]

Craig,

I'm sorry for my previous answer which I wrote in haste. Now I've read your
SO post and realized the question is a bit more complex then "is
execute_process safe instead of ExternalProject".

Anyway I still think your approach is basically correct. I have the
following comments:

- I wouldn't re-use the current build dir and would build mycomp always in
it's own build dir. Also, I'd always use the plain default cmake generator
(which is a must when crosscompiling anyway). No need to forward any
settings to it from the superbuild. Also, I'd always build the Release
config for mycomp.

- You could "install(TARGETS mycomp DESTINATION bin)" in your EARLY_BUILD
then later use "find_program(mycomp_EXECUTABLE mycomp ...) later to save
guessing the executable's name.

Tamas

On Fri, Apr 1, 2016 at 9:25 PM, Tamás Kenéz <tamas.ke...@gmail.com> wrote:

> Craig,
>
> My cmake-based build system in my company's CI framework works exactly
> that way: there's a generic cmake script[1] (invoked with cmake -P) that
> reads in a file which contains repo-urls and build parameters for 50+
> projects and builds them for 3 platforms (linux, win, mac) 5 compilers
> (cross-compilers, too) invoking child cmake builds with execute_process.
> This is done after each push and one daily clean build.
>
> I've never had any problems with that approach.
>
> On the other hand, the system was originally designed with ExternalProject
> and I had many problems.
>
> [1]: https://github.com/tamaskenez/centralbuilder
>
> Tamas
>
>
>
> On Fri, Apr 1, 2016 at 1:53 AM, Craig Scott <craig.sc...@crascit.com>
> wrote:
>
>> All,
>>
>> I originally planned to ask this question directly on this mailing list,
>> but it got a bit more involved, so I posted it to stackoverflow instead.
>> I'm interested if anyone can shed some more authoritative light on the
>> proposed method for the following question:
>>
>> http://stackoverflow.com/q/36084785/1938798
>>
>> *Short version*: invoke a nested cmake-and-build immediately within the
>> main CMake run to build a specific target via execute_process(). This makes
>> that tool available for use still within the same (main) CMake run. An
>> ExternalProject-based technique would normally be a better solution, but in
>> this particular case, that wasn't possible.
>>
>> I'd be interested if anyone can confirm whether the suggested approach is
>> guaranteed to be safe for all generators and platforms, or whether there
>> are other factors I have not considered in the proposed technique.
>>
>> Cheers
>>
>> --
>> Craig Scott
>> Melbourne, Australia
>> http://crascit.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

Re: [CMake] Building a tool immediately so it can be used later in same CMake run

[Tamás Kenéz]

Craig,

My cmake-based build system in my company's CI framework works exactly that
way: there's a generic cmake script[1] (invoked with cmake -P) that reads
in a file which contains repo-urls and build parameters for 50+ projects
and builds them for 3 platforms (linux, win, mac) 5 compilers
(cross-compilers, too) invoking child cmake builds with execute_process.
This is done after each push and one daily clean build.

I've never had any problems with that approach.

On the other hand, the system was originally designed with ExternalProject
and I had many problems.

[1]: https://github.com/tamaskenez/centralbuilder

Tamas



On Fri, Apr 1, 2016 at 1:53 AM, Craig Scott  wrote:

> All,
>
> I originally planned to ask this question directly on this mailing list,
> but it got a bit more involved, so I posted it to stackoverflow instead.
> I'm interested if anyone can shed some more authoritative light on the
> proposed method for the following question:
>
> http://stackoverflow.com/q/36084785/1938798
>
> *Short version*: invoke a nested cmake-and-build immediately within the
> main CMake run to build a specific target via execute_process(). This makes
> that tool available for use still within the same (main) CMake run. An
> ExternalProject-based technique would normally be a better solution, but in
> this particular case, that wasn't possible.
>
> I'd be interested if anyone can confirm whether the suggested approach is
> guaranteed to be safe for all generators and platforms, or whether there
> are other factors I have not considered in the proposed technique.
>
> Cheers
>
> --
> Craig Scott
> Melbourne, Australia
> http://crascit.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

Re: [cmake-developers] CMake aliasing system

[Tamás Kenéz]

Ruslo, I think we all could argue both against and for implementing
cmake-ini files inside the cmake command. I mean I'm also aware of all the
pros and cons. It's just that we weigh differently.
I like loosely connected simpler building blocks and my own cmake-wrapping
extension script works fine, that's why I thought you would not lose
anything with that.

>> git commit --author="John Doe" --email="john@example.com"
<john@example.com> --branch="master"
>> git push --remote="git://awesome.example.com"
> This is a complete nonsense!

I agree and that's why I think cmake ini files is a good idea.

Tamas

On Tue, Mar 15, 2016 at 3:25 AM, Ruslan Baratov <ruslan_bara...@yahoo.com>
wrote:

> On 15-Mar-16 02:42, Tamás Kenéz wrote:
>
> I also doubt this belongs to upstream. But you could write a single,
> generic script which forwards its arguments to cmake and also accepts and
> processes the additional parameters along the way. I don't think we'd lose
> anything:
>
> cmakeini -c ipad -H. -DTHIS_WILL_BE_FORWARDED=AS_IT_IS
>
> This is the approach I took as I needed features like you described. But
> if there would be a mature, versatile, community-tested script I'd be
> willing to use it and contribute to it.
>
> As you can see I'm already using script `build.py` and there is not enough
> power for now (even if it extends CMake basic functionality a lot) so I was
> thinking to introduce global/local ini-configuration file anyway. Then I
> realize that most of the `build.py` functions can be implemented in such
> ini-configuration. So why not use CMake? Why for example not extend CMake
> GUI with this feature support? Why do users need to install some extra
> tools instead of just one?
>
> Global/local configuration files in not something special. Git for example
> has same system, yes it increase complexity but literally every user store
> setting there.
> Just imagine you have to write something like this every commit + push:
>
> > git commit --author="John Doe" --email="john@example.com"
> <john@example.com> --branch="master"
> > git push --remote="git://awesome.example.com"
>
> This is a complete nonsense!
>
> So I'm planning to make a fork anyway and do some experiments even if it
> will not accepted to upstream.
>
> Ruslo
>
>
> Tamas
>
> On Mon, Mar 14, 2016 at 4:22 PM, Ruslan Baratov via cmake-developers <
> <cmake-developers@cmake.org>cmake-developers@cmake.org> wrote:
>
>> On 14-Mar-16 21:59, Brad King wrote:
>>
>>> On 03/12/2016 08:04 AM, Ruslan Baratov via cmake-developers wrote:
>>>
>>>> I guess it is a well known fact that cmake command is almost never
>>>> executed alone and for non-trivial examples usually hold some extra
>>>> arguments (home directory, build directory, verbosity level, toolchains,
>>>> options, ...). Also I guess that such commands doesn't change from
>>>> day-to-day development process and an obvious way to reduce typing is to
>>>> create wrapper build scripts (.bat or .sh, I personally use a Python
>>>> one).
>>>>
>>> Sorry, I don't think something like this belongs upstream.  It can easily
>>> be done with shell aliases or other custom scripts.
>>>
>> I've got quite opposite experience. It's hard to say that family of
>> custom scripts (+ a lot of environment variables in .bashrc)  is an "easy
>> shell scripting", example:
>> *
>> https://github.com/ruslo/polly/blob/162cd157d1d05261a7a708435197d883c4209005/bin/build.py
>>
>>We shouldn't increase the complexity of the CMake command line
>>> interface further.
>>>
>> To be clear this feature required only one new CMake option. The rest is
>> responsibility of some pre-build parsing module.
>>
>> In general I feel sad that CMake will not became more user-friendly in
>> this exact part. Though the only proves of my point that can be provided
>> here is a users experience. Since I don't see any feedback here I'm out of
>> arguments...
>>
>> Ruslo
>>
>> --
>>
>> 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/hel

Re: [cmake-developers] CMake aliasing system

[Tamás Kenéz]

I also doubt this belongs to upstream. But you could write a single,
generic script which forwards its arguments to cmake and also accepts and
processes the additional parameters along the way. I don't think we'd lose
anything:

cmakeini -c ipad -H. -DTHIS_WILL_BE_FORWARDED=AS_IT_IS

This is the approach I took as I needed features like you described. But if
there would be a mature, versatile, community-tested script I'd be willing
to use it and contribute to it.

Tamas

On Mon, Mar 14, 2016 at 4:22 PM, Ruslan Baratov via cmake-developers <
cmake-developers@cmake.org> wrote:

> On 14-Mar-16 21:59, Brad King wrote:
>
>> On 03/12/2016 08:04 AM, Ruslan Baratov via cmake-developers wrote:
>>
>>> I guess it is a well known fact that cmake command is almost never
>>> executed alone and for non-trivial examples usually hold some extra
>>> arguments (home directory, build directory, verbosity level, toolchains,
>>> options, ...). Also I guess that such commands doesn't change from
>>> day-to-day development process and an obvious way to reduce typing is to
>>> create wrapper build scripts (.bat or .sh, I personally use a Python
>>> one).
>>>
>> Sorry, I don't think something like this belongs upstream.  It can easily
>> be done with shell aliases or other custom scripts.
>>
> I've got quite opposite experience. It's hard to say that family of custom
> scripts (+ a lot of environment variables in .bashrc)  is an "easy shell
> scripting", example:
> *
> https://github.com/ruslo/polly/blob/162cd157d1d05261a7a708435197d883c4209005/bin/build.py
>
>We shouldn't increase the complexity of the CMake command line
>> interface further.
>>
> To be clear this feature required only one new CMake option. The rest is
> responsibility of some pre-build parsing module.
>
> In general I feel sad that CMake will not became more user-friendly in
> this exact part. Though the only proves of my point that can be provided
> here is a users experience. Since I don't see any feedback here I'm out of
> arguments...
>
> Ruslo
>
> --
>
> 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

Re: [CMake] Help for a cmake newbie

[Tamás Kenéz]

Vadtec,

> My main problem is getting cmake to use only my locally
installed/compiled copies of the libs. I need those libs to live along side
the binaries, and using the versions I compile is important.

I'll answer the question of finding the libraries and not the building
problem. We (in my company) are facing similar problems. This is the
workflow which has been working for us:

1. we make sure that all 3rdparty dependencies can be built with CMake and
install a config-module

Note that the "can be built with CMake" needs to be interpreted loosely:

- some 3rdparty libs already provide CMake builds which can be used as is.
In case of anything is missing (config-module) we fork and modify
- when a 3rdparty lib uses autotools we rewrite its build system in CMake
for windows compatibility
- in case the lib's build system is too complex we just wrap it in a CMake
build which launches autotools and also installs a config-module
- when only the binaries of the 3rdparty lib are available we create a
CMakeLists for the lib which detects the platform, installs the required
binaries and config-modules

In any case we end up having a project that can be built with cmake command
lines and installs a proper config-module.

2. For these 3rdparty libs we don't use the find-modules distributed with
CMake. We Set the CMAKE_PREFIX_PATH to the install prefix where we
installed our 3rdparty deps to make sure only those will be found by our
own projects.

On Sun, Jan 31, 2016 at 9:40 AM, Cristian Adam 
wrote:

> On 31-Jan-16 03:42, vadtec wrote:
>
>
> curl, libiconv, libpng, libssh2, and zlib are the libs I want to build and
> use both on Linux and Windows. I know all of those are available on Linux
> and I could use the system installed versions, but I want to use the same
> vesions on Windows as well. The server is only built on Linux, while the
> client needs to be built for Linux and Windows. All the libs, headers, etc
> go into the build directory, and the final "make install" puts everything
> into the bundle directory, so it can be packaged for distribution.
>
>
> Have a look at hunter  – Cross-platform
> package manager for C++ (based on CMake ExternalProject).
>
> Hunter has CMake versions for:
>
>- libpng 
>- libssh2 
>- zlib 
>
> Curl  has CMake support by itself. The
> only library missing is libiconv. It seems that
> LuaDist project has added  a CMake build here
> .
>
> You could either take all the libraries and include in your project or
> open hunter tickets. 
>
> Cheers,
> Cristian.
>
> --
>
> 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] seeking advice for building and testing variants

[Tamás Kenéz]

You can build the N variants from the same CMakeLists.txt in a single
directory.

On Wed, Jan 27, 2016 at 3:24 PM, Vania Joloboff 
wrote:

> Hi
>
> We have a library that we want to build with N different variants
>  in the compile flags for the same source code.
> Then in the test phase, I want to build N versions of a benchmark
> linked with the N versions of the library, then run the benchmark
> and compare.
>
> I can create N subdirectories (one for each variant) in my source dir
> with a CMakeLists.txt in each directory that will set  the compile flags
> for that variant and build the benchmark for that variant.
>  I will get N build directories.
>
> Is this the 'recommended' way of doing in this case,
> or there would be a smarter way ?
>
> Vania
>
> --
>
> 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] 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

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

Re: [CMake] exclude a dependency from export

[Tamás Kenéz]

The PRIVATE keyword for `target_link_libraries` has no effect on the
visibility of the names.
If `A` is static and `B` is shared then I think

target_link_libraries(B PRIVATE A)
install(TARGETS B ...)

should work for you.

Of course, if B static then it won't work. For that case they've introduced
the OBJECT library.  It has it it's own shortcomings but I've successfully
used it for the 'B'-is-static case.

Tamas

On Fri, Jan 22, 2016 at 8:20 PM, Jack Stalnaker 
wrote:

> Private doesn't work because the names in A need to be part of the public
> interface.
>
> On Fri, Jan 22, 2016 at 11:51 AM, Nicholas Braden <
> nicholas11bra...@gmail.com> wrote:
>
>> Have you tried using the PRIVATE keyword when linking to A?
>>
>> https://cmake.org/cmake/help/latest/command/target_link_libraries.html#libraries-for-a-target-and-or-its-dependents
>>
>> On Fri, Jan 22, 2016 at 9:14 AM, Jack Stalnaker 
>> wrote:
>> > Is there any way to exclude a dependency from an export? If I build a
>> static
>> > library target "A" but do not wish to install it, and then link that
>> target
>> > to another target "B" using target_link_libraries(B A), and then
>> attempt to
>> > export B, I get the error message:
>> >
>> > install (EXPORT "B" ...) includes target "B" which requires target "A"
>> that
>> > is not in the export set.
>> >
>> > I can solve the problem by installing A, but there is no need to. It is
>> a
>> > temporary target that is statically linked. I just need to export for
>> > creating a package config file, so there's no need for the package
>> config to
>> > ever need to worry about statically linked libraries.
>> >
>> > Is there a workaround for this?
>> >
>> > Long story short, I am trying to replicate convenience libraries from
>> > autotools. I'm having a hell of time doing it. I can use lists of
>> sources,
>> > but that requires passing around global variables that include the
>> sources
>> > and others that include the required libraries. This is far messier and
>> far
>> > less convenient. I've tried object libraries, and while they eliminate
>> the
>> > global source variables and prevent rebuilding things, they fail when
>> the
>> > source is nested, and you want to build a "super library" from smaller
>> > object libraries, which I believe is a fairly common working pattern.
>> > Building a static library that is never installed works really well ...
>> > until I go to create a package config file. Then this export fails.
>> >
>> > Thanks,
>> > --Jack
>> >
>> > --
>> >
>> > 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
>
-- 

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] install(EXPORT) with PRIVATE dependency: possible bug

[Tamás Kenéz]

It seems that the names of the PRIVATE dependencies of a library are not
affected by either the NAMESPACE option or the EXPORT_NAME property. A
minimal example:

add_library(one STATIC ...)
add_library(two STATIC ...)
target_link_libraries(two PRIVATE one)
install(TARGETS one two EXPORT targets DESTINATION lib)
install(EXPORT targets NAMESPACE ns:: DESTINATION cmake)

The generated `targets.cmake` describes the dependency relation with:

set_target_properties(ns::two PROPERTIES
  INTERFACE_LINK_LIBRARIES "\$"
)

That is, it uses `one` instead of `ns::one`. Changing the EXPORT_NAME of
`one` has no effect either.

It works find if I replace PRIVATE with PUBLIC or INTERFACE (of course
there'll be no more LINK_ONLY genexp in that case).

Is this really a bug or did I miss something? I also searched Mantis and
haven't found anything related.

Tamas
-- 

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

[Tamás Kenéz]

Looking at what kind of mistakes the newcomers make, I think it's rather
the global workflow and the roles of certain key variables/properties they
don't get.

At first their problem is not that they can't make a for-loop or increment
a variable. It's that they don't understand how the build and install
phases relate to each other, how to organise the files and targets of a
multi-target project, how to connect two projects. These would be just as
difficult to grasp in Python or Lua as it is in CMake-script.

I support replacing the CMake language but in order to lower the barrier I
think 10-20 nice, minimal sample projects would be more important.

Tamas


On Wed, Jan 13, 2016 at 2:14 PM, Charles Huet 
wrote:

> I don't think this is a dumb question, actually this is part of the
> problem I think would be resolved whit a new language.
>
> The barrier of entry to using CMake is too high in my opinion, and I think
> using an existing language would lower it *a lot*.
>
> Thanks for sharing :)
>
>
> Le mer. 13 janv. 2016 à 10:59, yann suisini  a
> écrit :
>
>> Hi,
>>
>> I'm a new user of CMake, but I just want to express my newcomer point of
>> view.
>> Honestly , I can feel the power of CMAKE, but it's a real pain to learn
>> ...
>> I'm using CMAKE for an embedded platform with a non GNU compiler , ant at
>> the end the CMAKE description is longer than the one I built directly in
>> Ninja.
>> I had to write a python script to parse my eclipse project xml to create
>> a list of sources files usable by CMAKE.
>> The first thing I thought was: why this is not a part of cmake ? And the
>> second thing was : why not using the scripting power of an existing
>> language like Python(or other one)
>> and add CMAKE as a framework / library ?
>> Probably a dumb question ! :)
>>
>> Yann
>>
>> 2016-01-13 10:34 GMT+01:00 Charles Huet :
>>
>>> Hi,
>>>
>>> > * There is a lot of code out there in the current CMake language so I
>>> do not
>>>   think it is realistic to drop it.  I'm not proposing that this change.
>>>
>>> I am. (more below)
>>>
>>> > * Many projects build elaborate macro/function systems in the CMake
>>> language
>>>   in order to end up with a declarative specification listing the actual
>>>   source files, dependencies, and usage requirements.  I'd like to offer
>>>   an alternative to this.
>>>
>>> In my experience, most of the elaborate macros/functions come either
>>> from a misunderstanding of some of CMake's internals (scope, link
>>> debug/release libs, etc) or to circumvent some shortcoming of the CMake
>>> language (e.g. no return value for functions).
>>>
>>> >  I'd like to improve this by *optionally* moving part of the
>>> specification
>>>   to a (stateless) declarative format that IDEs can load/edit/save
>>> directly
>>>
>>> Split the buildsystem in two different languages ? Would the declarative
>>> part be in a different file ?
>>> Also, the declarative part in my opinion must take advantage of the
>>> language.
>>> For instance, add a source file only for WIN32 systems should be easy in
>>> said declarative format.
>>> Using a custom language (based on JSON for instance) would mean to add
>>> conditionals, which comes back to making a custom language again.
>>>
>>>
>>> To come back to my first point, I understand completely that this would
>>> be a tremendous change, and the transition would be difficult to say the
>>> least. But I think it would be more than worth it in the long term.
>>>
>>> > The moment you make CMake scriptable in more than one language, you
>>> are forcing
>>> > every CMake user to learn that additional language because sooner or
>>> later he
>>> > will step into a third-party that is using that additional language.
>>>
>>> What I have in mind is to deprecate the current CMake language and
>>> replace it with another language. So there would be a transition period,
>>> but in the end there would only be one language again, and a better one.
>>>
>>> If CMake transitioned to python (or Lua, or whatever) newcomers to CMake
>>> would not need learn a new language (or at least learn one that has many
>>> resources, and can be used for other purposes).
>>> Old-timers would have to learn a new language (or maybe not, most
>>> programmers I know have played a bit with python to automate simple tasks),
>>> but this would be easier than learning CMake was, since there are
>>> established rules and a more consistent design to it.
>>>
>>> Of course I'm not saying this should happen overnight, nor am I saying
>>> this *must* happen, but I think discussing it can only be beneficial.
>>>
>>> I've seen lots of people wonder how to make their CMake scripts more
>>> efficient, and currently this is a very difficult thing to do, since there
>>> is no profiling possible.
>>> And who can say they never spent way too much time trying to understand
>>> why a variable was not correctly initialized ? When the configure step

Re: [cmake-developers] Using CMake as a library from Python

[Tamás Kenéz]

Charles,

I'd like to comment on a minor issue:

CMakeLists.txt files don't specify user-specific data like source and build
dirs (for a reason) yet your POC listfile contains this line:

cmake.init("Ninja", "/media/dev/src/cmaketest",
"/media/dev/build/cmaketest")

which sets the source and build directories. Is this some temporary
solution for the POC only?

Tamas

On Mon, Jan 4, 2016 at 8:41 AM, Charles Huet  wrote:

> Hi,
>
> Because of the above, I worry that you are basing your work on an old
>> version of CMake. As of April 2015 cmState is used as the interface to the
>> cache.
>
>
> Yeah, that is sadly right. I wanted to rebase on master before publishing,
> thinking it should not be too hard, and I have lots to re-do, mostly
> understand how things are done now.
>
> I did something similar some years ago with QML instead of python, so it
>> sounds interesting to me.
>
>
> I'm trying to be as declarative as possible, because really like how
> readable simple QML programs are, and I think it would be perfect for a
> buildsystem.
>
> My guess is that you are using python to instantiate a cmAddLibraryCommand
>> and then executing it.
>
>
> Actually, I'm directly using the cmMakefile, because I did not want to
> wrap all the commands, and it seemed backwards to me to wrap them.
>
> Even much of cmMakefile shouldn't be used by a new language. Instead
>> certain
>> parts of cmMakefile should be extracted as other classes
>> (cmVariableExpander
>> which should have the ExpandVariablesInString and ConfigureString stuff,
>> cmMessenger for the IssueMessage stuff, some other class for the
>> CompileFeature stuff etc). Then cmMakefile would be just about executing
>> and
>> scoping the CMake language. A new language would not need that, but would
>> use the refactored extracted classes.
>
>
> Ah, this is very interesting, thanks.
>
>
> Having said all that, Brad favors Lua I believe, and he favors a different
>> approach (which no one is working on as far as I know) to adding a new
>> language. So wait to hear from him to know whether it is something that
>> would be upstreamable.
>
>
> Have any details on the approach in question ? SWIG would allow for Lua
> bindings as easily, but I don't think having multiple languages would be a
> good idea.
> I went with Python because I'm familiar with it and have already written
> bindings for it with SWIG. Also, buildbot is written in python and it could
> provide a really interesting integration I think.
>
> I would guide/support you in refactoring cmake as needed. The refactoring
>> part would definitely be upstreamable. I would very much like to see a
>> proof
>> of concept alternative language even if that wasn't upstreamed. It would
>> prove that another language is possible, and that's one of the steps to
>> replacing the current cmake language I think.
>
>
> I will need to work on it to make it work again with master, but I'll try
> and do this soon.
>
> Here is what my test POC looked like for generating a simple shared
> library:
>
> #!/usr/bin/env python
>> # -*- coding: utf-8 -*-
>> import cmake
>> cmake.init("Ninja", "/media/dev/src/cmaketest",
>> "/media/dev/build/cmaketest")
>> myProject = cmake.Project("MyTestProject")
>> myProject.targets = [ cmake.SharedLibrary("testLibrary", ["lib.cxx"]) ]
>> cmake.generate()
>
>
> Thanks a lot for your comments, I'm happy to see this was not just a dumb
> idea, and that others have thought about it.
>
> I'll update with the github as soon as I get it working.
>
> Best
>
>
> Le lun. 4 janv. 2016 à 01:16, Stephen Kelly  a écrit :
>
>> Charles Huet wrote:
>>
>> > * cmCacheManager::AddCacheEntry was made public, as cmake::Configure
>> > cannot be used from python (it check for the existence of a
>> CMakeLists.txt
>> > file, which does not exist in this scenario) and the cache variables it
>> > sets seem to be necessary.
>>
>> Because of the above, I worry that you are basing your work on an old
>> version of CMake. As of April 2015 cmState is used as the interface to the
>> cache.
>>
>>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6b1ad13
>>
>> Also note that the C++ interfaces in CMake are not stable. In the last
>> year
>> they have been changed utterly and that will continue to happen without
>> notice. I'm sure you know this, but I thought I'd say it anyway.
>>
>> > I will try to make a layer of abstraction on top of the python bindings
>> > before publishing this work on github, in order to show the syntactic
>> > sugar python can provide, but I will publish this before if anybody is
>> > interested in working on this.
>>
>> I would be interested in seeing it.
>>
>> > Now, does anyone beside me think this is a good idea ?
>>
>> I did something similar some years ago with QML instead of python, so it
>> sounds interesting to me.
>>
>> In fact, one of the reasons for introducing cmState and doing all the
>> refactoring I did in cmake was to make it possible to 

Re: [CMake] Are the poor reviews of Mastering CMake Justified?

[Tamás Kenéz]

Jake,
I've read the older edition. Yes, I also think it could be written better
and most of the information is available online. Still, it provided me with
authorative information, concentrated into a single book, (as opposed to be
scattered over the internet). It really helped me to lay down the
foundations of my CMake knowledge.
Tamas

On Friday, December 18, 2015, DJ  wrote:

> I have only very recently encountered the need to use cmake. It seems this
> need came all at once out of the blue.
>
> It appears to me that there is a general perception that good tutorial
> material is in short supply. I have followed various tutorials that are
> available online and find them less than stellar. I am mostly familiar with
> gnu toolchain stuff. I admit that I am biased here because my own work
> presents zero requirement for cross-platform builds. So far I find cmake
> documentation to be considerably inferior to gnu documentation, but that's
> just me.
>
> This all led me to consider purchasing the book Mastering CMake. However,
> reviews on Amazon are generally very critical of the book. It is indeed
> expensive. Should I bother to shell out for it, or do others here share
> this negative evaluation of it? I don't want to waste my money.
>
> Best,
>
> - Jake -
>
>
> --
>
> 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] Idea: generic task-driven make-like targets with CMake

[Tamás Kenéz]

[getting offtopic] Well, not because of this script but for any serious
development on Windows I think it's a good idea to use the *nix shell
provided by the Windows Git installation, it feels quite native. Together
with cbucher's ConsoleZ you get a very convenient environment for
cmake/command-line centered development, even when working with VS IDE.

On Wed, Dec 9, 2015 at 6:43 PM, Kevin Wojniak <kain...@kainjow.com> wrote:

> Looks interesting Tamas! Too bad shell scripts don’t work natively on
> Windows :)
>
> Kevin
>
>
>
>
> On 8 Dec 2015, at 16:59, Tamás Kenéz wrote:
>
> Kevin, I have a shell script for such tasks, see
>> https://gist.github.com/tamaskenez/d4509f240f4224eb9853. Feel free to use
>> it if that's what you need.
>> It extends the `cmake` command by executing multiple, related `cmake`
>> calls
>> with one command. See docs in gist.
>>
>> Your 'make release' example looks like this:
>>
>>  cmakex cr -Hsourcedir -Bbuilddir # Configure Release
>>
>> with additional options you can do many tasks with one command
>>
>>  cmakex cbitdr -Hsourcedir -Bbuilddir -GXcode # Configure, Build,
>> Install, Test Debug & Release using Xcode
>>
>> Tamas
>>
>> On Tue, Dec 8, 2015 at 7:44 PM, Kevin Wojniak <kain...@kainjow.com>
>> wrote:
>>
>> Functionality like add_custom_target combined with script mode is close,
>>> but not quite there. add_custom_target already requires a build directory
>>> and a generator, so it’s too late. Script mode requires setting variables
>>> on the command line, so it’s too verbose. For example:
>>>
>>> if(“${ACTION}” STREQUAL “release”)
>>>  execute_process(…)
>>> endif()
>>>
>>> cmake -P myscript.cmake -DACTION=release
>>>
>>> I suppose you could have multiple *.cmake files for each task, and those
>>> could then call the master file with necessary variables set, but then
>>> you’d need one file per task and that could become excessive.
>>>
>>> Kevin
>>>
>>>
>>>
>>> On 8 Dec 2015, at 10:22, Nils Gladitz wrote:
>>>
>>> On 08.12.2015 19:04, Kevin Wojniak wrote:
>>>
>>>>
>>>>
>>>>> add_task(release
>>>>> COMMAND ${CMAKE_COMMAND} -E make_directory “build_dir”
>>>>> COMMAND ${CMAKE_COMMAND} -E chdir “build_dir” ${CMAKE_COMMAND}
>>>>> “-DCMAKE_BUILD_TYPE=Release”, “..”
>>>>> )
>>>>>
>>>>>
>>>>> There is add_custom_target().
>>>>
>>>> You can e.g. add_custom_target(release ${CMAKE_COMMAND} -E echo foobar)
>>>> and with the Makefiles generator run "make release" and with visual
>>>> studio trigger the build of the "release" project.
>>>>
>>>> For scripting you can use cmake in script mode with -P.
>>>>
>>>> e.g. given a script file release.cmake:
>>>> message("Hello World")
>>>>
>>>> add_custom_target(release ${CMAKE_COMMAND} -P
>>>> ${CMAKE_CURRENT_SOURCE_DIR}/release.cmake)
>>>>
>>>> Nils
>>>>
>>>> --
>>>
>>> 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] Idea: generic task-driven make-like targets with CMake

[Tamás Kenéz]

Kevin, I have a shell script for such tasks, see
https://gist.github.com/tamaskenez/d4509f240f4224eb9853. Feel free to use
it if that's what you need.
It extends the `cmake` command by executing multiple, related `cmake` calls
with one command. See docs in gist.

Your 'make release' example looks like this:

cmakex cr -Hsourcedir -Bbuilddir # Configure Release

with additional options you can do many tasks with one command

cmakex cbitdr -Hsourcedir -Bbuilddir -GXcode # Configure, Build,
Install, Test Debug & Release using Xcode

Tamas

On Tue, Dec 8, 2015 at 7:44 PM, Kevin Wojniak  wrote:

> Functionality like add_custom_target combined with script mode is close,
> but not quite there. add_custom_target already requires a build directory
> and a generator, so it’s too late. Script mode requires setting variables
> on the command line, so it’s too verbose. For example:
>
> if(“${ACTION}” STREQUAL “release”)
> execute_process(…)
> endif()
>
> cmake -P myscript.cmake -DACTION=release
>
> I suppose you could have multiple *.cmake files for each task, and those
> could then call the master file with necessary variables set, but then
> you’d need one file per task and that could become excessive.
>
> Kevin
>
>
>
> On 8 Dec 2015, at 10:22, Nils Gladitz wrote:
>
> On 08.12.2015 19:04, Kevin Wojniak wrote:
>>
>>>
>>> add_task(release
>>> COMMAND ${CMAKE_COMMAND} -E make_directory “build_dir”
>>> COMMAND ${CMAKE_COMMAND} -E chdir “build_dir” ${CMAKE_COMMAND}
>>> “-DCMAKE_BUILD_TYPE=Release”, “..”
>>> )
>>>
>>>
>> There is add_custom_target().
>>
>> You can e.g. add_custom_target(release ${CMAKE_COMMAND} -E echo foobar)
>> and with the Makefiles generator run "make release" and with visual
>> studio trigger the build of the "release" project.
>>
>> For scripting you can use cmake in script mode with -P.
>>
>> e.g. given a script file release.cmake:
>>  message("Hello World")
>>
>> add_custom_target(release ${CMAKE_COMMAND} -P
>> ${CMAKE_CURRENT_SOURCE_DIR}/release.cmake)
>>
>> Nils
>>
> --
>
> 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] 3.4.1 installer overwrites Windows PATH system var

[Tamás Kenéz]

about recovering the path see
http://superuser.com/questions/523688/deleted-path-environment-variable-how-to-restore

On Thursday, December 3, 2015, Brad King  wrote:

> On 12/03/2015 11:04 AM, Vasily Vladimirovich Vylkov wrote:
> > Installing CMake on Windows (7, 64-bit) with the "add cmake to system
> > PATH for all users" option overwrote the contents of my PATH variable,
> > instead of appending to it.  This is horrible!  I don't know of any
> > way to recover my previous PATH value.
> >
> > It also looks like this has been an issue in several previous versions:
> >   * https://cmake.org/Bug/view.php?id=10257
> >   * https://cmake.org/Bug/view.php?id=12875
> >
> > Shouldn't there be a regression / sanity test case for this prior to
> > publishing a new version of the installer?
>
> For every new release binary we run the installer by hand to verify
> that the interaction works.  This doesn't happen to us.
>
> The installer is produced with NSIS.  I wonder if this is a case of:
>
>
> http://stackoverflow.com/questions/21897103/nsis-envvarupdate-overwrites-system-path-when-path-is-too-long-is-there-a-wor
>
> How long was your PATH before?
>
> -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
>
-- 

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] actually using cmake alternative to convenience libraries

[Tamás Kenéz]

> I'd prefer using the PARENT_SCOPE option here...

Jack's initial email continues with "but now the variable is not visible to
baz.c" so using PARENT_SCOPE does not meet his requirements.

> which will make the variables available in the parent CMakeLists.txt.

So does using cache variables.



On Fri, Nov 20, 2015 at 3:18 PM, Mark Stijnman <mark.stijn...@gmail.com>
wrote:

> On Thu, Nov 19, 2015 at 11:04 PM, Tamás Kenéz <tamas.ke...@gmail.com>
> wrote:
>
>> > set(foobarSRCS foo.c bar.c)
>> > set(foobarLIBS ${externalLibFound})
>> >
>> > which is what the FAQ entry seems to suggest. However, this variable is
>> not visible to goo.c. Okay, so as an alternative, I can do this:
>> >
>> > set(foobarSRCS foo.c bar.c PARENT_SCOPE), etc.
>>
>> In similar cases I create CACHE variables:
>>
>> set(foobarSRCS foo.c bar.c CACHE INTERNAL "" FORCE)
>> set(foobarLIBS ${externalLibFound} CACHE INTERNAL "" FORCE)
>>
>> You can also write a set_cache() macro.
>>
>> Tamas
>>
>
> I'd prefer using the PARENT_SCOPE option here, which will make the
> variables available in the parent CMakeLists.txt.
> set(foobarSRCS foo.c bar.c PARENT_SCOPE)
> set(foobarLIBS ${externalLibFound} PARENT_SCOPE)
>
> --
>
> 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] actually using cmake alternative to convenience libraries

[Tamás Kenéz]

> set(foobarSRCS foo.c bar.c)
> set(foobarLIBS ${externalLibFound})
>
> which is what the FAQ entry seems to suggest. However, this variable is
not visible to goo.c. Okay, so as an alternative, I can do this:
>
> set(foobarSRCS foo.c bar.c PARENT_SCOPE), etc.

In similar cases I create CACHE variables:

set(foobarSRCS foo.c bar.c CACHE INTERNAL "" FORCE)
set(foobarLIBS ${externalLibFound} CACHE INTERNAL "" FORCE)

You can also write a set_cache() macro.

Tamas

On Tue, Nov 17, 2015 at 4:37 PM, Jack Stalnaker 
wrote:

> I'm trying to figure out the best way to handle something that was a
> convenience lib under autotools. I realize that there's a FAQ entry here:
>
>
> https://cmake.org/Wiki/CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F
>
> But its terse 2 paragraphs don't say how to actually do what it suggests.
> My problem is this. I have this source tree:
>
> lib
> |--foo.c
> |--foo.h
> |--bar.c
> |--bar.h
> |--baz.c
> src
> |--goo.c
>
> In lib, I need to somehow collectively refer to foo and bar. Okay, so I
> can create a variable:
>
> set(foobarSRCS foo.c bar.c)
> set(foobarLIBS ${externalLibFound})
>
> which is what the FAQ entry seems to suggest. However, this variable is
> not visible to goo.c. Okay, so as an alternative, I can do this:
>
> set(foobarSRCS foo.c bar.c PARENT_SCOPE), etc.
>
> but now the variable is not visible to baz.c, which also must include the
> srcs to create a module library called _baz! I can of course do something
> like this:
>
> set(foobarSRCSLOC foo.c bar.c)
> set(foobarSRCS ${foobarSRCSLOC} PARENT_SCOPE)
>
> but this feels dirty and repetitive.
>
> I also realize that I can just create the variables in src, but that kind
> of defeats the entire purpose of walling of the common libs and their
> dependencies in the first place.
>
> Is this the right way to work, or am I missing something simple?
>
> --Jack
>
> --
>
> 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] Creating relocatable export files

[Tamás Kenéz]

You need to manually write your config module which takes care of the
dependencies. Of course you will still use the generated exports, too.

For now let's say `ome-common` has one dependency: `omedep` and its
config-module, `omedep-config.cmake` creates the imported lib target
`omedep::omedep`. The in `ome-common`'s CMakeLists.txt:

target_link_libraries(ome-common PUBLIC omedep::omedep)
install(TARGETS ome-common
EXPORT ome-common-targets )
install(EXPORT ome-common-targets
DESTINATION cmake/ome-common)
install(FILES ome-common-config.cmake DESTINATION cmake/ome-common)

 The `ome-common-config.cmake` should look like this:

include(CMakeFindDependencyMacro)
find_dependency(omedep)
include(${CMAKE_CURRENT_LIST_DIR}/ome-common-targets.cmake)

Note: for CMake versions < 3.0 you need to use `find_package` instead of
`find_dependency`.

Okay, so that's the solution if `ome-common`'s dependency creates an
imported lib target.

If `omedep` has an oldschool config-module which provides only variables
like OMEDEP_LIBRARIES containing absolute paths, then these paths will be
hardcoded in `ome-common-targets.cmake`. In this case the recommended
method is to convert these paths to relative paths in a postprocess step
after installation.
See this: https://gist.github.com/tamaskenez/7ca4cba352525985ea70 as an
example for such a script.

Of course this can only be used if `omedep` is a dependency which is
installed into the same install tree as `ome-common`.
If you have a dependency in a separate install-tree which does not create
imported lib targets then you need to do it yourself both in `ome-common`'s
CMakeLists.txt and config-modules. This is not a trivial operation but
always can be done with more or less additional logic. For a simple case
where `omedep` consists of a single library file:

`ome-common`'s CMakeLists.txt:

find_package(omedep REQUIRED)
add_library(ome-common::omedep STATIC IMPORTED) # STATIC or SHARED or
UNKNOWN
set_target_properties(ome-common::omedep PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES ${OMEDEP_INCLUDE_DIRS}
IMPORTED_LINK_INTERFACE_LANGUAGES "C"
IMPORTED_LOCATION ${OMEDEP_LIBRARIES} # a single library
)
target_link_libraries(ome-common PUBLIC ome-common::omedep)
...

which should be repeated in `ome-common-config.cmake`:

include(CMakeFindDependencyMacro)
find_dependency(omedep)
set_target_properties(ome-common::omedep PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES ${OMEDEP_INCLUDE_DIRS}
IMPORTED_LINK_INTERFACE_LANGUAGES "C"
IMPORTED_LOCATION ${OMEDEP_LIBRARIES} # a single library
)
include(${CMAKE_CURRENT_LIST_DIR}/ome-targets.cmake)

Things get more complicated when OMEDEP_LIBRARIES has per-config variants
or further dependencies. You can check the generated
`ome-common-targets.cmake` and `ome-common-targets-Debug/Relase.cmake`
files for an example on how to set up such an imported lib target.



On Sat, Nov 14, 2015 at 7:19 PM, Nicholas Braden  wrote:

> Instead of using FOO_INCLUDE_DIR, I believe you should use
> target_include_directories() with the INTERFACE or PUBLIC options -
> this will export the include directories properly and they will be
> used when someone target_link_library()s your exported target.
>
> https://cmake.org/cmake/help/latest/command/target_include_directories.html?highlight=INTERFACE
>
> There seems to be a section in the documentation on making sure your
> packages are relocatable:
>
> https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-relocatable-packages
>
> See also:
> https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html
>
> As for recursively finding packages, I honestly don't know on this
> front. I would imagine that everything might work if everything was
> using exported/imported targets, but I'm not sure. The problem is that
> you have to consider what happens if you relocate your relocatable
> package to a system that doesn't have the dependencies installed. I
> don't think exported/imported targets or relocatable packages can
> solve that problem easily, but I am not very knowledgeable in this
> area myself.
>
> On Sat, Nov 14, 2015 at 5:53 AM, Roger Leigh  wrote:
> > Hi,
> >
> > I'm wanting to create -config scripts for my libraries so that dependent
> > projects can find them with find_package and use them transparently.  I
> have
> > a number of header-only and shared/static libs, and I'd like to retain
> their
> > relationships, plus any additional libraries they are linked with.
> >
> > I was previously using hand-crafted templates, e.g. with this type of
> > generated structure:
> >
> >
> ---
> > set(OME_COMMON_FOUND TRUE)
> >
> > set(OME_COMMON_VERSION "5.2.0-pre0-7-gfc53ca3")
> > set(OME_COMMON_VERSION_MAJOR "5")
> > 

Re: [CMake] How to figure out the "type" of an imported library

[Tamás Kenéz]

There's a TYPE property which should contain what you need:
https://cmake.org/cmake/help/latest/prop_tgt/TYPE.html

On Thu, Oct 29, 2015 at 4:53 PM, Attila Krasznahorkay <
attila.krasznahor...@gmail.com> wrote:

> Dear All,
>
> In my code I'm trying to do something slightly tricky. I include packages
> that provide imported libraries (amongst other things). Then, because of
> how my project is structured, I don't make use of the imported libraries
> directly, but first make "copies" of them, and then make use of these
> copies in my build.
>
> (The reason is that I allow the project to override libraries that are
> available from the base packages as well. In which case components using
> this overridden library need to use this instance instead of the imported
> one. But if no such override is in place, I need to give the library a name
> that the components in the project expect to find it with.)
>
> If there would be a way in CMake to "clone" an imported library with a new
> name, that would be perfect for my use case. Since as far as I know there's
> no such thing, I use code like:
>
>   ...
>   add_library( ${libName} SHARED IMPORTED GLOBAL )
>   # Check which builds it is available for:
>   get_property( _builds TARGET ${prefix}_${libName}
>  PROPERTY IMPORTED_CONFIGURATIONS )
>   set_property( TARGET ${libName} PROPERTY
>  IMPORTED_CONFIGURATIONS ${_builds} )
>   ...
>
> Now, I recently started producing MODULE and INTERFACE libraries as well.
> So the first line in this code is no longer correct for all the imported
> libraries. Plus, for INTERFACE libraries the get_property call on
> IMPORTED_CONFIGURATIONS just fails with an error message.
>
> So now I wonder: Is there a target property on INTERFACE libraries that I
> could use to identify them? Like how there is the target property IMPORTED
> on the imported libraries.
>
> Cheers,
> Attila
> --
>
> 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] Asking CMake to setup compiler for c++11

[Tamás Kenéz]

this is what I do:

if(NOT MSVC)
if(CMAKE_VERSION VERSION_LESS 3.1)
set(CMAKE_CXX_FLAGS "-std=c++11 ${CMAKE_CXX_FLAGS}")
else()
if(NOT DEFINED CMAKE_CXX_STANDARD OR CMAKE_CXX_STANDARD STREQUAL
"98")
set(CMAKE_CXX_STANDARD 11)
endif()
set(CMAKE_CXX_STANDARD_REQUIRED ON)
endif()
endif()


On Thu, Oct 29, 2015 at 11:22 AM, Mueller-Roemer, Johannes Sebastian <
johannes.sebastian.mueller-roe...@igd.fraunhofer.de> wrote:

> This fails for me when using Visual Studio
>
> --
> Johannes S. Mueller-Roemer, MSc
> Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)
>
> Fraunhofer-Institut für Graphische Datenverarbeitung IGD
> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
> Tel +49 6151 155-606  |  Fax +49 6151 155-139
> johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.de
>
>
> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Dan Kegel
> Sent: Wednesday, October 21, 2015 21:55
> To: Chris Stankevitz
> Cc: cmake
> Subject: Re: [CMake] Asking CMake to setup compiler for c++11
>
> Something like
>
> CMAKE_MINIMUM_REQUIRED(VERSION 3.1)
> SET(CMAKE_CXX_STANDARD 11)
>
> I think.
>
> On Wed, Oct 21, 2015 at 12:43 PM, Chris Stankevitz <
> chrisstankev...@gmail.com> wrote:
> > Hi,
> >
> > Q: What is the "CMake way" to ask that the compiler be setup for c++11?
> >
> > FYI I could not find the answer at
> > https://cmake.org/cmake/help/v3.4/search.html?q=c%2B%2B11
> >
> > Thank you,
> >
> > Chris
> > --
> >
> > 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
> --
>
> 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] Release and Debug build linking

[Tamás Kenéz]

CMake supports multi-config generators such as Visual Studio and Xcode for
a long time.

There are two flavors of config-modules (and find-modules), the legacy one
which creates variables like MY_PACKAGE_LIBRARIES and the install-export
kind which creates IMPORTED targets.
Both kinds of modules support providing Debug and Release versions of the
same library from a single find-module or config-module.

So if your package's find-module or config-module is written correctly you
don't need any if's just a single find_package().

Tamas

On Tue, Oct 6, 2015 at 10:21 PM, Lee Butler  wrote:

> I am looking for a way to tell my project to link against external debug
> libraries with a debug build and external release libraries with a release
> build with Visual Studio.
>
> I sort of want to be able to say something like
> if (BuildingReleaseConfig)
> find_package(OtherPackage REQUIRED COMPONENTS one two three PATHS
> OtherPkgDir/Release)
> endif()
>
> if (BuildingDebugConfig)
> find_package(OtherPackage REQUIRED COMPONENTS oned twod threed PATHS
> OtherPkgDir/Debug)
> endif()
>
> the idea is that the if () tells CMake which build configuration the
> find_package results should go into.  Is there any way to tell CMake what
> to write into each VS configuration?
>
> I realize the traditional CMake way is to create only one build at a time
> and specify CMAKE_BUILD_TYPE, but we seem to have stepped beyond that with
> the Visual Studio generator.
>
> Lee
> --
>
> 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] script mode current directory

[Tamás Kenéz]

file ${CMAKE_COMMAND} -P nosuchscriptfile.cmake)

+set(RunCMake_TEST_BINARY_DIR ${RunCMake_BINARY_DIR}/P_working-dir-build)
+file(MAKE_DIRECTORY "${RunCMake_TEST_BINARY_DIR}")
+run_cmake_command(P_working-dir ${CMAKE_COMMAND}
-DEXPECTED_WORKING_DIR=${RunCMake_TEST_BINARY_DIR} -P
${RunCMake_SOURCE_DIR}/P_working-dir.cmake)
+unset(RunCMake_TEST_BINARY_DIR)
+
 run_cmake_command(build-no-dir
   ${CMAKE_COMMAND} --build)
 run_cmake_command(build-no-cache
-- 
2.2.1


On Fri, Oct 2, 2015 at 2:45 PM, Brad King <brad.k...@kitware.com> wrote:

> On 10/02/2015 08:00 AM, J Decker wrote:
> > On Fri, Oct 2, 2015 at 4:40 AM, Tamás Kenéz wrote:
> >> In script mode it seems that all the CMAKE_[CURRENT_](BINARY|SOURCE)_DIR
> >> variables are set to the current working directory.
> >
> > if CMAKE_[CURRENT]_SOURCE_DIR is current directory; you're doing
> > something wrong :)   That implies that you're doing an in-source build
>
> Tamas is not doing a build at all but instead running
>
>  cmake -P myscript.cmake
>
> and checking the values of these variables.  Yes, the four variables
> are meant to be the current working directory in script mode.  This
> should be added to the documentation, but such a patch should also
> come with an update to the test suite, perhaps in RunCMake/CommandLine,
> that covers the behavior explicitly.
>
> -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
>
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] script mode current directory

[Tamás Kenéz]

In script mode it seems that all the CMAKE_[CURRENT_](BINARY|SOURCE)_DIR
variables are set to the current working directory.

Is this something we can rely on and it could be added to the documentation?

Tamas
-- 

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] ExternalProject: pass variable which contains a list

[Tamás Kenéz]

Hi,

I tried to pass a variable to an ExternalProjects config step which
contains a list:

ExternalProject_Add(... CMAKE_ARGS "-DVAR=contains\;list" ...)

I tried various number of backslashes but none of them worked.
I'd be interested in a workaround if there's one.

Tamas
-- 

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] ExternalProject: pass variable which contains a list

[Tamás Kenéz]

I'm sorry, I got it, LIST_SEPARATOR

On Thu, Oct 1, 2015 at 4:57 PM, Tamás Kenéz <tamas.ke...@gmail.com> wrote:

> Hi,
>
> I tried to pass a variable to an ExternalProjects config step which
> contains a list:
>
> ExternalProject_Add(... CMAKE_ARGS "-DVAR=contains\;list" ...)
>
> I tried various number of backslashes but none of them worked.
> I'd be interested in a workaround if there's one.
>
> Tamas
>
-- 

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 modules out of the CMake tree

[Tamás Kenéz]

> but I doubt the non-CMake ones generate SDL2Config.cmake files.

neither of them generates, not even the CMake one

On Wed, Sep 30, 2015 at 5:11 PM, Ben Boeckel 
wrote:

> On Wed, Sep 30, 2015 at 10:22:47 -0400, Brad King wrote:
> > With regard to SDL2, the proper way to make it find-able with CMake is
> > for SDL2 to provide a CMake packaging files themselves as part of their
> > own distribution (since they build with CMake):
>
> Just to note, SDL2 also has build systems for ~every buildsystem out
> there (VS projects, Xcode projects, Android.mk, autotools, premake,
> etc.). I *think* those are for ease-of-embedding, but I doubt the
> non-CMake ones generate SDL2Config.cmake files.
>
> --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
>
-- 

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] find_package for both debug and release with Visual Studio

[Tamás Kenéz]

1. build your own project, too, in separate build trees for debug and
release
2. if all your dependencies' are prepared to provide debug and release libs
simultanously (like Poco) you can build them in separate trees (however not
neccessary) but set CMAKE_INSTALL_PREFIX and CMAKE_PREFIX_PATH to the same
location for each configuration
3. you can examine CMakeCache.txt and find which variable is cached during
find_package and remove it manually (unset(... CACHE)) but this is a hack

Tamas

On Fri, Sep 25, 2015 at 11:58 AM, John Barbero Unenge <
john.barbero.une...@gmail.com> wrote:

> I'm tearing my hair out about how to include thrid party libraries in my
> cmake project. Currently I build Poco and a bunch of others that all
> generate their respective Config.cmake which I use with
> find_package. I have a wrapping build script that builds all of my
> dependencies and package them separately for debug and release (I don't
> want to tweak their cmake-scripts unless I really really really need to
> because maintanance).
>
> I thought I could just do:
>
> find_package(Foo
> HINTS "${CMAKE_SOURCE_DIR}/some/path/debug/libFoo/lib/cmake"
> REQUIRED
> )
> get_target_property(LIB_FOO_DEBUG lib_foo LOCATION)
>
> find_package(Foo
> HINTS "${CMAKE_SOURCE_DIR}/some/path/release/libFoo/lib/cmake"
> REQUIRED
> )
> get_target_property(LIB_FOO_RELEASE lib_foo LOCATION)
>
> set(LIB_FOO_LIBRARIES optimized "${LIB_FOO_RELEASE}" debug
> "${LIB_FOO_DEBUG}")
>
> message("LIB_FOO_LIBRARIES: \"${LIB_FOO_LIBRARIES}\"")
> # Gives: LIB_FOO_LIBRARIES: "
> optimized;C:/path/to/proj/some/path/debug/libFoo/lib/foo.lib;debug;C:/path/to/proj/some/path/debug/libFoo/lib/foo.lib"
>
> It seems like the first call to find_package for target Foo is cached,
> whis I don't really want.
>
> Am I going about this the wrong way? How do I properly work with 3rd party
> libraries with the Visual Studio generator?
>
> Any pointers are greatly appreciated.
>
> / John
>
> --
>
> 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] "Pre-configure" step in CMake

[Tamás Kenéz]

What if you call your dependency-fetcher script with a straight
macro/function call or `include` or `execute_process` instead of putting it
into a custom target? I'm thinking of something like this:

set(DEP_SCRIPT_OUT ${CMAKE_CURRENT_BINARY_DIR}/dep-script-out.cmake)
if(NOT EXISTS "${DEP_SCRIPT_OUT}")
  execute_process(${CMAKE_COMMAND}
-DC_COMPILER_ID=${CMAKE_C_COMPILER_ID}
-DC_COMPILER_VERSION=${CMAKE_C_COMPILER_VERSION}
-DDEP_SCRIPT_OUT =${DEP_SCRIPT_OUT}
-P dependency-fetcher.cmake)
endif()
include(${DEP_SCRIPT_OUT})

or, simply:

if(NOT DEPENDENCIES_FETCHED)
  include(dependency-fetcher.cmake)
  # fetch_dependencies() # call it in case it's implemented as a
macro/function
  set(DEPENDENCIES_FETCHED ON CACHE BOOL "" FORCE)
endif()

In the latter case there's no need to write the variables into a script
since the fetcher runs in the same scope.

Tamas


On Wed, Sep 23, 2015 at 9:49 PM, Matthäus G. Chajdas 
wrote:

> Hi,
>
> I'm trying to solve the following the problem: I have a C++ application
> and a dependency fetching script. I want to simplify the initial build
> such that the following happens: On the first run of cmake, the compiler
> ID and version is passed to an external script, which fetches some
> pre-build binaries. It then writes a CMake file which contains basically
> only set(FOO_INCLUDE_DIR /dep-dir), set(FOO_LIBRARY_DIR /dep-dir)
> commands. CMake would then read this file and subsequent find_library
> calls would pick up the values from this new CMake file. The idea is
> that "actual" build is dependent on this first dependency step, but it's
> already within the CMake framework so I can grab the compiler info and
> other build info.
>
> The obvious problem is that while I can easily run the external script
> by using configure_file, and have a custom target that does the
> dependency fetching and CMake configure file generation. But I don't see
> an easy way to get CMake to make the "rest of the project" depend on
> that configure file. How can I make such a "two-stage" build with CMake?
>
> Cheers,
>   Matthäus
> --
>
> 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] config-module installed to '/share/cmake' - good or bad?

[Tamás Kenéz]

Note: this question was motivated by having some troubles with HDF5 but
requires no familiarity with HDF5.

The HDF5 source distribution installs a very nice config-module (creates
imported targets unlike FindHDF5.cmake).

However it installs it to `/share/cmake` which path is not searched
by `find_package(hdf5 CONFIG)`, in accordance with the documentation.

I'd like to hear the opinion of the wise cmake people here whether this is
a bug or not.

I failed to convince a developer over at HDFGroup that it is a bug and they
should install  to '/share/cmake/hdf5' instead. But maybe I'm
wrong, that's why I'm asking it here.

Cheers,
Tamas
-- 

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

[Tamás Kenéz]

> However, that would still not make externals from
> a .tar.gz being rebuilt if their archive was changed. Am I right?

Yes, you're right, the UPDATE step is available only for git and svn.

On Wed, Sep 16, 2015 at 3:22 PM, Tino Mettler <tino.mett...@alcnetworx.de>
wrote:

> On Tue, 2015-09-15 at 16:32 +0200, Tamás Kenéz wrote:
> > > it would be nice to know if the usage of add_library(foo SHARED
> > > IMPORTED) is the way to go in this case.
> >
> > I wouldn't think this is the way to go. One thing we love CMake for is
> that
> > it separates the concerns of the library and the consumer target so it's
> > best to stick to find_package.
> >
> > This is the usage pattern of ExternalProject with find_package:
> > Create a super project which contains the library and the consumer target
> > in 2 separate ExternalProjects so the library can be installed before the
> > main target's CMakeLists is configured.
>
> Hi,
>
> thanks for that hint. However, that would still not make externals from
> a .tar.gz being rebuilt if their archive was changed. Am I right?
>
> Regards,
> Tino
>
>
> --
>
> 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] Linking with an external project also built with CMake

[Tamás Kenéz]

1. There is a (semi-)automatic way: you can export the targets of
ExternalLib with install(EXPORT...) from its CMakeLists.txt. In the
simplest cases you can use the generated export file as a config module:

install(TARGETS ... EXPORT externallib ...)
install(EXPORT externallib FILE externallib-config.cmake ...)

Of course you also need to set the appropriate properties of the targets of
ExternalLib by using the target_* commands.

2. (Another option) If you build the ExternalLib in the same project, its
targets will be available in the main project.

On Thu, Sep 17, 2015 at 6:25 PM, Saad Khattak  wrote:

> Hello,
>
> I have a project *ExternalLib* that uses CMake to build its libraries. I
> then have my own project (separate from the external library) that needs to
> include ExternalLib's headers and link with its libraries. ExternalLib does
> not have a find_package module.
>
> Since ExternalLib is also built using CMake, is there no 'automatic' way
> to have CMake figure out where the source files and library files are
> (since CMake built them in the first place)? That is, I want to avoid
> writing a find_package module for ExternalLib and since I have to build it
> using CMake anyway, I was hoping there would be some way to automatically
> fill in the correct paths for the libraries and source file directories in
> MyProject which also uses CMake.
>
> Thanks,
> Saad
>
> --
>
> 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] Libraries for a Target and/or its Dependents

[Tamás Kenéz]

I guess `Test` is also a static library. In that case this is the intended
behaviour.
Since `private_lib` is not compiled into `Test`'s object files, when you
link the consumer of `Test` you still need to pull in `private_lib`.

If `Test` were a shared lib then `private_lib` would not be listed.

Tamas

On Mon, Sep 14, 2015 at 12:10 PM, Wojciech Mamrak  wrote:

> Hello,
>
> The docs say [1]:
> "Libraries and targets following PRIVATE are linked to, but are not
> made part of the link interface."
>
> If so, why does this snippet:
>
> add_library(private_lib STATIC ...)
> add_library(public_lib STATIC ...)
>
> target_link_libraries(Test PRIVATE private_lib
> PUBLIC public_lib)
> install(EXPORT ...)
>
> sets Test's imported target's properties with:
>
> IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE "private_lib;public_lib"
>
> I thought BUILD_INTERFACE and INSTALL_INTERFACE generator expressions
> can solve this, but it turns out BUILD_INTERFACE is propagated, and
> INSTALL_INTERFACE is not, i.e.
>
> IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE
> "private_lib;public_lib;build_interface_lib"
>
> regards
>
> [1]
> http://www.cmake.org/cmake/help/v3.3/command/target_link_libraries.html#libraries-for-a-target-and-or-its-dependents
> --
>
> 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] Allow ALIAS of IMPORTED targets

[Tamás Kenéz]

Thank you, I was not aware of the EXPORT_NAME target property.
Tamas

On Tue, Sep 15, 2015 at 7:36 PM, Stephen Kelly <steve...@gmail.com> wrote:

> Tamás Kenéz wrote:
>
> >> For example, if an ALIAS can be IMPORTED, does it makes sense that it
> can
> > be
> >> exported with export() and install(EXPORT)?
> >
> > Yes: couple of months ago I was adding install(EXPORT) to an existing
> > CMakeList. The name of the library target which I had to export was not
> > correct as export target name but I was not able change the library
> target
> > name because of backward compatibility. Being able to export an alias
> > would have helped.
>
> I still think exporting should be a follow up to allowing IMPORTED ALIAS.
> Just too keep the branch and discussion as short as possible.
>
> Nevertheless, I think you wouldn't need ALIAS targets for your use-case.
> They are more than you need. You don't need the aliases anywhere except for
> exporting. So, we could design something which allows you to export
> aliases,
> but be completely separate from ALIAS targets.
>
> For example,
>
>  add_library(foo ${foo_SRCS})
>  set_target_property(foo EXPORT_NAMES foo foo_old_name)
>
>  ...
>
>  install(EXPORT ...)
>
> resulting in a generated file containing
>
>  add_library(foo IMPORTED)
>  ...
>
>  add_library(foo_old_name IMPORTED)
>  ...
>
> where each of the generated targets get the same target properties.
>
> Note that there is already an EXPORT_NAME target property
>
>  http://www.cmake.org/cmake/help/v3.3/prop_tgt/EXPORT_NAME.html
>
> but it is not a list, so the task would probably be to deprecate that one
> and add EXPORT_NAMES.
>
> I filed
>
>  http://public.kitware.com/Bug/view.php?id=15745
>
> 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

Re: [CMake] Shared library from ExternalProject

[Tamás Kenéz]

> it would be nice to know if the usage of add_library(foo SHARED
> IMPORTED) is the way to go in this case.

I wouldn't think this is the way to go. One thing we love CMake for is that
it separates the concerns of the library and the consumer target so it's
best to stick to find_package.

This is the usage pattern of ExternalProject with find_package:
Create a super project which contains the library and the consumer target
in 2 separate ExternalProjects so the library can be installed before the
main target's CMakeLists is configured.

In certain cases you can also clone, build and install the library in an
init shell script of your project, outside of the main CMakeLists.txt. This
can be achieved either in a separate CMakeLists.txt (e.g.
./dependencies/CMakeLists.txt) or by raw shell commands (calling curl, git,
cmake, cmake --build directly)

Tamas

On Tue, Sep 15, 2015 at 2:07 PM, Tino Mettler 
wrote:

> Hi,
>
> it would be nice to know if the usage of add_library(foo SHARED
> IMPORTED) is the way to go in this case.
>
> find_package() seems to be useless, as it requires that the external
> library is already present when cmake is invoked, which is not the case
> with an external project.
>
> So it seems like I have to define everything via set_target_properies().
>
> What I see is that cmake uses rpath for linking using gcc/binutils. Is
> there a way to just use -L here? In the final installation (an embedded
> device), the libraries will be placed in the standard search path of the
> dynamic linker, so the rpath is just build system specific and not
> needed for the resulting binary.
>
> I also discovered that the build of the external project is not updated
> when the filesystem timestamp as well as the contents of external.tar.gz
> were changed. How can I achieve this?
>
> Here is my minimized example:
>
> cmake_minimum_required(VERSION 3.0.0)
> project (hello)
> add_executable(hello helloworld.cpp)
> include(ExternalProject)
> ExternalProject_Add(externalproject URL ../../../external.tar.gz)
> ExternalProject_Get_Property(externalproject binary_dir)
> add_library(externallib SHARED IMPORTED)
> set_target_properties(externallib PROPERTIES IMPORTED_LOCATION
> ${binary_dir}/install/lib/${CMAKE_SHARED_LIBRARY_PREFIX}mylib${CMAKE_SHARED_LIBRARY_SUFFIX}
> )
> include_directories(${binary_dir}/install/include/)
> target_link_libraries(hello externallib)
> add_dependencies(hello externalproject)
>
> Regards,
> Tino
>
> --
>
> 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] Allow ALIAS of IMPORTED targets

[Tamás Kenéz]

> For example, if an ALIAS can be IMPORTED, does it makes sense that it can
be
> exported with export() and install(EXPORT)?

Yes: couple of months ago I was adding install(EXPORT) to an existing
CMakeList. The name of the library target which I had to export was not
correct as export target name but I was not able change the library target
name because of backward compatibility. Being able to export an alias would
have helped.

> and I export both of them with the NAMESPACE 'MyNS::', do I end up with
> MyNS::MyNS::Core

I guess so, at least that's what I would expect. As far as I know the
install(EXPORT) blindly preprends the target name with the namespace string.

Tamas

On Mon, Sep 14, 2015 at 7:34 PM, Stephen Kelly  wrote:

> Michael Scott wrote:
>
> > Hi,
> >
> > I'm planning on having a look at the CMake issue "Allow ALIAS of
> > IMPORTED targets", 0015569. After reading the thread between yourself
> > and Marc, I wanted to ask a couple of things before I start going
> > further with it.
>
> Thanks for working on this.
>
> > The proposed change would be for the add_library and add_executable
> > commands only right?
>
> Yes, I guess so.
>
> > Having a quick look at the code for those two commands, they
> > specifically check for a combination of ALIAS and IMPORTED and don't
> > allow it. I'm guessing that the required changes to allow both
> > simultaneously wouldn't be to just remove this check, there would be
> > other areas to modify as well right?
>
> Perhaps. Finding that out is the real task :). I don't have all the answers
> to it. The specific disallowing of ALIAS and IMPORTED together by issuing
> an
> error was a way to defer finding those answers while not being required to
> maintain compatibility with a particular behavior. I didn't want finding
> those answers to delay getting the ALIAS feature in, because it was useful
> already as it was.
>
> Now, we have time to consider all of the implications of allowing this as
> part of the design.
>
> For example, if an ALIAS can be IMPORTED, does it makes sense that it can
> be
> exported with export() and install(EXPORT)?
>
> If we have
>
>  add_library(CoreStatic ${Core_SRCS})
>  add_library(MyNS::Core ALIAS CoreStatic)
>
> and I export both of them with the NAMESPACE 'MyNS::', do I end up with
>
>  MyNS::MyNS::Core
>
> ?
>
> Or would the exporting code strip of everything before a '::' in the alias
> name?
>
> Or should exporting ALIAS targets still be disallowed?
>
> The two use cases described in
>
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/52452
>
> seem like they would not benefit from exporting ALIAS targets.
>
> A reasonable way forward might be:
>
> * Keep the restriction that ALIAS targets may not be exported.
> * Remove the code disallowing ALIAS IMPORTED targets.
> * Remove the unit test proving it is not allowed
> * Add new unit tests that it basically works
> * Add a unit test for using an ALIAS with try_compile(LINK_LIBRARIES)
> * (Anything else that comes up along the way)
>
> 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

Re: [CMake] How to depend on external cmake projects?

[Tamás Kenéz]

On Mon, Aug 17, 2015 at 5:17 PM, James Johnston jam...@motionview3d.com
wrote:

 [...] Your own CMake projects will be
 ExternalProjects to this high-level project and the superbuild would pass
 the location to your project via -Dproject_DIR=location so that
 find_package can locate the Config file.


I think a more convenient and also more conforming solution would be to
pass the location of a single install directory
(-DCMAKE_INSTALL_PREFIX=...) and pass the same dir also as prefix path
(-DCMAKE_PREFIX_PATH=...) to all projects.
All the projects of the superbuild will search for dependencies (config
modules) in this directory and also install their own config modules into
this directory.
This directory is best to create inside the superbuild dir (like
superbuild-root/out) and of course removed from source control.
CMAKE_PREFIX_PATH may additionally contain other, central locations for
other libraries built outside of the superbuild.

Tamas
-- 

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 depend on external cmake projects?

[Tamás Kenéz]

Robert,

1. If it's a library you are not modifying, only linking to, then you don't
need its targets in your projects. You just need to clone, build and
install it before running cmake for your actual project. It can be
accomplished in various ways:

- you can clone it as a submodule or manually by a script (shell or CMake
script or CMakeLists.txt)
- write a shell script that builds and installs it by calling `cmake` and
`cmake --build`
- write a super-project CMakeLists.txt which builds and installs it with
execute_process(${CMAKE_COMMAND} ...) (or ExternalProject, but it's a bit
cumbersome because you need to build the super-project to install the
dependency)
- build and install your dependency with execute_process(${CMAKE_COMMAND}
...) in your project's CMakeLists.txt (that is, in cmake configure-time)

2. If it's a library you will modify then:

- if it's not a submodule, you need to clone it either in a shell script or
in the super-project or in your project's CMakeLists
- use add_library to add it into your project

In first case you will need to use packages, or more precisely,
config-modules but I would not complicate things by creating
config-packages for the build tree. Create regular config modules
(install(EXPORT ...) and install the projects.

Tamas

On Sun, Aug 16, 2015 at 3:32 PM, Robert Dailey rcdailey.li...@gmail.com
wrote:

 There are certain repositories on Github I'd like to pull in as a
 dependency. These repositories already use CMake to build their source
 code. Based on personal experience and reading material online, there
 are a couple of different options:

 1. Pull down the repository as a submodule to my own git repository.
 Then call add_subdirectory() on it to make it part of the build,
 allowing me to refer to those targets as dependencies in my own
 targets.

 2. Use ExternalProject_Add(). This seems like legacy, I'm not sure if
 I should use this. It also seems very verbose and boilerplate.

 3. Use packages. The [CMake package documentation][1] does not go into
 great detail on support for both installed versions and build tree for
 a single package. Does this require two scripts? Can it share a single
 one? Where are the examples?

 How do I accomplish this?

 [1]:
 http://www.cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-a-package-configuration-file-for-the-build-tree
 --

 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] Imported libraries and cross platform target names

[Tamás Kenéz]

Anthony, instead of `find_library` I do think you should look into the
config-module feature and the command `install(EXPORT ...)` which helps you
generating them, as Nils Gladitz has already suggested. As you wrote, these
libraries are already building from CMakeLists so you don't even need to
cmakefy them.

Tamas

On Tue, Aug 18, 2015 at 8:51 PM, Ette, Anthony (CDS) 
anthony.r.e...@controlsdata.com wrote:

 Thank you for the response, I will look into find_library.  Note however
 that these static libraries are ours built from a separate CMake project
 (so I always know where they are “installed”).




 *Anthony Ette *Control Systems Engineer



 Rolls-Royce Controls and Data Services

 7661 N Perimeter Rd

 Indianapolis, IN 46241

 tel: +1 (317) 230-6943

 mob: +1 (317) 864-7975

 email: anthony.r.e...@controlsdata.com



 *From:* Miller Henry [mailto:millerhe...@johndeere.com]
 *Sent:* Tuesday, August 18, 2015 2:44 PM
 *To:* Ette, Anthony (CDS); CMake@cmake.org
 *Subject:* RE: Imported libraries and cross platform target names



 Use find_library to find the library.  You will probably need this anyway
 because different systems install libraries in different locations.



 http://www.cmake.org/cmake/help/v3.3/command/find_library.html





 *From:* CMake [mailto:cmake-boun...@cmake.org cmake-boun...@cmake.org] *On
 Behalf Of *Ette, Anthony (CDS)
 *Sent:* Tuesday, August 18, 2015 1:30 PM
 *To:* CMake@cmake.org
 *Subject:* [CMake] Imported libraries and cross platform target names
 *Importance:* High



 Given that add_library() produces a unique filename per platform (the “actual
 file name of the library built is constructed based on conventions of the
 native platform (such as libname.a orname.lib”), how does one add the
 library to the final application without having to deal with the filename
 difference?  In other words, I’ve got one library that, by default,
 produces ‘libtest.a’ on Linux and ‘test.lib’ on Windows.  How can I add
 this imported library into the final application in a cross platform
 manner?  I know I can specify two different imported locations (see below),
 but it seems odd to me that Cmake – the cross-platform build env generator
 – doesn’t have a better native way of dealing with this….



 The snippet below will work, but just seems wrong given the nature of what
 CMake is intended to do…is there a better way that I’m missing?!  If not,
 can I request that a future release of Cmake handle platform naming
 convention difference internally when invoking ADD_LIBRARY with the
 IMPORTED tag set?  Ok so, to be fair, Cmake can be used to cross compile
 and that certainly complicates my feature request but, when not cross
 compiling, CMake knows what platform it’s being executed on so it should be
 able to resolve static archive platform decorations internally.



 ADD_LIBRARY(test STATIC IMPORTED)

 if(WIN32)

SET_PROPERTY(TARGET test PROPERTY IMPORTED_LOCATION ${LIB_D}/timer.lib)

 endif()

 if(UNIX)

SET_PROPERTY(TARGET test PROPERTY IMPORTED_LOCATION
 ${LIB_D}/libtimer.a)

 endif()



 Thanks in advance,


 *Anthony Ette *Control Systems Engineer



 Rolls-Royce Controls and Data Services

 7661 N Perimeter Rd

 Indianapolis, IN 46241

 tel: +1 (317) 230-6943

 mob: +1 (317) 864-7975

 email: anthony.r.e...@controlsdata.com



 This e-mail (including attachments) contains contents owned by Rolls-Royce
 plc and its subsidiaries, affiliated companies or customers and covered by
 the laws of England and Wales, Brazil, US, or Canada (federal, state or
 provincial). The information contained in this email is intended to be
 confidential, may be legally privileged and subject to export controls
 which may restrict the access to and transfer of the information. If you
 are not the intended recipient, you are hereby notified that any retention,
 dissemination, distribution, interception or copying of this communication
 is strictly prohibited and may subject you to further legal action. Reply
 to the sender if you received this email by accident, and then delete the
 email and any attachments.


 __
 This email has been scanned.
 This e-mail (including attachments) contains contents owned by Rolls-Royce
 plc and its subsidiaries, affiliated companies or customers and covered by
 the laws of England and Wales, Brazil, US, or Canada (federal, state or
 provincial). The information contained in this email is intended to be
 confidential, may be legally privileged and subject to export controls
 which may restrict the access to and transfer of the information. If you
 are not the intended recipient, you are hereby notified that any retention,
 dissemination, distribution, interception or copying of this communication
 is strictly prohibited and may subject you to further legal action. Reply
 to the sender if you received this email by accident, and then delete the
 email and any attachments.

 --

 Powered by 

[CMake] on cmake supporting one arch per project (from CMake IR)

[Tamás Kenéz]

On 2015-07-30 11:51:54 GMT, Nagy-Egri Máté Ferenc via CMake wrote:

 how on Earth am I going to build x86/x64/ARM targets from one VS solution?
 [...]
 the way how CMake has been designed immediately rules it out from ~75% of
application development going on in the world in the future (mobile app
devel)

Well, we are building Android and iOS projects with CMake and we simply
configure separate build dirs for each architecture. We even need to
configure seperate dirs for Debug and Release builds for the makefile
generators.

It doesn't feel like a problem for us. We simply adapt our workflows to it.
Is there anything wrong with this approach we don't recognize?

Tamas Kenez
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty

[Tamás Kenéz]

 What is your actual use case for expanding this info during the configuration
process?

We feed our static lib and the list of its dependencies to the `libtool` to
create an amalgamated, standalone static library.
This is an iOS-specific issue: we need this because iOS doesn't support
shared libraries and we want to provide our users a single static lib
instead of 20-30.

Anyway, I understand if `CMakeExpandImportedTargets' doesn't fit the
current concepts. We will then use a local modified copy of it or try to
solve the issue by `install(CODE ..)` to postpone the amalgamation to
install time where the generator expressions can be resolved.

Thanks,
Tamas

(sorry for not replying-to-all in previous email)


On Fri, Jul 17, 2015 at 5:41 PM, Brad King brad.k...@kitware.com wrote:

 On 07/16/2015 11:29 AM, Tamás Kenéz wrote:
  Well, it seems that `BundleUtilities` can't expand a single static
 imported
  library target to the list of all dependent libraries (that's what I
 need)
  so I think `CMakeExpandImportedTargets` is still benefitial and could be
  benefitial to others, too.

 The BundleUtilities suggestion in the issue tracker page you linked
 was specific to the CPack use case discussed there.

  My patch enables `CMakeExpandImportedTargets` to use the
  `INTERFACE_LINK_LIBRARIES` property and also resolves the $CONFIG,
  $NOT and $0|1: generator expressions.

 This module should not be further maintained and should instead be
 deprecated:

 * Its original use case was to expand imported targets for calling
   try_compile and try_run.  Both now support imported targets
   natively in their LINK_LIBRARIES options so it is no longer
   needed (or used by CMake's own modules) for this purpose.

 * It is not possible to implement with generator expressions in
   general (see below).

  I found no elegant way to resolve all generator expressions
  (`file(GENERATE ...)` can't be used since it does not output the
  resolved content instantly).

 Generator expressions by definition cannot be evaluated until generate
 time because their evaluation can access information that is not
 available until then.  Even for imported targets with a given
 CONFIGURATION value we may not have all the information needed to
 expand INTERFACE_LINK_LIBRARIES.  For example, that property may
 contain expressions like $TARGET_PROPERTY:prop that refer to the
 target for which the link line is currently generating.

 What is your actual use case for expanding this info during the
 configuration process?

 -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-developers] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty

[Tamás Kenéz]

I submitted a patch to update `CMakeExpandImportedTargets` with
`INTERFACE_LINK_LIBRARIES`.
Shortly after I read the discussion at http://www.cmake
.org/Bug/view.php?id=15299 which suggested `CMakeExpandImportedTargets` is
deprecated and one should use `BundleUtilities` instead.

Well, it seems that `BundleUtilities` can't expand a single static imported
library target to the list of all dependent libraries (that's what I need)
so I think `CMakeExpandImportedTargets` is still benefitial and could be
benefitial to others, too.

My patch enables `CMakeExpandImportedTargets` to use the
`INTERFACE_LINK_LIBRARIES`
property and also resolves the $CONFIG, $NOT and $0|1: generator
expressions. I found no elegant way to resolve all generator expressions
(`file(GENERATE ...)` can't be used since it does not output the resolved
content instantly).

Tamas

On Wed, Jul 15, 2015 at 5:56 PM, Tamás Kenéz tamas.ke...@gmail.com wrote:

 The CMakeExpandedImportedTargets module used only the deprecated
 IMPORTED_LINK_INTERFACE_LIBRARIES property to resolve transitive
 dependencies.
 Since the current `install(EXPORT ...)` command generates target files
 that populate INTERFACE_LINK_LIBRARIES instead, the expand module was not
 working correctly with the imported libraries generated by `install(EXPORT
 ...)`.

 I considered this a bugfix so I based the commit onto the release branch.

 Please review and apply if it's ok.
 Tamas


 From f2df88ec4180595a3fcc4c6be9b2d38e46162cc3 Mon Sep 17 00:00:00 2001
 From: Tamas Kenez tamas.ke...@gmail.com
 Date: Wed, 15 Jul 2015 17:47:50 +0200
 Subject: [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES
 if
  non-empty

 The deprecated IMPORTED_LINK_INTERFACE_LIBRARIES should be
 overridden by INTERFACE_LINK_LIBRARIES if it's non-empty.

 Unlike IMPORTED_LINK_INTERFACE_LIBRARIES, INTERFACE_LINK_LIBRARIES
 usually contains config-related generator expressions which must
 be resolved according to the selected configuration.
 ---
  Modules/CMakeExpandImportedTargets.cmake | 22 +-
  1 file changed, 21 insertions(+), 1 deletion(-)

 diff --git a/Modules/CMakeExpandImportedTargets.cmake
 b/Modules/CMakeExpandImportedTargets.cmake
 index 8ac3364..b110e51 100644
 --- a/Modules/CMakeExpandImportedTargets.cmake
 +++ b/Modules/CMakeExpandImportedTargets.cmake
 @@ -102,7 +102,27 @@ function(CMAKE_EXPAND_IMPORTED_TARGETS _RESULT )
  list(GET _importedConfigs ${_configIndexToUse}
 _importedConfigToUse)

  get_target_property(_importedLocation ${_CURRENT_LIB}
 IMPORTED_LOCATION_${_importedConfigToUse})
 -get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
 IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} )
 +get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
 INTERFACE_LINK_LIBRARIES)
 +if(_linkInterfaceLibs)
 +   # resolve $CONFIG:... generator expressions
 +   string(REGEX REPLACE \\$CONFIG:${_importedConfigToUse}
 1
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +   string(REGEX REPLACE \\$CONFIG:[^]* 0
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +   # resolve $NOT:(0|1)
 +   string(REGEX REPLACE \\$NOT:0 1
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +   string(REGEX REPLACE \\$NOT:1 0
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +   # resolve $(0|1):...
 +   # empty items will be ignored by `foreach` later
 +   string(REGEX REPLACE \\$0:[^]* 
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +   string(REGEX REPLACE \\$1:([^]*) \\1
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +else()
 +   get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
 IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} )
 +endif()

  list(APPEND _CCSR_NEW_REQ_LIBS  ${_importedLocation})
  #message(STATUS Appending lib ${_CURRENT_LIB} as
 ${_importedLocation})
 --
 1.9.4.msysgit.2


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty

[Tamás Kenéz]

I've just read the discussion at
http://www.cmake.org/Bug/view.php?id=15299 about
the deprecation of CMakeExpandImportedTargets. I guess it means no fixes to
it.

I'm checking BundleUtilities as suggested there.

Tamas

On Wed, Jul 15, 2015 at 5:56 PM, Tamás Kenéz tamas.ke...@gmail.com wrote:

 The CMakeExpandedImportedTargets module used only the deprecated
 IMPORTED_LINK_INTERFACE_LIBRARIES property to resolve transitive
 dependencies.
 Since the current `install(EXPORT ...)` command generates target files
 that populate INTERFACE_LINK_LIBRARIES instead, the expand module was not
 working correctly with the imported libraries generated by `install(EXPORT
 ...)`.

 I considered this a bugfix so I based the commit onto the release branch.

 Please review and apply if it's ok.
 Tamas


 From f2df88ec4180595a3fcc4c6be9b2d38e46162cc3 Mon Sep 17 00:00:00 2001
 From: Tamas Kenez tamas.ke...@gmail.com
 Date: Wed, 15 Jul 2015 17:47:50 +0200
 Subject: [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES
 if
  non-empty

 The deprecated IMPORTED_LINK_INTERFACE_LIBRARIES should be
 overridden by INTERFACE_LINK_LIBRARIES if it's non-empty.

 Unlike IMPORTED_LINK_INTERFACE_LIBRARIES, INTERFACE_LINK_LIBRARIES
 usually contains config-related generator expressions which must
 be resolved according to the selected configuration.
 ---
  Modules/CMakeExpandImportedTargets.cmake | 22 +-
  1 file changed, 21 insertions(+), 1 deletion(-)

 diff --git a/Modules/CMakeExpandImportedTargets.cmake
 b/Modules/CMakeExpandImportedTargets.cmake
 index 8ac3364..b110e51 100644
 --- a/Modules/CMakeExpandImportedTargets.cmake
 +++ b/Modules/CMakeExpandImportedTargets.cmake
 @@ -102,7 +102,27 @@ function(CMAKE_EXPAND_IMPORTED_TARGETS _RESULT )
  list(GET _importedConfigs ${_configIndexToUse}
 _importedConfigToUse)

  get_target_property(_importedLocation ${_CURRENT_LIB}
 IMPORTED_LOCATION_${_importedConfigToUse})
 -get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
 IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} )
 +get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
 INTERFACE_LINK_LIBRARIES)
 +if(_linkInterfaceLibs)
 +   # resolve $CONFIG:... generator expressions
 +   string(REGEX REPLACE \\$CONFIG:${_importedConfigToUse}
 1
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +   string(REGEX REPLACE \\$CONFIG:[^]* 0
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +   # resolve $NOT:(0|1)
 +   string(REGEX REPLACE \\$NOT:0 1
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +   string(REGEX REPLACE \\$NOT:1 0
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +   # resolve $(0|1):...
 +   # empty items will be ignored by `foreach` later
 +   string(REGEX REPLACE \\$0:[^]* 
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +   string(REGEX REPLACE \\$1:([^]*) \\1
 +  _linkInterfaceLibs ${_linkInterfaceLibs})
 +else()
 +   get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
 IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} )
 +endif()

  list(APPEND _CCSR_NEW_REQ_LIBS  ${_importedLocation})
  #message(STATUS Appending lib ${_CURRENT_LIB} as
 ${_importedLocation})
 --
 1.9.4.msysgit.2


-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty

[Tamás Kenéz]

The CMakeExpandedImportedTargets module used only the deprecated
IMPORTED_LINK_INTERFACE_LIBRARIES property to resolve transitive
dependencies.
Since the current `install(EXPORT ...)` command generates target files that
populate INTERFACE_LINK_LIBRARIES instead, the expand module was not
working correctly with the imported libraries generated by `install(EXPORT
...)`.

I considered this a bugfix so I based the commit onto the release branch.

Please review and apply if it's ok.
Tamas


From f2df88ec4180595a3fcc4c6be9b2d38e46162cc3 Mon Sep 17 00:00:00 2001
From: Tamas Kenez tamas.ke...@gmail.com
Date: Wed, 15 Jul 2015 17:47:50 +0200
Subject: [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if
 non-empty

The deprecated IMPORTED_LINK_INTERFACE_LIBRARIES should be
overridden by INTERFACE_LINK_LIBRARIES if it's non-empty.

Unlike IMPORTED_LINK_INTERFACE_LIBRARIES, INTERFACE_LINK_LIBRARIES
usually contains config-related generator expressions which must
be resolved according to the selected configuration.
---
 Modules/CMakeExpandImportedTargets.cmake | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/Modules/CMakeExpandImportedTargets.cmake
b/Modules/CMakeExpandImportedTargets.cmake
index 8ac3364..b110e51 100644
--- a/Modules/CMakeExpandImportedTargets.cmake
+++ b/Modules/CMakeExpandImportedTargets.cmake
@@ -102,7 +102,27 @@ function(CMAKE_EXPAND_IMPORTED_TARGETS _RESULT )
 list(GET _importedConfigs ${_configIndexToUse}
_importedConfigToUse)

 get_target_property(_importedLocation ${_CURRENT_LIB}
IMPORTED_LOCATION_${_importedConfigToUse})
-get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} )
+get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
INTERFACE_LINK_LIBRARIES)
+if(_linkInterfaceLibs)
+   # resolve $CONFIG:... generator expressions
+   string(REGEX REPLACE \\$CONFIG:${_importedConfigToUse}
1
+  _linkInterfaceLibs ${_linkInterfaceLibs})
+   string(REGEX REPLACE \\$CONFIG:[^]* 0
+  _linkInterfaceLibs ${_linkInterfaceLibs})
+   # resolve $NOT:(0|1)
+   string(REGEX REPLACE \\$NOT:0 1
+  _linkInterfaceLibs ${_linkInterfaceLibs})
+   string(REGEX REPLACE \\$NOT:1 0
+  _linkInterfaceLibs ${_linkInterfaceLibs})
+   # resolve $(0|1):...
+   # empty items will be ignored by `foreach` later
+   string(REGEX REPLACE \\$0:[^]* 
+  _linkInterfaceLibs ${_linkInterfaceLibs})
+   string(REGEX REPLACE \\$1:([^]*) \\1
+  _linkInterfaceLibs ${_linkInterfaceLibs})
+else()
+   get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} )
+endif()

 list(APPEND _CCSR_NEW_REQ_LIBS  ${_importedLocation})
 #message(STATUS Appending lib ${_CURRENT_LIB} as
${_importedLocation})
-- 
1.9.4.msysgit.2
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] OBJECT library on left-hand-side of target_link_libraries

[Tamás Kenéz]

The documentation states that OBJECT libraries may not be [...] used in the
right hand side of target_link_libraries().

However it turns out that they can't be used on the left hand side either:

add_library(objlib OBJECT ...)
target_link_libraries(objlib dep-of-objlib)

Result:

CMake Error at CMakeLists.txt:13 (target_link_libraries):
  Object library target objlib may not link to anything.

This makes it impossible to concisely specify if an OBJECT library has a
dependency which is an IMPORTED library.

Only the legacy way works:

add_library(objlib OBJECT ...)
target_include_directories(objlib ${ZLIB_INCLUDE_DIRS})
...
add_executable(maintarget $TARGET_OBJECTS:objlib)
target_link_libraries(maintarget ${ZLIB_LIBRARIES})

But it would be convenient if this would also work:

add_library(objlib OBJECT ...)
target_link_libraries(objlib ZLIB::ZLIB)


Question:

Is this restriction, that an OBJECT library can't be on the left hand side
of
target_link_libraries, is it a hard, final decision? Or is this issue
open for a possible improvement which would allow this and would forward
the link dependencies to the main target the OBJECT library is incorporated
into?

Tamas
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [PATCH] Help: fix FindMatlab section headers

[Tamás Kenéz]

Hi,

FindMatlab used dash for its internal headers.
This commit replaces caret-headers with double-quote-headers and replaces
dash-headers with caret-headers.

On top of release.

Tamas


0001-Help-fix-FindMatlab-section-headers.patch
Description: Binary data
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] find_package config mode search path rule #5 error prone

[Tamás Kenéz]

Hi,

The search path rule #5 reads:

 Search project build trees recently configured in a cmake-gui(1). This can be 
 skipped if
 NO_CMAKE_BUILDS_PATH is passed. It is intended for the case when a user is 
 building
 multiple dependent projects one after another. (This step is implemented only 
 on Windows.)

I think this rule, while having the best intentions, is error prone
(speaking from experience).
There are great and proper ways to use the products of a project in a
dependent project. Opening the project in cmake-gui to expose the
byproduct of a config-module configuration+installation process in the
binary dir, is not of them.

What do you think, would it be wise to disable this rule with a new
policy? Would anybody miss it?

Tamas
-- 

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 0015231]: find_package: should be a simple way to alter the order of the config/module lookups

[Tamás Kenéz]

 Are you interested in working on a patch for this?

Yes, I'd give it a try. I signed up to Mantis, account: tamas.kenez so
you can assign it to me. I guess that's the next step.

Thanks,
Tamas

On Fri, Apr 17, 2015 at 2:01 PM, Brad King brad.k...@kitware.com wrote:
 On 04/16/2015 05:54 AM, Tamás Kenéz wrote:
 I think the main challenge will be how to format error messages when
 neither mode finds anything for a REQUIRED package.

 We can pretend they failed in the usual module;config order. So the
 wordings of the messages may remain as they are.

 The current message says:

   By not providing Findpkg.cmake in CMAKE_MODULE_PATH this project
   has asked CMake to find a package configuration file ...

 If someone sets CMAKE_FIND_PACKAGE_CONFIG_FIRST then that is what
 asked CMake to find a package configuration file even if the project
 does provide Findpkg.cmake in CMAKE_MODULE_PATH.  Therefore new
 wording will be needed in this case.  It should still depend on
 whether the find module was available.

 We should however think about what to do when
 CMAKE_FIND_PACKAGE_WARN_NO_MODULE is ON and both modes are enabled
 (and we're in CONFIG_FIRST mode). Should we check the missing
 find-module *after* we've found a config-module and print the warning?

 I think no, because the user has explicitly expressed the preference
 towards the CONFIG mode by specifying CONFIG_FIRST (either as a
 find_package option or as CMAKE_FIND_PACKAGE_CONFIG_FIRST).

 Agreed.  We can always add such a warning in the future.

 About the proposed change: The feature request proposes two ways to
 enable the CONFIG_FIRST mode: a new option for the find_package and a
 global variable (which I think should be called
 CMAKE_FIND_PACKAGE_CONFIG_FIRST).

 I think the find_package option is less important since the same
 effect can be achieved by creating a custom
 find_package_config_first() macro.

 If the functionality is implemented through either interface it will
 be easy to add the other, so I think they can just both be added
 together.

 Are you interested in working on a patch for this?

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

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0015231]: find_package: should be a simple way to alter the order of the config/module lookups

[Tamás Kenéz]

The https://public.kitware.com/Bug/view.php?id=15231 feature request
proposes a new feature to make find_package to attempt CONFIG mode
first.

On 10/31/2014 01:30 PM, Brad King wrote:

 I think the main challenge will be how to format error messages when
 neither mode finds anything for a REQUIRED package. It took years to
 get the current messages to a state that minimizes confusion among users
 that do not understand the two modes.

I think when neither mode finds anything it doesn't matter in which
order they failed.
We can pretend they failed in the usual module;config order. So the
wordings of the messages may remain as they are.

We should however think about what to do when
CMAKE_FIND_PACKAGE_WARN_NO_MODULE is ON and both modes are enabled
(and we're in CONFIG_FIRST mode). Should we check the missing
find-module *after* we've found a config-module and print the warning?

I think no, because the user has explicitly expressed the preference
towards the CONFIG mode by specifying CONFIG_FIRST (either as a
find_package option or as CMAKE_FIND_PACKAGE_CONFIG_FIRST).

About the proposed change: The feature request proposes two ways to
enable the CONFIG_FIRST mode: a new option for the find_package and a
global variable (which I think should be called
CMAKE_FIND_PACKAGE_CONFIG_FIRST).

I think the find_package option is less important since the same
effect can be achieved by creating a custom
find_package_config_first() macro.
To simulate the effect of the global variable is much more difficult
and heavy-weight.

Tamas
-- 

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