[CMake] GetPrerequisites with Android?

[Robert Dailey]

Has anyone used GetPrerequisites[1] when cross-compiling a shared
library with Android NDK toolchain? I'd like some way to get dependent
*.so files (located in the NDK itself and specified on the linker
command line when building) so I can copy them to my android java
project dir under "libs" so they get packaged when the APK is built.

[1]: https://cmake.org/cmake/help/v3.9/module/GetPrerequisites.html
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] There's several issues with NDK support in CMake 3.9.0

[Robert Dailey]

So I'm working with DanAlbert over on the NDK github project regarding
some issues I've hit with NDK r15b using CMake 3.9.0-rc5. He's already
identified one bug that I can help fix located in
`Modules/Platform/Android/ndk-stl-c++.cmake` related to platform
support. He also mentions something a bit more serious regarding
libandroid_support, which CMake isn't linking to. He recommended using
their pre-packaged toolchain file that comes with the NDK itself.
There's a couple more issues, I recommend heading over to the issue
page and read up on the discussion there:

https://github.com/android-ndk/ndk/issues/452

I'm stuck a bit in the middle here. I'm willing to help make changes
and help with testing on the CMake side, but I'm not very
knowledgeable on these things (compiler behavior, and CMake
integration with NDK). What I'm hoping is that you guys can help pitch
in on the discussion over on the NDK github page via the link above.
I'll try to learn from the discussions there and contribute one or
more merge requests to implement fixes.

All of these issues cropped up from my specific usage of CMake with
the NDK, so I'm in a really good position to be able to contribute
fixes and test solutions. Just let me know how I can help.
-- 

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] 3.9.0-rc3: CMAKE_ANDROID_NDK_DEPRECATED_HEADERS doesn't work outside of toolchain

[Robert Dailey]

Just wanted to share my solution to this, based on your suggestions
about code sharing. I still do some introspection but some of this is
based on our usage of environment variables and such. However the
logic to find NDK version is useful in general.

Instead of pasting the CMake code here, I have made it available as a gist:
https://gist.github.com/rcdailey/ae336b48b8681897c747524a5713c6c6

Hope this helps others that have similar questions. Thanks again Brad.

On Tue, Jun 27, 2017 at 11:07 AM, Brad King <brad.k...@kitware.com> wrote:
> On 06/27/2017 11:36 AM, Robert Dailey wrote:
>> Ok maybe I'm misunderstanding the design intent for toolchain files.
>
> Originally they were intended to contain information local to the
> machine, like `set(CMAKE_ANDROID_NDK /path/on/my/machine/to/ndk)`.
> In controlled environments that share many things it makes sense
> to have deployable toolchain files instead.
>
>> Basically, some things I like to determine programmatically. Putting
>> in them in the toolchain file violates the "introspection" rule, but
>> also results in code duplication
>
> Toolchain files can `include()` other files from next to them.  That
> can be used to avoid duplicate code.
>
> The only information you need within your toolchain file logic to
> compute CMAKE_ANDROID_NDK_DEPRECATED_HEADERS is CMAKE_ANDROID_NDK.
> If you add logic to find/require CMAKE_ANDROID_NDK up front then you
> can check its version.
>
> CMake's `Modules/Platform/Android-Determine.cmake` file has very little
> logic to choose `CMAKE_ANDROID_NDK` if it is not set by the user.  You
> can either duplicate this in a toolchain file helper or take advantage
> of knowledge about your controlled environments to have a shorter version.
>
> -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] FindDoxygen is doing find_package() when it is included

[Robert Dailey]

Apologies for the confusion and spam: I figured out that when you do a
find_package(), it also implicitly includes the contents of that
module into your list file so you can access its functions. I was
under the impression I had to include FindDoxygen.cmake explicitly to
access the functions it provides.

I'm guessing this is supported behavior. If so, I'll rely on it.

On Fri, Jul 7, 2017 at 1:20 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> I actually confused myself a bit... I think the issue is not that
> finding happens when including it, but that doxygen_add_docs() is
> bundled with the find module. What is the intended usage of this? If I
> do find_package() will that also make doxygen_add_docs() available? Or
> do I have to explicitly include FindDoxygen to get access to the
> function?
>
> On Fri, Jul 7, 2017 at 1:13 PM, Robert Dailey <rcdailey.li...@gmail.com> 
> wrote:
>> When I do this:
>>
>>
>> message( "blah1" )
>> include( FindDoxygen )
>>
>> message( "blah2" )
>> find_package( Doxygen 1.8.6 OPTIONAL_COMPONENTS dot )
>> message( "blah3" )
>>
>>
>> I get this output:
>>
>>
>> blah1
>> -- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found
>> version "1.8.13") found components:  doxygen missing components:  dot
>> blah2
>> -- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found
>> suitable version "1.8.13", minimum required is "1.8.6") found
>> components:  doxygen missing components:  dot
>> blah3
>>
>>
>> Two questions:
>>
>> 1. Why is find_package() happening automatically when I include the
>> find module? This is contrary to the behavior of other find modules. I
>> do not want it to find doxygen for me, as I have some minimum version
>> requirements and I do not want it to find dot. How can I disable this
>> implied search behavior?
>>
>> 2. Each time I run my scripts, it keeps searching for doxygen. Even
>> though I've specified dot as an optional component. I do not want it
>> to keep searching for doxygen each time I generate. It should find it
>> once and be done. How can I fix this behavior?
-- 

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] FindDoxygen is doing find_package() when it is included

[Robert Dailey]

Apologies for the confusion and spam: I figured out that when you do a
find_package(), it also implicitly includes the contents of that
module into your list file so you can access its functions. I was
under the impression I had to include FindDoxygen.cmake explicitly to
access the functions it provides.

I'm guessing this is supported behavior. If so, I'll rely on it.

On Fri, Jul 7, 2017 at 1:20 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> I actually confused myself a bit... I think the issue is not that
> finding happens when including it, but that doxygen_add_docs() is
> bundled with the find module. What is the intended usage of this? If I
> do find_package() will that also make doxygen_add_docs() available? Or
> do I have to explicitly include FindDoxygen to get access to the
> function?
>
> On Fri, Jul 7, 2017 at 1:13 PM, Robert Dailey <rcdailey.li...@gmail.com> 
> wrote:
>> When I do this:
>>
>>
>> message( "blah1" )
>> include( FindDoxygen )
>>
>> message( "blah2" )
>> find_package( Doxygen 1.8.6 OPTIONAL_COMPONENTS dot )
>> message( "blah3" )
>>
>>
>> I get this output:
>>
>>
>> blah1
>> -- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found
>> version "1.8.13") found components:  doxygen missing components:  dot
>> blah2
>> -- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found
>> suitable version "1.8.13", minimum required is "1.8.6") found
>> components:  doxygen missing components:  dot
>> blah3
>>
>>
>> Two questions:
>>
>> 1. Why is find_package() happening automatically when I include the
>> find module? This is contrary to the behavior of other find modules. I
>> do not want it to find doxygen for me, as I have some minimum version
>> requirements and I do not want it to find dot. How can I disable this
>> implied search behavior?
>>
>> 2. Each time I run my scripts, it keeps searching for doxygen. Even
>> though I've specified dot as an optional component. I do not want it
>> to keep searching for doxygen each time I generate. It should find it
>> once and be done. How can I fix this behavior?
-- 

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] FindDoxygen is doing find_package() when it is included

[Robert Dailey]

I actually confused myself a bit... I think the issue is not that
finding happens when including it, but that doxygen_add_docs() is
bundled with the find module. What is the intended usage of this? If I
do find_package() will that also make doxygen_add_docs() available? Or
do I have to explicitly include FindDoxygen to get access to the
function?

On Fri, Jul 7, 2017 at 1:13 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> When I do this:
>
>
> message( "blah1" )
> include( FindDoxygen )
>
> message( "blah2" )
> find_package( Doxygen 1.8.6 OPTIONAL_COMPONENTS dot )
> message( "blah3" )
>
>
> I get this output:
>
>
> blah1
> -- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found
> version "1.8.13") found components:  doxygen missing components:  dot
> blah2
> -- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found
> suitable version "1.8.13", minimum required is "1.8.6") found
> components:  doxygen missing components:  dot
> blah3
>
>
> Two questions:
>
> 1. Why is find_package() happening automatically when I include the
> find module? This is contrary to the behavior of other find modules. I
> do not want it to find doxygen for me, as I have some minimum version
> requirements and I do not want it to find dot. How can I disable this
> implied search behavior?
>
> 2. Each time I run my scripts, it keeps searching for doxygen. Even
> though I've specified dot as an optional component. I do not want it
> to keep searching for doxygen each time I generate. It should find it
> once and be done. How can I fix this behavior?
-- 

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] FindDoxygen is doing find_package() when it is included

[Robert Dailey]

I actually confused myself a bit... I think the issue is not that
finding happens when including it, but that doxygen_add_docs() is
bundled with the find module. What is the intended usage of this? If I
do find_package() will that also make doxygen_add_docs() available? Or
do I have to explicitly include FindDoxygen to get access to the
function?

On Fri, Jul 7, 2017 at 1:13 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> When I do this:
>
>
> message( "blah1" )
> include( FindDoxygen )
>
> message( "blah2" )
> find_package( Doxygen 1.8.6 OPTIONAL_COMPONENTS dot )
> message( "blah3" )
>
>
> I get this output:
>
>
> blah1
> -- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found
> version "1.8.13") found components:  doxygen missing components:  dot
> blah2
> -- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found
> suitable version "1.8.13", minimum required is "1.8.6") found
> components:  doxygen missing components:  dot
> blah3
>
>
> Two questions:
>
> 1. Why is find_package() happening automatically when I include the
> find module? This is contrary to the behavior of other find modules. I
> do not want it to find doxygen for me, as I have some minimum version
> requirements and I do not want it to find dot. How can I disable this
> implied search behavior?
>
> 2. Each time I run my scripts, it keeps searching for doxygen. Even
> though I've specified dot as an optional component. I do not want it
> to keep searching for doxygen each time I generate. It should find it
> once and be done. How can I fix this behavior?
-- 

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] FindDoxygen is doing find_package() when it is included

[Robert Dailey]

When I do this:


message( "blah1" )
include( FindDoxygen )

message( "blah2" )
find_package( Doxygen 1.8.6 OPTIONAL_COMPONENTS dot )
message( "blah3" )


I get this output:


blah1
-- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found
version "1.8.13") found components:  doxygen missing components:  dot
blah2
-- Found Doxygen: C:/Program Files/doxygen/bin/doxygen.exe (found
suitable version "1.8.13", minimum required is "1.8.6") found
components:  doxygen missing components:  dot
blah3


Two questions:

1. Why is find_package() happening automatically when I include the
find module? This is contrary to the behavior of other find modules. I
do not want it to find doxygen for me, as I have some minimum version
requirements and I do not want it to find dot. How can I disable this
implied search behavior?

2. Each time I run my scripts, it keeps searching for doxygen. Even
though I've specified dot as an optional component. I do not want it
to keep searching for doxygen each time I generate. It should find it
once and be done. How can I fix this behavior?
-- 

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] add_custom_target(): When is VERBATIM appropriate?

[Robert Dailey]

This is a continuation of the discussion I had with Brad here:
https://gitlab.kitware.com/cmake/cmake/merge_requests/1019#note_286609

Hopefully we can continue the discussion here, but I'm happy to hear
from others as well.

It was stated that VERBATIM is not necessarily useful in all cases.
Are these cases documented anywhere? Basically, how would I decide
when to use it and when not? For the MR above, it was suggested that
it be used for paths related to FindDoxygen.cmake, but I'm not sure
why it was recommended other than "Improved escaping behavior".

Thanks in advance for any information to help clarify my confusion.
-- 

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] Built-in tag support for FindDoxygen

[Robert Dailey]

I ran into an interesting situation. Originally, I had based
documentation on real targets. And in some ways, I still do, but not
directly anymore. I have some targets that are conditionally only
built on certain platforms. However, I wanted documentation for that
target to be generated regardless of platform. That means I cannot
bind a doxygen target to its real target, since it may not be there.
Everything else functions the same, and doxygen targets still build a
"mirror" of the dependency tree of the real targets amongst
themselves. Also the tag file generation happens the same way.

What I'd like to do is maybe put my doxygen CMake code (that simply
wraps doxygen_add_docs()) on a Gist for now or something, along with
some usage examples, and see what you think as far as implementation
goes. From there we can decide what needs to be integrated, or if
maybe this is a separate function provided by FindDoxygen.cmake.

I'll follow up later. Thanks for your advice.

On Fri, Jun 30, 2017 at 9:48 PM, Craig Scott <craig.sc...@crascit.com> wrote:
>
>
> On Thu, Jun 29, 2017 at 11:14 AM, Robert Dailey <rcdailey.li...@gmail.com>
> wrote:
>>
>> Doxygen supports linking external documentation together:
>> https://www.stack.nl/~dimitri/doxygen/manual/external.html
>>
>> Using doxygen_add_docs(), it doesn't provide built-in support for tag
>> files. I'm thinking this would be beneficial since the way the
>> function is designed encourages modular documentation. At least, I
>> have my projects structured like this (targets):
>>
>> A
>> A_doxygen
>> B
>> B_doxygen
>> C
>> C_doxygen
>>
>> I have 1 doxygen target per real library target. And each library has
>> dependencies on others. When library C uses something from A, I want
>> C_doxygen to link to the tagfile generated by A_doxygen.
>>
>> At the moment I'm accomplishing this by adding a target property to
>> each real target to keep track of target dependencies. Example:
>>
>> add_library(C ...)
>> target_link_libraries(C A)
>> set_property(TARGET C PROPERTY TARGET_DEPENDENCIES A)
>>
>> When I'm building A_doxygen target (using doxygen_add_docs()), I
>> specify DOXYGEN_GENERATE_TAGFILE. Then in C_doxygen, I specify
>> DOXYGEN_TAGFILES to point to the one output by A_doxygen.
>>
>> I don't like keeping target properties to query the dependency tree,
>> but this is the best I could come up with. Is there value in
>> incorporating this into FindDoxygen.cmake? If so, I'd like to
>> contribute it, if it's useful.
>
>
> I think there's good potential for this idea. The doxygen_add_docs()
> function could record the value of the DOXYGEN_GENERATE_TAGFILE variable in
> a target property (I'd recommend using the same name as the variable). A new
> DEPENDS option could be added to doxygen_add_docs() which would specify
> other targets this one depends on. This would invoke add_dependencies() to
> fulfil build ordering as usual, but it could also inspect the target
> properties of the dependees and if the DOXYGEN_GENERATE_TAGFILE property is
> set, then the DOXYGEN_TAGFILES variable could be augmented to pick up that
> tag file somehow. You'd have to be careful how the paths were handled to
> ensure they worked robustly, but conceptually at least I think this might be
> possible and useful. Example usage would then be something like this:
>
> # Populate DOXYGEN_GENERATE_TAGFILE if not already set,
> # use existing contents otherwise. Either way, define a target property
> # on foo which records the value.
> doxygen_add_docs(foo)
>
> # Does a similar thing as above for this target, but also picks up the
> # tag file from foo as recorded in its target properties and augments
>
> # the DOXYGEN_TAGFILES variable as appropriate.
>
> doxygen_add_docs(bar DEPENDS foo)
>
>
> You would need to be careful with how to handle contents of
> DOXYGEN_GENERATE_TAGFILE and DOXYGEN_TAGFILES that the project might already
> set. As a conservative measure, you might want to consider adding an option
> NO_AUTO_TAGFILES or similar to disable any of this logic in case a project
> does something complex and doxygen_add_docs() needs to be told to leave it
> completely up to the project to handle. The doxygen_add_docs() function was
> originally added with the intention of making it as easy as possible for
> projects to use Doxygen with minimal extra configuration, so I think having
> the auto tag handling enabled by default would probably be the right call,
> as long as there's a way for projects to disable it if needed.
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
-- 

Powered by www.kitware.com

Please keep

[cmake-developers] Built-in tag support for FindDoxygen

[Robert Dailey]

Doxygen supports linking external documentation together:
https://www.stack.nl/~dimitri/doxygen/manual/external.html

Using doxygen_add_docs(), it doesn't provide built-in support for tag
files. I'm thinking this would be beneficial since the way the
function is designed encourages modular documentation. At least, I
have my projects structured like this (targets):

A
A_doxygen
B
B_doxygen
C
C_doxygen

I have 1 doxygen target per real library target. And each library has
dependencies on others. When library C uses something from A, I want
C_doxygen to link to the tagfile generated by A_doxygen.

At the moment I'm accomplishing this by adding a target property to
each real target to keep track of target dependencies. Example:

add_library(C ...)
target_link_libraries(C A)
set_property(TARGET C PROPERTY TARGET_DEPENDENCIES A)

When I'm building A_doxygen target (using doxygen_add_docs()), I
specify DOXYGEN_GENERATE_TAGFILE. Then in C_doxygen, I specify
DOXYGEN_TAGFILES to point to the one output by A_doxygen.

I don't like keeping target properties to query the dependency tree,
but this is the best I could come up with. Is there value in
incorporating this into FindDoxygen.cmake? If so, I'd like to
contribute it, if it's useful.

Would love feedback and advice on this!
-- 

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] 3.9.0-rc3: CMAKE_ANDROID_NDK_DEPRECATED_HEADERS doesn't work outside of toolchain

[Robert Dailey]

On Tue, Jun 27, 2017 at 10:22 AM, Brad King <brad.k...@kitware.com> wrote:
> On 06/27/2017 11:14 AM, Robert Dailey wrote:
>> Also at $DAYJOB, we all work on the same code base. Our product is
>> tested and verified to work on a distinct set of configurations. Why
>> would I ask each user to create their own toolchain file?
>
> If you have a toolchain file that works in some finite set of
> tested environments then there is no reason not to share it
> among them.
>
> Why can't the logic to choose `CMAKE_ANDROID_NDK_DEPRECATED_HEADERS`
> be in your toolchain file?  All it needs to know is the NDK location.

Ok maybe I'm misunderstanding the design intent for toolchain files. I
agree they shouldn't do much introspection (i.e. "business logic"),
but I've always made sure to provide multiple toolchain files if
necessary in version control, one per supported (tested) configuration
for the code base. Generally speaking, I provide one per supported
platform (Android, Windows, Linux, etc). However, I will not specify
things in the toolchain file that are not "static". Basically, some
things I like to determine programmatically. Putting in them in the
toolchain file violates the "introspection" rule, but also results in
code duplication since I have to do that same introspection in each
toolchain file.

So my specific case is this: Unified headers have been supported since
NDK r14. However, because of certain libraries and language features
that we use, our code fails to compile due to bugs in the unified
headers. Again for our specific code base, these bugs are addressed in
NDK r15b. So now I'm faced with a situation: Just because unified
headers are present doesn't mean we should use them. So I can no
longer base the decision to use unified headers on when they were
introduced, but it needs to be based on an arbitrary NDK version.

To solve this issue, I have come up with this logic:
https://gist.github.com/rcdailey/0ee52bfca634e7da55b6f86b9af91911

This CMake logic allows me to obtain the version of the NDK the user
has on their system and based on that version I can strategically set
the CMAKE_ANDROID_NDK_DEPRECATED_HEADERS variable. This is all
transparent to users on my team. None of them have done the research I
have into this, so they would not know which NDK to use or when to set
this flag to 1 or 0. We support r14 and r15 in different environments.

Maybe my situation is the exception to the rule, but I just don't see
an elegant way to do what I want.
-- 

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] 3.9.0-rc3: CMAKE_ANDROID_NDK_DEPRECATED_HEADERS doesn't work outside of toolchain

[Robert Dailey]

On Mon, Jun 26, 2017 at 3:32 PM, Brad King <brad.k...@kitware.com> wrote:
> On 06/26/2017 11:58 AM, Robert Dailey wrote:
>> Why does this only work in the toolchain file?
>
> 1. It needs to be set early.
>
> 2. It needs to propagate into try_compile projects.
>
> The toolchain file is sufficient for both.  A cache entry is okay
> for (1) but for (2) one would additionally need to set this:
>
>   
> https://cmake.org/cmake/help/v3.9/variable/CMAKE_TRY_COMPILE_PLATFORM_VARIABLES.html
>
> ...though that is really meant for toolchain files too.
>
> Note that toolchain files are meant to be local to the machine, not
> distributed with source trees and full of introspection logic.  The
> (local) author of the toolchain file should know the NDK version and
> choose whether to use `CMAKE_ANDROID_NDK_DEPRECATED_HEADERS`.
>
> Your project code could check the NDK version and error out if
> the `CMAKE_ANDROID_NDK_DEPRECATED_HEADERS` is not correct.

Your idea of erroring out seems like the best alternative solution,
although again I strongly feel this is something that should be
automated. It makes the user's life easier. If we know it only works a
certain way and have the necessary information to make that decision
programmatically, then why not? Software is supposed to make our lives
easier. Adding unnecessary manual steps doesn't really serve any
benefit IMHO.

Also at $DAYJOB, we all work on the same code base. Our product is
tested and verified to work on a distinct set of configurations. Why
would I ask each user to create their own toolchain file? Each time a
change is needed, I'd have to email the whole team and ask them to
make a specific change to their toolchain file. This is very
unproductive. I can't say I agree with your philosophy.
-- 

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] Bug with CMAKE_ASM_COMPILER and Android NDK

[Robert Dailey]

On Mon, Jun 26, 2017 at 10:25 AM, Brad King <brad.k...@kitware.com> wrote:
> On 06/23/2017 03:18 PM, Robert Dailey wrote:
>> enable_language(ASM)
>>
>> CMake appears to find clang.exe in the wrong place
>
> Add a `Modules/Platform/Android-Determine-ASM.cmake` module
> based on `Modules/Platform/Android-Determine-CXX.cmake`.
>
> Also the modules
>
>   Modules/Platform/Android/Determine-Compiler-NDK.cmake
>   Modules/Platform/Android/Determine-Compiler-Standalone.cmake
>   Modules/Platform/Android/Determine-Compiler.cmake
>
> need to be updated to set `_ANDROID_TOOL_ASM_COMPILER` and similar
> variables for ASM as is done for C and CXX.

Are you saying I should modify my local installation? Or are these
your personal notes so that these changes get adopted upstream? Not
sure I understand...
-- 

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] 3.9.0-rc3: CMAKE_ANDROID_NDK_DEPRECATED_HEADERS doesn't work outside of toolchain

[Robert Dailey]

Hi,

I tried setting CMAKE_ANDROID_NDK_DEPRECATED_HEADERS in a common CMake
script of mine (set during configuration but before any targets are
created). I also tried making it a cache variable, but in each case it
isn't working. I set like this:

set( CMAKE_ANDROID_NDK_DEPRECATED_HEADERS 1 )

And for r14b NDK, the unified headers were used, I expected them to
NOT be used. When I move the above line of code to my toolchain file,
it works as expected (the unified headers are NOT used).

Why does this only work in the toolchain file? I'd like to be able to
set it outside the toolchain file because I do quite a bit of logic to
determine if I want deprecated headers to be used or not; it's not
meant to be something specified by the user/toolchain in my case, but
rather something calculated.

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

Re: [cmake-developers] Bug with CMAKE_ASM_COMPILER and Android NDK

[Robert Dailey]

Oh I'm using CMake 3.9.0 RC3

On Fri, Jun 23, 2017 at 2:18 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> So I have two environment variables:
>
> ANDROID_NDK = E:\android\ndk
> ANDROID_NDK_72 = E:\android\ndk_72
>
> In my toolchain file, I do this:
>
>
>
> set( CMAKE_SYSTEM_NAME Android )
> set( CMAKE_SYSTEM_VERSION 15 ) # API level
> set( CMAKE_ANDROID_ARCH_ABI armeabi-v7a )
> set( CMAKE_ANDROID_STL_TYPE c++_shared )
> set( CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION clang )
>
> # ANDROID_NDK_72 represents a separate path to the NDK for 7.2 frontend
> # builds and later. This is to make it less painful to convert between
> # Crystax (7.1.x) and official NDK, which was restored in version 7.2.
> string(REGEX REPLACE "" "/" ndk_path "$ENV{ANDROID_NDK_72}")
> if( NOT EXISTS ${ndk_path} )
> string(REGEX REPLACE "" "/" ndk_path "$ENV{ANDROID_NDK}")
> endif()
>
> set( CMAKE_ANDROID_NDK ${ndk_path} )
> unset(ndk_path)
>
>
>
> This works fine, until you do something like this in your CMake scripts:
>
>
> enable_language(ASM)
>
>
> CMake appears to find clang.exe in the wrong place (It's using
> ANDROID_NDK directly somehow instead of using the CMAKE_ANDROID_NDK I
> set from my toolchain file). Output from CMake is at the bottom of
> this email. The repository I'm configuring is here:
>
> https://github.com/Orphis/boost-cmake
>
> Logs:
>
>
> $ cmake .. -GNinja
> -DCMAKE_TOOLCHAIN_FILE="E:\code\_external\\android_armeabi-v7a.toolchain.cmake"
> -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=_install
> -DBOOST_LOCALE_ENABLE_ICU_BACKEND=OFF
> -DBOOST_LOCALE_ENABLE_ICONV_BACKEND=OFF
> -- Android: Targeting API '15' with architecture 'arm', ABI
> 'armeabi-v7a', and processor 'armv7-a'
> -- Android: Selected Clang toolchain 'arm-linux-androideabi-clang'
> with GCC toolchain 'arm-linux-androideabi-4.9'
> -- The C compiler identification is Clang 5.0.300080
> -- The CXX compiler identification is Clang 5.0.300080
> -- Check for working C compiler:
> E:/android/ndk_72/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe
> -- Check for working C compiler:
> E:/android/ndk_72/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe
> -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler:
> E:/android/ndk_72/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++.exe
> -- Check for working CXX compiler:
> E:/android/ndk_72/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++.exe
> -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Boost found: 1.63.0 E:/code/_external/boost-cmake/boost/boost_1_63_0
> -- Boost found: 1.63.0 E:/code/_external/boost-cmake/boost/boost_1_63_0
> -- Standalone mode detected
> -- Looking for __linux__
> -- Looking for __linux__ - found
> -- Looking for _WIN32
> -- Looking for _WIN32 - not found
> -- Looking for __APPLE__
> -- Looking for __APPLE__ - not found
> -- Looking for __ANDROID__
> -- Looking for __ANDROID__ - found
> -- Looking for __FreeBSD__
> -- Looking for __FreeBSD__ - not found
> -- The ASM compiler identification is unknown
> -- Found assembler:
> E:/android/ndk/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe
> CMake Error at libs/context.cmake:34 (enable_language):
>   The CMAKE_ASM_COMPILER:
>
> E:/android/ndk/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe
>
>   is not a full path to an existing compiler tool.
>
>   Tell CMake where to find the compiler by setting either the environment
>   variable "ASM" or the CMake cache entry CMAKE_ASM_COMPILER to the full path
>   to the compiler, or to the compiler name if it is in the PATH.
> Call Stack (most recent call first):
>   CMakeLists.txt:63 (include)
>
>
> -- Warning: Did not find file Compiler/-ASM
-- 

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] Bug with CMAKE_ASM_COMPILER and Android NDK

[Robert Dailey]

So I have two environment variables:

ANDROID_NDK = E:\android\ndk
ANDROID_NDK_72 = E:\android\ndk_72

In my toolchain file, I do this:



set( CMAKE_SYSTEM_NAME Android )
set( CMAKE_SYSTEM_VERSION 15 ) # API level
set( CMAKE_ANDROID_ARCH_ABI armeabi-v7a )
set( CMAKE_ANDROID_STL_TYPE c++_shared )
set( CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION clang )

# ANDROID_NDK_72 represents a separate path to the NDK for 7.2 frontend
# builds and later. This is to make it less painful to convert between
# Crystax (7.1.x) and official NDK, which was restored in version 7.2.
string(REGEX REPLACE "" "/" ndk_path "$ENV{ANDROID_NDK_72}")
if( NOT EXISTS ${ndk_path} )
string(REGEX REPLACE "" "/" ndk_path "$ENV{ANDROID_NDK}")
endif()

set( CMAKE_ANDROID_NDK ${ndk_path} )
unset(ndk_path)



This works fine, until you do something like this in your CMake scripts:


enable_language(ASM)


CMake appears to find clang.exe in the wrong place (It's using
ANDROID_NDK directly somehow instead of using the CMAKE_ANDROID_NDK I
set from my toolchain file). Output from CMake is at the bottom of
this email. The repository I'm configuring is here:

https://github.com/Orphis/boost-cmake

Logs:


$ cmake .. -GNinja
-DCMAKE_TOOLCHAIN_FILE="E:\code\_external\\android_armeabi-v7a.toolchain.cmake"
-DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=_install
-DBOOST_LOCALE_ENABLE_ICU_BACKEND=OFF
-DBOOST_LOCALE_ENABLE_ICONV_BACKEND=OFF
-- Android: Targeting API '15' with architecture 'arm', ABI
'armeabi-v7a', and processor 'armv7-a'
-- Android: Selected Clang toolchain 'arm-linux-androideabi-clang'
with GCC toolchain 'arm-linux-androideabi-4.9'
-- The C compiler identification is Clang 5.0.300080
-- The CXX compiler identification is Clang 5.0.300080
-- Check for working C compiler:
E:/android/ndk_72/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe
-- Check for working C compiler:
E:/android/ndk_72/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe
-- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler:
E:/android/ndk_72/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++.exe
-- Check for working CXX compiler:
E:/android/ndk_72/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++.exe
-- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Boost found: 1.63.0 E:/code/_external/boost-cmake/boost/boost_1_63_0
-- Boost found: 1.63.0 E:/code/_external/boost-cmake/boost/boost_1_63_0
-- Standalone mode detected
-- Looking for __linux__
-- Looking for __linux__ - found
-- Looking for _WIN32
-- Looking for _WIN32 - not found
-- Looking for __APPLE__
-- Looking for __APPLE__ - not found
-- Looking for __ANDROID__
-- Looking for __ANDROID__ - found
-- Looking for __FreeBSD__
-- Looking for __FreeBSD__ - not found
-- The ASM compiler identification is unknown
-- Found assembler:
E:/android/ndk/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe
CMake Error at libs/context.cmake:34 (enable_language):
  The CMAKE_ASM_COMPILER:

E:/android/ndk/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe

  is not a full path to an existing compiler tool.

  Tell CMake where to find the compiler by setting either the environment
  variable "ASM" or the CMake cache entry CMAKE_ASM_COMPILER to the full path
  to the compiler, or to the compiler name if it is in the PATH.
Call Stack (most recent call first):
  CMakeLists.txt:63 (include)


-- Warning: Did not find file Compiler/-ASM
-- 

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] How to refer to *.so files in Android NDK?

[Robert Dailey]

In my toolchain file for Android NDK, I specify the following *.so
paths manually:

set( ANDROID_PREBUILT_LIBRARIES

${CMAKE_ANDROID_NDK}/sources/cxx-stl/gnu-libstdc++/4.9/libs/x86/libgnustl_shared.so
${CMAKE_ANDROID_NDK}/platforms/android-15/arch-x86/usr/lib/libz.so
)

However, I'd like a better way to find these files: I already
configure CMake 3.8 using built-in Android support. It's able to
configure my toolchain just fine. Can I leverage some built-in
functionality to get the path to these files? I'm worried with the way
it is, if I change the other variables that the paths won't be valid
anymore and I'll have to update them manually again.
-- 

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] Reentrant-safe includes

[Robert Dailey]

So I have a series of common CMake scripts I use:

pre-setup.cmake
post-setup.cmake

I include pre-setup.cmake at the beginning of the root CMakeLists.txt
and post-setup.cmake is included at the bottom. add_subdirectory() and
other target stuff is done inbetween.

One issue I run into is that these files are sometimes re-entered. For
example, sometimes I have a git submodule with a CMakeLists.txt that
is the root when CMake is run on the submodule by itself, and in
others the submodule's root CMakeLists.txt is just a normal script
included by the parent repository's scripts.

At the moment I'm doing some counting logic to make sure that
pre-setup.cmake and post-setup.cmake are not included multiple times,
if they are not at the root CMakeLists.txt.

Example:

At the top of pre-setup.cmake:

if( NOT DEFINED PRE_SETUP_DEPTH_COUNT )
set( PRE_SETUP_DEPTH_COUNT 0 )
endif()

math( EXPR PRE_SETUP_DEPTH_COUNT "${PRE_SETUP_DEPTH_COUNT}+1" )

if( PRE_SETUP_DEPTH_COUNT GREATER 1 )
return()
endif()

And at the top of post-setup.cmake:

math( EXPR PRE_SETUP_DEPTH_COUNT "${PRE_SETUP_DEPTH_COUNT}-1" )
if( PRE_SETUP_DEPTH_COUNT )
return()
endif()

This seems to work, but is there a simpler/better solution?
-- 

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] Force target to always run last?

[Robert Dailey]

To be clear, I do have a "package" target per real native target.
However, if I set up the dependencies like so:

Target 'A' depends on 'copy_dlls'
Target 'A' depends on target 'B'
Target 'A_package' depends on 'A'
Target 'A_package' depends on 'copy_dlls'

Furthermore, the add_custom_command() to delete 'libs' and copy the
*.so is added to 'A' and 'B' (each for their own 'libs' directory and
their own *.so output)

Then when I do:

$ ninja A_package

The following items are built in any order (due to parallel builds):

* B
* A (after B)
* copy_dlls

If 'copy_dlls' happens while 'B' is building, then it's possible the
post-build event run by B that deletes the 'libs' directory also
deletes some files copied by 'copy_dlls', which means those files will
not get packaged when 'A_package' invokes `ant release` for the APK
packaging.

I hope that makes the issue a little clearer... sorry for the confusion.

On Thu, May 18, 2017 at 1:22 PM, David Cole <dlrd...@aol.com> wrote:
> Seems to me the simplest thing to do would be to have copy_dlls depend
> on nothing, and have package depend on copy_dlls and all the native
> targets, and then tell your developers to run:
>
>   make individualTarget && make package
>
> Either that, or introduce a packageIndividualTarget target for each
> individualTarget.
>
> Maybe I just don't understand fully, but why would you ever "make
> individualTarget" and then expect package to work properly? What if
> stuff that depends on that individualTarget also needs to rebuild
> before packaging? Shouldn't you have to do a build all to guarantee
> that packaging the results works properly?
>
>
>
>
>
>
> On Thu, May 18, 2017 at 12:16 PM, Robert Dailey
> <rcdailey.li...@gmail.com> wrote:
>> So let me go over the problem I'm trying to solve, because it's
>> possible at this point I'm over-engineering it, but it's hard to fix.
>>
>> So my build process is for native shared library targets that
>> eventually get included in an APK for Android. I'm using the NDK
>> toolchain to build my native targets. The general flow from nothing to
>> complete APK is as follows:
>>
>> 1. Build all native library targets
>> 2. Copy native *.so outputs from the CMake build to `libs/armeabi-v7a`
>> in the android project directory (where the src, res, and other
>> android directories are located)
>> 3. Run custom commands that basically invoke 'ant release', and since
>> I positioned the *.so files under 'libs' they get packaged with the
>> APK itself.
>>
>> This is how I provide support for using CMake to build native, run
>> java build, and perform APK packaging.
>>
>> There's a lot of setup that happens in CMake in order to make sure the
>> 'ant release' command behaves as expected. I have to handle a few
>> corner cases:
>>
>> * Each new build of the custom target that runs the 'ant release'
>> command has to only contain the *.so files that were built during that
>> run
>> * Various third-party libraries (pre-compiled *.so files) have to also
>> be copied to libs/armeabi-v7a for only certain android projects,
>> because we do not want duplicated *.so files across multiple android
>> libraries (ant release will fail if there are duplicate *.so files
>> across android project dependencies)
>>
>> So given this, my complete pipeline is as follows:
>>
>> 1. A `android_clean_libs` custom target is run which iterates all
>> known native targets with mapped java projects and completely deletes
>> its 'libs' directory (this is a forced clean prior to building)
>> 2. A `copy_dlls` target runs next, which copies third party
>> (precompiled) *.so files to a single common java project, in its
>> 'libs/armeabi-v7a' directory.
>> 3. Each native target now builds in parallel, as a post-build event it
>> copies its output *.so file to its respective libs/armeabi-v7a
>> directory for packaging.
>> 4. A final 'package' custom target runs which runs 'ant release' on
>> the bottom-most android project (that is not a library target by
>> itself).
>>
>> The part I don't like here is step #1. I don't like the clean to
>> require keeping track of a global property of a list of directories to
>> remove. Ideally, #1 should run as a post-build event during step 3.
>> Basically each native target should delete its 'libs' directory prior
>> to copying its own *.so target to that directory. However, I can't do
>> this because of step #2. Step 2 must happen first, because it's the
>> only way I can guarantee that it will execute regardless of which
>> target I build (all, or specific target). I make `co

Re: [CMake] Force target to always run last?

[Robert Dailey]

So let me go over the problem I'm trying to solve, because it's
possible at this point I'm over-engineering it, but it's hard to fix.

So my build process is for native shared library targets that
eventually get included in an APK for Android. I'm using the NDK
toolchain to build my native targets. The general flow from nothing to
complete APK is as follows:

1. Build all native library targets
2. Copy native *.so outputs from the CMake build to `libs/armeabi-v7a`
in the android project directory (where the src, res, and other
android directories are located)
3. Run custom commands that basically invoke 'ant release', and since
I positioned the *.so files under 'libs' they get packaged with the
APK itself.

This is how I provide support for using CMake to build native, run
java build, and perform APK packaging.

There's a lot of setup that happens in CMake in order to make sure the
'ant release' command behaves as expected. I have to handle a few
corner cases:

* Each new build of the custom target that runs the 'ant release'
command has to only contain the *.so files that were built during that
run
* Various third-party libraries (pre-compiled *.so files) have to also
be copied to libs/armeabi-v7a for only certain android projects,
because we do not want duplicated *.so files across multiple android
libraries (ant release will fail if there are duplicate *.so files
across android project dependencies)

So given this, my complete pipeline is as follows:

1. A `android_clean_libs` custom target is run which iterates all
known native targets with mapped java projects and completely deletes
its 'libs' directory (this is a forced clean prior to building)
2. A `copy_dlls` target runs next, which copies third party
(precompiled) *.so files to a single common java project, in its
'libs/armeabi-v7a' directory.
3. Each native target now builds in parallel, as a post-build event it
copies its output *.so file to its respective libs/armeabi-v7a
directory for packaging.
4. A final 'package' custom target runs which runs 'ant release' on
the bottom-most android project (that is not a library target by
itself).

The part I don't like here is step #1. I don't like the clean to
require keeping track of a global property of a list of directories to
remove. Ideally, #1 should run as a post-build event during step 3.
Basically each native target should delete its 'libs' directory prior
to copying its own *.so target to that directory. However, I can't do
this because of step #2. Step 2 must happen first, because it's the
only way I can guarantee that it will execute regardless of which
target I build (all, or specific target). I make `copy_dlls` a
dependency of every other target, so it always runs. If I could force
it to run *last*, then I could simplify step 1.

Sorry if this is too much information or if I've not explained things
clearly, but I wanted to hash out the details because maybe there is a
better approach. I'm willing to start from scratch on this if it
improves the design of the targets.

Thanks again!!


On Thu, May 18, 2017 at 10:51 AM, David Cole <dlrd...@aol.com> wrote:
> I'm sorry, I misunderstood that you wanted it to run last regardless
> of what target you are building. I was assuming you wanted it to
> happen when you build the "all" target. I didn't think you wanted to
> run it after any other *individual* target which you might specify.
>
> I don't know of an easy way to do that. You could add a custom command
> as a post-build command on every single target, but that seems like it
> wouldn't work for you either, as it would run the command potentially
> multiple times, with no way to tell whether you're being called last
> or not.
>
> Sorry.
>
> Why does this need to run after the build of any individual target?
> Why not just say there are two ways to get it to run: build "all" or
> explicitly build it after you build the other individual thing you
> want?
>
>
>
>
> On Thu, May 18, 2017 at 10:24 AM, Robert Dailey
> <rcdailey.li...@gmail.com> wrote:
>> David,
>>
>> Thanks for your help. So if I do it as you suggest, this will also
>> require I specify `ALL` to add_custom_target(), correct? If I do it
>> this way, will it still run even if it isn't a dependency of the
>> target I'm building?
>>
>> Let me set up a simple scenario for my own understanding. Suppose I
>> have the following targets:
>>
>> * A (add_library target)
>> * B (add_library target)
>> * C (add_custom_target target)
>>
>> Dependencies:
>>
>> B depends on A
>> C depends on B and A
>>
>> Normally if I build B, only A and B will build. However, if C was set
>> up using `ALL`, will it build C when I build B? So the expected build
>> order in this case would be:
>>
>> 1. A
>> 2. B
&g

Re: [CMake] Force target to always run last?

[Robert Dailey]

David,

Thanks for your help. So if I do it as you suggest, this will also
require I specify `ALL` to add_custom_target(), correct? If I do it
this way, will it still run even if it isn't a dependency of the
target I'm building?

Let me set up a simple scenario for my own understanding. Suppose I
have the following targets:

* A (add_library target)
* B (add_library target)
* C (add_custom_target target)

Dependencies:

B depends on A
C depends on B and A

Normally if I build B, only A and B will build. However, if C was set
up using `ALL`, will it build C when I build B? So the expected build
order in this case would be:

1. A
2. B
3. C

Thanks in advance.

On Wed, May 17, 2017 at 4:26 PM, David Cole <dlrd...@aol.com> wrote:
> The way I know how to do this is to add it last at the bottom of the
> top-level CMakeLists.txt file, and then use add_dependencies to make
> it depend on all other targets. (Or at least all other "leaf" targets,
> which further depend on others, ... the sum of which is "all other
> targets" besides the new "last" target.)
>
> So it's not pretty, but it's possible.
>
>
> HTH,
> David C.
>
>
>
> On Wed, May 17, 2017 at 11:36 AM, Robert Dailey
> <rcdailey.li...@gmail.com> wrote:
>> I have a custom target that must meet the following requirements:
>>
>> * It must always run, regardless of what subset of other targets are being 
>> built
>> * It must always be the very last thing run. In parallelized builds,
>> it must wait until all other targets are done building before
>> starting, so that it is the very last target run, and should not run
>> in parallel  with others.
>>
>> Is this possible? I'm willing to use hackery if needed...
>>
>> Running CMake 3.8.0. Thanks!
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: 
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more 
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at 
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] Force target to always run last?

[Robert Dailey]

I have a custom target that must meet the following requirements:

* It must always run, regardless of what subset of other targets are being built
* It must always be the very last thing run. In parallelized builds,
it must wait until all other targets are done building before
starting, so that it is the very last target run, and should not run
in parallel  with others.

Is this possible? I'm willing to use hackery if needed...

Running CMake 3.8.0. 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

Re: [CMake] How to get list of target dependencies?

[Robert Dailey]

Forgot to mention, I'm using CMake 3.8.1

On Thu, May 4, 2017 at 10:47 AM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> How can I get a list of target dependencies of a target? For example,
> if I have 3 library targets that depend on each other like this:
>
> A -> B -> C
>
> When I ask for the target dependencies for A, I should get a list back
> with B in it. Basically this would be the same list I pass to
> target_link_libraries(), minus actual library files with no
> corresponding target known to CMake.
>
> I see a LINK_DEPENDS target property. Is this what I want?
-- 

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] How to get list of target dependencies?

[Robert Dailey]

How can I get a list of target dependencies of a target? For example,
if I have 3 library targets that depend on each other like this:

A -> B -> C

When I ask for the target dependencies for A, I should get a list back
with B in it. Basically this would be the same list I pass to
target_link_libraries(), minus actual library files with no
corresponding target known to CMake.

I see a LINK_DEPENDS target property. Is this what I want?
-- 

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] What is ANDROID_JAVA_SOURCE_DIR for?

[Robert Dailey]

I am seeing hints of ANT / JAVA support for Android in 3.8.1
documentation. Essentially there is a whole list of properties that
have unexplained use cases under Properties for Targets. I see
ANDROID_JAVA_SOURCE_DIR, for example. What are these for? Will CMake
actually do the "ant release" command for you? I've been using custom
targets to do the java build & packaging steps for Android.
-- 

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] Trouble with FindPNG module

[Robert Dailey]

To give you some context, this is an Ubuntu 14 installation for
hosting our Atlassian Bamboo build server. We use it to build a 32-bit
application. The OS itself is 64-bit, but our app does not compile 64
bit (code is too crappy). So I had to make sure to be careful that I'm
using the correct toolchain (gcc 4.9) and 32-bit libs. CMake uses
find_package() for most libraries, and those libs must be the 32-bit
versions.

What instructions would you suggest for setting up the VM like you
mentioned? It needs to be something I can "initialize" from within
Bamboo. Basically as part of the build process, before doing anything,
I need to be able to tell bamboo to use a specific environment (in
this case specific VM). I'm not incredibly familiar with Linux, so
hopefully there is a recommended path here.

Thanks.

On Mon, Apr 24, 2017 at 1:17 PM, Roger Leigh <rle...@codelibre.net> wrote:
> On 24/04/2017 15:54, Robert Dailey wrote:
>>
>> Sorry to bump; any info on this? I'm completely blocked :-(
>>
>> On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey <rcdailey.li...@gmail.com>
>> wrote:
>>>
>>> I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
>>>
>>> find_package(PNG REQUIRED)
>>>
>>> Which gives me the output in CMake:
>>>
>>> Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50")
>>>
>>> The CMakeCache.txt file has these variables set:
>>>
>>> PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND
>>> PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND
>>> PNG_PNG_INCLUDE_DIR:PATH=/usr/include
>>>
>>> So it found the headers, but not the libs. Why did it not find the
>>> libs? Note that my version of Ubuntu is 64-bit, and I've installed the
>>> 32-bit libs like so:
>>>
>>> $ sudo apt-get install libpng12-dev:i386
>>>
>>> Would the find module be confused because it is trying to find the
>>> 64-bit library? What's the issue?
>
>
> Sounds like that's exactly the problem.  You can only have one libpng
> *development* package installed at once.  You probably want the regular
> "libpng-dev" package installed if you want to build against the standard
> libpng.
>
> What's your goal here?  Why did you install a single i386 development
> package?
>
> If you want to build i386 binaries, it's usually simpler to build in a
> virtual machine, i.e. a chroot, container, full VM or whatever you like,
> where you have a fully 32-bit environment.  The multiarch library support is
> primarily intended for *deploying and running* 32-bit code rather than
> development.  While you can use it for development, it gets painful due to
> the conflicts with the headers and other bits in the native development
> packages.
>
>
> Regards,
> Roger
>
> --
>
> 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] Trouble with FindPNG module

[Robert Dailey]

Interestingly, the changes to my toolchain made below work:


set( CMAKE_SYSTEM_NAME Linux )
set( CMAKE_SYSTEM_VERSION 1 )
set( CMAKE_SYSTEM_PROCESSOR i386 )
set( CMAKE_C_COMPILER gcc-4.9 )
set( CMAKE_CXX_COMPILER g++-4.9 )
set( CMAKE_C_COMPILER_ARG1 -m32 )
set( CMAKE_CXX_COMPILER_ARG1 -m32 )


The only change here is that I'm using CMAKE_C_COMPILER_ARG1 and
CMAKE_CXX_COMPILER_ARG1. These are not documented anywhere. I only
found out about them from a post from Bill Hoffman (which I have lost
the URL to).

Is this the correct toolchain? At least find_package() is properly
finding 32-bit libraries now, so I am happy. Should
CMAKE_SYSTEM_PROCESSOR be i386 or i686?



On Mon, Apr 24, 2017 at 12:22 PM, Robert Dailey
<rcdailey.li...@gmail.com> wrote:
> The output is:
>
> x86_64-linux-gnu
>
> How can I tell CMake to look for 32-bit libraries? I would like to
> force this from my toolchain file (which I posted a few minutes ago)
>
> On Mon, Apr 24, 2017 at 10:16 AM, Andrew Fuller <aful...@teradici.com> wrote:
>> Where did the library get installed on your system?  What's the value of
>> CMAKE__LIBRARY_ARCHITECTURE?
>>
>>
>> Since you're on a 64-bit system, I'd expect CMake to be looking for 64-bit
>> libraries unless you've told it otherwise.
>>
>> ________
>> From: CMake <cmake-boun...@cmake.org> on behalf of Robert Dailey
>> <rcdailey.li...@gmail.com>
>> Sent: April 24, 2017 7:54:18 AM
>> To: CMake; CMake Developers
>> Subject: Re: [CMake] Trouble with FindPNG module
>>
>> Sorry to bump; any info on this? I'm completely blocked :-(
>>
>> On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey <rcdailey.li...@gmail.com>
>> wrote:
>>> I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
>>>
>>> find_package(PNG REQUIRED)
>>>
>>> Which gives me the output in CMake:
>>>
>>> Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50")
>>>
>>> The CMakeCache.txt file has these variables set:
>>>
>>> PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND
>>> PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND
>>> PNG_PNG_INCLUDE_DIR:PATH=/usr/include
>>>
>>> So it found the headers, but not the libs. Why did it not find the
>>> libs? Note that my version of Ubuntu is 64-bit, and I've installed the
>>> 32-bit libs like so:
>>>
>>> $ sudo apt-get install libpng12-dev:i386
>>>
>>> Would the find module be confused because it is trying to find the
>>> 64-bit library? What's the issue?
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
-- 

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] Trouble with FindPNG module

[Robert Dailey]

The output is:

x86_64-linux-gnu

How can I tell CMake to look for 32-bit libraries? I would like to
force this from my toolchain file (which I posted a few minutes ago)

On Mon, Apr 24, 2017 at 10:16 AM, Andrew Fuller <aful...@teradici.com> wrote:
> Where did the library get installed on your system?  What's the value of
> CMAKE__LIBRARY_ARCHITECTURE?
>
>
> Since you're on a 64-bit system, I'd expect CMake to be looking for 64-bit
> libraries unless you've told it otherwise.
>
> 
> From: CMake <cmake-boun...@cmake.org> on behalf of Robert Dailey
> <rcdailey.li...@gmail.com>
> Sent: April 24, 2017 7:54:18 AM
> To: CMake; CMake Developers
> Subject: Re: [CMake] Trouble with FindPNG module
>
> Sorry to bump; any info on this? I'm completely blocked :-(
>
> On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey <rcdailey.li...@gmail.com>
> wrote:
>> I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
>>
>> find_package(PNG REQUIRED)
>>
>> Which gives me the output in CMake:
>>
>> Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50")
>>
>> The CMakeCache.txt file has these variables set:
>>
>> PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND
>> PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND
>> PNG_PNG_INCLUDE_DIR:PATH=/usr/include
>>
>> So it found the headers, but not the libs. Why did it not find the
>> libs? Note that my version of Ubuntu is 64-bit, and I've installed the
>> 32-bit libs like so:
>>
>> $ sudo apt-get install libpng12-dev:i386
>>
>> Would the find module be confused because it is trying to find the
>> 64-bit library? What's the issue?
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

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] [cmake-developers] Trouble with FindPNG module

[Robert Dailey]

On Mon, Apr 24, 2017 at 10:02 AM, Ben Boeckel <ben.boec...@kitware.com> wrote:
> On Mon, Apr 24, 2017 at 09:54:18 -0500, Robert Dailey wrote:
>> On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey <rcdailey.li...@gmail.com> 
>> wrote:
>> > I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
>> >
>> > find_package(PNG REQUIRED)
>> >
>> > Which gives me the output in CMake:
>> >
>> > Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50")
>> >
>> > The CMakeCache.txt file has these variables set:
>> >
>> > PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND
>> > PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND
>> > PNG_PNG_INCLUDE_DIR:PATH=/usr/include
>> >
>> > So it found the headers, but not the libs. Why did it not find the
>> > libs? Note that my version of Ubuntu is 64-bit, and I've installed the
>> > 32-bit libs like so:
>> >
>> > $ sudo apt-get install libpng12-dev:i386
>
> What compiler are you using (what does CMake say it is?)? Does an
> `strace` of CMake configuring the project show anything interesting?
> `cmake --trace-expand`?

It's using Gcc 4.9 because I told it to via toolchain file:



-- The C compiler identification is GNU 4.9.4
-- The CXX compiler identification is GNU 4.9.4
-- Check for working C compiler: /usr/bin/gcc-4.9
-- Check for working C compiler: /usr/bin/gcc-4.9 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/g++-4.9
-- Check for working CXX compiler: /usr/bin/g++-4.9 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done



Via the following toolchain file contents:



set( CMAKE_SYSTEM_NAME Linux )
set( CMAKE_SYSTEM_VERSION 1 )
set( CMAKE_SYSTEM_PROCESSOR "i686" )
set( CMAKE_C_COMPILER gcc-4.9 )
set( CMAKE_CXX_COMPILER g++-4.9 )
set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -m32" )
set( CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -m32" )



I'm not sure how to use strace. I tried following instructions I found
on the [CMake Performance Tips][1] page, but this isn't working. My
generate command has a lot of options, so I use a helper shell script
to generate. strace seems to not work well when using a shell script.
Trace also doesn't show much useful. Could you give exact command line
I can run to get the info you need?

Where possible, I install everything via apt-get for the 4.9
toolchain. For libpng this was not an option as far as I could tell,
so I'm not sure what implications that has on find_package() behavior.
-- 

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] Trouble with FindPNG module

[Robert Dailey]

On Mon, Apr 24, 2017 at 10:02 AM, Ben Boeckel <ben.boec...@kitware.com> wrote:
> On Mon, Apr 24, 2017 at 09:54:18 -0500, Robert Dailey wrote:
>> On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey <rcdailey.li...@gmail.com> 
>> wrote:
>> > I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
>> >
>> > find_package(PNG REQUIRED)
>> >
>> > Which gives me the output in CMake:
>> >
>> > Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50")
>> >
>> > The CMakeCache.txt file has these variables set:
>> >
>> > PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND
>> > PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND
>> > PNG_PNG_INCLUDE_DIR:PATH=/usr/include
>> >
>> > So it found the headers, but not the libs. Why did it not find the
>> > libs? Note that my version of Ubuntu is 64-bit, and I've installed the
>> > 32-bit libs like so:
>> >
>> > $ sudo apt-get install libpng12-dev:i386
>
> What compiler are you using (what does CMake say it is?)? Does an
> `strace` of CMake configuring the project show anything interesting?
> `cmake --trace-expand`?

It's using Gcc 4.9 because I told it to via toolchain file:



-- The C compiler identification is GNU 4.9.4
-- The CXX compiler identification is GNU 4.9.4
-- Check for working C compiler: /usr/bin/gcc-4.9
-- Check for working C compiler: /usr/bin/gcc-4.9 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/g++-4.9
-- Check for working CXX compiler: /usr/bin/g++-4.9 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done



Via the following toolchain file contents:



set( CMAKE_SYSTEM_NAME Linux )
set( CMAKE_SYSTEM_VERSION 1 )
set( CMAKE_SYSTEM_PROCESSOR "i686" )
set( CMAKE_C_COMPILER gcc-4.9 )
set( CMAKE_CXX_COMPILER g++-4.9 )
set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -m32" )
set( CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -m32" )



I'm not sure how to use strace. I tried following instructions I found
on the [CMake Performance Tips][1] page, but this isn't working. My
generate command has a lot of options, so I use a helper shell script
to generate. strace seems to not work well when using a shell script.
Trace also doesn't show much useful. Could you give exact command line
I can run to get the info you need?

Where possible, I install everything via apt-get for the 4.9
toolchain. For libpng this was not an option as far as I could tell,
so I'm not sure what implications that has on find_package() behavior.
-- 

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] Trouble with FindPNG module

[Robert Dailey]

Sorry to bump; any info on this? I'm completely blocked :-(

On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
>
> find_package(PNG REQUIRED)
>
> Which gives me the output in CMake:
>
> Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50")
>
> The CMakeCache.txt file has these variables set:
>
> PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND
> PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND
> PNG_PNG_INCLUDE_DIR:PATH=/usr/include
>
> So it found the headers, but not the libs. Why did it not find the
> libs? Note that my version of Ubuntu is 64-bit, and I've installed the
> 32-bit libs like so:
>
> $ sudo apt-get install libpng12-dev:i386
>
> Would the find module be confused because it is trying to find the
> 64-bit library? What's the issue?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Trouble with FindPNG module

[Robert Dailey]

Sorry to bump; any info on this? I'm completely blocked :-(

On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
>
> find_package(PNG REQUIRED)
>
> Which gives me the output in CMake:
>
> Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50")
>
> The CMakeCache.txt file has these variables set:
>
> PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND
> PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND
> PNG_PNG_INCLUDE_DIR:PATH=/usr/include
>
> So it found the headers, but not the libs. Why did it not find the
> libs? Note that my version of Ubuntu is 64-bit, and I've installed the
> 32-bit libs like so:
>
> $ sudo apt-get install libpng12-dev:i386
>
> Would the find module be confused because it is trying to find the
> 64-bit library? What's the issue?
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] Trouble with FindPNG module

[Robert Dailey]

I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:

find_package(PNG REQUIRED)

Which gives me the output in CMake:

Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50")

The CMakeCache.txt file has these variables set:

PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND
PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND
PNG_PNG_INCLUDE_DIR:PATH=/usr/include

So it found the headers, but not the libs. Why did it not find the
libs? Note that my version of Ubuntu is 64-bit, and I've installed the
32-bit libs like so:

$ sudo apt-get install libpng12-dev:i386

Would the find module be confused because it is trying to find the
64-bit library? What's the issue?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Need code review of my android toolchain file

[Robert Dailey]

I guess the only feedback I really would like is if the path
normalization I'm doing for CMAKE_ANDROID_NDK is necessary (converting
backslashes to forward slashes). Will CMake translate the backslashes
properly?

Sometimes I use CMAKE_ANDROID_NDK in custom commands and custom
targets to build absolute paths to items in the NDK.

On Tue, Apr 18, 2017 at 9:45 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> I'm trying to follow best practices where I can, but the trouble is
> I'm not aware of any. So I want to post my android.toolchain.cmake
> file here, with the hope that I can get some pointers.
>
> The main thing I want to understand is when it is appropriate to
> require cache variables be set via command line argument (-D) or via
> the toolchain file itself. Here is what is in my toolchain right now:
>
>
> set(CMAKE_SYSTEM_NAME Android)
> set(CMAKE_SYSTEM_VERSION 15) # API level
> set(CMAKE_ANDROID_ARCH_ABI armeabi-v7a)
> set(CMAKE_ANDROID_STL_TYPE c++_static)
> set(CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION clang)
>
> string(REGEX REPLACE "" "/" ndk_path "$ENV{ANDROID_NDK}")
> set(CMAKE_ANDROID_NDK ${ndk_path})
>
> unset(ndk_path)
>
>
>
> My idea here is to provide a different toolchain file per specific NDK
> configuration. For example, I need to build my native libraries for
> both x86 and ARM platforms, so I would use 2 CMAKE_BINARY_DIR, each
> configured using a different toolchain:
>
> x86 would use "android.toolchain.x86.cmake"
> ARM would use "android.toolchain.arm.cmake"
>
> Something like that. Is this best practice? What other advice would you offer?
>
> 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

Re: [cmake-developers] Support for unified headers in Android NDK

[Robert Dailey]

Thanks Florent!

Let me know if you need any help, especially testing. I have a real
world use case for this at $DAYJOB.

On Thu, Apr 20, 2017 at 4:14 PM, Florent Castelli
<florent.caste...@gmail.com> wrote:
> I just came back from some holidays now, I'll try to update the MR with the
> latest changes soon next week!
>
> /Florent
>
> On Apr 20, 2017 10:10 PM, "Robert Dailey" <rcdailey.li...@gmail.com> wrote:
>>
>> I may pick this up, because right now it's impossible to use libc++
>> (LLVM) with an API less than 21 since that's when clang was
>> introduced. libc is missing too many symbols that are required by
>> libc++ below API 21.
>>
>> On Thu, Apr 20, 2017 at 2:52 PM, Ben Boeckel <ben.boec...@kitware.com>
>> wrote:
>> > On Thu, Apr 20, 2017 at 14:31:58 -0500, Robert Dailey wrote:
>> >> Google is supporting unified headers for sysroot as of NDK r14:
>> >>
>> >>
>> >> https://android.googlesource.com/platform/ndk/+/master/docs/UnifiedHeaders.md
>> >>
>> >> Is there a plan to add support for this natively into CMake?
>> >
>> > There is a merge request that is in-progress, but was closed due to
>> > inactivity (lack of time on Florent's side it seems). I'd recommend
>> > coordinating with Florent to resurrect the MR.
>> >
>> > https://gitlab.kitware.com/cmake/cmake/merge_requests/492
>> >
>> > --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-developers] Support for unified headers in Android NDK

[Robert Dailey]

I may pick this up, because right now it's impossible to use libc++
(LLVM) with an API less than 21 since that's when clang was
introduced. libc is missing too many symbols that are required by
libc++ below API 21.

On Thu, Apr 20, 2017 at 2:52 PM, Ben Boeckel <ben.boec...@kitware.com> wrote:
> On Thu, Apr 20, 2017 at 14:31:58 -0500, Robert Dailey wrote:
>> Google is supporting unified headers for sysroot as of NDK r14:
>>
>> https://android.googlesource.com/platform/ndk/+/master/docs/UnifiedHeaders.md
>>
>> Is there a plan to add support for this natively into CMake?
>
> There is a merge request that is in-progress, but was closed due to
> inactivity (lack of time on Florent's side it seems). I'd recommend
> coordinating with Florent to resurrect the MR.
>
> https://gitlab.kitware.com/cmake/cmake/merge_requests/492
>
> --Ben
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Support for unified headers in Android NDK

[Robert Dailey]

Google is supporting unified headers for sysroot as of NDK r14:

https://android.googlesource.com/platform/ndk/+/master/docs/UnifiedHeaders.md

Is there a plan to add support for this natively into 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-developers

[CMake] Need code review of my android toolchain file

[Robert Dailey]

I'm trying to follow best practices where I can, but the trouble is
I'm not aware of any. So I want to post my android.toolchain.cmake
file here, with the hope that I can get some pointers.

The main thing I want to understand is when it is appropriate to
require cache variables be set via command line argument (-D) or via
the toolchain file itself. Here is what is in my toolchain right now:


set(CMAKE_SYSTEM_NAME Android)
set(CMAKE_SYSTEM_VERSION 15) # API level
set(CMAKE_ANDROID_ARCH_ABI armeabi-v7a)
set(CMAKE_ANDROID_STL_TYPE c++_static)
set(CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION clang)

string(REGEX REPLACE "" "/" ndk_path "$ENV{ANDROID_NDK}")
set(CMAKE_ANDROID_NDK ${ndk_path})

unset(ndk_path)



My idea here is to provide a different toolchain file per specific NDK
configuration. For example, I need to build my native libraries for
both x86 and ARM platforms, so I would use 2 CMAKE_BINARY_DIR, each
configured using a different toolchain:

x86 would use "android.toolchain.x86.cmake"
ARM would use "android.toolchain.arm.cmake"

Something like that. Is this best practice? What other advice would you offer?

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

[CMake] How to get message() to go to stdout when executed from -P?

[Robert Dailey]

When I execute a CMake script as a custom command, message() logs are
not shown in stdout from that script.

Is there a way to make it pipe out messages?
-- 

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 properly handle build version number in CMake script for project

[Robert Dailey]

OK weirdly, tested again, this also works and is a little more
simplified (although more confusing, since now we're intermixing
non-cache and cache variables with the same name; behavior is not
exactly clear, or well-defined.

if( BUILD_VERSION )
set( BUILD_VERSION ${BUILD_VERSION} )
unset( BUILD_VERSION CACHE )
else()
set( BUILD_VERSION 7.1.1.2 )
endif()

On Mon, Apr 10, 2017 at 1:32 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> Actually this seems to work:
>
> if( BUILD_VERSION )
>
> set( version_override ${BUILD_VERSION} )
> unset( BUILD_VERSION CACHE )
> set( BUILD_VERSION ${version_override} )
> unset( version_override )
>
> else()
>
> set( BUILD_VERSION 7.1.1.2 )
>
> endif()
>
> It's a bit messy but gets the job done, and doesn't require
> configure_file(). Maybe there is a way to clean this up even more?
>
> I noticed that unset( BUILD_VERSION CACHE ) actually unsets non-cache
> versions of a variable too, so I had to use the temporary variable to
> transfer the value.
>
> On Mon, Apr 10, 2017 at 1:15 PM, Robert Dailey <rcdailey.li...@gmail.com> 
> wrote:
>> Sorry you're right, this isn't working because -D creates a cache
>> entry for the variable, which breaks it.
>>
>> So maybe more ideas on the configure_file() solution would be ideal...
>> unsetting the cache variable might work as well, I have to toy around
>> with this.
>>
>> On Mon, Apr 10, 2017 at 12:48 PM, Bruce Stephens
>> <bruce.r.steph...@gmail.com> wrote:
>>> On Mon, Apr 10, 2017 at 5:04 PM, Robert Dailey <rcdailey.li...@gmail.com> 
>>> wrote:
>>>> Actually I think your idea does work. Why do you think it won't? I'm
>>>> using it right now and so far it seems OK.
>>>
>>> I assumed (without testing, admittedly) is that it would fail if
>>> someone used -D to set the value,
>>> then changed some CMakeLists.txt file, then executed the build command
>>> again. I'd expect that
>>> to rerun cmake to update the build files and I'd fear that you'd then
>>> get BUILD_VERSION from
>>> the CMakeLists.txt file rather than the value explicitly set.
>>>
>>> However, I haven't tried it, and maybe it works fine (with the
>>> generators you care about) even without
>>> caching?
-- 

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 properly handle build version number in CMake script for project

[Robert Dailey]

Actually this seems to work:

if( BUILD_VERSION )

set( version_override ${BUILD_VERSION} )
unset( BUILD_VERSION CACHE )
set( BUILD_VERSION ${version_override} )
unset( version_override )

else()

set( BUILD_VERSION 7.1.1.2 )

endif()

It's a bit messy but gets the job done, and doesn't require
configure_file(). Maybe there is a way to clean this up even more?

I noticed that unset( BUILD_VERSION CACHE ) actually unsets non-cache
versions of a variable too, so I had to use the temporary variable to
transfer the value.

On Mon, Apr 10, 2017 at 1:15 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> Sorry you're right, this isn't working because -D creates a cache
> entry for the variable, which breaks it.
>
> So maybe more ideas on the configure_file() solution would be ideal...
> unsetting the cache variable might work as well, I have to toy around
> with this.
>
> On Mon, Apr 10, 2017 at 12:48 PM, Bruce Stephens
> <bruce.r.steph...@gmail.com> wrote:
>> On Mon, Apr 10, 2017 at 5:04 PM, Robert Dailey <rcdailey.li...@gmail.com> 
>> wrote:
>>> Actually I think your idea does work. Why do you think it won't? I'm
>>> using it right now and so far it seems OK.
>>
>> I assumed (without testing, admittedly) is that it would fail if
>> someone used -D to set the value,
>> then changed some CMakeLists.txt file, then executed the build command
>> again. I'd expect that
>> to rerun cmake to update the build files and I'd fear that you'd then
>> get BUILD_VERSION from
>> the CMakeLists.txt file rather than the value explicitly set.
>>
>> However, I haven't tried it, and maybe it works fine (with the
>> generators you care about) even without
>> caching?
-- 

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 properly handle build version number in CMake script for project

[Robert Dailey]

Sorry you're right, this isn't working because -D creates a cache
entry for the variable, which breaks it.

So maybe more ideas on the configure_file() solution would be ideal...
unsetting the cache variable might work as well, I have to toy around
with this.

On Mon, Apr 10, 2017 at 12:48 PM, Bruce Stephens
<bruce.r.steph...@gmail.com> wrote:
> On Mon, Apr 10, 2017 at 5:04 PM, Robert Dailey <rcdailey.li...@gmail.com> 
> wrote:
>> Actually I think your idea does work. Why do you think it won't? I'm
>> using it right now and so far it seems OK.
>
> I assumed (without testing, admittedly) is that it would fail if
> someone used -D to set the value,
> then changed some CMakeLists.txt file, then executed the build command
> again. I'd expect that
> to rerun cmake to update the build files and I'd fear that you'd then
> get BUILD_VERSION from
> the CMakeLists.txt file rather than the value explicitly set.
>
> However, I haven't tried it, and maybe it works fine (with the
> generators you care about) even without
> caching?
-- 

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 properly handle build version number in CMake script for project

[Robert Dailey]

Actually I think your idea does work. Why do you think it won't? I'm
using it right now and so far it seems OK.

1. On build server, if it overrides it with -D, then it does not set
it by hand. If it doesn't override, it will use the fixed version in
the file
2. On work machines, it's never defined prior, so it sets it with the
fixed version.

On Mon, Apr 10, 2017 at 9:15 AM, Bruce Stephens
 wrote:
> On Mon, Apr 10, 2017 at 2:36 PM, Bruce Stephens
>  wrote:
>> You could do something like
>>
>> if(NOT "${BUILD_VERSION}")
>>   set(BUILD_VERSION 1.2.3.4)
>> endif()
>
>
> That doesn't work at all, come to think of it. I suspect your best bet
> is to handle
> the caching yourself (likely using a file in ${CMAKE_BINARY_DIR} and
> maybe "include(... OPTIONAL)"). That should allow whatever behaviour
> you want.
>
> I note that llvm's builds have the same sort of problem, so whatever
> fix is required
> isn't obvious even to obviously bright people. (That is, when the
> version switched
> from 4.0.0 to 5.0.0 my builds didn't change their version number. I
> had to remove the
> build directory and build again from clean.)
-- 

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] How to properly handle build version number in CMake script for project

[Robert Dailey]

I have a file called version.cmake that my root CMakeLists.txt
includes. There is only a single line in this file:

set( BUILD_VERSION 1.2.3.4 CACHE STRING "Version of the product" )

I have two scenarios where this version number setting needs to work
slightly differently from a CMake perspective:

1. Our CI build server does a fresh clone of our repo, and generates
from scratch. It sometimes needs to override the version number from
the command line via arguments. So it will do:

-D BUILD_VERSION=99.99.1.2

This works since it's a cache variable. In fact, the current solution
ONLY works well for this scenario (since it will allow overriding from
command line, but also allow the file to set the value if it is not
specified as a -D argument).

2. Local work machine builds. Local builds never override using -D,
they always use what is in the version.cmake file. However, because
it's a cache variable and I'm not using FORCE with set(), it never
updates if I change the version and push it to origin. This is the
missing requirement: it needs to update when the number (value)
changes in version control

I thought of making a BUILD_VERSION_OVERRIDE that is only accepted on
the command line, and if specified, it will set the BUILD_VERSION
value to the overridden value. However, I don't like the idea of 2
separate variables to manage this. Using a non-cache variable doesn't
allow overriding with the same variable value on the command line
either.

What's the best solution here for my situation?
-- 

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] custom command comments not showing up

[Robert Dailey]

Seems like the solution here is to make COMMENT work
properly/consistently across all generators. That's the point, after
all, right?

On Sat, Apr 8, 2017 at 12:33 AM, Hendrik Sattler
<p...@hendrik-sattler.de> wrote:
> However, this messes up parallel make progress output.
>
> Am 7. April 2017 22:22:08 MESZ schrieb Craig Scott <craig.sc...@crascit.com>:
>>Unfortunately, COMMENT is unreliable. Some generators will honour it,
>>others won't. A more robust alternative is to use CMake's command mode
>>to
>>echo the comment instead. Eg:
>>
>>add_custom_command( TARGET zApp_zip POST_BUILD
>>COMMAND ${CMAKE_COMMAND} -E echo "test2"
>>COMMAND ${CMAKE_COMMAND} ARGS ...snip...
>>)
>>
>>
>>
>>On Fri, Apr 7, 2017 at 11:40 PM, Robert Dailey
>><rcdailey.li...@gmail.com>
>>wrote:
>>
>>> So I probably am not understanding how this works.
>>>
>>> I have a custom target, that I later add multiple custom commands to.
>>> Each custom command has a COMMENT set, but the target itself does
>>too:
>>>
>>> add_custom_target(zApp_zip COMMENT "test1")
>>>
>>> add_custom_command( TARGET zApp_zip POST_BUILD
>>> COMMAND ${CMAKE_COMMAND} ARGS ...snip...
>>> COMMENT "test2"
>>> )
>>>
>>> Instead of seeing "test1" or "test2" when running, I get:
>>>
>>> $ ninja zApp_zip
>>> [1/1] Running utility command for zApp_zip
>>>
>>> Why does it say "Running utility command"? What is the behavior of
>>all
>>> the comments supposed to be? Is this a ninja-specific issue or
>>> behavior?
>>> --
>>>
>>> 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
>>>
>
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-- 

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] find_program() not using PATH on Windows?

[Robert Dailey]

Yeah I've wanted to use built in support for NDK, but it doesn't work
with Crystax for a number of reasons. Just had no luck with it.
Crystax provides its toolchain file that I have to use.

I'm trying to get away from Crystax, but in the meantime I'm stuck
fixing this obscure issue the same way you did.

On Fri, Apr 7, 2017 at 12:33 PM, Florent Castelli
<florent.caste...@gmail.com> wrote:
> What you mentioned is a classic problem of that famous Android toolchain. 
> When I used it, I just patched it and set the 
> CMAKE_FIND_ROOT_PATH_MODE_PROGRAM to NEVER directly, and removed some harmful 
> pieces in there (like that find macro and some other bug fix for macOS 
> builds, libc++ and recent NDK support…).
>
> Have you considered switching to the upstream support in either CMake or the 
> one provided by Google with Gradle?
> You can probably just upgrade to the first one and get rid of similar issues 
> by just tweaking the CMake command line.
>
> For the other issues you mentioned of compiling for multiple architectures, 
> the Gradle CMake plugin should handle that and build all the ones you specify.
> That one will be a bit more complicated to implement as you need to 
> transition from Ant to Gradle, but I remember the ant tooling being 
> deprecated now, so it should improve the situation a little bit.
>
> /Florent
>
>> On 7 Apr 2017, at 14:32, Robert Dailey <rcdailey.li...@gmail.com> wrote:
>>
>> Thanks for the feedback Brad, as always. Really appreciate your
>> continued help. Sorry for continuing the discussion on the dev list.
>>
>> To close out the discussion just wanted to share (for others that may
>> run into this issue) that I went ahead and just added this line to my
>> root CMakeLists.txt file:
>>
>> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
>>
>> This at least disables the root path for programs. I didn't add it to
>> the toolchain itself since I don't know the impact of doing it, nor do
>> I really care to support it. I'm slowly trying to move away from
>> Crystax at my workplace in favor of official NDK since that has built
>> in support in CMake and also is run a little better (Crystax has been
>> a fat mess to use; we originally only chose to use it for the prebuilt
>> libraries, but not worth it)
>>
>> Thanks again!!
>>
>> On Fri, Apr 7, 2017 at 7:16 AM, Brad King <brad.k...@kitware.com> wrote:
>>> On 04/06/2017 04:43 PM, Robert Dailey wrote:
>>>> Even worse, they seem to acknowledge this problem and created "proxy"
>>>> macros for the use by the host OS (code at the bottom)
>>>
>>> Interesting.  That approach depends on all projects using their
>>> macros instead of the normal `find_package`, requiring explicit
>>> porting to use their toolchain file.
>>>
>>> Typically toolchain files should do this:
>>>
>>> ```
>>> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
>>> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
>>> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
>>> set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
>>> ```
>>>
>>> so that packages for the target platform are found in the
>>> re-rooted locations but programs are found on the host.
>>>
>>> -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] custom command comments not showing up

[Robert Dailey]

So I probably am not understanding how this works.

I have a custom target, that I later add multiple custom commands to.
Each custom command has a COMMENT set, but the target itself does too:

add_custom_target(zApp_zip COMMENT "test1")

add_custom_command( TARGET zApp_zip POST_BUILD
COMMAND ${CMAKE_COMMAND} ARGS ...snip...
COMMENT "test2"
)

Instead of seeing "test1" or "test2" when running, I get:

$ ninja zApp_zip
[1/1] Running utility command for zApp_zip

Why does it say "Running utility command"? What is the behavior of all
the comments supposed to be? Is this a ninja-specific issue or
behavior?
-- 

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] find_program() not using PATH on Windows?

[Robert Dailey]

Thanks for the feedback Brad, as always. Really appreciate your
continued help. Sorry for continuing the discussion on the dev list.

To close out the discussion just wanted to share (for others that may
run into this issue) that I went ahead and just added this line to my
root CMakeLists.txt file:

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)

This at least disables the root path for programs. I didn't add it to
the toolchain itself since I don't know the impact of doing it, nor do
I really care to support it. I'm slowly trying to move away from
Crystax at my workplace in favor of official NDK since that has built
in support in CMake and also is run a little better (Crystax has been
a fat mess to use; we originally only chose to use it for the prebuilt
libraries, but not worth it)

Thanks again!!

On Fri, Apr 7, 2017 at 7:16 AM, Brad King <brad.k...@kitware.com> wrote:
> On 04/06/2017 04:43 PM, Robert Dailey wrote:
>> Even worse, they seem to acknowledge this problem and created "proxy"
>> macros for the use by the host OS (code at the bottom)
>
> Interesting.  That approach depends on all projects using their
> macros instead of the normal `find_package`, requiring explicit
> porting to use their toolchain file.
>
> Typically toolchain files should do this:
>
> ```
> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
> set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
> ```
>
> so that packages for the target platform are found in the
> re-rooted locations but programs are found on the host.
>
> -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] find_program() not using PATH on Windows?

[Robert Dailey]

Even worse, they seem to acknowledge this problem and created "proxy"
macros for the use by the host OS (code at the bottom)

Is it just me or is this really nasty?


# macro to find packages on the host OS
macro( find_host_package )
 set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER )
 set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY NEVER )
 set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE NEVER )
 if( CMAKE_HOST_WIN32 )
  SET( WIN32 1 )
  SET( UNIX )
 elseif( CMAKE_HOST_APPLE )
  SET( APPLE 1 )
  SET( UNIX )
 endif()
 find_package( ${ARGN} )
 SET( WIN32 )
 SET( APPLE )
 SET( UNIX 1 )
 set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )
endmacro()


# macro to find programs on the host OS
macro( find_host_program )
 set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER )
 set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY NEVER )
 set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE NEVER )
 if( CMAKE_HOST_WIN32 )
  SET( WIN32 1 )
  SET( UNIX )
 elseif( CMAKE_HOST_APPLE )
  SET( APPLE 1 )
  SET( UNIX )
 endif()
 find_program( ${ARGN} )
 SET( WIN32 )
 SET( APPLE )
 SET( UNIX 1 )
 set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )
endmacro()

On Thu, Apr 6, 2017 at 3:41 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> Unsetting these at the bottom of the toolchain file fixes it:
>
> unset( CMAKE_FIND_ROOT_PATH )
> unset( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM )
> unset( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY )
> unset( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE )
>
> However I'm not sure if this is the right solution. They do for some
> reason specify PROGRAM to ONLY. Should these values propagate outside
> of the toolchain file?
>
> On Thu, Apr 6, 2017 at 3:38 PM, Brad King <brad.k...@kitware.com> wrote:
>> On 04/06/2017 04:32 PM, Robert Dailey wrote:
>>> directories coming from PATH can be "rerooted" like this, it makes
>>> things very confusing... maybe there is a reason for it, but I'd never
>>> want this personally, and I find it concerning that a toolchain file
>>> can break this for the whole project.
>>
>> The toolchain file is using CMAKE_FIND_ROOT_PATH to prevent find
>> commands from searching outside of those directories.  That is
>> why everything is rerooted.
>>
>> Often one doesn't want this for programs, so the toolchain file
>> should set CMAKE_FIND_ROOT_PATH_MODE_PROGRAM to NEVER or BOTH.
>> If it has some reason for not doing that then one can always use
>> NO_CMAKE_FIND_ROOT_PATH in the individual find_program call.
>>
>> -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] find_program() not using PATH on Windows?

[Robert Dailey]

Looking further: in cmFindCommon::RerootPaths(), the passed in paths
look correct as far as what PATH shows, and then when this line of
code happens:

const char* rootPath = this->Makefile->GetDefinition("CMAKE_FIND_ROOT_PATH");

it returns a "root path" of:

E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin;E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi;E:/android/ndk/platforms/android-15/arch-arm;E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user;E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share

This is affected by CMAKE_FIND_ROOT_PATH I guess, which the Crystax
NDK toolchain file is mucking with maybe? I do find it bizarre that
directories coming from PATH can be "rerooted" like this, it makes
things very confusing... maybe there is a reason for it, but I'd never
want this personally, and I find it concerning that a toolchain file
can break this for the whole project.

What should I do?

On Thu, Apr 6, 2017 at 3:28 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> Brad,
>
> I debugged the issue and so far I'm seeing very weird behavior in the
> cmFindCommon::SearchPaths vector when used from cmFindProgramCommand.
> It goes into FindNormalProgramDirsPerName(), where the wrong "prefix"
> to each path in PATH environment variable is used. Looks like the NDK
> toolchain file is affecting find_program() behavior somehow?
>
> Attached the debug output of the SearchPaths vector to this email. In
> this case, note I'm doing this:
>
> find_program( PYTHON_EXECUTABLE python )
>
> And in the SearchPaths vector, the path to Python is shown as:
>
> E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Python35/
>
> The real location of it (and what is visible in PATH itself) is:
>
> E:/Python35/
>
> On Mon, Mar 20, 2017 at 9:20 AM, Brad King <brad.k...@kitware.com> wrote:
>> On 03/20/2017 10:17 AM, Robert Dailey wrote:
>>> What can I do to help you guys diagnose this problem? I could try
>>> getting a reproducible script for you, but this is so dependent on
>>> environment I'm not sure if it will serve as a good test case.
>>
>> Please build CMake from source with debugging enabled.  Then you
>> can step through the search process.
>>
>> 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

Re: [cmake-developers] find_program() not using PATH on Windows?

[Robert Dailey]

Brad,

I debugged the issue and so far I'm seeing very weird behavior in the
cmFindCommon::SearchPaths vector when used from cmFindProgramCommand.
It goes into FindNormalProgramDirsPerName(), where the wrong "prefix"
to each path in PATH environment variable is used. Looks like the NDK
toolchain file is affecting find_program() behavior somehow?

Attached the debug output of the SearchPaths vector to this email. In
this case, note I'm doing this:

find_program( PYTHON_EXECUTABLE python )

And in the SearchPaths vector, the path to Python is shown as:

E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Python35/

The real location of it (and what is visible in PATH itself) is:

E:/Python35/

On Mon, Mar 20, 2017 at 9:20 AM, Brad King <brad.k...@kitware.com> wrote:
> On 03/20/2017 10:17 AM, Robert Dailey wrote:
>> What can I do to help you guys diagnose this problem? I could try
>> getting a reproducible script for you, but this is so dependent on
>> environment I'm not sure if it will serve as a good test case.
>
> Please build CMake from source with debugging enabled.  Then you
> can step through the search process.
>
> Thanks,
> -Brad
>
-   this->SearchPaths   { size=235 }
std::vector<std::basic_string<char,std::char_traits,std::allocator 
>,std::allocator<std::basic_string<char,std::char_traits,std::allocator
 > > >
[capacity]  316 int
+   [allocator] allocator   
std::_Compressed_pair<std::_Wrap_alloc<std::allocator<std::basic_string<char,std::char_traits,std::allocator
 > > 
>,std::_Vector_val<std::_Simple_types<std::basic_string<char,std::char_traits,std::allocator
 > > >,1>
+   [0] 
"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/ProgramData/Oracle/Java/javapath/"
std::basic_string<char,std::char_traits,std::allocator >
+   [1] 
"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Windows/System32/"
std::basic_string<char,std::char_traits,std::allocator >
+   [2] 
"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Windows/"
 std::basic_string<char,std::char_traits,std::allocator >
+   [3] 
"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Windows/System32/wbem/"
   std::basic_string<char,std::char_traits,std::allocator >
+   [4] 
"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Windows/System32/WindowsPowerShell/v1.0/"
 std::basic_string<char,std::char_traits,std::allocator >
+   [5] 
"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Program
 Files/Beyond Compare 4/"  
std::basic_string<char,std::char_traits,std::allocator >
+   [6] 
"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/ant/bin/"
 std::basic_string<char,std::char_traits,std::allocator >
+   [7] 
"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/android/sdk/tools/"
   std::basic_string<char,std::char_traits,std::allocator >
+   [8] 
"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/android/sdk/platform-tools/"
  std::basic_string<char,std::char_traits,std::allocator >
+   [9] 
"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/code/ziosk-scripts/device-scripts/"
   std::basic_string<char,std::char_traits,std::allocator >
+   [10]
"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/tools/ninja/"
 std::basic_string<char,std::char_traits,std::allocator >
+   [11]
"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Ruby22/bin/"
  std::basic_string<char,std::char_traits,std::allocator >
+   [12]
"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Python35/"
std::basic_string<char,std::char_traits,std::allocator >
+   [13]
"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Python35/Scripts/"
std::basic_string<char,std::char_traits,std::allocator >
+   [14]
"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Program
 Files/CMake/bin/" 
std::basic_string<char,std::char_traits,std::allocator >
+   [15]
"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Program
 Files (x86)/Notepad++/"   
std::basic_string<char,std::char_traits,st

[CMake] Need advice on dual-build APK setup in CMake

[Robert Dailey]

I have CMake setup to build native shared libraries (*.so) that are
included in an APK built for Android. The "ant release" command is
invoked by a custom target I define in CMake, which handles building
the java pieces as well as packaging the final app into an APK file.

So the build pipeline when I invoke my custom target is:

Build Native Library (library target, output is *.so) -> Run Ant
Release (output is an APK)

This worked fine, until I needed to support multiple architectures on
the native side. So basically now I need to rebuild the C++ code 2
times: Once for ARM platform, another for x86 Android platform.

Once both native libraries are built (end up with two *.so files), I
need to copy both of those libraries into the android project
directory structure and run the custom target to do "ant release".
Since a single CMake binary directory is tied to 1 combination of
configuration/platform build for the C++ code, I can't make it build
twice through CMake itself.

Basically I've had to take away responsibility of the java build (via
the custom target) away from CMake and invoke it manually on the build
server. So our continuous build server does the following:

1. Generate CMake for ARM Android -> Build it -> Publish the *.so
2. Generate CMake for x86 Android -> Build it -> Publish the *.so
3. Gather previously published two *.so files, run "ant release" manually

The goal here is 1 APK that can be deployed to both platforms since it
has both shared libraries inside it. Android knows which shared
library to load when you launch the application based on whichever
platform you are on.

If I used the old method, I'd have 2 APK files (one for each platform)
which won't work for me.

Is there a way I can have CMake still responsible for running the
non-native tasks via custom commands and targets, while also building
two libraries? What would be the best setup for this?

Note that it is ideal to be able to replicate deployments locally, the
same way the build server would. So even if a single CMake binary
directory can't accomplish this somehow, I'd be OK with a superbuild
approach of some sort (superbuild would build the native parts 2
times, one for each platform, then do another CMake generate that just
runs custom targets and nothing else). Ideas are appreciated!
-- 

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

[Robert Dailey]

On Thu, Mar 30, 2017 at 3:42 AM, Tamás Kenéz  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

[Robert Dailey]

On Wed, Mar 29, 2017 at 9:32 PM, Florent Castelli
<florent.caste...@gmail.com> wrote:
> On 30/03/2017 03:54, Robert Dailey wrote:
>>
>> On Wed, Mar 29, 2017 at 8:18 PM, Florent Castelli
>> <florent.caste...@gmail.com> wrote:
>>>
>>> This is known as "super build".
>>> Yes, this is exactly why I made my Boost CMake build scripts, which you
>>> use
>>> unless you changed your mind today :)
>>
>> You mean this?
>> https://github.com/Orphis/boost-cmake
>>
>> It's on the drawing board, for sure. It's the best solution I've
>> found. It's also part of the reason I'm asking this question to begin
>> with.
>>
>> Although, this specific method of building boost doesn't use
>> superbuild, it uses normal add_subdirectory() with target.
>
> It doesn't "super build" its dependencies, you have to provide them
> externally, but it is a possible addition.
> But it is designed to be part of a super build environment and is used as
> such at some large companies shipping to millions of people.
>
>>
>>> It can be done for other projects as well. Sometimes, they even provide
>>> CMake build scripts you can use directly with "add_subdirectory()" so you
>>> don't have to write CMake scripts or use "ExternalProject_Add()" (which
>>> isn't all great since it doesn't propagate all your current project
>>> settings).
>>
>> Long term, I'm thinking a project like hunter[1] would be the best
>> choice. The problem with hunter is that it doesn't separate concerns
>> between host machine and target host. Specifically, when cross
>> compiling.
>>
>> All the superbuild commands assume linux command syntax, simply
>> because I specified a toolchain utilizing android NDK. For this reason
>> it requires a lot of TLC to get working.
>>
>> [1]: https://github.com/ruslo/hunter
>
> There are those issues and also ABI changing flags that can become an issue
> as they aren't always propagated from what I can see.
>
>>> You can use ccache or its Windows variants to make it faster. But you
>>> also
>>> shouldn't need "ninja clean" most of the time. Possibly, you could just
>>> clean a specific target "ninja -t clean foo".
>>> If you declare all your dependencies properly, then you could just always
>>> run "ninja" and the build will just be correct.
>>> If your purpose is to see the compiler output again (to fix warnings), it
>>> is
>>> acceptable to clean and rebuild (with ccache it should be fast enough).
>>> Personally, I just have a very long history in my terminal and scroll
>>> back
>>> or pipe the build content to a file to look at it later. Some IDEs will
>>> also
>>> record all the compilation output and make it available later (Xcode does
>>> it), then it's less of an issue.
>>
>> Never used ccache before, what does it do? Also if even if you ninja
>> -t to clean, it will also clean dependencies. So if I specify those
>> in-project dependencies that actually build third party libs, those
>> will be cleaned too.
>
>
> It's a program you use to record compilation outputs and save them to a disk
> cache. If you build a file again, instead of compiling it, it will just
> fetch the outputs from the cache and return the same warnings. It's usually
> a safe optimization in a build pipeline and is quite easy to use with CMake
> and Ninja generator.
>
> It works well with GCC or Clang and there are some alternative versions for
> the Microsoft compiler too.

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

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

[Robert Dailey]

On Wed, Mar 29, 2017 at 8:18 PM, Florent Castelli
 wrote:
> This is known as "super build".
> Yes, this is exactly why I made my Boost CMake build scripts, which you use
> unless you changed your mind today :)

You mean this?
https://github.com/Orphis/boost-cmake

It's on the drawing board, for sure. It's the best solution I've
found. It's also part of the reason I'm asking this question to begin
with.

Although, this specific method of building boost doesn't use
superbuild, it uses normal add_subdirectory() with target.

> It can be done for other projects as well. Sometimes, they even provide
> CMake build scripts you can use directly with "add_subdirectory()" so you
> don't have to write CMake scripts or use "ExternalProject_Add()" (which
> isn't all great since it doesn't propagate all your current project
> settings).

Long term, I'm thinking a project like hunter[1] would be the best
choice. The problem with hunter is that it doesn't separate concerns
between host machine and target host. Specifically, when cross
compiling.

All the superbuild commands assume linux command syntax, simply
because I specified a toolchain utilizing android NDK. For this reason
it requires a lot of TLC to get working.

[1]: https://github.com/ruslo/hunter

> You can use ccache or its Windows variants to make it faster. But you also
> shouldn't need "ninja clean" most of the time. Possibly, you could just
> clean a specific target "ninja -t clean foo".
> If you declare all your dependencies properly, then you could just always
> run "ninja" and the build will just be correct.
> If your purpose is to see the compiler output again (to fix warnings), it is
> acceptable to clean and rebuild (with ccache it should be fast enough).
> Personally, I just have a very long history in my terminal and scroll back
> or pipe the build content to a file to look at it later. Some IDEs will also
> record all the compilation output and make it available later (Xcode does
> it), then it's less of an issue.

Never used ccache before, what does it do? Also if even if you ninja
-t to clean, it will also clean dependencies. So if I specify those
in-project dependencies that actually build third party libs, those
will be cleaned too.
-- 

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] include() doesn't work with relative paths?

[Robert Dailey]

This fails:

include( foo/bar/myscript.cmake )

But this works:

include( ${CMAKE_CURRENT_LIST_DIR}/foo/bar/myscript.cmake )

Why are relative paths not working?
-- 

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

[Robert Dailey]

Interested in hearing everyone's thoughts on this idea of mine.

Right now I have several third party libraries: openssl, boost,
libpng, zlib, etc. List goes on. I need to support these libraries on
at least 3 different platforms: ARM android, x86 linux, x86 windows.
It's a real pain in the rear to build each of these libraries a total
of 3 times (once per platform). It makes upgrades painful.

So I was thinking: If I set up each third party library to build from
source as a normal target with the rest of my targets, this would get
me the libraries for each third party lib "for free". Basically, they
would all build the same way no matter what platform I'm on. I can
move to other platforms or architectures in the future with no extra
effort.

The downside, of course, is that they build along with my normal
targets. Which means doing "ninja clean" will clean them, when I
really don't need to, and it will make build times get longer.

Any thoughts on this idea? Are there any other downsides? Is this the
best way to have library support across 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] Trying to get android toolchain setup for Crystax

[Robert Dailey]

Sorry last email:

Assuming I get past the host tag issue, the next one is that the test
program is unable to compile because:

error: cannot find -lcrystax

Somehow, somewhere the linker is expecting this library. I do not see
it in the output from CMake when the build fails. I do know the file
is located here:

${CMAKE_ANDROID_NDK}/sources/crystax/libs/${ANDROID_ABI}

Is there a way I can add this to the linker search path from the
toolchain file? Or is there a better way?

On Thu, Mar 23, 2017 at 3:22 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> Update:
>
> Using the x86_64 version of the Crystax NDK worked. Meaning, the
> directory name aligned with what CMake was expecting. However, the
> question now is: Why didn't changing
> CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG work?
>
> On Thu, Mar 23, 2017 at 3:14 PM, Robert Dailey <rcdailey.li...@gmail.com> 
> wrote:
>> Sorry I guess it would help if I showed where the ANDROID_ variables
>> are being defined:
>>
>> cmake .. -G"Ninja" -DCMAKE_BUILD_TYPE="Release"
>> -DCMAKE_TOOLCHAIN_FILE="crystax.toolchain.cmake"
>> -DBUILD_TESTING=OFF -DANDROID_API=15
>> -DANDROID_TOOLCHAIN_NAME=arm-linux-androideabi-4.9
>> -DANDROID_ABI=armeabi-v7a     -DANDROID_TOOLCHAIN_VERSION=4.9
>> -DANDROID_STL=gnustl_static
>>
>> On Thu, Mar 23, 2017 at 3:03 PM, Robert Dailey <rcdailey.li...@gmail.com> 
>> wrote:
>>> So I'm having no luck getting the Crystax NDK setup using built-in
>>> android support in CMake 3.8.
>>>
>>> I have the following toolchain file:
>>>
>>> set( CMAKE_SYSTEM_NAME Android )
>>> set( CMAKE_SYSTEM_VERSION ${ANDROID_API} )
>>>
>>> # set( CMAKE_ANDROID_NDK $ENV{ANDROID_NDK} )
>>> set( CMAKE_ANDROID_NDK "E:/android/crystax-ndk-10.3.2-stable" )
>>> #set( CMAKE_ANDROID_API ${ANDROID_API} )
>>> set( CMAKE_ANDROID_ARCH_ABI ${ANDROID_ABI} )
>>> set( CMAKE_ANDROID_STL_TYPE ${ANDROID_STL} )
>>> set( CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION ${ANDROID_TOOLCHAIN_VERSION} )
>>>
>>> if( CMAKE_ANDROID_ARCH_ABI MATCHES "armeabi" )
>>> set( CMAKE_ANDROID_ARM_MODE ON )
>>> set( CMAKE_ANDROID_ARM_NEON OFF )
>>> endif()
>>>
>>>
>>> The logs output as follows:
>>>
>>>
>>> -- Android: Targeting API '15' with architecture 'arm', ABI
>>> 'armeabi-v7a', and processor 'armv7-a'
>>> -- Android: Selected GCC toolchain 'arm-linux-androideabi-4.9'
>>> -- The C compiler identification is unknown
>>> -- The CXX compiler identification is unknown
>>> CMake Error at CMakeLists.txt:10 (project):
>>>   The CMAKE_C_COMPILER:
>>>
>>> 
>>> E:/android/crystax-ndk-10.3.2-stable/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-gcc.exe
>>>
>>>   is not a full path to an existing compiler tool.
>>>
>>>
>>> The problem is the path to the toolchain it is trying to find is actually:
>>>
>>>
>>> "E:\android\crystax-ndk-10.3.2-stable\toolchains\arm-linux-androideabi-4.9\prebuilt\windows\bin\arm-linux-androideabi-gcc.exe"
>>>
>>> The one difference is that the path has "windows" in it instead of
>>> "windows-x86_64". I installed the 32-bit version of Crystax NDK, not
>>> the 64 bit one (not sure if that makes a difference, but my native
>>> android code will not build with 64-bit compiler anyway).
>>>
>>> How can I make it properly calculate the path? I tried setting this
>>> but it did not change the behavior:
>>>
>>> set( CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG windows )
-- 

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] Trying to get android toolchain setup for Crystax

[Robert Dailey]

Update:

Using the x86_64 version of the Crystax NDK worked. Meaning, the
directory name aligned with what CMake was expecting. However, the
question now is: Why didn't changing
CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG work?

On Thu, Mar 23, 2017 at 3:14 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> Sorry I guess it would help if I showed where the ANDROID_ variables
> are being defined:
>
> cmake .. -G"Ninja" -DCMAKE_BUILD_TYPE="Release"
> -DCMAKE_TOOLCHAIN_FILE="crystax.toolchain.cmake"
> -DBUILD_TESTING=OFF -DANDROID_API=15
> -DANDROID_TOOLCHAIN_NAME=arm-linux-androideabi-4.9
> -DANDROID_ABI=armeabi-v7a -DANDROID_TOOLCHAIN_VERSION=4.9
> -DANDROID_STL=gnustl_static
>
> On Thu, Mar 23, 2017 at 3:03 PM, Robert Dailey <rcdailey.li...@gmail.com> 
> wrote:
>> So I'm having no luck getting the Crystax NDK setup using built-in
>> android support in CMake 3.8.
>>
>> I have the following toolchain file:
>>
>> set( CMAKE_SYSTEM_NAME Android )
>> set( CMAKE_SYSTEM_VERSION ${ANDROID_API} )
>>
>> # set( CMAKE_ANDROID_NDK $ENV{ANDROID_NDK} )
>> set( CMAKE_ANDROID_NDK "E:/android/crystax-ndk-10.3.2-stable" )
>> #set( CMAKE_ANDROID_API ${ANDROID_API} )
>> set( CMAKE_ANDROID_ARCH_ABI ${ANDROID_ABI} )
>> set( CMAKE_ANDROID_STL_TYPE ${ANDROID_STL} )
>> set( CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION ${ANDROID_TOOLCHAIN_VERSION} )
>>
>> if( CMAKE_ANDROID_ARCH_ABI MATCHES "armeabi" )
>> set( CMAKE_ANDROID_ARM_MODE ON )
>> set( CMAKE_ANDROID_ARM_NEON OFF )
>> endif()
>>
>>
>> The logs output as follows:
>>
>>
>> -- Android: Targeting API '15' with architecture 'arm', ABI
>> 'armeabi-v7a', and processor 'armv7-a'
>> -- Android: Selected GCC toolchain 'arm-linux-androideabi-4.9'
>> -- The C compiler identification is unknown
>> -- The CXX compiler identification is unknown
>> CMake Error at CMakeLists.txt:10 (project):
>>   The CMAKE_C_COMPILER:
>>
>> 
>> E:/android/crystax-ndk-10.3.2-stable/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-gcc.exe
>>
>>   is not a full path to an existing compiler tool.
>>
>>
>> The problem is the path to the toolchain it is trying to find is actually:
>>
>>
>> "E:\android\crystax-ndk-10.3.2-stable\toolchains\arm-linux-androideabi-4.9\prebuilt\windows\bin\arm-linux-androideabi-gcc.exe"
>>
>> The one difference is that the path has "windows" in it instead of
>> "windows-x86_64". I installed the 32-bit version of Crystax NDK, not
>> the 64 bit one (not sure if that makes a difference, but my native
>> android code will not build with 64-bit compiler anyway).
>>
>> How can I make it properly calculate the path? I tried setting this
>> but it did not change the behavior:
>>
>> set( CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG windows )
-- 

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] Trying to get android toolchain setup for Crystax

[Robert Dailey]

Sorry I guess it would help if I showed where the ANDROID_ variables
are being defined:

cmake .. -G"Ninja" -DCMAKE_BUILD_TYPE="Release"
-DCMAKE_TOOLCHAIN_FILE="crystax.toolchain.cmake"
-DBUILD_TESTING=OFF -DANDROID_API=15
-DANDROID_TOOLCHAIN_NAME=arm-linux-androideabi-4.9
-DANDROID_ABI=armeabi-v7a -DANDROID_TOOLCHAIN_VERSION=4.9
-DANDROID_STL=gnustl_static

On Thu, Mar 23, 2017 at 3:03 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> So I'm having no luck getting the Crystax NDK setup using built-in
> android support in CMake 3.8.
>
> I have the following toolchain file:
>
> set( CMAKE_SYSTEM_NAME Android )
> set( CMAKE_SYSTEM_VERSION ${ANDROID_API} )
>
> # set( CMAKE_ANDROID_NDK $ENV{ANDROID_NDK} )
> set( CMAKE_ANDROID_NDK "E:/android/crystax-ndk-10.3.2-stable" )
> #set( CMAKE_ANDROID_API ${ANDROID_API} )
> set( CMAKE_ANDROID_ARCH_ABI ${ANDROID_ABI} )
> set( CMAKE_ANDROID_STL_TYPE ${ANDROID_STL} )
> set( CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION ${ANDROID_TOOLCHAIN_VERSION} )
>
> if( CMAKE_ANDROID_ARCH_ABI MATCHES "armeabi" )
> set( CMAKE_ANDROID_ARM_MODE ON )
> set( CMAKE_ANDROID_ARM_NEON OFF )
> endif()
>
>
> The logs output as follows:
>
>
> -- Android: Targeting API '15' with architecture 'arm', ABI
> 'armeabi-v7a', and processor 'armv7-a'
> -- Android: Selected GCC toolchain 'arm-linux-androideabi-4.9'
> -- The C compiler identification is unknown
> -- The CXX compiler identification is unknown
> CMake Error at CMakeLists.txt:10 (project):
>   The CMAKE_C_COMPILER:
>
> 
> E:/android/crystax-ndk-10.3.2-stable/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-gcc.exe
>
>   is not a full path to an existing compiler tool.
>
>
> The problem is the path to the toolchain it is trying to find is actually:
>
>
> "E:\android\crystax-ndk-10.3.2-stable\toolchains\arm-linux-androideabi-4.9\prebuilt\windows\bin\arm-linux-androideabi-gcc.exe"
>
> The one difference is that the path has "windows" in it instead of
> "windows-x86_64". I installed the 32-bit version of Crystax NDK, not
> the 64 bit one (not sure if that makes a difference, but my native
> android code will not build with 64-bit compiler anyway).
>
> How can I make it properly calculate the path? I tried setting this
> but it did not change the behavior:
>
> set( CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG windows )
-- 

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] Trying to get android toolchain setup for Crystax

[Robert Dailey]

So I'm having no luck getting the Crystax NDK setup using built-in
android support in CMake 3.8.

I have the following toolchain file:

set( CMAKE_SYSTEM_NAME Android )
set( CMAKE_SYSTEM_VERSION ${ANDROID_API} )

# set( CMAKE_ANDROID_NDK $ENV{ANDROID_NDK} )
set( CMAKE_ANDROID_NDK "E:/android/crystax-ndk-10.3.2-stable" )
#set( CMAKE_ANDROID_API ${ANDROID_API} )
set( CMAKE_ANDROID_ARCH_ABI ${ANDROID_ABI} )
set( CMAKE_ANDROID_STL_TYPE ${ANDROID_STL} )
set( CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION ${ANDROID_TOOLCHAIN_VERSION} )

if( CMAKE_ANDROID_ARCH_ABI MATCHES "armeabi" )
set( CMAKE_ANDROID_ARM_MODE ON )
set( CMAKE_ANDROID_ARM_NEON OFF )
endif()


The logs output as follows:


-- Android: Targeting API '15' with architecture 'arm', ABI
'armeabi-v7a', and processor 'armv7-a'
-- Android: Selected GCC toolchain 'arm-linux-androideabi-4.9'
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:10 (project):
  The CMAKE_C_COMPILER:


E:/android/crystax-ndk-10.3.2-stable/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-gcc.exe

  is not a full path to an existing compiler tool.


The problem is the path to the toolchain it is trying to find is actually:


"E:\android\crystax-ndk-10.3.2-stable\toolchains\arm-linux-androideabi-4.9\prebuilt\windows\bin\arm-linux-androideabi-gcc.exe"

The one difference is that the path has "windows" in it instead of
"windows-x86_64". I installed the 32-bit version of Crystax NDK, not
the 64 bit one (not sure if that makes a difference, but my native
android code will not build with 64-bit compiler anyway).

How can I make it properly calculate the path? I tried setting this
but it did not change the behavior:

set( CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG windows )
-- 

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] enable_language behavior change

[Robert Dailey]

On Thu, Mar 23, 2017 at 10:50 AM, Brad King <brad.k...@kitware.com> wrote:
> On 03/23/2017 11:35 AM, Robert Dailey wrote:
>> Thanks Brad. For future reference, are these changes documented
>> anywhere? I searched for "enable_language" in the 3.6 release notes,
>> and there is no 3.6 entry for policy changes.
>
> The release notes are for new features, deprecations, and major
> user-facing changes.  We do not cloud them with every bug fix.
>
> This enable_language change was a bug fix that prevented a crash
> in some cases.  I was not aware that there were valid projects
> that trigger the error.
>
> -Brad
>

Crystax NDK (on master branch) has a toolchain.cmake which invokes
enable_language() but it fails. I guess they didn't test with 3.6 or
greater. Basically any of the android.toolchain.cmake scripts floating
around have this problem, since they're all modifications of the same
base change by takanome:

https://github.com/taka-no-me/android-cmake

I've introduced a PR on the Crystax project to fix the problem,
although I do not know if I'm actually addressing the root cause. My
assumption is that the C language is already enabled, but they invoke
enable_language(C) anyway for some reason.

https://github.com/crystax/android-platform-ndk/pull/16
-- 

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] enable_language behavior change

[Robert Dailey]

On Thu, Mar 23, 2017 at 10:33 AM, Brad King <brad.k...@kitware.com> wrote:
> On 03/23/2017 11:16 AM, Robert Dailey wrote:
>> I remember around cmake v3.6, the behavior of enable_language()
>> changed so that if you did it too many times, you'd get the error:
>>
>> Language 'C' is currently being enabled.  Recursive call not allowed.
>>
>> I need to implement some backward compatibility code to check of CMake
>> version less than 3.6 (or appropriate version), then still call
>> enable_language(), otherwise do not call it.
>>
>> Is 3.6 the correct version in which this behavior was introduced?
>
> Yes.  It was commit v3.6.0-rc1~293^2.

Thanks Brad. For future reference, are these changes documented
anywhere? I searched for "enable_language" in the 3.6 release notes,
and there is no 3.6 entry for policy changes.
-- 

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] enable_language behavior change

[Robert Dailey]

I remember around cmake v3.6, the behavior of enable_language()
changed so that if you did it too many times, you'd get the error:

Language 'C' is currently being enabled.  Recursive call not allowed.

I need to implement some backward compatibility code to check of CMake
version less than 3.6 (or appropriate version), then still call
enable_language(), otherwise do not call it.

Is 3.6 the correct version in which this behavior was introduced?
-- 

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] find_program() not using PATH on Windows?

[Robert Dailey]

On Mon, Mar 20, 2017 at 9:20 AM, Brad King <brad.k...@kitware.com> wrote:
> On 03/20/2017 10:17 AM, Robert Dailey wrote:
>> What can I do to help you guys diagnose this problem? I could try
>> getting a reproducible script for you, but this is so dependent on
>> environment I'm not sure if it will serve as a good test case.
>
> Please build CMake from source with debugging enabled.  Then you
> can step through the search process.

I was hoping that wouldn't be your answer but looks like it's unavoidable :-)

I'm short on time since $DAYJOB keeps me pretty busy. I'll do my best
though. Thanks for the guidance.
-- 

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] find_program() not using PATH on Windows?

[Robert Dailey]

On Mon, Mar 20, 2017 at 8:40 AM, Brad King <brad.k...@kitware.com> wrote:
> On 03/17/2017 05:38 PM, Robert Dailey wrote:
>> find_program(GIT_EXECUTABLE git)
>
> The steps it follows are documented here:
>
>   https://cmake.org/cmake/help/v3.8/command/find_program.html
>
> It does include PATH, so it is strange that it is not working.
> Just to be sure the environment is as expected, add
>
>   message(STATUS "PATH=$ENV{PATH}")
>
> just before the find_program call.

Here is the result:

PATH=C:\ProgramData\Oracle\Java\javapath;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program
Files\Beyond Compare
4;E:\ant\bin;E:\android\sdk\tools;E:\android\sdk\platform-tools;E:\code\ziosk-scripts\device-scripts;E:\tools\ninja;E:\Ruby22\bin;E:\Python35;E:\Python35\Scripts;E:\Program
Files\CMake\bin;E:\Program Files\CMake\bin;C:\Program Files
(x86)\Notepad++;E:\Git\cmd;C:\Program Files (x86)\Windows
Kits\8.1\Windows Performance Toolkit\;C:\Program Files (x86)\Microsoft
Emulator Manager\1.0\;C:\Program
Files\TortoiseSVN\bin;C:\Users\robert\AppData\Local\Microsoft\WindowsApps;

Notice that "E:\Git\cmd" is in the list. Trust me I've beat the hell
out of this one, I can't figure out what's going on. I even enabled
trace logs but it didn't help much.

What can I do to help you guys diagnose this problem? I could try
getting a reproducible script for you, but this is so dependent on
environment I'm not sure if it will serve as a good test case.

let me know.
-- 

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_program() not using PATH on Windows?

[Robert Dailey]

So I have Git 2.11.1 installed and it's located in E:\Git\cmd\git.exe.
I ticked the option in the installer to add it to path.

I tried using the FindGit module via find_package() to find Git, but
it's not working. So I tried a simpler case:

find_program(GIT_EXECUTABLE git)

However it cannot find 'git'. No matter if I specify PATHS either, it
won't work. The documentation states it should use PATH at some point
to find git.exe, but it doesn't seem that it is doing this.

My PATH on Windows is as follows:

$ echo %PATH%
C:\Program Files\ConEmu\ConEmu\Scripts;C:\Program
Files\ConEmu;C:\Program
Files\ConEmu\ConEmu;C:\ProgramData\Oracle\Java\javapath;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program
Files\Beyond Compare
4;E:\ant\bin;E:\android\sdk\tools;E:\android\sdk\platform-tools;E:\code\ziosk-scripts\device-scripts;E:\tools\ninja;E:\Ruby22\bin;E:\Python35;E:\Python35\Scripts;E:\Program
Files\CMake\bin;E:\Program Files\CMake\bin;C:\Program Files
(x86)\Notepad++;E:\Git\cmd;C:\Program Files (x86)\Windows
Kits\8.1\Windows Performance Toolkit\;C:\Program Files (x86)\Microsoft
Emulator Manager\1.0\;C:\Program
Files\TortoiseSVN\bin;C:\Users\robert\AppData\Local\Microsoft\WindowsApps

Note that "E:\Git\cmd" is in the list of paths. I'm able to run
git.exe commands from CMD as well.

Any idea why CMake is not finding git.exe? I'm using CMake v3.8.0-rc2.
-- 

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] Multi-line strings with indentation ignored

[Robert Dailey]

At the moment, with CMake 3.0 and on, I can use this syntax for
multi-line strings:


option( ZIOSK_ENABLE_ZPAY_DIAGNOSTICS "\
Enable additional diagnostic logs for zPay related code. \
Should not be enabled for production due to the sensitivity \
and volume of logs that will be printed." )

The problem with this approach is that it's ugly; I can't indent the
code because the indentations are made to be a literal part of the
string itself. I prefer the C++ approach to multi-line strings because
it allows strings to be hard-wrapped AND indent them for style, all
without affecting the actual string data:

option( ZIOSK_ENABLE_ZPAY_DIAGNOSTICS
"Enable additional diagnostic logs for zPay related code. "
"Should not be enabled for production due to the sensitivity "
"and volume of logs that will be printed" )

This is much nicer, but CMake fails this code because it sees each
string as a separate parameter. Is there a mechanism I can use to
style my strings this way? If not, are there any plans to add better
multi-line string support?
-- 

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] Multi-line strings with indentation ignored

[Robert Dailey]

At the moment, with CMake 3.0 and on, I can use this syntax for
multi-line strings:


option( ZIOSK_ENABLE_ZPAY_DIAGNOSTICS "\
Enable additional diagnostic logs for zPay related code. \
Should not be enabled for production due to the sensitivity \
and volume of logs that will be printed." )

The problem with this approach is that it's ugly; I can't indent the
code because the indentations are made to be a literal part of the
string itself. I prefer the C++ approach to multi-line strings because
it allows strings to be hard-wrapped AND indent them for style, all
without affecting the actual string data:

option( ZIOSK_ENABLE_ZPAY_DIAGNOSTICS
"Enable additional diagnostic logs for zPay related code. "
"Should not be enabled for production due to the sensitivity "
"and volume of logs that will be printed" )

This is much nicer, but CMake fails this code because it sees each
string as a separate parameter. Is there a mechanism I can use to
style my strings this way? If not, are there any plans to add better
multi-line string support?
-- 

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 do static libraries get linked in Ninja?

[Robert Dailey]

The latter.

On Thu, Jan 5, 2017 at 3:39 PM, Robert Maynard
<robert.mayn...@kitware.com> wrote:
> Do you mean you don't see where the static library is created or where
> the static library is listed on the link line for the dynamic library?
>
> On Thu, Jan 5, 2017 at 11:30 AM, Robert Dailey <rcdailey.li...@gmail.com> 
> wrote:
>> I have two targets in CMake: a static library and a shared library.
>> The shared library specifies the static library as a target link
>> library.
>>
>> When I generate for Ninja, and I run:
>>
>> $ ninja -v
>>
>> During the link command for the shared library, I do not see the
>> static library specified to g++. I do see *.so files, but not *.a
>> files. Why are static libraries not showing up on the command line for
>> the link step? There must be some black magic happening that I'm not
>> seeing...
>> --
>>
>> 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] How do static libraries get linked in Ninja?

[Robert Dailey]

I have two targets in CMake: a static library and a shared library.
The shared library specifies the static library as a target link
library.

When I generate for Ninja, and I run:

$ ninja -v

During the link command for the shared library, I do not see the
static library specified to g++. I do see *.so files, but not *.a
files. Why are static libraries not showing up on the command line for
the link step? There must be some black magic happening that I'm not
seeing...
-- 

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] Does target order matter for dependencies?

[Robert Dailey]

When I define my targets (custom, library, executable), does the order
of their declaration matter when it comes to using those targets in
dependencies? It's difficult to explain, so I'll show an example:


add_executable(foo main1.cpp)
target_link_libraries(foo abc)

add_library(abc main2.cpp)

In the example above, the add_library() happens after
target_link_libraries() for the executable. I've seen this work, but I
was using static libraries. Would this work for shared libraries too?
Does CMake do a multi-pass parse so that all targets are known prior
to them being referenced?

The target_link_libraries() [1] documentation states:

"The named target must be created by add_library() within the project
or as an IMPORTED library. If it is created within the project an
ordering dependency will automatically be added in the build system to
make sure the named library target is up-to-date before the 
links."

I'm not sure what "up-to-date" here means, or if this specific
documentation is talking about compile-time dependencies or cmake
dependencies.

[1]: https://cmake.org/cmake/help/latest/command/target_link_libraries.html
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] VS2017 + CMake integration

[Robert Dailey]

Thanks for the feedback Marian!

If/when you rebase to CMake 3.7, how will that package be delivered to
Visual Studio customers? My real concern stems from basically our
minimum required version of CMake for our specific scripts. The
minimum is 3.7 due to the awesome Android integration added in that
version. Which means obviously I can't use the bundled version of
CMake in VS currently.

On Wed, Nov 23, 2016 at 1:57 PM, Marian Luparu <mlup...@microsoft.com> wrote:
> Thanks Robert -- this is great feedback
>
> Yes, VS ships with a patched 3.6 CMake that includes both changes to find the 
> VS 2017 installation as well as the CMake-Server functionality needed for the 
> IDE services. We have not yet started upstreaming these changes (got totally 
> sidetracked by getting the VS 2017 RC release out the door) but are 
> absolutely committed to do so. As a first step, we will be rebasing our 
> changes to the 3.7 CMake release and then start contributing these pieces.
>
> Once the changes are in PR, at a minimum, you will be able to compile your 
> own version of CMake if you wanted to, to replace the one shipping in VS. But 
> currently, to answer your other question, we have no capability of pointing 
> VS to a different version of CMake. That's primarily because of the 
> thick-coupling between VS and the custom patches we need in CMake to make the 
> end-to-end experience work.
>
> Thanks,
> Marian Luparu
> Visual C++ PM Lead
>
> -Original Message-----
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Robert Dailey
> Sent: Tuesday, November 22, 2016 10:58 AM
> To: CMake <cmake@cmake.org>
> Subject: [CMake] VS2017 + CMake integration
>
> First of all, I personally find the CMake integration in Visual Studio just 
> absolutely amazing. Granted I am not doing any cross-compiling with Android 
> yet, but for just building on Windows it's phenomenal.
>
> I noticed that Visual Studio 2017 RC is actually packaging its own version of 
> CMake:
>
> E:\PROGRAM FILES (X86)\MICROSOFT VISUAL
> STUDIO\2017\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe
>
> Is Microsoft patching the CMake code base to support what they are doing? And 
> if so, are those changes not upstream yet? Personally, I'd rather have the 
> ability to tell Visual Studio to use my external version of CMake that is on 
> PATH, rather than its own. I can understand if that isn't possible right now 
> due to custom changes, but I'm curious to learn more, assuming Kitware has 
> had a partnership with Microsoft for this integration with Visual Studio.
>
> Would anyone be able to provide more news here? Is there a way to make VS 
> 2017 use my separate install of CMake? Are the Microsoft-specific patches 
> contributed to upstream (or planned to be)?
> --
>
> Powered by 
> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863=Plv73v%2B4m3KwGsh6VinIPPgg1qUsCdmDlx%2F9U2urOqA%3D=0
>
> Please keep messages on-topic and check the CMake FAQ at: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cmake.org%2FWiki%2FCMake_FAQ=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863=qBtWeiauHkzD7ISZxtqz3Q72SaDZZwKwdY%2F1voAI2U8%3D=0
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fsupport.html=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863=NZgcc%2BxtLPkIWXjqcIwItZr7KXAe6cqbcQaLpAMMA9Q%3D=0
> CMake Consulting: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fconsulting.html=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863=YXiCCEGtOMh3qvpKtXTgiL86czKy8xedQbUOoFaTsXA%3D=0
> CMake Training Courses: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Ftraining.html=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863=Paz%2Ft%2Bm63qi1AavokeWDNrR69wIUD2Tzjuyp7gUHORk%3D=0
>
> Visit other Kitware open-source projects at 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html=02%7C01%7Cmluparu%40microsoft.com%7C00957bc2ac4847ee794f08d413098464%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154378985417863=Mkwb

[CMake] VS2017 + CMake integration

[Robert Dailey]

First of all, I personally find the CMake integration in Visual Studio
just absolutely amazing. Granted I am not doing any cross-compiling
with Android yet, but for just building on Windows it's phenomenal.

I noticed that Visual Studio 2017 RC is actually packaging its own
version of CMake:

E:\PROGRAM FILES (X86)\MICROSOFT VISUAL
STUDIO\2017\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe

Is Microsoft patching the CMake code base to support what they are
doing? And if so, are those changes not upstream yet? Personally, I'd
rather have the ability to tell Visual Studio to use my external
version of CMake that is on PATH, rather than its own. I can
understand if that isn't possible right now due to custom changes, but
I'm curious to learn more, assuming Kitware has had a partnership with
Microsoft for this integration with Visual Studio.

Would anyone be able to provide more news here? Is there a way to make
VS 2017 use my separate install of CMake? Are the Microsoft-specific
patches contributed to upstream (or planned to be)?
-- 

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] [cmake-developers] CMake integration in Gradle (Android Studio)

[Robert Dailey]

Florent, I had the same thoughts. It seems that the CMake generate +
build step happen silently as a prerequisite step when doing the
'gradle build' command somewhere. It makes it appear as if CMake is
not running at all, but instead the Java piece of the build is just
taking forever.

Really I want to get away from ant / eclipse, but unlike Android
Studio, at least in Eclipse I can view C++ code and edit it. I don't
know of any other IDE I can use to edit both java & android code. My
last shining hope is perhaps Visual Studio 2015 and their Android
support. They have a fork of the CMake repository with some changes
for generating Android IDE projects for VS, I have not tried it
though.

What a giant mess this has become... I have no idea what direction to
go on this. Advice on tooling combinations you guys are using would be
very helpful though.

On Mon, Oct 31, 2016 at 5:04 PM, Florent Castelli
<florent.caste...@gmail.com> wrote:
> I tried the Gradle + CMake integration and I'm not really impressed.
> I would recommend not using it right now until they fix the rough edges.
>
> The prime concern is that it is REALLY hard to get the CMake output and
> compilation output,
> even within Android Studio. If you compile from command line, you won't see
> much.
> This is a no go for CI environments where you need to see what went wrong
> and also some
> output once in a while (or builds are usually considered stuck and canceled
> if they take too long).
> See the issue: https://code.google.com/p/android/issues/detail?id=210930
>
> Installing CMake within the SDK is not trivial. There's an open bug with a
> proposed solution,
> it's not pretty stuff but does the work:
> https://code.google.com/p/android/issues/detail?id=221907
> An alternative would be to repackage your SDK folder after running Android
> Studio and installing
> everything you need and distribute that to your CI build machines /
> developer machines.
>
> But essentially, what you want is probably just use their toolchain file,
> which is much better
> than the OpenCV one. You can find it bundled in the latest NDK and I guess
> you could be using
> that directly with CMake. If it is doing weird things, I guess you could
> have a look at it and debug it.
> It's not as complicated as the OpenCV one and I hope you'll find the
> solution to your issues!
>
> As for CMake 3.7, when I asked about it in this mailing list, someone said
> there will be
> a compatibility layer to the toolchain to reuse the upstream support when
> it's available
> if I remember correctly.
>
> /Florent
>
>
> On 25/10/2016 15:48, Robert Dailey wrote:
>>
>> I'm not sure if the CMake mailing lists are the right place to ask
>> this question but I thought I'd ask just in case someone has gone down
>> this path or has experience with what Google/Gradle is actually trying
>> to accomplish with what seems to be a hand-built version of CMake with
>> custom patches that are not in upstream repositories.
>>
>> Prior to switching to Android Studio / Gradle, I was using Eclipse /
>> Ant. The way I did CMake integration was not really integration at
>> all: I generated Ninja build scripts using CMake and implemented
>> custom targets to run "ant release" after all the C++ projects were
>> built. I made sure that CMake copied relevant *.so files to
>> appropriate directories in the Ant structure so they are packaged with
>> built APKs. That's how I did my Android development.
>>
>> Now that I'm integrating CMake into Gradle, first annoyance I noticed
>> is that I can't use CMake 3.7 (or any external installation of CMake)
>> with Android Studio. It requires a version of CMake installed through
>> SDK Manager. This means I can't use the new Android toolchain
>> functionality built into CMake 3.7 (sad face). But this is something I
>> can work around...
>>
>> Next I found out that stuff I'm setting in my CMake scripts, such as
>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
>> For whatever reason, Gradle is overriding these from the command line
>> (I'm guessing?). So this requires me to duplicate the toolchain /
>> compiler flag setup I already do in my CMake scripts now in the Gradle
>> build scripts. This seems completely unnecessary and a maintenance
>> burden.
>>
>> What I was expecting Gradle to do was essentially provide me some
>> toolchain file so that CMake can find the compiler and linker to use
>> and then the rest would be determined by CMake itself.
>>
>> Is there a way I can tell Gradle to not take so much control over
>> compiler flags? I want my CMake scripts to do this. I can't imagine
>> t

Re: [cmake-developers] CMake integration in Gradle (Android Studio)

[Robert Dailey]

Florent, I had the same thoughts. It seems that the CMake generate +
build step happen silently as a prerequisite step when doing the
'gradle build' command somewhere. It makes it appear as if CMake is
not running at all, but instead the Java piece of the build is just
taking forever.

Really I want to get away from ant / eclipse, but unlike Android
Studio, at least in Eclipse I can view C++ code and edit it. I don't
know of any other IDE I can use to edit both java & android code. My
last shining hope is perhaps Visual Studio 2015 and their Android
support. They have a fork of the CMake repository with some changes
for generating Android IDE projects for VS, I have not tried it
though.

What a giant mess this has become... I have no idea what direction to
go on this. Advice on tooling combinations you guys are using would be
very helpful though.

On Mon, Oct 31, 2016 at 5:04 PM, Florent Castelli
<florent.caste...@gmail.com> wrote:
> I tried the Gradle + CMake integration and I'm not really impressed.
> I would recommend not using it right now until they fix the rough edges.
>
> The prime concern is that it is REALLY hard to get the CMake output and
> compilation output,
> even within Android Studio. If you compile from command line, you won't see
> much.
> This is a no go for CI environments where you need to see what went wrong
> and also some
> output once in a while (or builds are usually considered stuck and canceled
> if they take too long).
> See the issue: https://code.google.com/p/android/issues/detail?id=210930
>
> Installing CMake within the SDK is not trivial. There's an open bug with a
> proposed solution,
> it's not pretty stuff but does the work:
> https://code.google.com/p/android/issues/detail?id=221907
> An alternative would be to repackage your SDK folder after running Android
> Studio and installing
> everything you need and distribute that to your CI build machines /
> developer machines.
>
> But essentially, what you want is probably just use their toolchain file,
> which is much better
> than the OpenCV one. You can find it bundled in the latest NDK and I guess
> you could be using
> that directly with CMake. If it is doing weird things, I guess you could
> have a look at it and debug it.
> It's not as complicated as the OpenCV one and I hope you'll find the
> solution to your issues!
>
> As for CMake 3.7, when I asked about it in this mailing list, someone said
> there will be
> a compatibility layer to the toolchain to reuse the upstream support when
> it's available
> if I remember correctly.
>
> /Florent
>
>
> On 25/10/2016 15:48, Robert Dailey wrote:
>>
>> I'm not sure if the CMake mailing lists are the right place to ask
>> this question but I thought I'd ask just in case someone has gone down
>> this path or has experience with what Google/Gradle is actually trying
>> to accomplish with what seems to be a hand-built version of CMake with
>> custom patches that are not in upstream repositories.
>>
>> Prior to switching to Android Studio / Gradle, I was using Eclipse /
>> Ant. The way I did CMake integration was not really integration at
>> all: I generated Ninja build scripts using CMake and implemented
>> custom targets to run "ant release" after all the C++ projects were
>> built. I made sure that CMake copied relevant *.so files to
>> appropriate directories in the Ant structure so they are packaged with
>> built APKs. That's how I did my Android development.
>>
>> Now that I'm integrating CMake into Gradle, first annoyance I noticed
>> is that I can't use CMake 3.7 (or any external installation of CMake)
>> with Android Studio. It requires a version of CMake installed through
>> SDK Manager. This means I can't use the new Android toolchain
>> functionality built into CMake 3.7 (sad face). But this is something I
>> can work around...
>>
>> Next I found out that stuff I'm setting in my CMake scripts, such as
>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
>> For whatever reason, Gradle is overriding these from the command line
>> (I'm guessing?). So this requires me to duplicate the toolchain /
>> compiler flag setup I already do in my CMake scripts now in the Gradle
>> build scripts. This seems completely unnecessary and a maintenance
>> burden.
>>
>> What I was expecting Gradle to do was essentially provide me some
>> toolchain file so that CMake can find the compiler and linker to use
>> and then the rest would be determined by CMake itself.
>>
>> Is there a way I can tell Gradle to not take so much control over
>> compiler flags? I want my CMake scripts to do this. I can't imagine
>> t

Re: [cmake-developers] [CMake] CMake integration in Gradle (Android Studio)

[Robert Dailey]

I'm sorry but that doesn't really answer my questions.

On Mon, Oct 31, 2016 at 8:55 AM, Cong Monkey <congzhan...@gmail.com> wrote:
> Try to update your Android SDK from android studio?
>
>
> 2016年10月31日 21:31，"Robert Dailey" <rcdailey.li...@gmail.com>写道：
>
> Which version of Android Studio? Latest stable is 2.2 IIRC. Are you
> talking about dev/beta builds?
>
> On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey <congzhan...@gmail.com> wrote:
>> The latest release of android studio work with CMAKE well.
>>
>> you can create a new project with c++ support to test CMAKE support!
>>
>> You can follow https://code.google.com/p/android/issues/detail?id=212007
>> to get the details.
>>
>> 2016-10-28 5:48 GMT+08:00 Robert Dailey <rcdailey.li...@gmail.com>:
>>> I'm at a bit of a loss on finding more information. Can anyone at
>>> least confirm that this isn't a reliable place to find the answers I'm
>>> looking for? Does anyone have real experience with android + gradle +
>>> cmake integration and can provide some pointers?
>>>
>>> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey <rcdailey.li...@gmail.com>
>>> wrote:
>>>> I'm not sure if the CMake mailing lists are the right place to ask
>>>> this question but I thought I'd ask just in case someone has gone down
>>>> this path or has experience with what Google/Gradle is actually trying
>>>> to accomplish with what seems to be a hand-built version of CMake with
>>>> custom patches that are not in upstream repositories.
>>>>
>>>> Prior to switching to Android Studio / Gradle, I was using Eclipse /
>>>> Ant. The way I did CMake integration was not really integration at
>>>> all: I generated Ninja build scripts using CMake and implemented
>>>> custom targets to run "ant release" after all the C++ projects were
>>>> built. I made sure that CMake copied relevant *.so files to
>>>> appropriate directories in the Ant structure so they are packaged with
>>>> built APKs. That's how I did my Android development.
>>>>
>>>> Now that I'm integrating CMake into Gradle, first annoyance I noticed
>>>> is that I can't use CMake 3.7 (or any external installation of CMake)
>>>> with Android Studio. It requires a version of CMake installed through
>>>> SDK Manager. This means I can't use the new Android toolchain
>>>> functionality built into CMake 3.7 (sad face). But this is something I
>>>> can work around...
>>>>
>>>> Next I found out that stuff I'm setting in my CMake scripts, such as
>>>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
>>>> For whatever reason, Gradle is overriding these from the command line
>>>> (I'm guessing?). So this requires me to duplicate the toolchain /
>>>> compiler flag setup I already do in my CMake scripts now in the Gradle
>>>> build scripts. This seems completely unnecessary and a maintenance
>>>> burden.
>>>>
>>>> What I was expecting Gradle to do was essentially provide me some
>>>> toolchain file so that CMake can find the compiler and linker to use
>>>> and then the rest would be determined by CMake itself.
>>>>
>>>> Is there a way I can tell Gradle to not take so much control over
>>>> compiler flags? I want my CMake scripts to do this. I can't imagine
>>>> they had a good reason to do this. What have others done in this
>>>> situation with their own Gradle + CMake integration? Looking for
>>>> advice here, since information is sparse, especially since the Android
>>>> Studio 2.2 CMake integration is relatively new stuff.
>>> --
>>>
>>> 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-developers

Re: [CMake] CMake integration in Gradle (Android Studio)

[Robert Dailey]

I'm sorry but that doesn't really answer my questions.

On Mon, Oct 31, 2016 at 8:55 AM, Cong Monkey <congzhan...@gmail.com> wrote:
> Try to update your Android SDK from android studio?
>
>
> 2016年10月31日 21:31，"Robert Dailey" <rcdailey.li...@gmail.com>写道：
>
> Which version of Android Studio? Latest stable is 2.2 IIRC. Are you
> talking about dev/beta builds?
>
> On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey <congzhan...@gmail.com> wrote:
>> The latest release of android studio work with CMAKE well.
>>
>> you can create a new project with c++ support to test CMAKE support!
>>
>> You can follow https://code.google.com/p/android/issues/detail?id=212007
>> to get the details.
>>
>> 2016-10-28 5:48 GMT+08:00 Robert Dailey <rcdailey.li...@gmail.com>:
>>> I'm at a bit of a loss on finding more information. Can anyone at
>>> least confirm that this isn't a reliable place to find the answers I'm
>>> looking for? Does anyone have real experience with android + gradle +
>>> cmake integration and can provide some pointers?
>>>
>>> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey <rcdailey.li...@gmail.com>
>>> wrote:
>>>> I'm not sure if the CMake mailing lists are the right place to ask
>>>> this question but I thought I'd ask just in case someone has gone down
>>>> this path or has experience with what Google/Gradle is actually trying
>>>> to accomplish with what seems to be a hand-built version of CMake with
>>>> custom patches that are not in upstream repositories.
>>>>
>>>> Prior to switching to Android Studio / Gradle, I was using Eclipse /
>>>> Ant. The way I did CMake integration was not really integration at
>>>> all: I generated Ninja build scripts using CMake and implemented
>>>> custom targets to run "ant release" after all the C++ projects were
>>>> built. I made sure that CMake copied relevant *.so files to
>>>> appropriate directories in the Ant structure so they are packaged with
>>>> built APKs. That's how I did my Android development.
>>>>
>>>> Now that I'm integrating CMake into Gradle, first annoyance I noticed
>>>> is that I can't use CMake 3.7 (or any external installation of CMake)
>>>> with Android Studio. It requires a version of CMake installed through
>>>> SDK Manager. This means I can't use the new Android toolchain
>>>> functionality built into CMake 3.7 (sad face). But this is something I
>>>> can work around...
>>>>
>>>> Next I found out that stuff I'm setting in my CMake scripts, such as
>>>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
>>>> For whatever reason, Gradle is overriding these from the command line
>>>> (I'm guessing?). So this requires me to duplicate the toolchain /
>>>> compiler flag setup I already do in my CMake scripts now in the Gradle
>>>> build scripts. This seems completely unnecessary and a maintenance
>>>> burden.
>>>>
>>>> What I was expecting Gradle to do was essentially provide me some
>>>> toolchain file so that CMake can find the compiler and linker to use
>>>> and then the rest would be determined by CMake itself.
>>>>
>>>> Is there a way I can tell Gradle to not take so much control over
>>>> compiler flags? I want my CMake scripts to do this. I can't imagine
>>>> they had a good reason to do this. What have others done in this
>>>> situation with their own Gradle + CMake integration? Looking for
>>>> advice here, since information is sparse, especially since the Android
>>>> Studio 2.2 CMake integration is relatively new stuff.
>>> --
>>>
>>> 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] CMake integration in Gradle (Android Studio)

[Robert Dailey]

Which version of Android Studio? Latest stable is 2.2 IIRC. Are you
talking about dev/beta builds?

On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey <congzhan...@gmail.com> wrote:
> The latest release of android studio work with CMAKE well.
>
> you can create a new project with c++ support to test CMAKE support!
>
> You can follow https://code.google.com/p/android/issues/detail?id=212007
> to get the details.
>
> 2016-10-28 5:48 GMT+08:00 Robert Dailey <rcdailey.li...@gmail.com>:
>> I'm at a bit of a loss on finding more information. Can anyone at
>> least confirm that this isn't a reliable place to find the answers I'm
>> looking for? Does anyone have real experience with android + gradle +
>> cmake integration and can provide some pointers?
>>
>> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey <rcdailey.li...@gmail.com> 
>> wrote:
>>> I'm not sure if the CMake mailing lists are the right place to ask
>>> this question but I thought I'd ask just in case someone has gone down
>>> this path or has experience with what Google/Gradle is actually trying
>>> to accomplish with what seems to be a hand-built version of CMake with
>>> custom patches that are not in upstream repositories.
>>>
>>> Prior to switching to Android Studio / Gradle, I was using Eclipse /
>>> Ant. The way I did CMake integration was not really integration at
>>> all: I generated Ninja build scripts using CMake and implemented
>>> custom targets to run "ant release" after all the C++ projects were
>>> built. I made sure that CMake copied relevant *.so files to
>>> appropriate directories in the Ant structure so they are packaged with
>>> built APKs. That's how I did my Android development.
>>>
>>> Now that I'm integrating CMake into Gradle, first annoyance I noticed
>>> is that I can't use CMake 3.7 (or any external installation of CMake)
>>> with Android Studio. It requires a version of CMake installed through
>>> SDK Manager. This means I can't use the new Android toolchain
>>> functionality built into CMake 3.7 (sad face). But this is something I
>>> can work around...
>>>
>>> Next I found out that stuff I'm setting in my CMake scripts, such as
>>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
>>> For whatever reason, Gradle is overriding these from the command line
>>> (I'm guessing?). So this requires me to duplicate the toolchain /
>>> compiler flag setup I already do in my CMake scripts now in the Gradle
>>> build scripts. This seems completely unnecessary and a maintenance
>>> burden.
>>>
>>> What I was expecting Gradle to do was essentially provide me some
>>> toolchain file so that CMake can find the compiler and linker to use
>>> and then the rest would be determined by CMake itself.
>>>
>>> Is there a way I can tell Gradle to not take so much control over
>>> compiler flags? I want my CMake scripts to do this. I can't imagine
>>> they had a good reason to do this. What have others done in this
>>> situation with their own Gradle + CMake integration? Looking for
>>> advice here, since information is sparse, especially since the Android
>>> Studio 2.2 CMake integration is relatively new stuff.
>> --
>>
>> 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-developers

Re: [CMake] CMake integration in Gradle (Android Studio)

[Robert Dailey]

Which version of Android Studio? Latest stable is 2.2 IIRC. Are you
talking about dev/beta builds?

On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey <congzhan...@gmail.com> wrote:
> The latest release of android studio work with CMAKE well.
>
> you can create a new project with c++ support to test CMAKE support!
>
> You can follow https://code.google.com/p/android/issues/detail?id=212007
> to get the details.
>
> 2016-10-28 5:48 GMT+08:00 Robert Dailey <rcdailey.li...@gmail.com>:
>> I'm at a bit of a loss on finding more information. Can anyone at
>> least confirm that this isn't a reliable place to find the answers I'm
>> looking for? Does anyone have real experience with android + gradle +
>> cmake integration and can provide some pointers?
>>
>> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey <rcdailey.li...@gmail.com> 
>> wrote:
>>> I'm not sure if the CMake mailing lists are the right place to ask
>>> this question but I thought I'd ask just in case someone has gone down
>>> this path or has experience with what Google/Gradle is actually trying
>>> to accomplish with what seems to be a hand-built version of CMake with
>>> custom patches that are not in upstream repositories.
>>>
>>> Prior to switching to Android Studio / Gradle, I was using Eclipse /
>>> Ant. The way I did CMake integration was not really integration at
>>> all: I generated Ninja build scripts using CMake and implemented
>>> custom targets to run "ant release" after all the C++ projects were
>>> built. I made sure that CMake copied relevant *.so files to
>>> appropriate directories in the Ant structure so they are packaged with
>>> built APKs. That's how I did my Android development.
>>>
>>> Now that I'm integrating CMake into Gradle, first annoyance I noticed
>>> is that I can't use CMake 3.7 (or any external installation of CMake)
>>> with Android Studio. It requires a version of CMake installed through
>>> SDK Manager. This means I can't use the new Android toolchain
>>> functionality built into CMake 3.7 (sad face). But this is something I
>>> can work around...
>>>
>>> Next I found out that stuff I'm setting in my CMake scripts, such as
>>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
>>> For whatever reason, Gradle is overriding these from the command line
>>> (I'm guessing?). So this requires me to duplicate the toolchain /
>>> compiler flag setup I already do in my CMake scripts now in the Gradle
>>> build scripts. This seems completely unnecessary and a maintenance
>>> burden.
>>>
>>> What I was expecting Gradle to do was essentially provide me some
>>> toolchain file so that CMake can find the compiler and linker to use
>>> and then the rest would be determined by CMake itself.
>>>
>>> Is there a way I can tell Gradle to not take so much control over
>>> compiler flags? I want my CMake scripts to do this. I can't imagine
>>> they had a good reason to do this. What have others done in this
>>> situation with their own Gradle + CMake integration? Looking for
>>> advice here, since information is sparse, especially since the Android
>>> Studio 2.2 CMake integration is relatively new stuff.
>> --
>>
>> 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] CMake integration in Gradle (Android Studio)

[Robert Dailey]

I'm at a bit of a loss on finding more information. Can anyone at
least confirm that this isn't a reliable place to find the answers I'm
looking for? Does anyone have real experience with android + gradle +
cmake integration and can provide some pointers?

On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> I'm not sure if the CMake mailing lists are the right place to ask
> this question but I thought I'd ask just in case someone has gone down
> this path or has experience with what Google/Gradle is actually trying
> to accomplish with what seems to be a hand-built version of CMake with
> custom patches that are not in upstream repositories.
>
> Prior to switching to Android Studio / Gradle, I was using Eclipse /
> Ant. The way I did CMake integration was not really integration at
> all: I generated Ninja build scripts using CMake and implemented
> custom targets to run "ant release" after all the C++ projects were
> built. I made sure that CMake copied relevant *.so files to
> appropriate directories in the Ant structure so they are packaged with
> built APKs. That's how I did my Android development.
>
> Now that I'm integrating CMake into Gradle, first annoyance I noticed
> is that I can't use CMake 3.7 (or any external installation of CMake)
> with Android Studio. It requires a version of CMake installed through
> SDK Manager. This means I can't use the new Android toolchain
> functionality built into CMake 3.7 (sad face). But this is something I
> can work around...
>
> Next I found out that stuff I'm setting in my CMake scripts, such as
> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
> For whatever reason, Gradle is overriding these from the command line
> (I'm guessing?). So this requires me to duplicate the toolchain /
> compiler flag setup I already do in my CMake scripts now in the Gradle
> build scripts. This seems completely unnecessary and a maintenance
> burden.
>
> What I was expecting Gradle to do was essentially provide me some
> toolchain file so that CMake can find the compiler and linker to use
> and then the rest would be determined by CMake itself.
>
> Is there a way I can tell Gradle to not take so much control over
> compiler flags? I want my CMake scripts to do this. I can't imagine
> they had a good reason to do this. What have others done in this
> situation with their own Gradle + CMake integration? Looking for
> advice here, since information is sparse, especially since the Android
> Studio 2.2 CMake integration is relatively new stuff.
-- 

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 integration in Gradle (Android Studio)

[Robert Dailey]

I'm at a bit of a loss on finding more information. Can anyone at
least confirm that this isn't a reliable place to find the answers I'm
looking for? Does anyone have real experience with android + gradle +
cmake integration and can provide some pointers?

On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> I'm not sure if the CMake mailing lists are the right place to ask
> this question but I thought I'd ask just in case someone has gone down
> this path or has experience with what Google/Gradle is actually trying
> to accomplish with what seems to be a hand-built version of CMake with
> custom patches that are not in upstream repositories.
>
> Prior to switching to Android Studio / Gradle, I was using Eclipse /
> Ant. The way I did CMake integration was not really integration at
> all: I generated Ninja build scripts using CMake and implemented
> custom targets to run "ant release" after all the C++ projects were
> built. I made sure that CMake copied relevant *.so files to
> appropriate directories in the Ant structure so they are packaged with
> built APKs. That's how I did my Android development.
>
> Now that I'm integrating CMake into Gradle, first annoyance I noticed
> is that I can't use CMake 3.7 (or any external installation of CMake)
> with Android Studio. It requires a version of CMake installed through
> SDK Manager. This means I can't use the new Android toolchain
> functionality built into CMake 3.7 (sad face). But this is something I
> can work around...
>
> Next I found out that stuff I'm setting in my CMake scripts, such as
> CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
> For whatever reason, Gradle is overriding these from the command line
> (I'm guessing?). So this requires me to duplicate the toolchain /
> compiler flag setup I already do in my CMake scripts now in the Gradle
> build scripts. This seems completely unnecessary and a maintenance
> burden.
>
> What I was expecting Gradle to do was essentially provide me some
> toolchain file so that CMake can find the compiler and linker to use
> and then the rest would be determined by CMake itself.
>
> Is there a way I can tell Gradle to not take so much control over
> compiler flags? I want my CMake scripts to do this. I can't imagine
> they had a good reason to do this. What have others done in this
> situation with their own Gradle + CMake integration? Looking for
> advice here, since information is sparse, especially since the Android
> Studio 2.2 CMake integration is relatively new stuff.
-- 

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 integration in Gradle (Android Studio)

[Robert Dailey]

I'm not sure if the CMake mailing lists are the right place to ask
this question but I thought I'd ask just in case someone has gone down
this path or has experience with what Google/Gradle is actually trying
to accomplish with what seems to be a hand-built version of CMake with
custom patches that are not in upstream repositories.

Prior to switching to Android Studio / Gradle, I was using Eclipse /
Ant. The way I did CMake integration was not really integration at
all: I generated Ninja build scripts using CMake and implemented
custom targets to run "ant release" after all the C++ projects were
built. I made sure that CMake copied relevant *.so files to
appropriate directories in the Ant structure so they are packaged with
built APKs. That's how I did my Android development.

Now that I'm integrating CMake into Gradle, first annoyance I noticed
is that I can't use CMake 3.7 (or any external installation of CMake)
with Android Studio. It requires a version of CMake installed through
SDK Manager. This means I can't use the new Android toolchain
functionality built into CMake 3.7 (sad face). But this is something I
can work around...

Next I found out that stuff I'm setting in my CMake scripts, such as
CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
For whatever reason, Gradle is overriding these from the command line
(I'm guessing?). So this requires me to duplicate the toolchain /
compiler flag setup I already do in my CMake scripts now in the Gradle
build scripts. This seems completely unnecessary and a maintenance
burden.

What I was expecting Gradle to do was essentially provide me some
toolchain file so that CMake can find the compiler and linker to use
and then the rest would be determined by CMake itself.

Is there a way I can tell Gradle to not take so much control over
compiler flags? I want my CMake scripts to do this. I can't imagine
they had a good reason to do this. What have others done in this
situation with their own Gradle + CMake integration? Looking for
advice here, since information is sparse, especially since the Android
Studio 2.2 CMake integration is relatively new stuff.
-- 

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] CMake integration in Gradle (Android Studio)

[Robert Dailey]

I'm not sure if the CMake mailing lists are the right place to ask
this question but I thought I'd ask just in case someone has gone down
this path or has experience with what Google/Gradle is actually trying
to accomplish with what seems to be a hand-built version of CMake with
custom patches that are not in upstream repositories.

Prior to switching to Android Studio / Gradle, I was using Eclipse /
Ant. The way I did CMake integration was not really integration at
all: I generated Ninja build scripts using CMake and implemented
custom targets to run "ant release" after all the C++ projects were
built. I made sure that CMake copied relevant *.so files to
appropriate directories in the Ant structure so they are packaged with
built APKs. That's how I did my Android development.

Now that I'm integrating CMake into Gradle, first annoyance I noticed
is that I can't use CMake 3.7 (or any external installation of CMake)
with Android Studio. It requires a version of CMake installed through
SDK Manager. This means I can't use the new Android toolchain
functionality built into CMake 3.7 (sad face). But this is something I
can work around...

Next I found out that stuff I'm setting in my CMake scripts, such as
CPP flags like `-std=c++14` and `-fexceptions` was not being applied.
For whatever reason, Gradle is overriding these from the command line
(I'm guessing?). So this requires me to duplicate the toolchain /
compiler flag setup I already do in my CMake scripts now in the Gradle
build scripts. This seems completely unnecessary and a maintenance
burden.

What I was expecting Gradle to do was essentially provide me some
toolchain file so that CMake can find the compiler and linker to use
and then the rest would be determined by CMake itself.

Is there a way I can tell Gradle to not take so much control over
compiler flags? I want my CMake scripts to do this. I can't imagine
they had a good reason to do this. What have others done in this
situation with their own Gradle + CMake integration? Looking for
advice here, since information is sparse, especially since the Android
Studio 2.2 CMake integration is relatively new stuff.
-- 

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] Android Support

[Robert Dailey]

On Thu, Oct 20, 2016 at 2:51 PM, Brad King <brad.k...@kitware.com> wrote:
> On 10/20/2016 03:35 PM, Robert Dailey wrote:
>> So using takanome's cmake toolchain, he had support for native app
>> glue. Does CMake offer support for this now? I was able to generate
>> but I'm not able to load in native app glue from the NDK.
>
> We don't currently offer a first-class interface for it but the locations
> are available relative to CMAKE_ANDROID_NDK:
>
> ```
> include_directories("${CMAKE_ANDROID_NDK}/sources/android/native_app_glue")
> set(my_sources ...
>   
> ${CMAKE_ANDROID_NDK}/sources/android/native_app_glue/android_native_app_glue.c
>   )
> ```
>
> Similarly for cpufeatures and ndk_helper.
>
> That is why
>
>  
> https://github.com/taka-no-me/android-cmake/blob/master/AndroidNdkModules.cmake
>
> simply wraps around hard-coded locations.

Thanks a bunch Brad. I simply modified AndroidNdkModules.cmake to use
CMAKE_ANDROID_NDK and it works perfect now.

Another question: Will CMake's android support only work with official
NDK releases? Or can I expect it to function with unofficial NDKs such
as Crystax?
-- 

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] Android Support

[Robert Dailey]

So using takanome's cmake toolchain, he had support for native app
glue. Does CMake offer support for this now? I was able to generate
but I'm not able to load in native app glue from the NDK.

On Tue, Oct 18, 2016 at 10:05 AM, Mikhail Filimonov
 wrote:
> Hi Brad,
> It looks that those commits broke CMake scripts used to generate Nsight Tegra 
> projects:
> https://gitlab.kitware.com/cmake/cmake/issues/16371
> Even CMake/tree/master/Tests/VSNsightTegra doesn't work with CMake ToT
>
> Regards,
> Mikhail Filimonov
>
> -Original Message-
> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf 
> Of Brad King
> Sent: Friday, August 12, 2016 6:13 PM
> To: cmake-developers@cmake.org
> Subject: [cmake-developers] Android Support
>
> Hi Folks,
>
> I've implemented native support for cross-compiling to Android with CMake 
> using either an Android NDK or an Android Standalone Toolchain.
> I plan to include this in the CMake 3.7 release.
>
> Please see the MR here:
>
>   https://gitlab.kitware.com/cmake/cmake/merge_requests/62
>
> This enables building with simple toolchain files, or even without one:
>
>   $ cmake ../src -DCMAKE_SYSTEM_NAME=Android -DCMAKE_ANDROID_NDK=/path/to/ndk
>
> Note that interface compatibility with popular third-party Android toolchain 
> files is a non-goal of this work (though we should not break them too much).
> Instead I'd like to make the support feel native within CMake.  For example, 
> the Android API level is naturally specified by CMAKE_SYSTEM_VERSION.
>
> If you're interested in this support please fetch the MR branch and try it 
> out.  The Help/manual/cmake-toolchains.7.rst manual has been updated with 
> documentation about how to use this.
>
> -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
> ---
> This email message is for the sole use of the intended recipient(s) and may 
> contain
> confidential information.  Any unauthorized review, use, disclosure or 
> distribution
> is prohibited.  If you are not the intended recipient, please contact the 
> sender by
> reply email and destroy all copies of the original message.
> ---
> --
>
> 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-developers] Android Support

[Robert Dailey]

On Tue, Sep 27, 2016 at 10:39 AM, Brad King  wrote:
> On 09/27/2016 11:28 AM, Florent Castelli wrote:
>> Is there any plan on having their toolchain in CMake directly at some point?
>
> No.  Their toolchain files are designed to be loaded from the NDK.  They
> compute things relative to their own location and are meant to know exactly
> what is there.
>
> The whole point of a toolchain file is supposed to be to have information 
> about
> the local machine that CMake can't know in general.  They aren't supposed to 
> be
> these huge files with tables of information common to the target platform and
> full of system introspection logic.  CMake now has those tables so the 
> toolchain
> files don't have to.
>
> With CMake 3.7 you shouldn't actually need a toolchain file from the NDK.
> In fact for simple cases you don't even need a toolchain file at all.

Brad, do you have a guide or walkthrough for the new CMake integration
features of 3.7 that I can read? I'm actively developing using CMake +
NDK and it's incredibly difficult to keep takanome's android-cmake
toolchain file functional for newer versions of the NDK (specifically
r11 and r12).

Would love to see a tutorial on how it works for an out-of-the-box NDK
setup. I'm not sure how much CMake has hard-coded the location of
prebuilt toolchains and such on the NDK. As you pointed out, the
toolchain is supposed to point to this stuff. Does CMake just need the
ANDROID_NDK environment variable?

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

Re: [cmake-developers] Android Support

[Robert Dailey]

Currently nightly builds are tagged 3.6.2. Are there no nightly builds
for 3.7 or am I missing something?

On Fri, Aug 12, 2016 at 10:26 AM, Robert Goulet
 wrote:
> That's super awesome Brad!
>
> Looking forward to try this out!
>
> -Original Message-
> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf 
> Of Brad King
> Sent: Friday, August 12, 2016 11:13 AM
> To: cmake-developers@cmake.org
> Subject: [cmake-developers] Android Support
>
> Hi Folks,
>
> I've implemented native support for cross-compiling to Android with CMake 
> using either an Android NDK or an Android Standalone Toolchain.
> I plan to include this in the CMake 3.7 release.
>
> Please see the MR here:
>
>   https://gitlab.kitware.com/cmake/cmake/merge_requests/62
>
> This enables building with simple toolchain files, or even without one:
>
>   $ cmake ../src -DCMAKE_SYSTEM_NAME=Android -DCMAKE_ANDROID_NDK=/path/to/ndk
>
> Note that interface compatibility with popular third-party Android toolchain 
> files is a non-goal of this work (though we should not break them too much).
> Instead I'd like to make the support feel native within CMake.  For example, 
> the Android API level is naturally specified by CMAKE_SYSTEM_VERSION.
>
> If you're interested in this support please fetch the MR branch and try it 
> out.  The Help/manual/cmake-toolchains.7.rst manual has been updated with 
> documentation about how to use this.
>
> -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
-- 

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] Need ideas/opinions on third party library management

[Robert Dailey]

On Fri, Aug 12, 2016 at 4:58 PM, Roger Leigh  wrote:
> You can simplify this to two steps:
>
> 1. Clone the superbuild repository
> 2. Build the third-party and first-party packages
>
> This is the approach we take with the OME super-build
> https://github.com/ome/ome-cmake-superbuild/
>
> See the packages in
> https://github.com/ome/ome-cmake-superbuild/tree/develop/packages
> all the ones with an "ome-" prefix are the first-party libraries;
> everything else is third-party.  They are all external projects.
>
> We have cmake options to select all packages, first-party packages only or
> select individual packages by hand; the recursive dependency resolution will
> add/ignore dependencies depending upon the chosen policy (defaulting to
> include third-party dependencies).  So when you're building on BSD or Linux,
> you can say "no third-party dependencies except for gtest", or choose
> everything, and on Windows where there is no package manager, you always
> build everything.  And on Windows you can build just the dependencies and
> reuse them later; it has support for using cached builds which we use on the
> CI side to cut down build times; we only rebuild the cache when the
> superbuild git tree hash changes; see the scripts/jenkins-build script
>
> In addition to that, we have the means to build the first-party libraries in
> different ways
>
> 1. From source release tarball (last stable release)
> 2. From git (specify remote+branch as cmake options)
> 3. From a local git checkout (on whatever branch is currently checked out)
>
> You can see the selection logic here:
> https://github.com/ome/ome-cmake-superbuild/blob/develop/packages/ome-files/superbuild.cmake#L4
>
> In practice (1) is for end-users to build the whole thing, and (3) is what I
> use in practice to develop locally where I have a full set of git repos
> checked out locally, and I tell the superbuild to build them, along with all
> the third-party deps; (3) is also what we use on the CI system, with jenkins
> cloning all the individual repos into the workspace, then doing pretty much
> the same thing.  (2) is OK for one-off builds, but the need for a full git
> clone for every package is too much for routine use
>
> And you can see how first- and third-party dependencies are handled here:
> https://github.com/ome/ome-cmake-superbuild/blob/develop/packages/ome-files/superbuild.cmake#L48
>
> I might rearrange that so that the classification is in the dependency
> rather than the dependeee later on though.  It kind of evolved this way as
> we added additional features and needs a little cleanup to make it perfect.
>
> Everything in the above repository is BSD licensed, so feel free to use it
> for inspiration or take what you like.  The main point I wanted to make was
> that with the superbuild *everything* can be an external project, including
> your own code.  And from that point you can add in features like being able
> to selectively build just the third-party or just your own code, rather than
> forcing them to be separate manual steps.

I get where you are going with this, but I don't really think our code
base would benefit from treating third party and first party libraries
the same in CMake. We can't really use our different libraries in
isolation anyway, mostly due to a combination of architectural issues
and business logic.

Also I have to do some custom target stuff to pull everything together
for our Android APK build (our product is targeted for Android
platform). I have to do a lot of trickery to integrate with ant to
make our builds seamless between java & C++.
-- 

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] Need ideas/opinions on third party library management

[Robert Dailey]

Wow I actually completely forgot about that lol. I think I was looking
into it for some other reasons, not related to work. I will have to
look into it again. I don't really remember much about it.

Thanks for the reminder.

On Sat, Aug 13, 2016 at 7:02 PM, Ruslan Baratov
<ruslan_bara...@yahoo.com> wrote:
> Hi, Robert
>
> According to your GitHub account you've send a trivial patch about a year
> ago to the Hunter (https://github.com/ruslo/hunter) package manager. So I
> wonder what is your experience, have you tried it? Have you run into some
> troubles?
>
> Thanks, Ruslo
>
>
> On 12-Aug-16 22:59, Robert Dailey wrote:
>>
>> Hello,
>>
>> There is an internal C++ product at the company I work for which I
>> have written a series of CMake scripts for. This project actually has
>> dependencies on several open source libraries, such as boost,
>> freetype, openssl, etc.
>>
>> Right now what we do is build each of these third party libraries *by
>> hand*, once for every platform we support (Windows, Linux x86, Android
>> NDK). Then we stuff the includes (headers) and libraries
>> (static/shared) in a submodule and the primary code base's CMake
>> scripts pull them in as interface targets.
>>
>> This works well and is light-weight but is a pain when upgrading or
>> changing libraries. It's a pain because if I want to upgrade boost, I
>> have to build it up to 6 times (once for each platform and once for
>> each configuration).
>>
>> I've been thinking of a different approach for a while. I've done some
>> toying around with the "Super Build" concept, where I have a separate
>> CMake project that does nothing but use the ExternalProject module to
>> build libraries in real time along with our project. So the order of
>> operations would be as follows (for our automated build server):
>>
>> 1. Clone our "Third Party" repository
>> 2. Use CMake to generate & build the "Super Build" project (this
>> builds boost, openssl, freetype, etc for the current platform).
>> 3. Clone the main code base's repository
>> 4. Use CMake to generate & build, using find_package() to refer to
>> interface targets exported by those third party libraries built in
>> step 2
>>
>> Obviously this will make builds take significantly longer, because
>> we're constantly rebuilding the same third party libraries over and
>> over again. However, it virtually eliminates the maintenance burden
>> for third party libraries because they are built inherently with
>> everything else.
>>
>> Note that I can't refer to pre-built libraries in our build
>> environments because we need very specific control over the versions
>> of our libraries as well as the toolchains that were used to build
>> them. Also we may specifically build our libraries a certain way (such
>> as boost). For this reason we do not rely on our external environment
>> or external package managers to fulfill third party dependencies, like
>> most open source projects do on Linux for example.
>>
>> Does this "Super Build" approach sound like a better idea? What other
>> options are available? The downside with the "Super Build" solution is
>> that it will become very difficult to make the transition between
>> building third party and building our code base seamless. I can't do
>> both in the same generate step because find_package() can't be called
>> until the libraries are built & installed.
>
>
>
-- 

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] Need ideas/opinions on third party library management

[Robert Dailey]

I did some brief digging into spack, and it doesn't look like it
supports Windows. All I see are shell scripts and the documentation
uses POSIX.

If I'm going to use a package manager, it needs to be able to support
Android (ARM), Windows, and Linux. I have specific toolchains that
I'll need the package manager to use for each of these platforms,
assuming it compiles these libraries. It also needs to be capable of
cross-compiling (in the case of ARM toolchain in the Android NDK).

I mean, we can't really call it "reinventing the wheel" if my
requirements are so specific that no current tooling can support it.
If you have any info on spack related to my requirements please let me
know. It looks promising, but so far doesn't seem like it will work
out.

On Fri, Aug 12, 2016 at 3:41 PM, Elizabeth A. Fischer
<elizabeth.fisc...@columbia.edu> wrote:
> This is what Spack and other meta builders do.  See http://github.
> com/llnl/spack
>
> On Aug 12, 2016 3:59 PM, "Robert Dailey" <rcdailey.li...@gmail.com> wrote:
>>
>> Hello,
>>
>> There is an internal C++ product at the company I work for which I
>> have written a series of CMake scripts for. This project actually has
>> dependencies on several open source libraries, such as boost,
>> freetype, openssl, etc.
>>
>> Right now what we do is build each of these third party libraries *by
>> hand*, once for every platform we support (Windows, Linux x86, Android
>> NDK). Then we stuff the includes (headers) and libraries
>> (static/shared) in a submodule and the primary code base's CMake
>> scripts pull them in as interface targets.
>>
>> This works well and is light-weight but is a pain when upgrading or
>> changing libraries. It's a pain because if I want to upgrade boost, I
>> have to build it up to 6 times (once for each platform and once for
>> each configuration).
>>
>> I've been thinking of a different approach for a while. I've done some
>> toying around with the "Super Build" concept, where I have a separate
>> CMake project that does nothing but use the ExternalProject module to
>> build libraries in real time along with our project. So the order of
>> operations would be as follows (for our automated build server):
>>
>> 1. Clone our "Third Party" repository
>> 2. Use CMake to generate & build the "Super Build" project (this
>> builds boost, openssl, freetype, etc for the current platform).
>> 3. Clone the main code base's repository
>> 4. Use CMake to generate & build, using find_package() to refer to
>> interface targets exported by those third party libraries built in
>> step 2
>>
>> Obviously this will make builds take significantly longer, because
>> we're constantly rebuilding the same third party libraries over and
>> over again. However, it virtually eliminates the maintenance burden
>> for third party libraries because they are built inherently with
>> everything else.
>>
>> Note that I can't refer to pre-built libraries in our build
>> environments because we need very specific control over the versions
>> of our libraries as well as the toolchains that were used to build
>> them. Also we may specifically build our libraries a certain way (such
>> as boost). For this reason we do not rely on our external environment
>> or external package managers to fulfill third party dependencies, like
>> most open source projects do on Linux for example.
>>
>> Does this "Super Build" approach sound like a better idea? What other
>> options are available? The downside with the "Super Build" solution is
>> that it will become very difficult to make the transition between
>> building third party and building our code base seamless. I can't do
>> both in the same generate step because find_package() can't be called
>> until the libraries are built & installed.
>> --
>>
>> 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.

Re: [cmake-developers] [CMake] Need ideas/opinions on third party library management

[Robert Dailey]

I did some brief digging into spack, and it doesn't look like it
supports Windows. All I see are shell scripts and the documentation
uses POSIX.

If I'm going to use a package manager, it needs to be able to support
Android (ARM), Windows, and Linux. I have specific toolchains that
I'll need the package manager to use for each of these platforms,
assuming it compiles these libraries. It also needs to be capable of
cross-compiling (in the case of ARM toolchain in the Android NDK).

I mean, we can't really call it "reinventing the wheel" if my
requirements are so specific that no current tooling can support it.
If you have any info on spack related to my requirements please let me
know. It looks promising, but so far doesn't seem like it will work
out.

On Fri, Aug 12, 2016 at 3:41 PM, Elizabeth A. Fischer
<elizabeth.fisc...@columbia.edu> wrote:
> This is what Spack and other meta builders do.  See http://github.
> com/llnl/spack
>
> On Aug 12, 2016 3:59 PM, "Robert Dailey" <rcdailey.li...@gmail.com> wrote:
>>
>> Hello,
>>
>> There is an internal C++ product at the company I work for which I
>> have written a series of CMake scripts for. This project actually has
>> dependencies on several open source libraries, such as boost,
>> freetype, openssl, etc.
>>
>> Right now what we do is build each of these third party libraries *by
>> hand*, once for every platform we support (Windows, Linux x86, Android
>> NDK). Then we stuff the includes (headers) and libraries
>> (static/shared) in a submodule and the primary code base's CMake
>> scripts pull them in as interface targets.
>>
>> This works well and is light-weight but is a pain when upgrading or
>> changing libraries. It's a pain because if I want to upgrade boost, I
>> have to build it up to 6 times (once for each platform and once for
>> each configuration).
>>
>> I've been thinking of a different approach for a while. I've done some
>> toying around with the "Super Build" concept, where I have a separate
>> CMake project that does nothing but use the ExternalProject module to
>> build libraries in real time along with our project. So the order of
>> operations would be as follows (for our automated build server):
>>
>> 1. Clone our "Third Party" repository
>> 2. Use CMake to generate & build the "Super Build" project (this
>> builds boost, openssl, freetype, etc for the current platform).
>> 3. Clone the main code base's repository
>> 4. Use CMake to generate & build, using find_package() to refer to
>> interface targets exported by those third party libraries built in
>> step 2
>>
>> Obviously this will make builds take significantly longer, because
>> we're constantly rebuilding the same third party libraries over and
>> over again. However, it virtually eliminates the maintenance burden
>> for third party libraries because they are built inherently with
>> everything else.
>>
>> Note that I can't refer to pre-built libraries in our build
>> environments because we need very specific control over the versions
>> of our libraries as well as the toolchains that were used to build
>> them. Also we may specifically build our libraries a certain way (such
>> as boost). For this reason we do not rely on our external environment
>> or external package managers to fulfill third party dependencies, like
>> most open source projects do on Linux for example.
>>
>> Does this "Super Build" approach sound like a better idea? What other
>> options are available? The downside with the "Super Build" solution is
>> that it will become very difficult to make the transition between
>> building third party and building our code base seamless. I can't do
>> both in the same generate step because find_package() can't be called
>> until the libraries are built & installed.
>> --
>>
>> 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.

[CMake] Need ideas/opinions on third party library management

[Robert Dailey]

Hello,

There is an internal C++ product at the company I work for which I
have written a series of CMake scripts for. This project actually has
dependencies on several open source libraries, such as boost,
freetype, openssl, etc.

Right now what we do is build each of these third party libraries *by
hand*, once for every platform we support (Windows, Linux x86, Android
NDK). Then we stuff the includes (headers) and libraries
(static/shared) in a submodule and the primary code base's CMake
scripts pull them in as interface targets.

This works well and is light-weight but is a pain when upgrading or
changing libraries. It's a pain because if I want to upgrade boost, I
have to build it up to 6 times (once for each platform and once for
each configuration).

I've been thinking of a different approach for a while. I've done some
toying around with the "Super Build" concept, where I have a separate
CMake project that does nothing but use the ExternalProject module to
build libraries in real time along with our project. So the order of
operations would be as follows (for our automated build server):

1. Clone our "Third Party" repository
2. Use CMake to generate & build the "Super Build" project (this
builds boost, openssl, freetype, etc for the current platform).
3. Clone the main code base's repository
4. Use CMake to generate & build, using find_package() to refer to
interface targets exported by those third party libraries built in
step 2

Obviously this will make builds take significantly longer, because
we're constantly rebuilding the same third party libraries over and
over again. However, it virtually eliminates the maintenance burden
for third party libraries because they are built inherently with
everything else.

Note that I can't refer to pre-built libraries in our build
environments because we need very specific control over the versions
of our libraries as well as the toolchains that were used to build
them. Also we may specifically build our libraries a certain way (such
as boost). For this reason we do not rely on our external environment
or external package managers to fulfill third party dependencies, like
most open source projects do on Linux for example.

Does this "Super Build" approach sound like a better idea? What other
options are available? The downside with the "Super Build" solution is
that it will become very difficult to make the transition between
building third party and building our code base seamless. I can't do
both in the same generate step because find_package() can't be called
until the libraries are built & installed.
-- 

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] Need ideas/opinions on third party library management

[Robert Dailey]

Hello,

There is an internal C++ product at the company I work for which I
have written a series of CMake scripts for. This project actually has
dependencies on several open source libraries, such as boost,
freetype, openssl, etc.

Right now what we do is build each of these third party libraries *by
hand*, once for every platform we support (Windows, Linux x86, Android
NDK). Then we stuff the includes (headers) and libraries
(static/shared) in a submodule and the primary code base's CMake
scripts pull them in as interface targets.

This works well and is light-weight but is a pain when upgrading or
changing libraries. It's a pain because if I want to upgrade boost, I
have to build it up to 6 times (once for each platform and once for
each configuration).

I've been thinking of a different approach for a while. I've done some
toying around with the "Super Build" concept, where I have a separate
CMake project that does nothing but use the ExternalProject module to
build libraries in real time along with our project. So the order of
operations would be as follows (for our automated build server):

1. Clone our "Third Party" repository
2. Use CMake to generate & build the "Super Build" project (this
builds boost, openssl, freetype, etc for the current platform).
3. Clone the main code base's repository
4. Use CMake to generate & build, using find_package() to refer to
interface targets exported by those third party libraries built in
step 2

Obviously this will make builds take significantly longer, because
we're constantly rebuilding the same third party libraries over and
over again. However, it virtually eliminates the maintenance burden
for third party libraries because they are built inherently with
everything else.

Note that I can't refer to pre-built libraries in our build
environments because we need very specific control over the versions
of our libraries as well as the toolchains that were used to build
them. Also we may specifically build our libraries a certain way (such
as boost). For this reason we do not rely on our external environment
or external package managers to fulfill third party dependencies, like
most open source projects do on Linux for example.

Does this "Super Build" approach sound like a better idea? What other
options are available? The downside with the "Super Build" solution is
that it will become very difficult to make the transition between
building third party and building our code base seamless. I can't do
both in the same generate step because find_package() can't be called
until the libraries are built & installed.
-- 

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] Interface targets with their own project in Visual Studio

[Robert Dailey]

On Tue, Jul 19, 2016 at 9:38 AM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> Hello,
>
> I'd like to define an INTERFACE library that has header files only but
> still generates its own project in Visual Studio. The only way to add
> headers to an interface target that I'm aware of is
> target_source_files(), which instead of creating a project it will
> cause the header files themselves to propagate to the actual targets
> that specify the interface target as a link dependency.
>
> Is there a way to change this behavior?
>
> If not, the only workaround I can think of is pretty old-school:
> add_custom_target(), but if I use that I'm not sure I can specify
> include directories and preprocessor definitions that will be
> inherited by dependencies. So it seems like I'm forced to choose one
> or the other.

Anyone have any thoughts on this please?
-- 

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] Interface targets with their own project in Visual Studio

[Robert Dailey]

Hello,

I'd like to define an INTERFACE library that has header files only but
still generates its own project in Visual Studio. The only way to add
headers to an interface target that I'm aware of is
target_source_files(), which instead of creating a project it will
cause the header files themselves to propagate to the actual targets
that specify the interface target as a link dependency.

Is there a way to change this behavior?

If not, the only workaround I can think of is pretty old-school:
add_custom_target(), but if I use that I'm not sure I can specify
include directories and preprocessor definitions that will be
inherited by dependencies. So it seems like I'm forced to choose one
or the other.
-- 

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] Natvis support in Visual Studio

[Robert Dailey]

On Fri, Jul 15, 2016 at 9:05 AM, Brad King  wrote:
>  VS: Add a VS_TOOL_OVERRIDE source file property
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed05f11d

Nice, I wasn't aware that there was already a feature in place to
support this. Given that this exists, is there any point to adding an
explicit code change to support natvis files?

I will install a 3.6.2 nightly build and try out that property. I like
that idea, the only downside is you lose the automatic mapping based
on file extension. I have a simple patch attached that shows the
change I've made to the code. I don't have time ATM to write a unit
test for it, but hopefully you can build onto this if you find it
valuable? Seems the change is simple based on your explanation.


0001-Support-NATVIS-files-in-VS10-generator.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] Natvis support in Visual Studio

[Robert Dailey]

Hello CMake devs,

I'm writing code to support Natvis files in Visual Studio 2015
(earlier versions support this as well, I think).

I found an issue regarding this here (is Kitware officially using
github or gitlab? CMake exists on both):
https://gitlab.kitware.com/cmake/cmake/issues/16043

Corresponding link on mantis (deprecated?):
https://cmake.org/Bug/view.php?id=16043

I have some questions. It's not straightforward on  how to implement
this. In cmVisualStudio10TargetGenerator, there is a WriteAllSources()
function which seems to do 2 main things. It seems to look up things
mapped to object files and call WriteSource() on each of those.
Currently it seems to support C, CXX, MASM, and RC language types.
Then there is WriteExtraSources(), which I can only assume is
"everything else". Is this correct?

If I am correct, would I also be correct to assume that
WriteExtraSource should be the one to set the XML element name
() for *.natvis files based on LANGUAGE being set to NATVIS?
To add to this confusion, cmVisualStudio7Generator::WriteGroup() seems
to do the file extension to LANGUAGE mapping, and I can't tell if the
VS10 generator class is also sharing this code. If it is, do I extend
that function in the VS10 generator class for *.natvis files?
Somewhere I need to be able to automatically set the LANGUAGE property
based on file extension.

Guidance is appreciated!
-- 

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] Convenience version of CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE for INTERFACE_SOURCES

[Robert Dailey]

On Sun, Jul 10, 2016 at 1:23 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> I am exporting/installing a header-only INTERFACE library and I run
> into difficulty with target_sources() because I can't use relative
> paths to the files. So I do this:
>
>
>
> set(project_name fubar)
>
> set(source_files
> myfile.h
> )
>
> # Include dir for installed targets
> set(INCLUDE_DIR include/${project_name}-${upstream_version})
>
> foreach(source_file ${source_files})
> get_filename_component(abs_source_file ${source_file} ABSOLUTE)
> list(APPEND absolute_source_files
> $<BUILD_INTERFACE:${abs_source_file}>
> $<INSTALL_INTERFACE:${INCLUDE_DIR}/${source_file}>
> )
> endforeach()
>
> add_library(${project_name} INTERFACE)
> target_sources(${project_name} INTERFACE ${absolute_source_files})
>
>
>
> Without the separate generator expressions for BUILD_INTERFACE and
> INSTALL_INTERFACE, CMake complains that absolute paths are not inside
> INSTALL_PREFIX in my install() command later:
>
>
>
> CMake Error in CMakeLists.txt:
> Target "better-enums" INTERFACE_SOURCES property contains path:
>
> "C:/code/fubar/myfile.h"
>
> which is prefixed in the source directory.
>
>
>
> Corresponding install() command is:
>
>
> install(TARGETS ${project_name} EXPORT ${project_name}-targets
> INCLUDES DESTINATION ${INCLUDE_DIR}
> )
>
> export(EXPORT ${project_name}-targets
> FILE ${CMAKE_CURRENT_BINARY_DIR}/${project_name}-targets.cmake
> )
>
> install(EXPORT ${project_name}-targets
> FILE ${project_name}-targets.cmake
> DESTINATION ${package_config_dir}
> )
>
> For INTERFACE_INCLUDE_DIRECTORIES, this same problem exists except
> CMake provides a convenience toggle called
> INTERFACE_SYSTEM_INCLUDE_DIRECTORIES. Is there a similar convenience
> for interface sources? Or maybe I'm going about this all the wrong
> way?
>
> Honestly the only reason interface sources are specified is because I
> have a header-only library and I want that header to show up in only
> MY targets during development so I can edit those header files through
> my IDE. I do not expect the header files to appear in targets that
> simply import my target as a dependency.
>
> So it's possible I'm going about this the wrong way. Advice is greatly
> appreciated.

So after I posted this, I made a minor change so that my
INTERFACE_SOURCES property (modified via the target_sources() command)
simply doesn't specify a listing for INSTALL_INTERFACE. Basically only
the BUILD_INTERFACE is populated.

I think this gives me the desired output, since I do not want
downstream targets to inherit my library's public headers in their own
project's file listing. They only get the public include directories
instead.

I still feel like I'm doing things wrong or sub-optimally, so feedback
is still very much appreciated.
-- 

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