Re: [CMake] How to use Ninja on Windows with MSVC?

[Robert Dailey]

Thanks everyone. I fully understand about compilers being on PATH or
setting the CMAKE__COMPILER variables. However, what is really
important is the system introspection done by CMake to find the IDEs
when you select the visual studio generators. I was hoping that logic
could be shared. This would save a lot of work in setting up
environment and/or hunting down vcvars batch files.

On Wed, May 22, 2019 at 10:44 AM Michael Ellery  wrote:
>
>
>
> > On May 22, 2019, at 6:58 AM, Robert Dailey  wrote:
> >
> > From the command line, I want to generate Ninja build scripts that
> > utilize a specific version of MSVC compiler. Basically I'd like the
> > combination of `-G"Visual Studio 15 2017"` with regards to its ability
> > to find the C and C++ compiler on the system via registry/environment
> > variables, and `-G"Ninja"` with regards to it being the build driver
> > for that compiler.
> >
> > Is this even possible?
> > —
>
>
> In addition to the other suggestions about using a MSVC command prompt (which 
> work just fine for manual builds), Here’s what I’ve done when needing to 
> automate the build using powershell:
>
>
> Invoke-BatchFile "${env:ProgramFiles(x86)}\\Microsoft Visual 
> Studio\\2017\\Community\\VC\\Auxiliary\\Build\\vcvarsall.bat" x86_amd64
> Get-ChildItem env:* | Sort-Object name
>
>
> …which invokes the vcvarsall batch and imports all of the environment vars 
> that were set by that invocation. vcvarsall is provided exactly for the 
> purpose of setting your env for building and it supports a few different arch 
> arguments to select the right toolchain.
>
> HTH,
> Mike
>
>
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] How to use Ninja on Windows with MSVC?

[Robert Dailey]

>From the command line, I want to generate Ninja build scripts that
utilize a specific version of MSVC compiler. Basically I'd like the
combination of `-G"Visual Studio 15 2017"` with regards to its ability
to find the C and C++ compiler on the system via registry/environment
variables, and `-G"Ninja"` with regards to it being the build driver
for that compiler.

Is this even possible?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] [cmake-developers] libc++ usage in CMake with Clang?

[Robert Dailey]

On Tue, Aug 21, 2018 at 3:47 PM Craig Scott  wrote:
> Excuse the brevity, but it sounds like you might be looking for the 
> CXX_EXTENSIONS target property (sorry if I've misunderstood your problem, let 
> me know why it isn't appropriate if so). See the following article for a more 
> complete overview of this and related properties:
>
> https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/

Unfortunately that's not the same. Extensions manage C++ language
features and STL capabilities, but -stdlib is for selecting an STL
implementation, AFAIK. Such as GNU STL and LLVM STL (which is libc++
to clang).
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] libc++ usage in CMake with Clang?

[Robert Dailey]

On Tue, Aug 21, 2018 at 3:47 PM Craig Scott  wrote:
> Excuse the brevity, but it sounds like you might be looking for the 
> CXX_EXTENSIONS target property (sorry if I've misunderstood your problem, let 
> me know why it isn't appropriate if so). See the following article for a more 
> complete overview of this and related properties:
>
> https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/

Unfortunately that's not the same. Extensions manage C++ language
features and STL capabilities, but -stdlib is for selecting an STL
implementation, AFAIK. Such as GNU STL and LLVM STL (which is libc++
to clang).
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] libc++ usage in CMake with Clang?

[Robert Dailey]

I'll explain a bit why I'm asking. I noticed that for code bases that
work on Android plus other UNIX platforms, they unconditionally
specify `-stdlib=libc++`, however this doesn't work on Ubuntu by
default, which uses gnu stl + gcc/clang. So  you get compiler errors.
There's no way for me to "search" a platform to see if it is eligible
for the libc++ flag, I simply have to either disable it completely or
conditionally include it based on target platform and/or toolchain.
None of these really address the root cause.

I'm not even really sure what a find module for this would do... but
typically find modules don't provide compiler flags, so I'm not sure
if that's the right tool for the job. Would love to hear from the
developers on this, so I've cross posted to the dev mailing list in
this reply.
On Mon, Aug 20, 2018 at 10:05 PM Thompson, KT  wrote:
>
> I'm also interested in the answer to Robert's question.  I've been using
>
>   set( CMAKE_CXX_FLAGS "${CMAKE_C_FLAGS} -stdlib=libc++")
>
> but it seems like there should be a more elegant approach.
>
> -tk
>
> -Original Message-
> From: CMake  On Behalf Of Robert Dailey
> Sent: Monday, August 20, 2018 11:48 AM
> To: CMake 
> Subject: [CMake] libc++ usage in CMake with Clang?
>
> Is the only way to use libc++ to muck with compile flags? Or is there a 
> proper find module for this or something? Is there a more CMake-esque way of 
> specifying the STL library to use with the toolchain?
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] libc++ usage in CMake with Clang?

[Robert Dailey]

I'll explain a bit why I'm asking. I noticed that for code bases that
work on Android plus other UNIX platforms, they unconditionally
specify `-stdlib=libc++`, however this doesn't work on Ubuntu by
default, which uses gnu stl + gcc/clang. So  you get compiler errors.
There's no way for me to "search" a platform to see if it is eligible
for the libc++ flag, I simply have to either disable it completely or
conditionally include it based on target platform and/or toolchain.
None of these really address the root cause.

I'm not even really sure what a find module for this would do... but
typically find modules don't provide compiler flags, so I'm not sure
if that's the right tool for the job. Would love to hear from the
developers on this, so I've cross posted to the dev mailing list in
this reply.
On Mon, Aug 20, 2018 at 10:05 PM Thompson, KT  wrote:
>
> I'm also interested in the answer to Robert's question.  I've been using
>
>   set( CMAKE_CXX_FLAGS "${CMAKE_C_FLAGS} -stdlib=libc++")
>
> but it seems like there should be a more elegant approach.
>
> -tk
>
> -Original Message-
> From: CMake  On Behalf Of Robert Dailey
> Sent: Monday, August 20, 2018 11:48 AM
> To: CMake 
> Subject: [CMake] libc++ usage in CMake with Clang?
>
> Is the only way to use libc++ to muck with compile flags? Or is there a 
> proper find module for this or something? Is there a more CMake-esque way of 
> specifying the STL library to use with the toolchain?
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] libc++ usage in CMake with Clang?

[Robert Dailey]

Is the only way to use libc++ to muck with compile flags? Or is there
a proper find module for this or something? Is there a more
CMake-esque way of specifying the STL library to use with the
toolchain?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMAKE_C_COMPILER_ARG# not documented?

[Robert Dailey]

On Thu, Jul 19, 2018 at 1:17 PM, Robert Dailey  wrote:
> On Thu, Jul 19, 2018 at 1:13 PM, Robert Dailey  
> wrote:
>> On Thu, Jul 19, 2018 at 1:07 PM, Brad King  wrote:
>>> On 07/19/2018 11:58 AM, Robert Dailey wrote:
>>>> I can't remember where I heard about these CMake variables, but in one
>>>> of my toolchain files I do this:
>>>>
>>>> set( CMAKE_C_COMPILER_ARG1 -m32 )
>>>> set( CMAKE_CXX_COMPILER_ARG1 -m32 )
>>>
>>> They are not documented because they are internal implementation
>>> details.  Projects should not be setting them.
>>
>> I think this was recommended to me because `-m32` had to be the first
>> argument to clang. I'll try to dig up the conversation, I forgot who
>> recommended it and why.
>
> Found it:
> https://cmake.org/pipermail/cmake/2013-March/054161.html
>
> Looks like something Bill Hoffman suggested years ago. I still don't
> remember why I started using it, it was definitely to work around some
> sort of issue. What is the proper, public API solution that gives
> identical functionality? Should I be using `CMAKE_C_COMPILER` instead,
> and appending to it as a string from my toolchain file?
>
> Thanks in advance.

Looking at the docs a bit closer, it seems like this is the better solution:

set( CMAKE_C_FLAGS_INIT -m32 )
set( CMAKE_CXX_FLAGS_INIT -m32 )

Not sure if you'd agree, but at least I can verify it is 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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMAKE_C_COMPILER_ARG# not documented?

[Robert Dailey]

On Thu, Jul 19, 2018 at 1:13 PM, Robert Dailey  wrote:
> On Thu, Jul 19, 2018 at 1:07 PM, Brad King  wrote:
>> On 07/19/2018 11:58 AM, Robert Dailey wrote:
>>> I can't remember where I heard about these CMake variables, but in one
>>> of my toolchain files I do this:
>>>
>>> set( CMAKE_C_COMPILER_ARG1 -m32 )
>>> set( CMAKE_CXX_COMPILER_ARG1 -m32 )
>>
>> They are not documented because they are internal implementation
>> details.  Projects should not be setting them.
>
> I think this was recommended to me because `-m32` had to be the first
> argument to clang. I'll try to dig up the conversation, I forgot who
> recommended it and why.

Found it:
https://cmake.org/pipermail/cmake/2013-March/054161.html

Looks like something Bill Hoffman suggested years ago. I still don't
remember why I started using it, it was definitely to work around some
sort of issue. What is the proper, public API solution that gives
identical functionality? Should I be using `CMAKE_C_COMPILER` instead,
and appending to it as a string from my toolchain file?

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMAKE_C_COMPILER_ARG# not documented?

[Robert Dailey]

On Thu, Jul 19, 2018 at 1:07 PM, Brad King  wrote:
> On 07/19/2018 11:58 AM, Robert Dailey wrote:
>> I can't remember where I heard about these CMake variables, but in one
>> of my toolchain files I do this:
>>
>> set( CMAKE_C_COMPILER_ARG1 -m32 )
>> set( CMAKE_CXX_COMPILER_ARG1 -m32 )
>
> They are not documented because they are internal implementation
> details.  Projects should not be setting them.

I think this was recommended to me because `-m32` had to be the first
argument to clang. I'll try to dig up the conversation, I forgot who
recommended it and why.
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] CMAKE_C_COMPILER_ARG# not documented?

[Robert Dailey]

I can't remember where I heard about these CMake variables, but in one
of my toolchain files I do this:

set( CMAKE_C_COMPILER_ARG1 -m32 )
set( CMAKE_CXX_COMPILER_ARG1 -m32 )

On the [cmake variables][1] page, these are not documented. I expected
an entry somewhere like `CMAKE__COMPILER_ARG<#>` but there isn't
one. Are these documented? If so, where? If not, I'll create an issue
on the gitlab project page to make sure that gets done at some point.
I would offer to do it but I'm not too sure what the variables do
myself, nor am I sure what the upper limit for ARG is.

[1]: https://cmake.org/cmake/help/latest/manual/cmake-variables.7.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:
https://cmake.org/mailman/listinfo/cmake-developers

[CMake] Parallel builds and auto generated header files

[Robert Dailey]

I have a Version.hpp file that I have a custom command tied to which
basically runs CMake in script mode to perform configure_file() on it
during build time. The reason it does this is because it builds
Version.hpp using dynamic information, such as defining a macro with
the current SHA1 being built, etc.

I notice in parallel builds, this header file gets built too late,
because of parallel builds. What if a file includes the header and its
translation unit is built before Version.hpp is generated by the
custom command? Would it be better/simpler to do configure_file() at
configuration time instead of at build time as a custom command?
Here's the logic (some variables are defined elsewhere, but should
give you the gist):


set( generated_source_dir ${CMAKE_CURRENT_BINARY_DIR}/Source )
set( version_file_in  ${CMAKE_CURRENT_SOURCE_DIR}/Version.cpp.in )
set( version_file_out ${generated_source_dir}/Main/Version.cpp )

add_custom_command(
OUTPUT ${version_file_out}
COMMAND ${CMAKE_COMMAND}
-D IN_FILE=${version_file_in}
-D OUT_FILE=${version_file_out}
-D GIT_EXECUTABLE=${GIT_EXECUTABLE}
-D BUILD_VERSION=${ZIOSK_BUILD_VERSION}
-P ${CMAKE_CURRENT_SOURCE_DIR}/build_version_header.cmake
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
)

source_group( Generated FILES ${version_file_out} )
list( APPEND source_files ${version_file_out} )
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Building cmake QtDialog: Can't find QT 5.11.1

[Robert Dailey]

I have QT 5.11.1 installed, I used the open source installer. It did
install msvc2015 32-bit libs but not 2017. Google search shows that
2015 is ABI compatible so CMake should use that.

When I generate the CMake project, it says it can't find QT version
4.x. How do I build CMake with the GUI application using the version
of QT I have installed? QT installed at C:\QT
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] C# targets and content source files

[Robert Dailey]

In Visual Studio, I can add *.ico files to my C# project and in the
CSPROJ XML, it shows up as a  element. Is this supported in
CMake for CSharp targets?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Link element in C# project causing issues with binary dir

[Robert Dailey]

Submitted a fix here:
https://gitlab.kitware.com/cmake/cmake/merge_requests/2177

David: I think the source dir is stripped because that path is
effectively the same as source_group() command. It's a path relative
to the root of the solution explorer panel. That's a big assumption, I
honestly don't know what the inner workings of the CSPROJ file are.

 Yes, they are sibling directories

On Fri, Jun 29, 2018 at 3:37 PM, David Cole  wrote:
> The code looks wrong like this, too:
>
> You shouldn't strip the source directory from the path of the file
> name unless the character after the source directory is "/" or "\\",
> should you? If the thing you're trying to end up with is a path name
> to the file under the source directory, then this is incorrect in this
> case.
>
> I'm guessing you have "layout-composer" and "layout-composer-build" as
> sibling directories of each other?
>
>
>
> On Fri, Jun 29, 2018 at 4:12 PM Robert Dailey  
> wrote:
>>
>> According to the code, the logic is wrong:
>>
>> void cmVisualStudio10TargetGenerator::GetCSharpSourceLink(
>>   cmSourceFile const* sf, std::string& link)
>> {
>>   std::string f = sf->GetFullPath();
>>   if (!this->InSourceBuild) {
>> const std::string stripFromPath =
>>   this->Makefile->GetCurrentSourceDirectory();
>> if (f.find(stripFromPath) != std::string::npos) {
>>   link = f.substr(stripFromPath.length() + 1);
>>   if (const char* l = sf->GetProperty("VS_CSHARP_Link")) {
>> link = l;
>>   }
>>   ConvertToWindowsSlash(link);
>> }
>>   }
>> }
>>
>>
>> It's checking if the whole binary dir is rooted where source dir is,
>> instead it should be checking each file to see if they are descendents
>> of CMAKE_BINARY_DIR, and if so, use the , otherwise don't use
>> it. This allows  to be variable between files in the project.
>>
>> Does anyone know if there's already a function in CMake for checking
>> if a file is in the CMAKE_BINARY_DIR? Or do I have to write my own
>> code for that check?
>>
>> On Fri, Jun 29, 2018 at 3:08 PM, Robert Dailey  
>> wrote:
>> > When I use configure_file() to generate AssemblyInfo.cs, which I allow
>> > to go to the CMAKE_CURRENT_BINARY_DIR, Visual Studio 2017 reports:
>> >
>> > Warning The file
>> > 'E:\code\layout-composer-build\Properties\AssemblyInfo.cs' could not
>> > be added to the project.  Cannot add a link to the file
>> > E:\code\layout-composer-build\Properties\AssemblyInfo.cs. This file is
>> > within the project directory tree.
>> >
>> > When I define a target using C# language, it adds this for files under
>> > the same directory as the generated CSPROJ file:
>> >
>> > > > Include="E:\code\layout-composer-build\Properties\AssemblyInfo.cs">
>> >   build\Properties\AssemblyInfo.cs
>> > 
>> >
>> > The CSPROJ file is located: 
>> > E:\code\layout-composer-build\LayoutComposer.csproj
>> >
>> > Is there a way to make the  element not needed in this scenario?
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: 
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more 
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at 
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Link element in C# project causing issues with binary dir

[Robert Dailey]

According to the code, the logic is wrong:

void cmVisualStudio10TargetGenerator::GetCSharpSourceLink(
  cmSourceFile const* sf, std::string& link)
{
  std::string f = sf->GetFullPath();
  if (!this->InSourceBuild) {
const std::string stripFromPath =
  this->Makefile->GetCurrentSourceDirectory();
if (f.find(stripFromPath) != std::string::npos) {
  link = f.substr(stripFromPath.length() + 1);
  if (const char* l = sf->GetProperty("VS_CSHARP_Link")) {
link = l;
  }
  ConvertToWindowsSlash(link);
}
  }
}


It's checking if the whole binary dir is rooted where source dir is,
instead it should be checking each file to see if they are descendents
of CMAKE_BINARY_DIR, and if so, use the , otherwise don't use
it. This allows  to be variable between files in the project.

Does anyone know if there's already a function in CMake for checking
if a file is in the CMAKE_BINARY_DIR? Or do I have to write my own
code for that check?

On Fri, Jun 29, 2018 at 3:08 PM, Robert Dailey  wrote:
> When I use configure_file() to generate AssemblyInfo.cs, which I allow
> to go to the CMAKE_CURRENT_BINARY_DIR, Visual Studio 2017 reports:
>
> Warning The file
> 'E:\code\layout-composer-build\Properties\AssemblyInfo.cs' could not
> be added to the project.  Cannot add a link to the file
> E:\code\layout-composer-build\Properties\AssemblyInfo.cs. This file is
> within the project directory tree.
>
> When I define a target using C# language, it adds this for files under
> the same directory as the generated CSPROJ file:
>
> 
>   build\Properties\AssemblyInfo.cs
> 
>
> The CSPROJ file is located: 
> E:\code\layout-composer-build\LayoutComposer.csproj
>
> Is there a way to make the  element not needed in this scenario?
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Link element in C# project causing issues with binary dir

[Robert Dailey]

When I use configure_file() to generate AssemblyInfo.cs, which I allow
to go to the CMAKE_CURRENT_BINARY_DIR, Visual Studio 2017 reports:

Warning The file
'E:\code\layout-composer-build\Properties\AssemblyInfo.cs' could not
be added to the project.  Cannot add a link to the file
E:\code\layout-composer-build\Properties\AssemblyInfo.cs. This file is
within the project directory tree.

When I define a target using C# language, it adds this for files under
the same directory as the generated CSPROJ file:


  build\Properties\AssemblyInfo.cs


The CSPROJ file is located: E:\code\layout-composer-build\LayoutComposer.csproj

Is there a way to make the  element not needed in this scenario?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] 3.12.0-rc1: C# project outputting as a "vcxproj" (C++ project)

[Robert Dailey]

I'm happy to do that. I assume you would require an MCVE for that bug?
If so it will take me considerably longer, as I don't have a lot of
time to build a reproducible example from scratch. I'll do my best,
though.

On Tue, Jun 26, 2018 at 10:06 AM, Brad King  wrote:
> On 06/26/2018 10:25 AM, Robert Dailey wrote:
>> To fix this issue for now I had to do this:
>>
>> set_property( TARGET ${project_name} PROPERTY LINKER_LANGUAGE CSharp 
>> )
>>
>> I don't remember having to explicitly tell CMake that the project is
>> CSharp in the past; it was always able to deduce it before. Is this
>> considered a symptom of a bug? Or is this required behavior? To be
>> honest, I'm not sure what criteria is used by CMake to deduce the
>> linker language of targets, especially in the C# case. It appears that
>> introducing a link-level dependency from a C# project to a Managed C++
>> project, forces the parent project to be C++ as well.
>
> Please open an issue for that.
>
> 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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] 3.12.0-rc1: C# project outputting as a "vcxproj" (C++ project)

[Robert Dailey]

To fix this issue for now I had to do this:

set_property( TARGET ${project_name} PROPERTY LINKER_LANGUAGE CSharp )

I don't remember having to explicitly tell CMake that the project is
CSharp in the past; it was always able to deduce it before. Is this
considered a symptom of a bug? Or is this required behavior? To be
honest, I'm not sure what criteria is used by CMake to deduce the
linker language of targets, especially in the C# case. It appears that
introducing a link-level dependency from a C# project to a Managed C++
project, forces the parent project to be C++ as well.

On Tue, Jun 26, 2018 at 9:12 AM, Robert Dailey  wrote:
> Using 3.12.0-rc1, if I create a C# project, but use
> `target_link_libraries` on it to pull in a dependency to a managed C++
> target, the C# project turns into a "vcxproj" after generation,
> whereas if I remove the "target_link_libraries()" call, it outputs as
> a "csproj" as I expect.
>
> Is this a known issue? Am I doing something wrong or is this a bug? I
> plan to spend some time debugging this in CMake if I get a chance.
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] 3.12.0-rc1: C# project outputting as a "vcxproj" (C++ project)

[Robert Dailey]

Using 3.12.0-rc1, if I create a C# project, but use
`target_link_libraries` on it to pull in a dependency to a managed C++
target, the C# project turns into a "vcxproj" after generation,
whereas if I remove the "target_link_libraries()" call, it outputs as
a "csproj" as I expect.

Is this a known issue? Am I doing something wrong or is this a bug? I
plan to spend some time debugging this in CMake if I get a chance.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Performance profiling for CMake scripts?

[Robert Dailey]

I set my minimum required version to 3.6, which should enable those
policies by default (if they're truly in 3.1 as you indicated).

My CMake scripts do a lot of work to build a "tree" of properties
connecting targets, so that I can recurse the targets my system
generates to process things. CMake does not natively offer the ability
to recurse targets created AFAIK. I suspect a lot of this logic is
what is causing the slow down, but at this point I have no tooling to
help me prove that.

I have included the developer list, maybe the CMake developers have
some insight for me as this doesn't seem to be a common user issue
from what I can tell.

On Wed, Jun 20, 2018 at 7:39 AM, Robert Maynard
 wrote:
> I am not aware of any built in functionality that can generate
> performance numbers for a project.
>
> Have you made sure that the performance/parsing policies are set to
> NEW or your cmake_minimum_required is sufficiently high, those can
> have a significant improvement on configuration time.
>
> Polices ( both in CMake 3.1 )
>  - CMP0054 'if parsing'
>  - CMP0053 'simplified variable reference and escape parsing'
>
> On Tue, Jun 19, 2018 at 2:12 PM Robert Dailey  
> wrote:
>>
>> So I noticed over the years my CMake scripts take longer and longer to
>> configure/generate. Is there a mechanism to tell which parts of my
>> CMake scripts are slowest? I'd like to know how to optimize my CMake
>> scripts to reduce the time it takes to generate projects.
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: 
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more 
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at 
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] Performance profiling for CMake scripts?

[Robert Dailey]

I set my minimum required version to 3.6, which should enable those
policies by default (if they're truly in 3.1 as you indicated).

My CMake scripts do a lot of work to build a "tree" of properties
connecting targets, so that I can recurse the targets my system
generates to process things. CMake does not natively offer the ability
to recurse targets created AFAIK. I suspect a lot of this logic is
what is causing the slow down, but at this point I have no tooling to
help me prove that.

I have included the developer list, maybe the CMake developers have
some insight for me as this doesn't seem to be a common user issue
from what I can tell.

On Wed, Jun 20, 2018 at 7:39 AM, Robert Maynard
 wrote:
> I am not aware of any built in functionality that can generate
> performance numbers for a project.
>
> Have you made sure that the performance/parsing policies are set to
> NEW or your cmake_minimum_required is sufficiently high, those can
> have a significant improvement on configuration time.
>
> Polices ( both in CMake 3.1 )
>  - CMP0054 'if parsing'
>  - CMP0053 'simplified variable reference and escape parsing'
>
> On Tue, Jun 19, 2018 at 2:12 PM Robert Dailey  
> wrote:
>>
>> So I noticed over the years my CMake scripts take longer and longer to
>> configure/generate. Is there a mechanism to tell which parts of my
>> CMake scripts are slowest? I'd like to know how to optimize my CMake
>> scripts to reduce the time it takes to generate projects.
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: 
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more 
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at 
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] Performance profiling for CMake scripts?

[Robert Dailey]

So I noticed over the years my CMake scripts take longer and longer to
configure/generate. Is there a mechanism to tell which parts of my
CMake scripts are slowest? I'd like to know how to optimize my CMake
scripts to reduce the time it takes to generate projects.
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] How to make RUN_TESTS build projects first?

[Robert Dailey]

I'd like RUN_TESTS to build the executable targets that are tied to
add_test() commands prior to running the tests themselves. Note I'm
doing this from within Visual Studio. Is there a way I can set up
CMake to do 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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] How to obtain a list of target dependencies

[Robert Dailey]

I'm going to add the CMake Dev group as well, since I asked this same
question last year around May and I didn't get any response. Hoping
for some help this time around. I don't see anything documented, so
maybe the developers know the best approach here.

On Mon, Mar 12, 2018 at 3:03 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> Sometimes I need to manually take action on the dependencies of my
> targets. Without keeping track of the dependencies externally using
> global or custom target properties, is there a way to obtain the list
> of targets that a target depends on? This would be the same list of
> targets passed to `target_link_libraries()`. For bonus points I'd like
> a flattened list of transitive dependencies, to avoid recursively
> building this list myself.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] How to obtain a list of target dependencies

[Robert Dailey]

I'm going to add the CMake Dev group as well, since I asked this same
question last year around May and I didn't get any response. Hoping
for some help this time around. I don't see anything documented, so
maybe the developers know the best approach here.

On Mon, Mar 12, 2018 at 3:03 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> Sometimes I need to manually take action on the dependencies of my
> targets. Without keeping track of the dependencies externally using
> global or custom target properties, is there a way to obtain the list
> of targets that a target depends on? This would be the same list of
> targets passed to `target_link_libraries()`. For bonus points I'd like
> a flattened list of transitive dependencies, to avoid recursively
> building this list myself.
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] How to obtain a list of target dependencies

[Robert Dailey]

Sometimes I need to manually take action on the dependencies of my
targets. Without keeping track of the dependencies externally using
global or custom target properties, is there a way to obtain the list
of targets that a target depends on? This would be the same list of
targets passed to `target_link_libraries()`. For bonus points I'd like
a flattened list of transitive dependencies, to avoid recursively
building this list myself.
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] Confusion with range-based FOREACH logic

[Robert Dailey]

I am doing the following:

```
set( CS_THIRD_PARTY_REFERENCES
Iconic.Zip ${CMAKE_CURRENT_SOURCE_DIR}/DotNetZip/Iconic.Zip.dll
)

if( CS_THIRD_PARTY_REFERENCES )
list( LENGTH CS_THIRD_PARTY_REFERENCES len )
message( STATUS "len: ${len}" )
foreach( i RANGE 0 ${len} 2 )
message( STATUS "i: ${i}" )
list( GET CS_THIRD_PARTY_REFERENCES ${i} assembly_name )
math( EXPR i "${i}+1" )
list( GET CS_THIRD_PARTY_REFERENCES ${i} assembly_path )
set_property( TARGET ${target_name} PROPERTY
VS_DOTNET_REFERENCE_${assembly_name} ${assembly_path}
)
message( STATUS "i: ${i}" )
message( STATUS "assembly_name: ${assembly_name}" )
message( STATUS "assembly_path: ${assembly_path}" )
endforeach()
endif()
```

I am finding that the foreach() loops 2 times when ${len} is 2. What I
expect during the 2nd iteration is that it does ${i}+STEP (0+2) which
would equal 2, and so long as 2<${len} (2<2), then it would continue
to iterate. In this case, it should stop after the first iteration.
I'm thinking that this should work like a C++ for loop. Is this not
the case? How should I be iterating over a list of 2 times at a time?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] project() with ASM fails with MSVC 19

[Robert Dailey]

Also, I am using the "Visual Studio 15 2017" generator with no other
options (generating through cmake-gui on Windows)

On Tue, Sep 12, 2017 at 1:33 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> Using CMake 3.9, I do this:
>
> cmake_minimum_required(VERSION 3.9)
> project(libpng VERSION 1.6.33 LANGUAGES ASM C)
>
> I get the following error:
>
> -- The ASM compiler identification is unknown
> -- Didn't find assembler
> -- The C compiler identification is MSVC 19.11.25507.1
> CMake Error at CMakeLists.txt:16 (project):
> No CMAKE_ASM_COMPILER could be found.
>
>
> Why doesn't this work?
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] project() with ASM fails with MSVC 19

[Robert Dailey]

Using CMake 3.9, I do this:

cmake_minimum_required(VERSION 3.9)
project(libpng VERSION 1.6.33 LANGUAGES ASM C)

I get the following error:

-- The ASM compiler identification is unknown
-- Didn't find assembler
-- The C compiler identification is MSVC 19.11.25507.1
CMake Error at CMakeLists.txt:16 (project):
No CMAKE_ASM_COMPILER could be found.


Why doesn't this work?
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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 maintain compatibility with earlier versions?

[Robert Dailey]

So typically my setup is that I have the newest CMake installed, but
am working with projects that set cmake_minimum_required to something
like version 2.8. Will version 3.9 of CMake prevent me from using
features that were introduced after 2.8? How can I make sure that
someone with *actual* version 2.8 installed will not run into
errors/issues?
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] configuration packages, IMPORTED targets, and global scope

[Robert Dailey]

Thanks, I am watching that discussion and will try to contribute where I can.

On Thu, Sep 7, 2017 at 4:02 AM, Deniz Bahadir <dbaha...@benocs.com> wrote:
> Am 06.09.2017 um 20:24 schrieb Robert Dailey:
>>
>> So it took me a while to figure out why find_package() calls I was
>> making (with CONFIG) option were not accessible outside of the
>> directory in which it was invoked. I realized that all targets seem to
>> be global by default except IMPORTED targets (according to
>> add_library() docs). I find this counterintuitive, since I expect
>> imported targets to behave the same as normal ones WRT scope.
>>
>> Is there a reason that imported targets need to be explicitly made GLOBAL?
>>
>> Barring that, I'd like to find some way to make find_package() convert
>> those imported targets to global. I don't see a target property I can
>> set or a command I can call to make an existing imported target a
>> global one. Any thoughts on workarounds? If there are none, are there
>> some changes we could make to CMake to support this behavior?
>
>
> Just a two days ago I created an issue for this:
> https://gitlab.kitware.com/cmake/cmake/issues/17256
>
> It would probably help if you participate in that discussion.
>
>> My use case is that I have a subdirectory I step into, which builds
>> various third party libraries and then follows up with a
>> find_package() call. I do this in a isolated but central place because
>> I have to set up various variables like CMAKE_PREFIX_PATH and many
>> others to isolate searches to a controlled location. Beyond this, if a
>> target needs one of these third party libs, the expectation is that
>> they only have to do target_link_libraries() with the import target
>> names to use those libs. However, because they are out of scope, they
>> can't use them.
>>
>
> HTH,
> Deniz
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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] Configuration packages & versioning for parallel installations

[Robert Dailey]

First obvious question is: Should this even be a concern? The
cmake-packages documentation doesn't really touch on versioning, but
there are a couple of concerns I see when you want users to be able to
install (with CMake) multiple versions of the same library
side-by-side:

1. The library files have to use VERSION or SOVERSION properties to
affect their name (this needs to be consistent on all platforms)
2. Debug configurations should alter the name of the library (to
support multi-configuration generators like Visual Studio, for the
most part, but also useful to single-configuration generators)
3. Header file installation: How do you do versioning? How do you have
a foo.h that is version 1.0, and a foo.h that is version 2.0? Does
this even make sense?

One approach I've taken so far is:

1. CMake scripts like config scripts and exported target scripts go
under "share/libraryname-1.0/cmake"
2. Library names follow a format like "libfoo-1.0.0", or
"libfoo-1.0.0-debug" for debug versions of that same library.

I have no answer for include files.
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] configuration packages, IMPORTED targets, and global scope

[Robert Dailey]

So it took me a while to figure out why find_package() calls I was
making (with CONFIG) option were not accessible outside of the
directory in which it was invoked. I realized that all targets seem to
be global by default except IMPORTED targets (according to
add_library() docs). I find this counterintuitive, since I expect
imported targets to behave the same as normal ones WRT scope.

Is there a reason that imported targets need to be explicitly made GLOBAL?

Barring that, I'd like to find some way to make find_package() convert
those imported targets to global. I don't see a target property I can
set or a command I can call to make an existing imported target a
global one. Any thoughts on workarounds? If there are none, are there
some changes we could make to CMake to support this behavior?

My use case is that I have a subdirectory I step into, which builds
various third party libraries and then follows up with a
find_package() call. I do this in a isolated but central place because
I have to set up various variables like CMAKE_PREFIX_PATH and many
others to isolate searches to a controlled location. Beyond this, if a
target needs one of these third party libs, the expectation is that
they only have to do target_link_libraries() with the import target
names to use those libs. However, because they are out of scope, they
can't use them.
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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 should config packages handle components?

[Robert Dailey]

In the case where I'm exporting 1 target.cmake script per component
for a single package, could someone provide an example on how to
manage dependencies? There are 2 types of dependencies:

1. Dependencies on external packages
2. Cross-dependencies within the same package (i.e. on other
components in the same package)

The cmake-packages doc kind of goes over #1, but #2 doesn't seem to
have examples.

On Fri, Sep 1, 2017 at 1:21 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> First of all, I want to apologize for including the developer list.
> Maybe I'm not being patient enough, but it seems like every post I've
> made on the normal users list doesn't get any attention.
>
> Secondly, the cmake-packages portion of the cmake documentation
> doesn't go into a ton of detail about components, but it does give an
> example towards the bottom of how you export targets for components.
> This leads to my questions:
>
> When defining the target exports via install(TARGET foo EXPORT
> foo-export), is it recommended for all components to collectively
> export as 1 target.cmake script? Or is it better to have 1
> target.cmake script per component? If we use Boost as an example, the
> latter would mean having:
>
> boost-config.cmake
> boost-target-filesystem.cmake
> boost-target-thread.cmake
> ...etc...
>
> This means that boost-config.cmake would "include()" only the relevant
> target cmake scripts based on the provided COMPONENTS list, I assume?
>
> Which is the better approach here and why?
>
> One problem I thought of with the former (one big target.cmake with
> all import targets in there) is that if you only ask for a subset of
> components in find_package(), you will still get all of them since all
> imports are defined in a single file. Does this go against any design
> principles? Assuming this really happens, are there any negative side
> effects?
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] How should config packages handle components?

[Robert Dailey]

In the case where I'm exporting 1 target.cmake script per component
for a single package, could someone provide an example on how to
manage dependencies? There are 2 types of dependencies:

1. Dependencies on external packages
2. Cross-dependencies within the same package (i.e. on other
components in the same package)

The cmake-packages doc kind of goes over #1, but #2 doesn't seem to
have examples.

On Fri, Sep 1, 2017 at 1:21 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> First of all, I want to apologize for including the developer list.
> Maybe I'm not being patient enough, but it seems like every post I've
> made on the normal users list doesn't get any attention.
>
> Secondly, the cmake-packages portion of the cmake documentation
> doesn't go into a ton of detail about components, but it does give an
> example towards the bottom of how you export targets for components.
> This leads to my questions:
>
> When defining the target exports via install(TARGET foo EXPORT
> foo-export), is it recommended for all components to collectively
> export as 1 target.cmake script? Or is it better to have 1
> target.cmake script per component? If we use Boost as an example, the
> latter would mean having:
>
> boost-config.cmake
> boost-target-filesystem.cmake
> boost-target-thread.cmake
> ...etc...
>
> This means that boost-config.cmake would "include()" only the relevant
> target cmake scripts based on the provided COMPONENTS list, I assume?
>
> Which is the better approach here and why?
>
> One problem I thought of with the former (one big target.cmake with
> all import targets in there) is that if you only ask for a subset of
> components in find_package(), you will still get all of them since all
> imports are defined in a single file. Does this go against any design
> principles? Assuming this really happens, are there any negative side
> effects?
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Should configuration package files define module package variables?

[Robert Dailey]

On Sat, Sep 2, 2017 at 3:08 AM, P F  wrote:
> In general, if the library does not have any dependencies, you can just 
> export the targets directly to the config.cmake file:
>
> install(TARGETS foo EXPORT foo-config)
> install(EXPORT foo-config DESTINATION lib/cmake/foo)
>
> However, if the library has dependencies, you will need to iterate over them 
> in the config.cmake file. That is if `foo` uses zlib, like this:
>
> find_package(ZLIB)
> target_link_libraries(foo ZLIB::ZLIB)
>
> Then the foo-config.cmake needs to do this(assuming the export targets are 
> written to foo-targets):
>
> include(CMakeFindDependencyMacro)
> find_dependency(ZLIB)
> include("${CMAKE_CURRENT_LIST_DIR}/foo-targets.cmake”)
>
> The reason for this is that the imported foo target will link against 
> ZLIB::ZLIB, but it will not define it. Actually, the generated 
> foo-targets.cmake will create an error if ZLIB::ZLIB doesn’t exists, which is 
> why `find_dependency(ZLIB)`(which is really just `find_package` underneath) 
> needs to be called before including the foo-targets.cmake.

When you throw components in the mix, where you have 1 targets.cmake
exported per component, each may have its own find_dependency()
requirements. It would be nice if that was self-contained in the
targets.cmake script itself, but there's no examples I could find on
how to manage per-component find dependencies like this, especially if
those components are put into `OPTIONAL_COMPONENTS`.

Thanks for the information, it is very helpful!
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Should configuration package files define module package variables?

[Robert Dailey]

On Sat, Sep 2, 2017 at 3:08 AM, P F  wrote:
> In general, if the library does not have any dependencies, you can just 
> export the targets directly to the config.cmake file:
>
> install(TARGETS foo EXPORT foo-config)
> install(EXPORT foo-config DESTINATION lib/cmake/foo)
>
> However, if the library has dependencies, you will need to iterate over them 
> in the config.cmake file. That is if `foo` uses zlib, like this:
>
> find_package(ZLIB)
> target_link_libraries(foo ZLIB::ZLIB)
>
> Then the foo-config.cmake needs to do this(assuming the export targets are 
> written to foo-targets):
>
> include(CMakeFindDependencyMacro)
> find_dependency(ZLIB)
> include("${CMAKE_CURRENT_LIST_DIR}/foo-targets.cmake”)
>
> The reason for this is that the imported foo target will link against 
> ZLIB::ZLIB, but it will not define it. Actually, the generated 
> foo-targets.cmake will create an error if ZLIB::ZLIB doesn’t exists, which is 
> why `find_dependency(ZLIB)`(which is really just `find_package` underneath) 
> needs to be called before including the foo-targets.cmake.

When you throw components in the mix, where you have 1 targets.cmake
exported per component, each may have its own find_dependency()
requirements. It would be nice if that was self-contained in the
targets.cmake script itself, but there's no examples I could find on
how to manage per-component find dependencies like this, especially if
those components are put into `OPTIONAL_COMPONENTS`.

Thanks for the information, it is very helpful!
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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-developers] How should config packages handle components?

[Robert Dailey]

On Fri, Sep 1, 2017 at 1:40 PM, Alex Turbov <i.za...@gmail.com> wrote:
> Hi Robert,
>
>
> On Fri, Sep 1, 2017 at 9:21 PM, Robert Dailey <rcdailey.li...@gmail.com>
> wrote:
>>
>>
>> One problem I thought of with the former (one big target.cmake with
>> all import targets in there) is that if you only ask for a subset of
>> components in find_package(), you will still get all of them since all
>> imports are defined in a single file.
>
>
> In my project I have a bunch of components and do one exported target per
> component
> exactly by the mentioned reason -- user didn't ask for others...
>
>>
>> Does this go against any design
>> principles?
>
>
> As far as I know, there are no clear design principles :) (yet, at least
> nowadays) -- at least doing
> a lot of CMake projects since 2009, I've never seen an explicit list of them
> %)
> IMHO, there is a lack of "official guildelines" (or it is really hard to
> search for 'em)
>
>> Assuming this really happens, are there any negative side
>> effects?
>
>
> I could see the impact on build time only in this case... and for me the
> most obvious is increasing
> time to process the lists (which is for some reasons really slow on Windows,
> at least in our
> build farm which uses vargant and VirtualBox images)
> (but I don't have any particular numbers, cuz never implemented the first
> approach)

Thanks for the quick response. The "official guidelines" or "package
standard" is really exactly what we need I think. What worries me the
most is that it seems like this is deep knowledge that is stuck in the
brains of folks like Brad King and David Cole. I think somehow getting
a knowledge dump from them into a documentation page would be a
valuable task. I think for something as complex and variable as
packages in CMake (install process in general) deserves some
standardization, because we need the ability to distinguish between
practices that we should follow for legacy (backward compatibility)
reasons, non-cmake project reasons, and fully "modern" cmake packages.
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] How should config packages handle components?

[Robert Dailey]

On Fri, Sep 1, 2017 at 1:40 PM, Alex Turbov <i.za...@gmail.com> wrote:
> Hi Robert,
>
>
> On Fri, Sep 1, 2017 at 9:21 PM, Robert Dailey <rcdailey.li...@gmail.com>
> wrote:
>>
>>
>> One problem I thought of with the former (one big target.cmake with
>> all import targets in there) is that if you only ask for a subset of
>> components in find_package(), you will still get all of them since all
>> imports are defined in a single file.
>
>
> In my project I have a bunch of components and do one exported target per
> component
> exactly by the mentioned reason -- user didn't ask for others...
>
>>
>> Does this go against any design
>> principles?
>
>
> As far as I know, there are no clear design principles :) (yet, at least
> nowadays) -- at least doing
> a lot of CMake projects since 2009, I've never seen an explicit list of them
> %)
> IMHO, there is a lack of "official guildelines" (or it is really hard to
> search for 'em)
>
>> Assuming this really happens, are there any negative side
>> effects?
>
>
> I could see the impact on build time only in this case... and for me the
> most obvious is increasing
> time to process the lists (which is for some reasons really slow on Windows,
> at least in our
> build farm which uses vargant and VirtualBox images)
> (but I don't have any particular numbers, cuz never implemented the first
> approach)

Thanks for the quick response. The "official guidelines" or "package
standard" is really exactly what we need I think. What worries me the
most is that it seems like this is deep knowledge that is stuck in the
brains of folks like Brad King and David Cole. I think somehow getting
a knowledge dump from them into a documentation page would be a
valuable task. I think for something as complex and variable as
packages in CMake (install process in general) deserves some
standardization, because we need the ability to distinguish between
practices that we should follow for legacy (backward compatibility)
reasons, non-cmake project reasons, and fully "modern" cmake packages.
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] How should config packages handle components?

[Robert Dailey]

First of all, I want to apologize for including the developer list.
Maybe I'm not being patient enough, but it seems like every post I've
made on the normal users list doesn't get any attention.

Secondly, the cmake-packages portion of the cmake documentation
doesn't go into a ton of detail about components, but it does give an
example towards the bottom of how you export targets for components.
This leads to my questions:

When defining the target exports via install(TARGET foo EXPORT
foo-export), is it recommended for all components to collectively
export as 1 target.cmake script? Or is it better to have 1
target.cmake script per component? If we use Boost as an example, the
latter would mean having:

boost-config.cmake
boost-target-filesystem.cmake
boost-target-thread.cmake
...etc...

This means that boost-config.cmake would "include()" only the relevant
target cmake scripts based on the provided COMPONENTS list, I assume?

Which is the better approach here and why?

One problem I thought of with the former (one big target.cmake with
all import targets in there) is that if you only ask for a subset of
components in find_package(), you will still get all of them since all
imports are defined in a single file. Does this go against any design
principles? Assuming this really happens, are there any negative side
effects?
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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 should config packages handle components?

[Robert Dailey]

First of all, I want to apologize for including the developer list.
Maybe I'm not being patient enough, but it seems like every post I've
made on the normal users list doesn't get any attention.

Secondly, the cmake-packages portion of the cmake documentation
doesn't go into a ton of detail about components, but it does give an
example towards the bottom of how you export targets for components.
This leads to my questions:

When defining the target exports via install(TARGET foo EXPORT
foo-export), is it recommended for all components to collectively
export as 1 target.cmake script? Or is it better to have 1
target.cmake script per component? If we use Boost as an example, the
latter would mean having:

boost-config.cmake
boost-target-filesystem.cmake
boost-target-thread.cmake
...etc...

This means that boost-config.cmake would "include()" only the relevant
target cmake scripts based on the provided COMPONENTS list, I assume?

Which is the better approach here and why?

One problem I thought of with the former (one big target.cmake with
all import targets in there) is that if you only ask for a subset of
components in find_package(), you will still get all of them since all
imports are defined in a single file. Does this go against any design
principles? Assuming this really happens, are there any negative side
effects?
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Proper process for static & shared variants of config packages?

[Robert Dailey]

Suppose I have a library target and I setup a config package for it
and install target exports for it. What is the process for supporting
installation of the shared library and static library variants (maybe
the same answer applies to debug and release variants too)?

Should you create 1 target and rely on BUILD_SHARED_LIBS, which means
generating two binary directories, building and installing once in
each? Will this overwrite existing target.cmake and config.cmake files
in a negative way?

Or should there be 2 library targets (something like foo_shared and
foo_static) and build & install once?
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Debugging find_package() search behavior?

[Robert Dailey]

One other thing: Is there a way to make find_package() default to
CONFIG mode? Right now it seems to search MODULE first, then CONFIG.
But right now the only way to enable config is to explicitly use the
CONFIG option or make sure CMake can't find a find module by
manipulating CMAKE_MODULE_PATH.

On Tue, Aug 29, 2017 at 12:51 PM, Robert Dailey
<rcdailey.li...@gmail.com> wrote:
> On Tue, Aug 29, 2017 at 12:12 PM, Rolf Eike Beer <e...@sf-mail.de> wrote:
>> Am Dienstag, 29. August 2017, 11:21:42 schrieb Robert Dailey:
>>> Ok I debugged find_path() code in CMake and I determined the problem.
>>> First, let me explain what I'm doing a little more...
>>>
>>> I build third party libraries on demand during configure step in
>>> CMake. I do so via execute_process() to invoke another CMake instance,
>>> that builds and installs a library. This is similar to how
>>> ExternalProject_Add() works, but forces it to happen at configure time
>>> so I can use find_package() afterwards to find the library I just
>>> built.
>>
>> The trick with ExternalProject_Add is to also build your project with it, and
>> not with add_subdirectory, i.e. the CMakeLists.txt that drives the build 
>> needs
>> to be one level above your actual project. This way all things are done in
>> order, so the dependencies are build before your main project.
>
> That's not going to work since for multi-configuration generators you
> want to be able to edit and build your code through the IDE, not via
> command line.
>
> Regarding find modules: it seems simpler at this point to just redo
> the install logic of upstream libraries using configuration packages
> instead, that way I can have finer control over how packages are
> found. Plus it's good for upstream repositories to be able to
> contribute this back.
>
> Thanks to everyone for their feedback. I have a much better
> understanding of this now, although I still strongly feel this is
> crazy complex. But nothing we can do about that I guess... it's just
> the nature of things.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] Debugging find_package() search behavior?

[Robert Dailey]

On Tue, Aug 29, 2017 at 12:12 PM, Rolf Eike Beer <e...@sf-mail.de> wrote:
> Am Dienstag, 29. August 2017, 11:21:42 schrieb Robert Dailey:
>> Ok I debugged find_path() code in CMake and I determined the problem.
>> First, let me explain what I'm doing a little more...
>>
>> I build third party libraries on demand during configure step in
>> CMake. I do so via execute_process() to invoke another CMake instance,
>> that builds and installs a library. This is similar to how
>> ExternalProject_Add() works, but forces it to happen at configure time
>> so I can use find_package() afterwards to find the library I just
>> built.
>
> The trick with ExternalProject_Add is to also build your project with it, and
> not with add_subdirectory, i.e. the CMakeLists.txt that drives the build needs
> to be one level above your actual project. This way all things are done in
> order, so the dependencies are build before your main project.

That's not going to work since for multi-configuration generators you
want to be able to edit and build your code through the IDE, not via
command line.

Regarding find modules: it seems simpler at this point to just redo
the install logic of upstream libraries using configuration packages
instead, that way I can have finer control over how packages are
found. Plus it's good for upstream repositories to be able to
contribute this back.

Thanks to everyone for their feedback. I have a much better
understanding of this now, although I still strongly feel this is
crazy complex. But nothing we can do about that I guess... it's just
the nature of things.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] Debugging find_package() search behavior?

[Robert Dailey]

Ok I debugged find_path() code in CMake and I determined the problem.
First, let me explain what I'm doing a little more...

I build third party libraries on demand during configure step in
CMake. I do so via execute_process() to invoke another CMake instance,
that builds and installs a library. This is similar to how
ExternalProject_Add() works, but forces it to happen at configure time
so I can use find_package() afterwards to find the library I just
built.

Each library first tries to be found, and if not found, I build it
then try to find it again. Like so:

```
set( library_version 1.2.11 )

set( ZLIB_ROOT ${ZIOSK_THIRD_PARTY_INSTALL} )

find_package( ZLIB ${library_version} EXACT )
if( NOT ZLIB_FOUND OR NOT library_version VERSION_EQUAL ZLIB_VERSION_STRING )
build_third_party_library( CLEAN_BUILD )
find_package( ZLIB ${library_version} EXACT REQUIRED )
endif()
```

When Android's Toolchain is in use, this is what happens:

1. find_package() happens, it finds zlib under android NDK's root, but
doesn't accept it because of a version mismatch (since I use the EXACT
option)
2. I build the third party library with execute_process()
3. Second find_package() happens, but "AlreadyInCache" is true (line
28 in cmFindPathCommand.cxx) this time, so it doesn't search for it
again.

Hard to tell where the bug is here. I'd argue that AlreadyInCache
shouldn't be set to true since an exact version was not found, and the
next find_package() command should do a full path search. Is this a
bug in the C++ code or the find module script? What determines the
AlreadyInCache variable?

On Tue, Aug 29, 2017 at 11:02 AM, David Cole  wrote:
> Sorry for the mis-statement. I stand corrected.
>
> However, it is true that there are many find modules with some
> differences in approach, and if you are using one, you need to read up
> on the individual documentation of that particular find module.
> Especially if you need to know how to tell it how to find the exact
> one you already know you have...
>
>
>
>
> On Tue, Aug 29, 2017 at 11:49 AM, Brad King  wrote:
>> On 08/29/2017 11:33 AM, David Cole wrote:
>>> That's correct:
>>>
>>> find modules do what they want, and most do not pay attention to
>>> CMAKE_PREFIX_PATH.
>>
>> CMAKE_PREFIX_PATH *is* used by find modules.
>>
>> The find modules use find_* commands, and those use CMAKE_PREFIX_PATH.
>> See the documentation of find_library, find_path, etc. for details.
>> Each command searches an appropriate `/` where ``
>> is based on the kind of command doing the searching.
>>
>> -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] [cmake-developers] Debugging find_package() search behavior?

[Robert Dailey]

Ok I debugged find_path() code in CMake and I determined the problem.
First, let me explain what I'm doing a little more...

I build third party libraries on demand during configure step in
CMake. I do so via execute_process() to invoke another CMake instance,
that builds and installs a library. This is similar to how
ExternalProject_Add() works, but forces it to happen at configure time
so I can use find_package() afterwards to find the library I just
built.

Each library first tries to be found, and if not found, I build it
then try to find it again. Like so:

```
set( library_version 1.2.11 )

set( ZLIB_ROOT ${ZIOSK_THIRD_PARTY_INSTALL} )

find_package( ZLIB ${library_version} EXACT )
if( NOT ZLIB_FOUND OR NOT library_version VERSION_EQUAL ZLIB_VERSION_STRING )
build_third_party_library( CLEAN_BUILD )
find_package( ZLIB ${library_version} EXACT REQUIRED )
endif()
```

When Android's Toolchain is in use, this is what happens:

1. find_package() happens, it finds zlib under android NDK's root, but
doesn't accept it because of a version mismatch (since I use the EXACT
option)
2. I build the third party library with execute_process()
3. Second find_package() happens, but "AlreadyInCache" is true (line
28 in cmFindPathCommand.cxx) this time, so it doesn't search for it
again.

Hard to tell where the bug is here. I'd argue that AlreadyInCache
shouldn't be set to true since an exact version was not found, and the
next find_package() command should do a full path search. Is this a
bug in the C++ code or the find module script? What determines the
AlreadyInCache variable?

On Tue, Aug 29, 2017 at 11:02 AM, David Cole  wrote:
> Sorry for the mis-statement. I stand corrected.
>
> However, it is true that there are many find modules with some
> differences in approach, and if you are using one, you need to read up
> on the individual documentation of that particular find module.
> Especially if you need to know how to tell it how to find the exact
> one you already know you have...
>
>
>
>
> On Tue, Aug 29, 2017 at 11:49 AM, Brad King  wrote:
>> On 08/29/2017 11:33 AM, David Cole wrote:
>>> That's correct:
>>>
>>> find modules do what they want, and most do not pay attention to
>>> CMAKE_PREFIX_PATH.
>>
>> CMAKE_PREFIX_PATH *is* used by find modules.
>>
>> The find modules use find_* commands, and those use CMAKE_PREFIX_PATH.
>> See the documentation of find_library, find_path, etc. for details.
>> Each command searches an appropriate `/` where ``
>> is based on the kind of command doing the searching.
>>
>> -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

Re: [CMake] [cmake-developers] Debugging find_package() search behavior?

[Robert Dailey]

On Tue, Aug 29, 2017 at 10:54 AM, Brad King <brad.k...@kitware.com> wrote:
> On 08/29/2017 11:50 AM, Robert Dailey wrote:
>> Wow even if I set ZLIB_ROOT, FindZLIB.cmake *still* won't find my zlib
>> over the one provided by the Android NDK...
>>
>> Although I was able to get this working fine on Windows, it does not
>> work with the NDK's toolchain file.
>
> That's because the CMAKE_FIND_ROOT_PATH settings re-root all search
> paths to look only inside the NDK.  This is one reason toolchain files
> should not be monolithic and should only be authored locally for the
> current machine.

But the documentation[1] says it's a list, so if I add my own
directory to that list, it should search there right?

[1]: https://cmake.org/cmake/help/v3.6/variable/CMAKE_FIND_ROOT_PATH.html
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] Debugging find_package() search behavior?

[Robert Dailey]

On Tue, Aug 29, 2017 at 10:54 AM, Brad King <brad.k...@kitware.com> wrote:
> On 08/29/2017 11:50 AM, Robert Dailey wrote:
>> Wow even if I set ZLIB_ROOT, FindZLIB.cmake *still* won't find my zlib
>> over the one provided by the Android NDK...
>>
>> Although I was able to get this working fine on Windows, it does not
>> work with the NDK's toolchain file.
>
> That's because the CMAKE_FIND_ROOT_PATH settings re-root all search
> paths to look only inside the NDK.  This is one reason toolchain files
> should not be monolithic and should only be authored locally for the
> current machine.

But the documentation[1] says it's a list, so if I add my own
directory to that list, it should search there right?

[1]: https://cmake.org/cmake/help/v3.6/variable/CMAKE_FIND_ROOT_PATH.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-developers

Re: [cmake-developers] [CMake] Debugging find_package() search behavior?

[Robert Dailey]

Wow even if I set ZLIB_ROOT, FindZLIB.cmake *still* won't find my zlib
over the one provided by the Android NDK...

Although I was able to get this working fine on Windows, it does not
work with the NDK's toolchain file.

On Tue, Aug 29, 2017 at 10:43 AM, Robert Dailey
<rcdailey.li...@gmail.com> wrote:
> Thanks for your help, the problem is that I was expecting too much
> consistency between find module behavior. I'll treat them as if I have
> no guarantees.
>
> Last question: Are there guarantees with find modules and
> CMAKE_FIND_ROOT_PATH? I'm asking because on Android, when I use
> find_package(), behavior is different because the NDK's toolchain file
> sets:
>
> 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)
> list(APPEND CMAKE_FIND_ROOT_PATH "${ANDROID_NDK}")
>
> To try to "intercept" the search of NDK for libraries using
> find_package(), I try this:
>
> set( CMAKE_FIND_ROOT_PATH ${ZIOSK_THIRD_PARTY_INSTALL} 
> ${CMAKE_FIND_ROOT_PATH} )
>
> However, after running, it's always finding results in the NDK
> directory set by the toolchain file, even though I put mine first in
> the list. Furthermore, my install of zlib has the correct version, the
> NDK one does not, but it still says it founds the NDK version.
>
> On Tue, Aug 29, 2017 at 10:33 AM, David Cole <dlrd...@aol.com> wrote:
>> That's correct:
>>
>> find modules do what they want, and most do not pay attention to
>> CMAKE_PREFIX_PATH.
>>
>> It's better to use a config file, but when you have to use a find
>> module, you have to dig in and figure out the right way to use each
>> one.
>>
>>
>>
>> On Tue, Aug 29, 2017 at 11:25 AM, Robert Dailey
>> <rcdailey.li...@gmail.com> wrote:
>>> I think the discrepancy here might be config vs module find mode. The
>>> documentation I linked seems to be for config mode only, however I'm
>>> utilizing the CMake-shipped FindZLIB.cmake module to find this
>>> particular library. Does this offer no guarantees on how
>>> CMAKE_PREFIX_PATH is used?
>>>
>>> On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey
>>> <rcdailey.li...@gmail.com> wrote:
>>>> What I'm hoping for is that find_package() follows the rules it
>>>> documents here:
>>>> https://cmake.org/cmake/help/v3.6/command/find_package.html
>>>>
>>>> Specifically, it states it searches these paths (and that  is
>>>> treated case-insensitive):
>>>>
>>>> /   (W)
>>>> /(cmake|CMake)/ (W)
>>>> /*/   (W)
>>>> /*/(cmake|CMake)/ (W)
>>>> /(lib/|lib|share)/cmake/*/  (U)
>>>> /(lib/|lib|share)/*/(U)
>>>> /(lib/|lib|share)/*/(cmake|CMake)/  (U)
>>>>
>>>> If this is true, then the 3rd one from the top should be a match,
>>>> because  is set to:
>>>>
>>>> E:/code/frontend/msvc_2015/third_party/installed
>>>>
>>>> And  is set to ZLIB in find_package() first argument, so it
>>>> should be adding that to the end.
>>>>
>>>> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory
>>>> ("installed") because I have other libraries that get installed in
>>>> that directory, each with their own directory to contain their
>>>> installation files. If find_package() is appending  to 
>>>> like it says it should, it should find each one of them without
>>>> switching the value of CMAKE_PREFIX_PATH.
>>>>
>>>> Am I misunderstanding something?
>>>>
>>>>
>>>> On Tue, Aug 29, 2017 at 10:06 AM, David Cole <dlrd...@aol.com> wrote:
>>>>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH?
>>>>>
>>>>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey
>>>>> <rcdailey.li...@gmail.com> wrote:
>>>>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <brad.k...@kitware.com> wrote:
>>>>>>> On 08/29/2017 10:55 AM, Brad King wrote:
>>>>>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
>>>>>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend

Re: [CMake] [cmake-developers] Debugging find_package() search behavior?

[Robert Dailey]

Wow even if I set ZLIB_ROOT, FindZLIB.cmake *still* won't find my zlib
over the one provided by the Android NDK...

Although I was able to get this working fine on Windows, it does not
work with the NDK's toolchain file.

On Tue, Aug 29, 2017 at 10:43 AM, Robert Dailey
<rcdailey.li...@gmail.com> wrote:
> Thanks for your help, the problem is that I was expecting too much
> consistency between find module behavior. I'll treat them as if I have
> no guarantees.
>
> Last question: Are there guarantees with find modules and
> CMAKE_FIND_ROOT_PATH? I'm asking because on Android, when I use
> find_package(), behavior is different because the NDK's toolchain file
> sets:
>
> 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)
> list(APPEND CMAKE_FIND_ROOT_PATH "${ANDROID_NDK}")
>
> To try to "intercept" the search of NDK for libraries using
> find_package(), I try this:
>
> set( CMAKE_FIND_ROOT_PATH ${ZIOSK_THIRD_PARTY_INSTALL} 
> ${CMAKE_FIND_ROOT_PATH} )
>
> However, after running, it's always finding results in the NDK
> directory set by the toolchain file, even though I put mine first in
> the list. Furthermore, my install of zlib has the correct version, the
> NDK one does not, but it still says it founds the NDK version.
>
> On Tue, Aug 29, 2017 at 10:33 AM, David Cole <dlrd...@aol.com> wrote:
>> That's correct:
>>
>> find modules do what they want, and most do not pay attention to
>> CMAKE_PREFIX_PATH.
>>
>> It's better to use a config file, but when you have to use a find
>> module, you have to dig in and figure out the right way to use each
>> one.
>>
>>
>>
>> On Tue, Aug 29, 2017 at 11:25 AM, Robert Dailey
>> <rcdailey.li...@gmail.com> wrote:
>>> I think the discrepancy here might be config vs module find mode. The
>>> documentation I linked seems to be for config mode only, however I'm
>>> utilizing the CMake-shipped FindZLIB.cmake module to find this
>>> particular library. Does this offer no guarantees on how
>>> CMAKE_PREFIX_PATH is used?
>>>
>>> On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey
>>> <rcdailey.li...@gmail.com> wrote:
>>>> What I'm hoping for is that find_package() follows the rules it
>>>> documents here:
>>>> https://cmake.org/cmake/help/v3.6/command/find_package.html
>>>>
>>>> Specifically, it states it searches these paths (and that  is
>>>> treated case-insensitive):
>>>>
>>>> /   (W)
>>>> /(cmake|CMake)/ (W)
>>>> /*/   (W)
>>>> /*/(cmake|CMake)/ (W)
>>>> /(lib/|lib|share)/cmake/*/  (U)
>>>> /(lib/|lib|share)/*/(U)
>>>> /(lib/|lib|share)/*/(cmake|CMake)/  (U)
>>>>
>>>> If this is true, then the 3rd one from the top should be a match,
>>>> because  is set to:
>>>>
>>>> E:/code/frontend/msvc_2015/third_party/installed
>>>>
>>>> And  is set to ZLIB in find_package() first argument, so it
>>>> should be adding that to the end.
>>>>
>>>> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory
>>>> ("installed") because I have other libraries that get installed in
>>>> that directory, each with their own directory to contain their
>>>> installation files. If find_package() is appending  to 
>>>> like it says it should, it should find each one of them without
>>>> switching the value of CMAKE_PREFIX_PATH.
>>>>
>>>> Am I misunderstanding something?
>>>>
>>>>
>>>> On Tue, Aug 29, 2017 at 10:06 AM, David Cole <dlrd...@aol.com> wrote:
>>>>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH?
>>>>>
>>>>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey
>>>>> <rcdailey.li...@gmail.com> wrote:
>>>>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <brad.k...@kitware.com> wrote:
>>>>>>> On 08/29/2017 10:55 AM, Brad King wrote:
>>>>>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
>>>>>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend

Re: [CMake] [cmake-developers] Debugging find_package() search behavior?

[Robert Dailey]

Thanks for your help, the problem is that I was expecting too much
consistency between find module behavior. I'll treat them as if I have
no guarantees.

Last question: Are there guarantees with find modules and
CMAKE_FIND_ROOT_PATH? I'm asking because on Android, when I use
find_package(), behavior is different because the NDK's toolchain file
sets:

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)
list(APPEND CMAKE_FIND_ROOT_PATH "${ANDROID_NDK}")

To try to "intercept" the search of NDK for libraries using
find_package(), I try this:

set( CMAKE_FIND_ROOT_PATH ${ZIOSK_THIRD_PARTY_INSTALL} ${CMAKE_FIND_ROOT_PATH} )

However, after running, it's always finding results in the NDK
directory set by the toolchain file, even though I put mine first in
the list. Furthermore, my install of zlib has the correct version, the
NDK one does not, but it still says it founds the NDK version.

On Tue, Aug 29, 2017 at 10:33 AM, David Cole <dlrd...@aol.com> wrote:
> That's correct:
>
> find modules do what they want, and most do not pay attention to
> CMAKE_PREFIX_PATH.
>
> It's better to use a config file, but when you have to use a find
> module, you have to dig in and figure out the right way to use each
> one.
>
>
>
> On Tue, Aug 29, 2017 at 11:25 AM, Robert Dailey
> <rcdailey.li...@gmail.com> wrote:
>> I think the discrepancy here might be config vs module find mode. The
>> documentation I linked seems to be for config mode only, however I'm
>> utilizing the CMake-shipped FindZLIB.cmake module to find this
>> particular library. Does this offer no guarantees on how
>> CMAKE_PREFIX_PATH is used?
>>
>> On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey
>> <rcdailey.li...@gmail.com> wrote:
>>> What I'm hoping for is that find_package() follows the rules it
>>> documents here:
>>> https://cmake.org/cmake/help/v3.6/command/find_package.html
>>>
>>> Specifically, it states it searches these paths (and that  is
>>> treated case-insensitive):
>>>
>>> /   (W)
>>> /(cmake|CMake)/ (W)
>>> /*/   (W)
>>> /*/(cmake|CMake)/ (W)
>>> /(lib/|lib|share)/cmake/*/  (U)
>>> /(lib/|lib|share)/*/(U)
>>> /(lib/|lib|share)/*/(cmake|CMake)/  (U)
>>>
>>> If this is true, then the 3rd one from the top should be a match,
>>> because  is set to:
>>>
>>> E:/code/frontend/msvc_2015/third_party/installed
>>>
>>> And  is set to ZLIB in find_package() first argument, so it
>>> should be adding that to the end.
>>>
>>> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory
>>> ("installed") because I have other libraries that get installed in
>>> that directory, each with their own directory to contain their
>>> installation files. If find_package() is appending  to 
>>> like it says it should, it should find each one of them without
>>> switching the value of CMAKE_PREFIX_PATH.
>>>
>>> Am I misunderstanding something?
>>>
>>>
>>> On Tue, Aug 29, 2017 at 10:06 AM, David Cole <dlrd...@aol.com> wrote:
>>>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH?
>>>>
>>>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey
>>>> <rcdailey.li...@gmail.com> wrote:
>>>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <brad.k...@kitware.com> wrote:
>>>>>> On 08/29/2017 10:55 AM, Brad King wrote:
>>>>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
>>>>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>>>
>>>>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with
>>>>>>> drive letters on Windows.
>>>>>>
>>>>>> Oops, sent too soon.
>>>>>>
>>>>>> CMAKE_FIND_ROOT_PATH should not be necessary here.  It's for 
>>>>>> cross-compiling
>>>>>> to re-root paths like `/usr` into some prefix on the host.
>>>>>>
>>>>>> -Brad
>>>>>
>>>>> Ok but even if I remove that, find_package() still isn't working..

Re: [cmake-developers] [CMake] Debugging find_package() search behavior?

[Robert Dailey]

Thanks for your help, the problem is that I was expecting too much
consistency between find module behavior. I'll treat them as if I have
no guarantees.

Last question: Are there guarantees with find modules and
CMAKE_FIND_ROOT_PATH? I'm asking because on Android, when I use
find_package(), behavior is different because the NDK's toolchain file
sets:

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)
list(APPEND CMAKE_FIND_ROOT_PATH "${ANDROID_NDK}")

To try to "intercept" the search of NDK for libraries using
find_package(), I try this:

set( CMAKE_FIND_ROOT_PATH ${ZIOSK_THIRD_PARTY_INSTALL} ${CMAKE_FIND_ROOT_PATH} )

However, after running, it's always finding results in the NDK
directory set by the toolchain file, even though I put mine first in
the list. Furthermore, my install of zlib has the correct version, the
NDK one does not, but it still says it founds the NDK version.

On Tue, Aug 29, 2017 at 10:33 AM, David Cole <dlrd...@aol.com> wrote:
> That's correct:
>
> find modules do what they want, and most do not pay attention to
> CMAKE_PREFIX_PATH.
>
> It's better to use a config file, but when you have to use a find
> module, you have to dig in and figure out the right way to use each
> one.
>
>
>
> On Tue, Aug 29, 2017 at 11:25 AM, Robert Dailey
> <rcdailey.li...@gmail.com> wrote:
>> I think the discrepancy here might be config vs module find mode. The
>> documentation I linked seems to be for config mode only, however I'm
>> utilizing the CMake-shipped FindZLIB.cmake module to find this
>> particular library. Does this offer no guarantees on how
>> CMAKE_PREFIX_PATH is used?
>>
>> On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey
>> <rcdailey.li...@gmail.com> wrote:
>>> What I'm hoping for is that find_package() follows the rules it
>>> documents here:
>>> https://cmake.org/cmake/help/v3.6/command/find_package.html
>>>
>>> Specifically, it states it searches these paths (and that  is
>>> treated case-insensitive):
>>>
>>> /   (W)
>>> /(cmake|CMake)/ (W)
>>> /*/   (W)
>>> /*/(cmake|CMake)/ (W)
>>> /(lib/|lib|share)/cmake/*/  (U)
>>> /(lib/|lib|share)/*/(U)
>>> /(lib/|lib|share)/*/(cmake|CMake)/  (U)
>>>
>>> If this is true, then the 3rd one from the top should be a match,
>>> because  is set to:
>>>
>>> E:/code/frontend/msvc_2015/third_party/installed
>>>
>>> And  is set to ZLIB in find_package() first argument, so it
>>> should be adding that to the end.
>>>
>>> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory
>>> ("installed") because I have other libraries that get installed in
>>> that directory, each with their own directory to contain their
>>> installation files. If find_package() is appending  to 
>>> like it says it should, it should find each one of them without
>>> switching the value of CMAKE_PREFIX_PATH.
>>>
>>> Am I misunderstanding something?
>>>
>>>
>>> On Tue, Aug 29, 2017 at 10:06 AM, David Cole <dlrd...@aol.com> wrote:
>>>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH?
>>>>
>>>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey
>>>> <rcdailey.li...@gmail.com> wrote:
>>>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <brad.k...@kitware.com> wrote:
>>>>>> On 08/29/2017 10:55 AM, Brad King wrote:
>>>>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
>>>>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>>>
>>>>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with
>>>>>>> drive letters on Windows.
>>>>>>
>>>>>> Oops, sent too soon.
>>>>>>
>>>>>> CMAKE_FIND_ROOT_PATH should not be necessary here.  It's for 
>>>>>> cross-compiling
>>>>>> to re-root paths like `/usr` into some prefix on the host.
>>>>>>
>>>>>> -Brad
>>>>>
>>>>> Ok but even if I remove that, find_package() still isn't working..

Re: [CMake] [cmake-developers] Debugging find_package() search behavior?

[Robert Dailey]

I think the discrepancy here might be config vs module find mode. The
documentation I linked seems to be for config mode only, however I'm
utilizing the CMake-shipped FindZLIB.cmake module to find this
particular library. Does this offer no guarantees on how
CMAKE_PREFIX_PATH is used?

On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey
<rcdailey.li...@gmail.com> wrote:
> What I'm hoping for is that find_package() follows the rules it
> documents here:
> https://cmake.org/cmake/help/v3.6/command/find_package.html
>
> Specifically, it states it searches these paths (and that  is
> treated case-insensitive):
>
> /   (W)
> /(cmake|CMake)/ (W)
> /*/   (W)
> /*/(cmake|CMake)/ (W)
> /(lib/|lib|share)/cmake/*/  (U)
> /(lib/|lib|share)/*/(U)
> /(lib/|lib|share)/*/(cmake|CMake)/  (U)
>
> If this is true, then the 3rd one from the top should be a match,
> because  is set to:
>
> E:/code/frontend/msvc_2015/third_party/installed
>
> And  is set to ZLIB in find_package() first argument, so it
> should be adding that to the end.
>
> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory
> ("installed") because I have other libraries that get installed in
> that directory, each with their own directory to contain their
> installation files. If find_package() is appending  to 
> like it says it should, it should find each one of them without
> switching the value of CMAKE_PREFIX_PATH.
>
> Am I misunderstanding something?
>
>
> On Tue, Aug 29, 2017 at 10:06 AM, David Cole <dlrd...@aol.com> wrote:
>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH?
>>
>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey
>> <rcdailey.li...@gmail.com> wrote:
>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <brad.k...@kitware.com> wrote:
>>>> On 08/29/2017 10:55 AM, Brad King wrote:
>>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
>>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>
>>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with
>>>>> drive letters on Windows.
>>>>
>>>> Oops, sent too soon.
>>>>
>>>> CMAKE_FIND_ROOT_PATH should not be necessary here.  It's for 
>>>> cross-compiling
>>>> to re-root paths like `/usr` into some prefix on the host.
>>>>
>>>> -Brad
>>>
>>> Ok but even if I remove that, find_package() still isn't 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
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Debugging find_package() search behavior?

[Robert Dailey]

I think the discrepancy here might be config vs module find mode. The
documentation I linked seems to be for config mode only, however I'm
utilizing the CMake-shipped FindZLIB.cmake module to find this
particular library. Does this offer no guarantees on how
CMAKE_PREFIX_PATH is used?

On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey
<rcdailey.li...@gmail.com> wrote:
> What I'm hoping for is that find_package() follows the rules it
> documents here:
> https://cmake.org/cmake/help/v3.6/command/find_package.html
>
> Specifically, it states it searches these paths (and that  is
> treated case-insensitive):
>
> /   (W)
> /(cmake|CMake)/ (W)
> /*/   (W)
> /*/(cmake|CMake)/ (W)
> /(lib/|lib|share)/cmake/*/  (U)
> /(lib/|lib|share)/*/(U)
> /(lib/|lib|share)/*/(cmake|CMake)/  (U)
>
> If this is true, then the 3rd one from the top should be a match,
> because  is set to:
>
> E:/code/frontend/msvc_2015/third_party/installed
>
> And  is set to ZLIB in find_package() first argument, so it
> should be adding that to the end.
>
> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory
> ("installed") because I have other libraries that get installed in
> that directory, each with their own directory to contain their
> installation files. If find_package() is appending  to 
> like it says it should, it should find each one of them without
> switching the value of CMAKE_PREFIX_PATH.
>
> Am I misunderstanding something?
>
>
> On Tue, Aug 29, 2017 at 10:06 AM, David Cole <dlrd...@aol.com> wrote:
>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH?
>>
>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey
>> <rcdailey.li...@gmail.com> wrote:
>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <brad.k...@kitware.com> wrote:
>>>> On 08/29/2017 10:55 AM, Brad King wrote:
>>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
>>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>
>>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with
>>>>> drive letters on Windows.
>>>>
>>>> Oops, sent too soon.
>>>>
>>>> CMAKE_FIND_ROOT_PATH should not be necessary here.  It's for 
>>>> cross-compiling
>>>> to re-root paths like `/usr` into some prefix on the host.
>>>>
>>>> -Brad
>>>
>>> Ok but even if I remove that, find_package() still isn't 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
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] Debugging find_package() search behavior?

[Robert Dailey]

What I'm hoping for is that find_package() follows the rules it
documents here:
https://cmake.org/cmake/help/v3.6/command/find_package.html

Specifically, it states it searches these paths (and that  is
treated case-insensitive):

/   (W)
/(cmake|CMake)/ (W)
/*/   (W)
/*/(cmake|CMake)/ (W)
/(lib/|lib|share)/cmake/*/  (U)
/(lib/|lib|share)/*/(U)
/(lib/|lib|share)/*/(cmake|CMake)/  (U)

If this is true, then the 3rd one from the top should be a match,
because  is set to:

E:/code/frontend/msvc_2015/third_party/installed

And  is set to ZLIB in find_package() first argument, so it
should be adding that to the end.

I need to keep CMAKE_PREFIX_PATH pointing to the parent directory
("installed") because I have other libraries that get installed in
that directory, each with their own directory to contain their
installation files. If find_package() is appending  to 
like it says it should, it should find each one of them without
switching the value of CMAKE_PREFIX_PATH.

Am I misunderstanding something?


On Tue, Aug 29, 2017 at 10:06 AM, David Cole <dlrd...@aol.com> wrote:
> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH?
>
> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey
> <rcdailey.li...@gmail.com> wrote:
>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <brad.k...@kitware.com> wrote:
>>> On 08/29/2017 10:55 AM, Brad King wrote:
>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>
>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with
>>>> drive letters on Windows.
>>>
>>> Oops, sent too soon.
>>>
>>> CMAKE_FIND_ROOT_PATH should not be necessary here.  It's for cross-compiling
>>> to re-root paths like `/usr` into some prefix on the host.
>>>
>>> -Brad
>>
>> Ok but even if I remove that, find_package() still isn't 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
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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-developers] Debugging find_package() search behavior?

[Robert Dailey]

What I'm hoping for is that find_package() follows the rules it
documents here:
https://cmake.org/cmake/help/v3.6/command/find_package.html

Specifically, it states it searches these paths (and that  is
treated case-insensitive):

/   (W)
/(cmake|CMake)/ (W)
/*/   (W)
/*/(cmake|CMake)/ (W)
/(lib/|lib|share)/cmake/*/  (U)
/(lib/|lib|share)/*/(U)
/(lib/|lib|share)/*/(cmake|CMake)/  (U)

If this is true, then the 3rd one from the top should be a match,
because  is set to:

E:/code/frontend/msvc_2015/third_party/installed

And  is set to ZLIB in find_package() first argument, so it
should be adding that to the end.

I need to keep CMAKE_PREFIX_PATH pointing to the parent directory
("installed") because I have other libraries that get installed in
that directory, each with their own directory to contain their
installation files. If find_package() is appending  to 
like it says it should, it should find each one of them without
switching the value of CMAKE_PREFIX_PATH.

Am I misunderstanding something?


On Tue, Aug 29, 2017 at 10:06 AM, David Cole <dlrd...@aol.com> wrote:
> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH?
>
> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey
> <rcdailey.li...@gmail.com> wrote:
>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <brad.k...@kitware.com> wrote:
>>> On 08/29/2017 10:55 AM, Brad King wrote:
>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>
>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with
>>>> drive letters on Windows.
>>>
>>> Oops, sent too soon.
>>>
>>> CMAKE_FIND_ROOT_PATH should not be necessary here.  It's for cross-compiling
>>> to re-root paths like `/usr` into some prefix on the host.
>>>
>>> -Brad
>>
>> Ok but even if I remove that, find_package() still isn't 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
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Debugging find_package() search behavior?

[Robert Dailey]

On Tue, Aug 29, 2017 at 9:56 AM, Brad King <brad.k...@kitware.com> wrote:
> On 08/29/2017 10:55 AM, Brad King wrote:
>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>
>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with
>> drive letters on Windows.
>
> Oops, sent too soon.
>
> CMAKE_FIND_ROOT_PATH should not be necessary here.  It's for cross-compiling
> to re-root paths like `/usr` into some prefix on the host.
>
> -Brad

Ok but even if I remove that, find_package() still isn't 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-developers

Re: [CMake] [cmake-developers] Debugging find_package() search behavior?

[Robert Dailey]

On Tue, Aug 29, 2017 at 9:56 AM, Brad King <brad.k...@kitware.com> wrote:
> On 08/29/2017 10:55 AM, Brad King wrote:
>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>
>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with
>> drive letters on Windows.
>
> Oops, sent too soon.
>
> CMAKE_FIND_ROOT_PATH should not be necessary here.  It's for cross-compiling
> to re-root paths like `/usr` into some prefix on the host.
>
> -Brad

Ok but even if I remove that, find_package() still isn't 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

Re: [CMake] [cmake-developers] Debugging find_package() search behavior?

[Robert Dailey]

I am doing that. Here is a live example:

Library is zlib, installed here:

E:\code\frontend\msvc_2015\third_party\installed\zlib

(has include, lib, bin, share inside it)

I set the following variables (Using the set() command (non-cache)
inside my CMake script, before the find_package calls):

CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed

And then the find_package() command is executed:

find_package( ZLIB 1.2.11 EXACT REQUIRED )

And fails with:

CMake Error at E:/Program
Files/CMake/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:137
(message):
Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR) (Required is
exact version "1.2.11")
Call Stack (most recent call first):
E:/Program 
Files/CMake/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:377
(_FPHSA_FAILURE_MESSAGE)
E:/Program Files/CMake/share/cmake-3.9/Modules/FindZLIB.cmake:112
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
Core/ThirdParty/zlib/CMakeLists.txt:6 (find_package)

On Tue, Aug 29, 2017 at 9:33 AM, Brad King <brad.k...@kitware.com> wrote:
> On 08/29/2017 10:27 AM, Robert Dailey wrote:
>> I'm relying on the two variables above to control this behavior, but
>> CMAKE_INSTALL_PREFIX doesn't work well for both purposes.
>
> Use CMAKE_PREFIX_PATH, not CMAKE_INSTALL_PREFIX, to control
> the set of prefixes that find commands search.
>
> -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

Re: [cmake-developers] Debugging find_package() search behavior?

[Robert Dailey]

I am doing that. Here is a live example:

Library is zlib, installed here:

E:\code\frontend\msvc_2015\third_party\installed\zlib

(has include, lib, bin, share inside it)

I set the following variables (Using the set() command (non-cache)
inside my CMake script, before the find_package calls):

CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed

And then the find_package() command is executed:

find_package( ZLIB 1.2.11 EXACT REQUIRED )

And fails with:

CMake Error at E:/Program
Files/CMake/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:137
(message):
Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR) (Required is
exact version "1.2.11")
Call Stack (most recent call first):
E:/Program 
Files/CMake/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:377
(_FPHSA_FAILURE_MESSAGE)
E:/Program Files/CMake/share/cmake-3.9/Modules/FindZLIB.cmake:112
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
Core/ThirdParty/zlib/CMakeLists.txt:6 (find_package)

On Tue, Aug 29, 2017 at 9:33 AM, Brad King <brad.k...@kitware.com> wrote:
> On 08/29/2017 10:27 AM, Robert Dailey wrote:
>> I'm relying on the two variables above to control this behavior, but
>> CMAKE_INSTALL_PREFIX doesn't work well for both purposes.
>
> Use CMAKE_PREFIX_PATH, not CMAKE_INSTALL_PREFIX, to control
> the set of prefixes that find commands search.
>
> -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] Debugging find_package() search behavior?

[Robert Dailey]

I want to clarify my post since I've spent some more time on this.

find_package() doesn't seem to work intuitively on Windows. On Linux,
for example, installation prefixes are like "/usr/local", so if I'm
building & installing a library in linux, you'd get a structure like:

/usr/local/include
/usr/local/lib
/usr/local/bin

On Windows, if I make the prefix "C:/Program Files", then you get:

C:/Program Files/include
C:/Program Files/lib
C:/Program Files/bin

This is not the idiomatic way to install libraries on windows.
Instead, it should be:

C:/Program Files/MyLibrary/include
C:/Program Files/MyLibrary/lib
C:/Program Files/MyLibrary/bin

I can achieve this during installation by setting my
CMAKE_INSTALL_PREFIX to "C:/Program Files/MyLibrary", however
CMAKE_INSTALL_PREFIX seems like it should be different when used with
find_package().

After doing tons of reading, the search behavior for find_package() is
very confusing outside of linux. Combined with CMAKE_FIND_ROOT_PATH, I
have no idea what the heck these should be on Windows.

Suppose I want to use a super build to build a lot of third party
libraries and install them relative to my CMAKE_BINARY_DIR, and
completely ignore system root paths for find_package() searching. My
first instinct would be to do this:

-D CMAKE_FIND_ROOT_PATH=${CMAKE_BINARY_DIR}/installed_libraries
-D CMAKE_INSTALL_PREFIX=${name_of_library}

Note that there are two goals:

1. The library being built must install its files to
${CMAKE_BINARY_DIR}/installed_libraries/${name_of_library}
2. Any find_package() invocations made by the library being built
should search within ${CMAKE_BINARY_DIR}/installed_libraries

I'm relying on the two variables above to control this behavior, but
CMAKE_INSTALL_PREFIX doesn't work well for both purposes. I can't make
it relative on Windows because it puts it somewhere random on my
filesystem, I think in program files. I'm not sure what
CMAKE_INSTALL_PREFIX does if it isn't an absolute path (but based on
linux behavior it should just append to the end of
CMAKE_FIND_ROOT_PATH I think?)

How can I get the proper install & find_package behavior on Windows
based on the requirements above?

On Sun, Aug 27, 2017 at 2:55 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> So I'm trying to get CMake to find a package, and it isn't finding it.
> I am setting CMAKE_PREFIX_PATH to try to get it to find it. Is there a
> way I can view the search paths & prefixes that CMake is using with
> each find_package() call? I tried enabling debug and trace output, but
> neither of these seem to show any detail of what happens internally
> with find_package() searches.
>
> 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] Debugging find_package() search behavior?

[Robert Dailey]

I want to clarify my post since I've spent some more time on this.

find_package() doesn't seem to work intuitively on Windows. On Linux,
for example, installation prefixes are like "/usr/local", so if I'm
building & installing a library in linux, you'd get a structure like:

/usr/local/include
/usr/local/lib
/usr/local/bin

On Windows, if I make the prefix "C:/Program Files", then you get:

C:/Program Files/include
C:/Program Files/lib
C:/Program Files/bin

This is not the idiomatic way to install libraries on windows.
Instead, it should be:

C:/Program Files/MyLibrary/include
C:/Program Files/MyLibrary/lib
C:/Program Files/MyLibrary/bin

I can achieve this during installation by setting my
CMAKE_INSTALL_PREFIX to "C:/Program Files/MyLibrary", however
CMAKE_INSTALL_PREFIX seems like it should be different when used with
find_package().

After doing tons of reading, the search behavior for find_package() is
very confusing outside of linux. Combined with CMAKE_FIND_ROOT_PATH, I
have no idea what the heck these should be on Windows.

Suppose I want to use a super build to build a lot of third party
libraries and install them relative to my CMAKE_BINARY_DIR, and
completely ignore system root paths for find_package() searching. My
first instinct would be to do this:

-D CMAKE_FIND_ROOT_PATH=${CMAKE_BINARY_DIR}/installed_libraries
-D CMAKE_INSTALL_PREFIX=${name_of_library}

Note that there are two goals:

1. The library being built must install its files to
${CMAKE_BINARY_DIR}/installed_libraries/${name_of_library}
2. Any find_package() invocations made by the library being built
should search within ${CMAKE_BINARY_DIR}/installed_libraries

I'm relying on the two variables above to control this behavior, but
CMAKE_INSTALL_PREFIX doesn't work well for both purposes. I can't make
it relative on Windows because it puts it somewhere random on my
filesystem, I think in program files. I'm not sure what
CMAKE_INSTALL_PREFIX does if it isn't an absolute path (but based on
linux behavior it should just append to the end of
CMAKE_FIND_ROOT_PATH I think?)

How can I get the proper install & find_package behavior on Windows
based on the requirements above?

On Sun, Aug 27, 2017 at 2:55 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> So I'm trying to get CMake to find a package, and it isn't finding it.
> I am setting CMAKE_PREFIX_PATH to try to get it to find it. Is there a
> way I can view the search paths & prefixes that CMake is using with
> each find_package() call? I tried enabling debug and trace output, but
> neither of these seem to show any detail of what happens internally
> with find_package() searches.
>
> 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] CMake + Gradle for Android

[Robert Dailey]

I could probably do you one better, and just give you a stripped-down
version of our repository. Basically, I'd remove all our C++ and Java
source code but leave the CMake scripts and such intact somehow. It
would take me some time to do this, though. Would this be helpful for
you?

In the meantime, when I get into the office tomorrow I'll answer your
questions directly with as much detail as possible. Would you like me
to contact you personally from this point on or should we keep the
conversation on the CMake list?

On Fri, Aug 25, 2017 at 7:20 PM, Jom O'Fisher <jomofis...@gmail.com> wrote:
> Hi again Robert,
> Would you be able to give me an estimate of how many APK projects you have,
> roughly which open source projects you reference via CMake
> add_subdirectories, and whether you have any variants beyond the default
> Debug and Release? If possible I'd like to approximate your project layout
> so we can study it in more closely with an eye toward making the experience
> better for this kind of layout.
>
>
>
>
>
> On Fri, Aug 25, 2017 at 2:46 PM, Jom O'Fisher <jomofis...@gmail.com> wrote:
>>
>> Targets are specified per-Variation so they need to go under the
>> variation-specific section. Probably something like this:
>>
>> defaultConfig {
>>   externalNativeBuild {
>> cmake {
>>   targets "library1", "library2"
>> }
>>           }
>> }
>>
>> That should work for you. Let me know.
>>
>> On Fri, Aug 25, 2017 at 2:42 PM, Robert Dailey <rcdailey.li...@gmail.com>
>> wrote:
>>>
>>> By the way when I try to use "targets", I get a failure. Basically
>>> Gradle doesn't recognize that keyword. I tried singular form as well
>>> ("target"), no luck.
>>>
>>> I'm running canary build of everything possible. What am I missing?
>>>
>>> On Wed, Aug 23, 2017 at 4:20 PM, Jom O'Fisher <jomofis...@gmail.com>
>>> wrote:
>>> > By gradle module projects, I just mean the leaf build.gradle files as
>>> > opposed to the root build.gradle. By configurations, I mean Build Types
>>> > (debug vs release) and Product Flavors (demo vs free vs paid).
>>> > Hereafter I
>>> > will use the term "variant" rather than "configuration" to be precise.
>>> > See
>>> > this write-up on build variants:
>>> >
>>> >
>>> > https://developer.android.com/studio/build/build-variants.html#build-types
>>> >
>>> > This build matrix is constructed at the leaf build.gradle level. Native
>>> > build in gradle allows you to set C/C++ flags individually for each
>>> > variant
>>> > so that you can define compiler flags (for example, -DFREE_VERSION).
>>> >
>>> > One thing to notice at this stage is that the same CMake target may be
>>> > built
>>> > with different compiler flags across different projects, build types,
>>> > and
>>> > product flavors. So in the general case, build outputs won't be the
>>> > same.
>>> >
>>> > You asked which targets build when specifying path. By default, we
>>> > build all
>>> > targets that produce an .so. You can override this by setting
>>> > externalNativeBuild.cmake.targets. For example,
>>> >
>>> > paid {
>>> >   ...
>>> >   externalNativeBuild {
>>> > cmake {
>>> >   ...
>>> >   targets "native-lib-paid"
>>> > }
>>> >   }
>>> > }
>>> >
>>> > As for your last question, the model we generally see used is that the
>>> > main
>>> > CMakeLists.txt is next to the leaf build.gradle such that this
>>> > CMakeLists.txt doesn't couple with peer APK project CMakeLists.txt
>>> > (though
>>> > they may share common dependencies and settings). Otherwise, multiple
>>> > APK
>>> > projects would perform pretty much similar to yours--they would build
>>> > targets per-leaf project and not share build outputs. As far as I can
>>> > see
>>> > your organization is just as valid so long as you only build the
>>> > targets you
>>> > need.
>>> >
>>> > Regarding native dependencies between java 

[CMake] Debugging find_package() search behavior?

[Robert Dailey]

So I'm trying to get CMake to find a package, and it isn't finding it.
I am setting CMAKE_PREFIX_PATH to try to get it to find it. Is there a
way I can view the search paths & prefixes that CMake is using with
each find_package() call? I tried enabling debug and trace output, but
neither of these seem to show any detail of what happens internally
with find_package() searches.

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] CMake + Gradle for Android

[Robert Dailey]

By the way when I try to use "targets", I get a failure. Basically
Gradle doesn't recognize that keyword. I tried singular form as well
("target"), no luck.

I'm running canary build of everything possible. What am I missing?

On Wed, Aug 23, 2017 at 4:20 PM, Jom O'Fisher <jomofis...@gmail.com> wrote:
> By gradle module projects, I just mean the leaf build.gradle files as
> opposed to the root build.gradle. By configurations, I mean Build Types
> (debug vs release) and Product Flavors (demo vs free vs paid). Hereafter I
> will use the term "variant" rather than "configuration" to be precise. See
> this write-up on build variants:
>
> https://developer.android.com/studio/build/build-variants.html#build-types
>
> This build matrix is constructed at the leaf build.gradle level. Native
> build in gradle allows you to set C/C++ flags individually for each variant
> so that you can define compiler flags (for example, -DFREE_VERSION).
>
> One thing to notice at this stage is that the same CMake target may be built
> with different compiler flags across different projects, build types, and
> product flavors. So in the general case, build outputs won't be the same.
>
> You asked which targets build when specifying path. By default, we build all
> targets that produce an .so. You can override this by setting
> externalNativeBuild.cmake.targets. For example,
>
> paid {
>   ...
>   externalNativeBuild {
> cmake {
>   ...
>   targets "native-lib-paid"
> }
>   }
> }
>
> As for your last question, the model we generally see used is that the main
> CMakeLists.txt is next to the leaf build.gradle such that this
> CMakeLists.txt doesn't couple with peer APK project CMakeLists.txt (though
> they may share common dependencies and settings). Otherwise, multiple APK
> projects would perform pretty much similar to yours--they would build
> targets per-leaf project and not share build outputs. As far as I can see
> your organization is just as valid so long as you only build the targets you
> need.
>
> Regarding native dependencies between java projects. We generally try to
> avoid making the CMake build depend on the gradle build (you should be able
> to replicate the CMake build from the command-line if you set the right
> flags). At the moment I don't see a way we could make things better without
> violating that tenet but that could be lack of imagination on my part.
>
> We'll definitely be discussing this use case at our next C++ meeting and
> I'll also be checking for myself whether ccache will work in this CMake
> scenario. If ccache does work it seems like the natural level at which to
> fold identical builds.
>
>
>
> On Wed, Aug 23, 2017 at 1:03 PM, Robert Dailey <rcdailey.li...@gmail.com>
> wrote:
>>
>> I'm not sure what you mean by "gradle module projects", but maybe
>> having some examples of what you mean by "configurations, C++ flags,
>> etc" might make it more clear.
>>
>> Question: When specifying "path" for the CMakeLists.txt in the
>> build.gradle file, how do you know which targets to build? For
>> example, that run of CMake may generate 100 targets, but only 20 need
>> to build and be packaged (*.so files) with the APK. Do you just build
>> "all"? Is there a way to specify the target itself?
>>
>> Thanks again. I'd still like to know more about what the ideal
>> organization is. I find it hard to believe that large android projects
>> rarely break things up into multiple, separate "components" that are
>> built independently. That's really the gist of what we're dealing with
>> here. Your typical "hello world" project likely will have only 1
>> CMakeLists.txt that is pretty self-contained, but all the
>> documentation I've looked at so far doesn't show the best way to
>> handle native library dependencies across java projects between
>> build.gradle files (or maybe I'm just not looking hard enough).
>>
>> On Wed, Aug 23, 2017 at 1:02 PM, Jom O'Fisher <jomofis...@gmail.com>
>> wrote:
>> > Thanks for the write-up Robert. Having thought about it, I don't believe
>> > we
>> > have a satisfying answer at the gradle level for this kind of
>> > organization.
>> > In the gradle model module projects are the unit of organization for
>> > configurations, C/C++ flags, etc. and that's something we're pretty much
>> > stuck with.
>> > Regarding just the redundant build issue, would something like ccache
>> > help?
>> > I know people have used it with ndk-build w

Re: [cmake-developers] Should configuration package files define module package variables?

[Robert Dailey]

Doh, forgot the links I intended to reference in my original email:

[1]: https://cmake.org/cmake/help/v3.6/command/find_package.html
[2]: 
https://cmake.org/cmake/help/v3.6/manual/cmake-packages.7.html#creating-packages
[3]: https://cmake.org/cmake/help/v3.6/module/CMakePackageConfigHelpers.html

On Fri, Aug 25, 2017 at 11:21 AM, Robert Dailey
<rcdailey.li...@gmail.com> wrote:
> So I've been studying the find_package[1] and "creating packages"[2]
> documentation, as well as the CMakePackageConfigHelpers[3] page.
>
> Based on the current offerings of configuration packages, I do not
> understand the need for the relocatable config.cmake file when all it
> really contains is:
>
> include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake)
>
> However, what I'm wondering is even though the import targets should
> contain all information about include directories, libraries, etc,
> should I still define the typical Foo_INCLUDE_DIRS, Foo_LIBRARIES
> variables? Example of what foo-config.cmake would be like:
>
> include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake)
> set( Foo_INCLUDE_DIRS "... path here" )
> set( Foo_LIBRARIES "List of libraries here..." )
>
>
> Is this necessary? Honestly the learning curve for creating packages
> for find_package is very steep. I did not see any general advice on
> this kind of stuff. It seems like Module packages are being deprecated
> in favor of Config packages, because it puts the responsibility of
> maintaining find package logic on the upstream maintainer (config
> package) instead of on CMake (module packages it ships with).
>
> Thanks in advance for any 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] Should configuration package files define module package variables?

[Robert Dailey]

Doh, forgot the links I intended to reference in my original email:

[1]: https://cmake.org/cmake/help/v3.6/command/find_package.html
[2]: 
https://cmake.org/cmake/help/v3.6/manual/cmake-packages.7.html#creating-packages
[3]: https://cmake.org/cmake/help/v3.6/module/CMakePackageConfigHelpers.html

On Fri, Aug 25, 2017 at 11:21 AM, Robert Dailey
<rcdailey.li...@gmail.com> wrote:
> So I've been studying the find_package[1] and "creating packages"[2]
> documentation, as well as the CMakePackageConfigHelpers[3] page.
>
> Based on the current offerings of configuration packages, I do not
> understand the need for the relocatable config.cmake file when all it
> really contains is:
>
> include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake)
>
> However, what I'm wondering is even though the import targets should
> contain all information about include directories, libraries, etc,
> should I still define the typical Foo_INCLUDE_DIRS, Foo_LIBRARIES
> variables? Example of what foo-config.cmake would be like:
>
> include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake)
> set( Foo_INCLUDE_DIRS "... path here" )
> set( Foo_LIBRARIES "List of libraries here..." )
>
>
> Is this necessary? Honestly the learning curve for creating packages
> for find_package is very steep. I did not see any general advice on
> this kind of stuff. It seems like Module packages are being deprecated
> in favor of Config packages, because it puts the responsibility of
> maintaining find package logic on the upstream maintainer (config
> package) instead of on CMake (module packages it ships with).
>
> Thanks in advance for any 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

[cmake-developers] Should configuration package files define module package variables?

[Robert Dailey]

So I've been studying the find_package[1] and "creating packages"[2]
documentation, as well as the CMakePackageConfigHelpers[3] page.

Based on the current offerings of configuration packages, I do not
understand the need for the relocatable config.cmake file when all it
really contains is:

include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake)

However, what I'm wondering is even though the import targets should
contain all information about include directories, libraries, etc,
should I still define the typical Foo_INCLUDE_DIRS, Foo_LIBRARIES
variables? Example of what foo-config.cmake would be like:

include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake)
set( Foo_INCLUDE_DIRS "... path here" )
set( Foo_LIBRARIES "List of libraries here..." )


Is this necessary? Honestly the learning curve for creating packages
for find_package is very steep. I did not see any general advice on
this kind of stuff. It seems like Module packages are being deprecated
in favor of Config packages, because it puts the responsibility of
maintaining find package logic on the upstream maintainer (config
package) instead of on CMake (module packages it ships with).

Thanks in advance for any 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

[CMake] Should configuration package files define module package variables?

[Robert Dailey]

So I've been studying the find_package[1] and "creating packages"[2]
documentation, as well as the CMakePackageConfigHelpers[3] page.

Based on the current offerings of configuration packages, I do not
understand the need for the relocatable config.cmake file when all it
really contains is:

include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake)

However, what I'm wondering is even though the import targets should
contain all information about include directories, libraries, etc,
should I still define the typical Foo_INCLUDE_DIRS, Foo_LIBRARIES
variables? Example of what foo-config.cmake would be like:

include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake)
set( Foo_INCLUDE_DIRS "... path here" )
set( Foo_LIBRARIES "List of libraries here..." )


Is this necessary? Honestly the learning curve for creating packages
for find_package is very steep. I did not see any general advice on
this kind of stuff. It seems like Module packages are being deprecated
in favor of Config packages, because it puts the responsibility of
maintaining find package logic on the upstream maintainer (config
package) instead of on CMake (module packages it ships with).

Thanks in advance for any 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

[CMake] Best practice for modifying search path for find_package()

[Robert Dailey]

So I have a "super build" CMake script that runs a series of
ExternalProject_Add() functions to execute builds of various third
party libraries and install them to a path relative to the parent
project's CMAKE_BINARY_DIR.

Once the parent project generation occurs, it is expected to do a
series of find_package() commands to locate the packages installed by
the previous super build.

What is the best way to intercept the find_package() search paths to
prioritize searching to the custom relative root directory managed by
the super build? Based on the documentation for find_package()[1],
seems like CMAKE_PREFIX_PATH might be the best way (set it as a normal
variable, not a cache variable) inside the CMake scripts prior to the
find_package() invocations (which are done indirectly by other CMake
scripts I do not manage and cannot change). Although, the usage intent
for CMAKE_PREFIX_PATH seems to be documented differently than how I
plan to use it.

Any advice?

[1]: https://cmake.org/cmake/help/v3.6/command/find_package.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] CMake + Gradle for Android

[Robert Dailey]

Thanks for explaining, as usual your answers are making things much more clear.

When it's all said and done and considering everything we've discussed
up to this point, I'm fine with how you've architected the CMake
integration with Gradle. I think the way things function is perfectly
fine. My only concern is with a (should I say minor?) implementation
detail: Trying to promote CMAKE_BINARY_DIR sharing where feasible to
do so. Like I mentioned earlier, I believe that the code-behind for
"externalNativeBuild" logic should detect when two "path" files refer
to the same physical CMakeLists.txt file within the same build
configuration and variant, and if true, reuse/share the same
CMAKE_BINARY_DIR instead of generating another one. This seems safe to
me since the only difference is possibly which targets get invoked.
Optimistically, the best case scenario here is that the 2nd
externalNativeBuild has to build nothing and just grab *.so files
already built by the first externalNativeProject (so long as both
point to the same "path" file on filesystem).

Whether or not you decide to specify the "path" at the common ancestor
build.gradle (to make managing the configuration in gradle easier
since the properties will be transitive) or keep it as it is (require
"path" at each leaf build.gradle), you can still check if the same
physical CMakeLists.txt file is being used between multiple leaf
gradle build files.

If ccache is capable of reading build cache between multiple CMake
binary dirs, I think it may solve some aspects of this problem: In
particular, it might solve the build performance problems (you'd still
be building the same libs only once, even across separate
CMAKE_BINARY_DIR, if I understand correctly). But it does not solve
other issues: In particular, custom_target or custom_command logic
that depends on custom timestamp file or caching logic (like, checking
if files already exist in CMAKE_BINARY_DIR, and if not, download them,
install them, etc. (ExternalProject_Add is a prime example)). Also
ccache won't reduce the disk space consumption that would exist due to
having multiple CMAKE_BINARY_DIR instead of consolidating and sharing
them.

Sorry if I'm just repeating myself, but I'm just trying to summarize
my thoughts. The situation is complex so I want to make sure I am not
leaving out any details for when you do finally discuss this
internally.

Thanks and let me know how things end up after your C++ meeting!

On Wed, Aug 23, 2017 at 4:20 PM, Jom O'Fisher <jomofis...@gmail.com> wrote:
> By gradle module projects, I just mean the leaf build.gradle files as
> opposed to the root build.gradle. By configurations, I mean Build Types
> (debug vs release) and Product Flavors (demo vs free vs paid). Hereafter I
> will use the term "variant" rather than "configuration" to be precise. See
> this write-up on build variants:
>
> https://developer.android.com/studio/build/build-variants.html#build-types
>
> This build matrix is constructed at the leaf build.gradle level. Native
> build in gradle allows you to set C/C++ flags individually for each variant
> so that you can define compiler flags (for example, -DFREE_VERSION).
>
> One thing to notice at this stage is that the same CMake target may be built
> with different compiler flags across different projects, build types, and
> product flavors. So in the general case, build outputs won't be the same.
>
> You asked which targets build when specifying path. By default, we build all
> targets that produce an .so. You can override this by setting
> externalNativeBuild.cmake.targets. For example,
>
> paid {
>   ...
>   externalNativeBuild {
> cmake {
>   ...
>   targets "native-lib-paid"
> }
>   }
> }
>
> As for your last question, the model we generally see used is that the main
> CMakeLists.txt is next to the leaf build.gradle such that this
> CMakeLists.txt doesn't couple with peer APK project CMakeLists.txt (though
> they may share common dependencies and settings). Otherwise, multiple APK
> projects would perform pretty much similar to yours--they would build
> targets per-leaf project and not share build outputs. As far as I can see
> your organization is just as valid so long as you only build the targets you
> need.
>
> Regarding native dependencies between java projects. We generally try to
> avoid making the CMake build depend on the gradle build (you should be able
> to replicate the CMake build from the command-line if you set the right
> flags). At the moment I don't see a way we could make things better without
> violating that tenet but that could be lack of imagination on my part.
>
> We'll definitely be discussing this use case at our next C++ meeting and
> I'll also be 

Re: [CMake] CMake + Gradle for Android

[Robert Dailey]

I'm not sure what you mean by "gradle module projects", but maybe
having some examples of what you mean by "configurations, C++ flags,
etc" might make it more clear.

Question: When specifying "path" for the CMakeLists.txt in the
build.gradle file, how do you know which targets to build? For
example, that run of CMake may generate 100 targets, but only 20 need
to build and be packaged (*.so files) with the APK. Do you just build
"all"? Is there a way to specify the target itself?

Thanks again. I'd still like to know more about what the ideal
organization is. I find it hard to believe that large android projects
rarely break things up into multiple, separate "components" that are
built independently. That's really the gist of what we're dealing with
here. Your typical "hello world" project likely will have only 1
CMakeLists.txt that is pretty self-contained, but all the
documentation I've looked at so far doesn't show the best way to
handle native library dependencies across java projects between
build.gradle files (or maybe I'm just not looking hard enough).

On Wed, Aug 23, 2017 at 1:02 PM, Jom O'Fisher <jomofis...@gmail.com> wrote:
> Thanks for the write-up Robert. Having thought about it, I don't believe we
> have a satisfying answer at the gradle level for this kind of organization.
> In the gradle model module projects are the unit of organization for
> configurations, C/C++ flags, etc. and that's something we're pretty much
> stuck with.
> Regarding just the redundant build issue, would something like ccache help?
> I know people have used it with ndk-build with success, I'm not sure about
> CMake but I don't see why that should make a difference.
>
>
>
> On Tue, Aug 22, 2017 at 10:27 AM, Robert Dailey <rcdailey.li...@gmail.com>
> wrote:
>>
>> Another reason to reduce the number of binary directories is that
>> there are different ways of managing third party libraries. One in
>> particular that we use is to clone a repository into the binary
>> directory and build all third party libs in real time based on a
>> toolchain file (Similar to the functionality provided by
>> ExternalProject module in CMake). This is repeated from scratch only
>> if the work hasn't already been done in the binary directory before.
>> By having more binary dirs than needed, this work is being done an
>> exponential amount of times which can result in a lot of wasted time
>> waiting. There are 1 time operations that multiple targets can benefit
>> from in a single binary tree, instead of 1 per unique target being
>> invoked.
>>
>> Sorry to keep responding: I'm just thinking of things as I go and
>> bringing them up, to shed light on some of the reasoning behind my
>> suggestions.
>>
>> On Tue, Aug 22, 2017 at 9:26 AM, Robert Dailey <rcdailey.li...@gmail.com>
>> wrote:
>> > Sorry I forgot to answer your last set of questions:
>> >
>> > CommonLib is indeed 2 things:
>> >
>> > * A common (static or shared) library for native code (most of our
>> > CMake targets specify CommonLib as a link dependency)
>> > * A common library for Java code (we do specify this as a dependency
>> > for most java targets in Gradle, specifically those under
>> > Applications/)
>> >
>> > On Mon, Aug 21, 2017 at 6:20 PM, Raymond Chiu <ch...@google.com> wrote:
>> >> Hi Robert,
>> >>
>> >> I work with Jom on the Android Studio team, and I would like to clarify
>> >> a
>> >> few things to better understand your situation.
>> >> You mentioned the project is intend to be cross platform.  Normally, in
>> >> such
>> >> situation, we expect there to be a single CMake root project to be
>> >> imported
>> >> into one of the Android library/application.  However, in your case,
>> >> there
>> >> are subprojects with Java code.
>> >>
>> >> Are the CMake code in App1/2/3 intended to be cross platform too?  Or
>> >> are
>> >> they Android specific code?  If they are meant to be cross platform,
>> >> how
>> >> does the Java code works on other platforms?  Or perhaps you added Java
>> >> binding in those subprojects just for Android?
>> >>
>> >> The build.gradle in CommonLib, what kind of Gradle project is that?
>> >> From
>> >> your description, it doesn't look like an Android library project.  Or
>> >> am I
>> >> mistaken and it also applies the android library plugin?
>> >>
>> >> Raymond
>> >>

Re: [CMake] CMake + Gradle for Android

[Robert Dailey]

Another reason to reduce the number of binary directories is that
there are different ways of managing third party libraries. One in
particular that we use is to clone a repository into the binary
directory and build all third party libs in real time based on a
toolchain file (Similar to the functionality provided by
ExternalProject module in CMake). This is repeated from scratch only
if the work hasn't already been done in the binary directory before.
By having more binary dirs than needed, this work is being done an
exponential amount of times which can result in a lot of wasted time
waiting. There are 1 time operations that multiple targets can benefit
from in a single binary tree, instead of 1 per unique target being
invoked.

Sorry to keep responding: I'm just thinking of things as I go and
bringing them up, to shed light on some of the reasoning behind my
suggestions.

On Tue, Aug 22, 2017 at 9:26 AM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> Sorry I forgot to answer your last set of questions:
>
> CommonLib is indeed 2 things:
>
> * A common (static or shared) library for native code (most of our
> CMake targets specify CommonLib as a link dependency)
> * A common library for Java code (we do specify this as a dependency
> for most java targets in Gradle, specifically those under
> Applications/)
>
> On Mon, Aug 21, 2017 at 6:20 PM, Raymond Chiu <ch...@google.com> wrote:
>> Hi Robert,
>>
>> I work with Jom on the Android Studio team, and I would like to clarify a
>> few things to better understand your situation.
>> You mentioned the project is intend to be cross platform.  Normally, in such
>> situation, we expect there to be a single CMake root project to be imported
>> into one of the Android library/application.  However, in your case, there
>> are subprojects with Java code.
>>
>> Are the CMake code in App1/2/3 intended to be cross platform too?  Or are
>> they Android specific code?  If they are meant to be cross platform, how
>> does the Java code works on other platforms?  Or perhaps you added Java
>> binding in those subprojects just for Android?
>>
>> The build.gradle in CommonLib, what kind of Gradle project is that?  From
>> your description, it doesn't look like an Android library project.  Or am I
>> mistaken and it also applies the android library plugin?
>>
>> Raymond
>>
>> On Mon, Aug 21, 2017 at 3:34 PM, Jom O'Fisher <jomofis...@gmail.com> wrote:
>>>
>>> + a colleague
>>>
>>> On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher <jomofis...@gmail.com>
>>> wrote:
>>>>
>>>> You can find that number like this:
>>>> - x = number of externalNativeBuild.cmake.path in your build.gradle files
>>>> - y = number of gradle configurations (like debug and release)
>>>> - z = number of ABIs that you build
>>>>
>>>> The result is x * y * z. To be more accurate, you should consider y and z
>>>> to be functions of each build.gradle file since these can vary.
>>>>
>>>> There is a second set of folders that hold the stripped versions of the
>>>> .so files that is purely managed by the android gradle plugin, so you might
>>>> consider the answer to be 2 * x * y * z.
>>>>
>>>> Hope this helps.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey <rcdailey.li...@gmail.com>
>>>> wrote:
>>>>>
>>>>> This definitely a bit better, but still requires the boilerplate in
>>>>> each leaf gradle file. But I can't seriously complain too much. I
>>>>> think I'm more concerned with the implications this has underneath.
>>>>> First, let me ask just to make sure I'm not misunderstanding: Does
>>>>> each `externalNativeBuild` entry essentially mean 1 CMAKE_BINARY_DIR?
>>>>> How many binary dirs do you manage internally and what determines when
>>>>> they get created?
>>>>>
>>>>> On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher <jomofis...@gmail.com>
>>>>> wrote:
>>>>> > Would it work for your scenario to provide properties in the root
>>>>> > build.gradle:
>>>>> >
>>>>> > ext {
>>>>> > cmakePath = file "CMakeLists.txt"
>>>>> > }
>>>>> >
>>>>> > And then consume them in the leaf app/build.gradle like this?
>>>>> >
>>>>> > externalNat

Re: [CMake] CMake + Gradle for Android

[Robert Dailey]

Sorry I forgot to answer your last set of questions:

CommonLib is indeed 2 things:

* A common (static or shared) library for native code (most of our
CMake targets specify CommonLib as a link dependency)
* A common library for Java code (we do specify this as a dependency
for most java targets in Gradle, specifically those under
Applications/)

On Mon, Aug 21, 2017 at 6:20 PM, Raymond Chiu <ch...@google.com> wrote:
> Hi Robert,
>
> I work with Jom on the Android Studio team, and I would like to clarify a
> few things to better understand your situation.
> You mentioned the project is intend to be cross platform.  Normally, in such
> situation, we expect there to be a single CMake root project to be imported
> into one of the Android library/application.  However, in your case, there
> are subprojects with Java code.
>
> Are the CMake code in App1/2/3 intended to be cross platform too?  Or are
> they Android specific code?  If they are meant to be cross platform, how
> does the Java code works on other platforms?  Or perhaps you added Java
> binding in those subprojects just for Android?
>
> The build.gradle in CommonLib, what kind of Gradle project is that?  From
> your description, it doesn't look like an Android library project.  Or am I
> mistaken and it also applies the android library plugin?
>
> Raymond
>
> On Mon, Aug 21, 2017 at 3:34 PM, Jom O'Fisher <jomofis...@gmail.com> wrote:
>>
>> + a colleague
>>
>> On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher <jomofis...@gmail.com>
>> wrote:
>>>
>>> You can find that number like this:
>>> - x = number of externalNativeBuild.cmake.path in your build.gradle files
>>> - y = number of gradle configurations (like debug and release)
>>> - z = number of ABIs that you build
>>>
>>> The result is x * y * z. To be more accurate, you should consider y and z
>>> to be functions of each build.gradle file since these can vary.
>>>
>>> There is a second set of folders that hold the stripped versions of the
>>> .so files that is purely managed by the android gradle plugin, so you might
>>> consider the answer to be 2 * x * y * z.
>>>
>>> Hope this helps.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey <rcdailey.li...@gmail.com>
>>> wrote:
>>>>
>>>> This definitely a bit better, but still requires the boilerplate in
>>>> each leaf gradle file. But I can't seriously complain too much. I
>>>> think I'm more concerned with the implications this has underneath.
>>>> First, let me ask just to make sure I'm not misunderstanding: Does
>>>> each `externalNativeBuild` entry essentially mean 1 CMAKE_BINARY_DIR?
>>>> How many binary dirs do you manage internally and what determines when
>>>> they get created?
>>>>
>>>> On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher <jomofis...@gmail.com>
>>>> wrote:
>>>> > Would it work for your scenario to provide properties in the root
>>>> > build.gradle:
>>>> >
>>>> > ext {
>>>> > cmakePath = file "CMakeLists.txt"
>>>> > }
>>>> >
>>>> > And then consume them in the leaf app/build.gradle like this?
>>>> >
>>>> > externalNativeBuild {
>>>> > cmake {
>>>> > path cmakePath
>>>> > }
>>>> > }
>>>> >
>>>> > It doesn't fully hide the details but it does centralize the
>>>> > information.
>>>> >
>>>> >
>>>> > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey
>>>> > <rcdailey.li...@gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> I wouldn't want to do that, it's too convoluted. I have other
>>>> >> platforms that use these CMake scripts as well. For example, I run on
>>>> >> Windows and Linux platforms as well to build the native code. Normal
>>>> >> CMake behavior is designed to work at a root then go downwards to
>>>> >> find
>>>> >> targets. However it seems Gradle wants to start at a subdirectory and
>>>> >> work its way up to the root, which is opposite of CMake's intended
>>>> >> behavior IMHO. Not only that but I want to avoid special-casing
>>>> >> behavior in CMake just for Android's use.
>>>> >>
>>>> >> At the mom

Re: [CMake] CMake + Gradle for Android

[Robert Dailey]

 Aug 21, 2017 at 6:20 PM, Raymond Chiu <ch...@google.com> wrote:
> Hi Robert,
>
> I work with Jom on the Android Studio team, and I would like to clarify a
> few things to better understand your situation.
> You mentioned the project is intend to be cross platform.  Normally, in such
> situation, we expect there to be a single CMake root project to be imported
> into one of the Android library/application.  However, in your case, there
> are subprojects with Java code.
>
> Are the CMake code in App1/2/3 intended to be cross platform too?  Or are
> they Android specific code?  If they are meant to be cross platform, how
> does the Java code works on other platforms?  Or perhaps you added Java
> binding in those subprojects just for Android?
>
> The build.gradle in CommonLib, what kind of Gradle project is that?  From
> your description, it doesn't look like an Android library project.  Or am I
> mistaken and it also applies the android library plugin?
>
> Raymond
>
> On Mon, Aug 21, 2017 at 3:34 PM, Jom O'Fisher <jomofis...@gmail.com> wrote:
>>
>> + a colleague
>>
>> On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher <jomofis...@gmail.com>
>> wrote:
>>>
>>> You can find that number like this:
>>> - x = number of externalNativeBuild.cmake.path in your build.gradle files
>>> - y = number of gradle configurations (like debug and release)
>>> - z = number of ABIs that you build
>>>
>>> The result is x * y * z. To be more accurate, you should consider y and z
>>> to be functions of each build.gradle file since these can vary.
>>>
>>> There is a second set of folders that hold the stripped versions of the
>>> .so files that is purely managed by the android gradle plugin, so you might
>>> consider the answer to be 2 * x * y * z.
>>>
>>> Hope this helps.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey <rcdailey.li...@gmail.com>
>>> wrote:
>>>>
>>>> This definitely a bit better, but still requires the boilerplate in
>>>> each leaf gradle file. But I can't seriously complain too much. I
>>>> think I'm more concerned with the implications this has underneath.
>>>> First, let me ask just to make sure I'm not misunderstanding: Does
>>>> each `externalNativeBuild` entry essentially mean 1 CMAKE_BINARY_DIR?
>>>> How many binary dirs do you manage internally and what determines when
>>>> they get created?
>>>>
>>>> On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher <jomofis...@gmail.com>
>>>> wrote:
>>>> > Would it work for your scenario to provide properties in the root
>>>> > build.gradle:
>>>> >
>>>> > ext {
>>>> > cmakePath = file "CMakeLists.txt"
>>>> > }
>>>> >
>>>> > And then consume them in the leaf app/build.gradle like this?
>>>> >
>>>> > externalNativeBuild {
>>>> > cmake {
>>>> > path cmakePath
>>>> > }
>>>> > }
>>>> >
>>>> > It doesn't fully hide the details but it does centralize the
>>>> > information.
>>>> >
>>>> >
>>>> > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey
>>>> > <rcdailey.li...@gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> I wouldn't want to do that, it's too convoluted. I have other
>>>> >> platforms that use these CMake scripts as well. For example, I run on
>>>> >> Windows and Linux platforms as well to build the native code. Normal
>>>> >> CMake behavior is designed to work at a root then go downwards to
>>>> >> find
>>>> >> targets. However it seems Gradle wants to start at a subdirectory and
>>>> >> work its way up to the root, which is opposite of CMake's intended
>>>> >> behavior IMHO. Not only that but I want to avoid special-casing
>>>> >> behavior in CMake just for Android's use.
>>>> >>
>>>> >> At the moment it feels like (again referring back to my previous
>>>> >> example structure) that both App2 and App3 each run CMake in
>>>> >> independent binary directories instead of sharing 1 binary directory
>>>> >> and building 2 targets inside of it. I prefer this behavior instead,
>>>&g

Re: [CMake] CMake + Gradle for Android

[Robert Dailey]

This definitely a bit better, but still requires the boilerplate in
each leaf gradle file. But I can't seriously complain too much. I
think I'm more concerned with the implications this has underneath.
First, let me ask just to make sure I'm not misunderstanding: Does
each `externalNativeBuild` entry essentially mean 1 CMAKE_BINARY_DIR?
How many binary dirs do you manage internally and what determines when
they get created?

On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher <jomofis...@gmail.com> wrote:
> Would it work for your scenario to provide properties in the root
> build.gradle:
>
> ext {
> cmakePath = file "CMakeLists.txt"
> }
>
> And then consume them in the leaf app/build.gradle like this?
>
> externalNativeBuild {
> cmake {
> path cmakePath
> }
> }
>
> It doesn't fully hide the details but it does centralize the information.
>
>
> On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey <rcdailey.li...@gmail.com>
> wrote:
>>
>> I wouldn't want to do that, it's too convoluted. I have other
>> platforms that use these CMake scripts as well. For example, I run on
>> Windows and Linux platforms as well to build the native code. Normal
>> CMake behavior is designed to work at a root then go downwards to find
>> targets. However it seems Gradle wants to start at a subdirectory and
>> work its way up to the root, which is opposite of CMake's intended
>> behavior IMHO. Not only that but I want to avoid special-casing
>> behavior in CMake just for Android's use.
>>
>> At the moment it feels like (again referring back to my previous
>> example structure) that both App2 and App3 each run CMake in
>> independent binary directories instead of sharing 1 binary directory
>> and building 2 targets inside of it. I prefer this behavior instead,
>> especially since it allows CMake to operate as it was intended. I
>> think it's a common case that projects will define multiple targets
>> starting from a single root, and expect multiple APKs or java
>> dependencies to be built within it.
>>
>> If I'm misunderstanding or making false assumptions please let me know.
>>
>>
>>
>> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher <jomofis...@gmail.com>
>> wrote:
>> > Would it work for your situation for the leaf CMakeLists.txt to include
>> > the
>> > root CMakeLists.txt? Then have the leaf-specific logic in the leaf
>> > CMakeLists.txt?
>> >
>> >
>> >
>> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey
>> > <rcdailey.li...@gmail.com>
>> > wrote:
>> >>
>> >> Basically, yes. We have this sort of structure:
>> >>
>> >> /
>> >> Applications/
>> >> App1/
>> >> build.gradle
>> >> CMakeLists.txt
>> >> App2/
>> >> build.gradle
>> >> CMakeLists.txt
>> >> App3/
>> >> build.gradle
>> >> CMakeLists.txt
>> >> CommonLib/
>> >> build.gradle
>> >> CMakeLists.txt
>> >> CMakeLists.txt
>> >>
>> >> The libs are defined as follows:
>> >>
>> >> * CommonLib is a static library (java code builds into a library)
>> >> * No dependencies of its own
>> >> * App1 is a shared library (java code builds into a library)
>> >> * Dependencies (both java & native): CommonLib
>> >> * App2 is a shared library (java code builds into an APK)
>> >>* Dependencies (both java & native): App1, CommonLib
>> >> * App3 is a shared library (java code builds into an APK)
>> >>* Dependencies (both java & native): CommonLib
>> >>
>> >> In all cases, CMake must be invoked starting at the root
>> >> CMakeLists.txt 1 time. Each target can be built from the same binary
>> >> directory after that. Previously with ANT, I was building all native
>> >> targets first, then moved libs to appropriate directories so that the
>> >> 'ant' command would package the libs.
>> >>
>> >> For gradle, I wanted to avoid redundantly specifying the root
>> >> directory in each leaf-level project directory. Using the example
>> >> above, the leaf-level directories in this case would be App1, App2,
>> >> App3, and CommonLib. However I think we only specify the native CMake
>> >> stuff for the java targets that actually output an APK (

Re: [CMake] CMake + Gradle for Android

[Robert Dailey]

I wouldn't want to do that, it's too convoluted. I have other
platforms that use these CMake scripts as well. For example, I run on
Windows and Linux platforms as well to build the native code. Normal
CMake behavior is designed to work at a root then go downwards to find
targets. However it seems Gradle wants to start at a subdirectory and
work its way up to the root, which is opposite of CMake's intended
behavior IMHO. Not only that but I want to avoid special-casing
behavior in CMake just for Android's use.

At the moment it feels like (again referring back to my previous
example structure) that both App2 and App3 each run CMake in
independent binary directories instead of sharing 1 binary directory
and building 2 targets inside of it. I prefer this behavior instead,
especially since it allows CMake to operate as it was intended. I
think it's a common case that projects will define multiple targets
starting from a single root, and expect multiple APKs or java
dependencies to be built within it.

If I'm misunderstanding or making false assumptions please let me know.



On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher <jomofis...@gmail.com> wrote:
> Would it work for your situation for the leaf CMakeLists.txt to include the
> root CMakeLists.txt? Then have the leaf-specific logic in the leaf
> CMakeLists.txt?
>
>
>
> On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey <rcdailey.li...@gmail.com>
> wrote:
>>
>> Basically, yes. We have this sort of structure:
>>
>> /
>> Applications/
>> App1/
>> build.gradle
>> CMakeLists.txt
>> App2/
>> build.gradle
>> CMakeLists.txt
>> App3/
>> build.gradle
>> CMakeLists.txt
>> CommonLib/
>> build.gradle
>> CMakeLists.txt
>> CMakeLists.txt
>>
>> The libs are defined as follows:
>>
>> * CommonLib is a static library (java code builds into a library)
>> * No dependencies of its own
>> * App1 is a shared library (java code builds into a library)
>> * Dependencies (both java & native): CommonLib
>> * App2 is a shared library (java code builds into an APK)
>>* Dependencies (both java & native): App1, CommonLib
>> * App3 is a shared library (java code builds into an APK)
>>* Dependencies (both java & native): CommonLib
>>
>> In all cases, CMake must be invoked starting at the root
>> CMakeLists.txt 1 time. Each target can be built from the same binary
>> directory after that. Previously with ANT, I was building all native
>> targets first, then moved libs to appropriate directories so that the
>> 'ant' command would package the libs.
>>
>> For gradle, I wanted to avoid redundantly specifying the root
>> directory in each leaf-level project directory. Using the example
>> above, the leaf-level directories in this case would be App1, App2,
>> App3, and CommonLib. However I think we only specify the native CMake
>> stuff for the java targets that actually output an APK (that would be
>> App2 and App3 only).
>>
>> The ultimate goal is to specify stuff that doesn't change per
>> independent "module" of ours at the top level so it is transitive /
>> inherited. Then only specify the differences (e.g. the native CMake
>> target to build) in the leaf build gradle files. However you indicated
>> this isn't possible.
>>
>>
>>
>> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher <jomofis...@gmail.com>
>> wrote:
>> > What you're doing already sounds correct. You can't directly specify
>> > CMakeLists.txt from the top-level build.gradle. Recommendation is that
>> > it
>> > should be specified from the build.gradle of the module of the APK. Is
>> > the
>> > issue that you have multiple APK modules that all reference the same
>> > CMake
>> > libraries?
>> >
>> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey
>> > <rcdailey.li...@gmail.com>
>> > wrote:
>> >>
>> >> Thanks this is very helpful. The other question I have is: Is there a
>> >> place to centrally specify the root CMakeLists.txt? Basically, I want
>> >> to specify the CMake root in 1 place, and have targets (defined
>> >> further down in subdirectories) that require APK packaging to specify
>> >> only the native target name that should be built & packaged.
>> >>
>> >> At the moment we specify the root CMakeLists.txt by walking up the
>> >> tree, paths like "../../../../CMakeLists.txt". I think this s

Re: [CMake] CMake + Gradle for Android

[Robert Dailey]

Basically, yes. We have this sort of structure:

/
Applications/
App1/
build.gradle
CMakeLists.txt
App2/
build.gradle
CMakeLists.txt
App3/
build.gradle
CMakeLists.txt
CommonLib/
build.gradle
CMakeLists.txt
CMakeLists.txt

The libs are defined as follows:

* CommonLib is a static library (java code builds into a library)
* No dependencies of its own
* App1 is a shared library (java code builds into a library)
* Dependencies (both java & native): CommonLib
* App2 is a shared library (java code builds into an APK)
   * Dependencies (both java & native): App1, CommonLib
* App3 is a shared library (java code builds into an APK)
   * Dependencies (both java & native): CommonLib

In all cases, CMake must be invoked starting at the root
CMakeLists.txt 1 time. Each target can be built from the same binary
directory after that. Previously with ANT, I was building all native
targets first, then moved libs to appropriate directories so that the
'ant' command would package the libs.

For gradle, I wanted to avoid redundantly specifying the root
directory in each leaf-level project directory. Using the example
above, the leaf-level directories in this case would be App1, App2,
App3, and CommonLib. However I think we only specify the native CMake
stuff for the java targets that actually output an APK (that would be
App2 and App3 only).

The ultimate goal is to specify stuff that doesn't change per
independent "module" of ours at the top level so it is transitive /
inherited. Then only specify the differences (e.g. the native CMake
target to build) in the leaf build gradle files. However you indicated
this isn't possible.



On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher <jomofis...@gmail.com> wrote:
> What you're doing already sounds correct. You can't directly specify
> CMakeLists.txt from the top-level build.gradle. Recommendation is that it
> should be specified from the build.gradle of the module of the APK. Is the
> issue that you have multiple APK modules that all reference the same CMake
> libraries?
>
> On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey <rcdailey.li...@gmail.com>
> wrote:
>>
>> Thanks this is very helpful. The other question I have is: Is there a
>> place to centrally specify the root CMakeLists.txt? Basically, I want
>> to specify the CMake root in 1 place, and have targets (defined
>> further down in subdirectories) that require APK packaging to specify
>> only the native target name that should be built & packaged.
>>
>> At the moment we specify the root CMakeLists.txt by walking up the
>> tree, paths like "../../../../CMakeLists.txt". I think this should be
>> put at the top-level build gradle file if possible. Is this doable at
>> the moment? What is the recommended setup?
>>
>> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher <jomofis...@gmail.com>
>> wrote:
>> > Gradle does introspection on the CMake build to find .so targets and
>> > those
>> > get packaged.
>> > There is also a special case for stl/runtime .so files from the NDK.
>> > Any additional .so files need to specified in build.gradle using jniDirs
>> >
>> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey
>> > <rcdailey.li...@gmail.com>
>> > wrote:
>> >>
>> >> How exactly does Gradle package *.so files in an APK? I know that ANT
>> >> used to do this for any libs under "libs/". Does Gradle do some
>> >> introspection into CMake targets to see if outputs are *.so, and copy
>> >> those to some location if needed? What about libraries like
>> >> libgnustl_shared.so that come with the NDK? I'd like to know if any
>> >> manual copy steps are needed in CMake to put outputs in proper
>> >> locations for the APK build step. I had to do this when using ANT.
>> >>
>> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher <jomofis...@gmail.com>
>> >> wrote:
>> >> > 1) There is a folder created for each ABI under the project module
>> >> > folder
>> >> > (so unique per module per ABI)
>> >> > 2) Gradle doesn't specify language level though you can choose to
>> >> > specify it
>> >> > yourself from the build.gradle. This doc does a pretty good job of
>> >> > explaining which variables are set by Gradle:
>> >> > https://developer.android.com/ndk/guides/cmake.html#variables.
>> >> > Philosophically, we try to set as little as we can get away with. In
>> >> > particular, the 

Re: [CMake] CMake + Gradle for Android

[Robert Dailey]

Thanks this is very helpful. The other question I have is: Is there a
place to centrally specify the root CMakeLists.txt? Basically, I want
to specify the CMake root in 1 place, and have targets (defined
further down in subdirectories) that require APK packaging to specify
only the native target name that should be built & packaged.

At the moment we specify the root CMakeLists.txt by walking up the
tree, paths like "../../../../CMakeLists.txt". I think this should be
put at the top-level build gradle file if possible. Is this doable at
the moment? What is the recommended setup?

On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher <jomofis...@gmail.com> wrote:
> Gradle does introspection on the CMake build to find .so targets and those
> get packaged.
> There is also a special case for stl/runtime .so files from the NDK.
> Any additional .so files need to specified in build.gradle using jniDirs
>
> On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey <rcdailey.li...@gmail.com>
> wrote:
>>
>> How exactly does Gradle package *.so files in an APK? I know that ANT
>> used to do this for any libs under "libs/". Does Gradle do some
>> introspection into CMake targets to see if outputs are *.so, and copy
>> those to some location if needed? What about libraries like
>> libgnustl_shared.so that come with the NDK? I'd like to know if any
>> manual copy steps are needed in CMake to put outputs in proper
>> locations for the APK build step. I had to do this when using ANT.
>>
>> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher <jomofis...@gmail.com> wrote:
>> > 1) There is a folder created for each ABI under the project module
>> > folder
>> > (so unique per module per ABI)
>> > 2) Gradle doesn't specify language level though you can choose to
>> > specify it
>> > yourself from the build.gradle. This doc does a pretty good job of
>> > explaining which variables are set by Gradle:
>> > https://developer.android.com/ndk/guides/cmake.html#variables.
>> > Philosophically, we try to set as little as we can get away with. In
>> > particular, the section titled "Understanding the CMake build command"
>> > lays
>> > out exactly what we set. You can also see the folders we specify (one
>> > per
>> > module per ABI)
>> > 3) Not sure I understand this.
>> >
>> > The other document worth taking a look at (if you haven't already) is:
>> > https://developer.android.com/studio/projects/add-native-code.html
>> >
>> >
>> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey <rcdailey.li...@gmail.com>
>> > wrote:
>> >>
>> >> Thanks Jom
>> >>
>> >> Honestly, I prefer option 1 to work simply because that's how Google's
>> >> officially supporting CMake. But it also has debugging which is the #1
>> >> reason for me.
>> >>
>> >> However, I'd like to understand a lot more about how the integration
>> >> really happens. For example, I have these questions:
>> >>
>> >> 1) How, internally, are CMake build directories managed? Do you
>> >> generate 1 per unique android project? What about for each specific
>> >> platform (x86, armeabi-v7a, etc)?
>> >> 2) Last time I looked into CMake integration, things defined inside
>> >> the CMake scripts were ignored because they are specified at the
>> >> command line. Namely, all of those settings that are driven by the
>> >> Gradle configuration (CXX language level was one in particular I
>> >> think; I specify C++14 support via CMake, but I recall this being
>> >> overridden from outside)?
>> >> 3) How redundant is it to configure individual libraries via the
>> >> gradle scripts? In my previous attempts, I wanted to define common
>> >> stuff for CMake / native code at the root gradle or settings file, and
>> >> only define the differences in the actual gradle build files for each
>> >> corresponding Java target (like, defining the name of the native
>> >> (shared library) target in Gradle, but the command line invocation, -D
>> >> CMake settings, etc would all be common and defined at the root).
>> >>
>> >> The TLDR is, the closer we can stay to CMake's way of doing things and
>> >> keep CMake-related settings self-contained to the CMake scripts
>> >> themselves, the better. This also makes cross-platform easier (we
>> >> build the native code in Windows, for example, so having settings
>> >> specified in the 

Re: [CMake] CMake + Gradle for Android

[Robert Dailey]

How exactly does Gradle package *.so files in an APK? I know that ANT
used to do this for any libs under "libs/". Does Gradle do some
introspection into CMake targets to see if outputs are *.so, and copy
those to some location if needed? What about libraries like
libgnustl_shared.so that come with the NDK? I'd like to know if any
manual copy steps are needed in CMake to put outputs in proper
locations for the APK build step. I had to do this when using ANT.

On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher <jomofis...@gmail.com> wrote:
> 1) There is a folder created for each ABI under the project module folder
> (so unique per module per ABI)
> 2) Gradle doesn't specify language level though you can choose to specify it
> yourself from the build.gradle. This doc does a pretty good job of
> explaining which variables are set by Gradle:
> https://developer.android.com/ndk/guides/cmake.html#variables.
> Philosophically, we try to set as little as we can get away with. In
> particular, the section titled "Understanding the CMake build command" lays
> out exactly what we set. You can also see the folders we specify (one per
> module per ABI)
> 3) Not sure I understand this.
>
> The other document worth taking a look at (if you haven't already) is:
> https://developer.android.com/studio/projects/add-native-code.html
>
>
> On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey <rcdailey.li...@gmail.com>
> wrote:
>>
>> Thanks Jom
>>
>> Honestly, I prefer option 1 to work simply because that's how Google's
>> officially supporting CMake. But it also has debugging which is the #1
>> reason for me.
>>
>> However, I'd like to understand a lot more about how the integration
>> really happens. For example, I have these questions:
>>
>> 1) How, internally, are CMake build directories managed? Do you
>> generate 1 per unique android project? What about for each specific
>> platform (x86, armeabi-v7a, etc)?
>> 2) Last time I looked into CMake integration, things defined inside
>> the CMake scripts were ignored because they are specified at the
>> command line. Namely, all of those settings that are driven by the
>> Gradle configuration (CXX language level was one in particular I
>> think; I specify C++14 support via CMake, but I recall this being
>> overridden from outside)?
>> 3) How redundant is it to configure individual libraries via the
>> gradle scripts? In my previous attempts, I wanted to define common
>> stuff for CMake / native code at the root gradle or settings file, and
>> only define the differences in the actual gradle build files for each
>> corresponding Java target (like, defining the name of the native
>> (shared library) target in Gradle, but the command line invocation, -D
>> CMake settings, etc would all be common and defined at the root).
>>
>> The TLDR is, the closer we can stay to CMake's way of doing things and
>> keep CMake-related settings self-contained to the CMake scripts
>> themselves, the better. This also makes cross-platform easier (we
>> build the native code in Windows, for example, so having settings
>> specified in the gradle files do not carry over to other platforms.
>> Namely, settings that are not platform specific like the C++ language
>> level).
>>
>> If there's a detailed document / wiki I can read on the intrinsics of
>> CMake integration in Gradle / Android Studio, I'd love to read it.
>> Otherwise, I hope you won't mind if I pick your brain as questions
>> come up. I think I'm going to try option 1 for now and see how it
>> goes. It's just black box for me because unlike option 2, I have very
>> little control over what happens after building the shared libraries,
>> and to make up for that I need to really get a deep understanding of
>> how it works so I can make sure I code my CMake scripts properly for
>> not only Android, but my other platforms as well (non-Android
>> platforms).
>>
>> Thanks again.
>>
>> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher <jomofis...@gmail.com> wrote:
>> > Either option can work fine. Disclosure: I work on Android Studio and
>> > was
>> > the one that added CMake support.
>> >
>> > Option (1) is the way it's designed to work and we're working toward
>> > getting
>> > rid of the need for the CMake fork. I can't really say when that will
>> > happen
>> > but if you can get away with an older CMake for now then I'd go this
>> > way.
>> > As you mentioned, option (1) will allow you to view your source file
>> > structure in Android Studio, edit files, and debug using the bui

[CMake] RUN_TESTS does not rebuild targets?

[Robert Dailey]

Why does the RUN_TESTS target in Visual Studio IDE not first build the
unit tests before running them? If my tests are out of date, I expect
the executables to be built first and then CTest to be invoked.
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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 + Gradle for Android

[Robert Dailey]

Thanks Jom

Honestly, I prefer option 1 to work simply because that's how Google's
officially supporting CMake. But it also has debugging which is the #1
reason for me.

However, I'd like to understand a lot more about how the integration
really happens. For example, I have these questions:

1) How, internally, are CMake build directories managed? Do you
generate 1 per unique android project? What about for each specific
platform (x86, armeabi-v7a, etc)?
2) Last time I looked into CMake integration, things defined inside
the CMake scripts were ignored because they are specified at the
command line. Namely, all of those settings that are driven by the
Gradle configuration (CXX language level was one in particular I
think; I specify C++14 support via CMake, but I recall this being
overridden from outside)?
3) How redundant is it to configure individual libraries via the
gradle scripts? In my previous attempts, I wanted to define common
stuff for CMake / native code at the root gradle or settings file, and
only define the differences in the actual gradle build files for each
corresponding Java target (like, defining the name of the native
(shared library) target in Gradle, but the command line invocation, -D
CMake settings, etc would all be common and defined at the root).

The TLDR is, the closer we can stay to CMake's way of doing things and
keep CMake-related settings self-contained to the CMake scripts
themselves, the better. This also makes cross-platform easier (we
build the native code in Windows, for example, so having settings
specified in the gradle files do not carry over to other platforms.
Namely, settings that are not platform specific like the C++ language
level).

If there's a detailed document / wiki I can read on the intrinsics of
CMake integration in Gradle / Android Studio, I'd love to read it.
Otherwise, I hope you won't mind if I pick your brain as questions
come up. I think I'm going to try option 1 for now and see how it
goes. It's just black box for me because unlike option 2, I have very
little control over what happens after building the shared libraries,
and to make up for that I need to really get a deep understanding of
how it works so I can make sure I code my CMake scripts properly for
not only Android, but my other platforms as well (non-Android
platforms).

Thanks again.

On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher <jomofis...@gmail.com> wrote:
> Either option can work fine. Disclosure: I work on Android Studio and was
> the one that added CMake support.
>
> Option (1) is the way it's designed to work and we're working toward getting
> rid of the need for the CMake fork. I can't really say when that will happen
> but if you can get away with an older CMake for now then I'd go this way.
> As you mentioned, option (1) will allow you to view your source file
> structure in Android Studio, edit files, and debug using the built-in
> debugging support.
>
> To get option (2) to work, you can use jniDirs setting to tell Android
> Gradle where to pick up your built .so files (see
> https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7).
> I'm not aware of any projects that use this approach but it should work in
> principal.
>
> I hope this helps,
> Jomo
>
>
> On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey <rcdailey.li...@gmail.com>
> wrote:
>>
>> Right now I have custom targets set to execute the "ant release"
>> command after my native targets are built. Part of that command
>> involves copying *.so files to the libs/armeabi-v7a directory so they
>> get packaged in an APK.
>>
>> When switching to gradle, I have two options:
>>
>> 1. Gradle drives CMake: This means using Android Studio and being
>> locked down to Google's fork of CMake which is a few major releases
>> behind. I see that as a negative.
>>
>> 2. CMake drives Gradle: This would be the same or similar to what I'm
>> already doing: The custom targets I have would execute gradle as a
>> separate build step, instead of running ant commands. I'm not too
>> familiar with Gradle, so I'm not sure how you tell it where your
>> shared libraries are for the APK packaging steps.
>>
>> Which does everyone recommend? Is anyone using one of these setups
>> successfully? The downside to option 2 is probably no on-device native
>> debugging since Android Studio probably can't handle gradle projects
>> without any external CMake builds set up.
>>
>> Would like some general direction & advice before I move away from
>> ANT. 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
>>
>> 

[CMake] CMake + Gradle for Android

[Robert Dailey]

Right now I have custom targets set to execute the "ant release"
command after my native targets are built. Part of that command
involves copying *.so files to the libs/armeabi-v7a directory so they
get packaged in an APK.

When switching to gradle, I have two options:

1. Gradle drives CMake: This means using Android Studio and being
locked down to Google's fork of CMake which is a few major releases
behind. I see that as a negative.

2. CMake drives Gradle: This would be the same or similar to what I'm
already doing: The custom targets I have would execute gradle as a
separate build step, instead of running ant commands. I'm not too
familiar with Gradle, so I'm not sure how you tell it where your
shared libraries are for the APK packaging steps.

Which does everyone recommend? Is anyone using one of these setups
successfully? The downside to option 2 is probably no on-device native
debugging since Android Studio probably can't handle gradle projects
without any external CMake builds set up.

Would like some general direction & advice before I move away from
ANT. 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] How to do platform specific setup?

[Robert Dailey]

According to Brad King, toolchain files are not intended for what I'm
asking about. I recall someone mentioning some built-in modules in
CMake that are responsible for toolchain and platform setup, that can
be overridden somehow. This is different from toolchain files AFAIK. I
apologize for being vague, but I was hoping someone would recognize
what I'm talking about.

On Wed, Jul 26, 2017 at 10:29 AM, Mario Werner
<mario.wer...@iaik.tugraz.at> wrote:
> Hi Robert,
>
> I usually do all my platform and compiler specific customization in a
> toolchain file [1]. Such a toolchain file is more or less standard CMake
> script which get executed before the root CMakeLists.txt from the
> project is processed. When invoking cmake for the first time you simply
> specify which toolchain file you want to use by adding
> `-DCMAKE_TOOLCHAIN_FILE=` as parameter.
>
> Note that the idea of a toolchain file is that the file is customized
> exactly for your environment.
>
> Best regards,
> Mario
>
>
> [1] https://cmake.org/Wiki/CMake_Cross_Compiling#The_toolchain_file
>
> On 2017-07-19 21:22, Robert Dailey wrote:
>> So in one of my top level CMake scripts, I have this:
>>
>> ```
>> if( ANDROID )
>> include( android )
>> _setup_android_platform()
>> elseif( UNIX )
>> include( unix )
>> _setup_unix_platform()
>> endif()
>>
>> if( CMAKE_CXX_COMPILER_ID STREQUAL "Clang" )
>> include( clang )
>> _setup_clang_toolchain()
>> elseif( CMAKE_CXX_COMPILER_ID STREQUAL "MSVC" )
>> include( msvc )
>> _setup_msvc_toolchain()
>> endif()
>> ```
>>
>> This allows me to set up various global things used by all targets
>> defined by CMake. An example of what android's does:
>>
>> ```
>> macro( _setup_android_platform )
>> # Forward the android ABI from CMake to a custom variable for
>> portability to other toolchains
>> if( CMAKE_ANDROID_ARCH_ABI )
>> set( ANDROID_ABI ${CMAKE_ANDROID_ARCH_ABI} )
>> endif()
>>
>> # Forcefully disable testing while cross compiling for Android
>> platform. It doesn't make sense
>> # to build tests, since we can't run them natively. We build tests
>> on a separate platform.
>> set( BUILD_TESTING OFF CACHE BOOL "Do not build unit tests when
>> cross compiling for Android" FORCE )
>>
>> android_ndk_import_module_cpufeatures()
>> android_ndk_import_module_native_app_glue()
>>
>> # Export ANativeActivity_onCreate(),
>> # Refer to: https://github.com/android-ndk/ndk/issues/381.
>> set( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -u
>> ANativeActivity_onCreate" )
>>
>> add_definitions(
>> -DANDROID
>> )
>> endmacro()
>> ```
>>
>> And clang:
>>
>> ```
>> macro( _setup_clang_toolchain )
>> # Disable certain clang warnings
>> # These spam like crazy; disable for now
>> add_compile_options(
>> -Wno-inconsistent-missing-override
>> )
>>
>> # Clang 3.8.0 on Ubuntu was failing with -Wno-expansion-to-defined.
>> # Version 3.8.2 in NDK r14b seems ok with it.
>> if( CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 3.8.2 )
>> add_compile_options(
>> -Wno-expansion-to-defined
>> )
>> endif()
>>
>> set( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}
>> -Wl,--no-undefined" )
>> endmacro()
>> ```
>>
>> I feel like there is a better way. I recall there being some built-in
>> way to override CMake's platform specific setup modules, but I don't
>> know anything about it. Can someone offer some advice on if there is a
>> built in way to do 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
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Boost is planning to switch from bjam to CMake!

[Robert Dailey]

Very exciting news... hopefully it works out! Congratulations to CMake
for this; this is huge support for CMake and shows it is becoming way
more popular (not that it wasn't already!)

https://lists.boost.org/boost-interest/2017/07/0162.php?utm_content=buffera6a82_medium=social_source=plus.google.com_campaign=buffer
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] file(COPY) is copying even if file hasn't changed

[Robert Dailey]

FYI I decided to file an issue for this here:
https://gitlab.kitware.com/cmake/cmake/issues/17087

On Wed, Jul 19, 2017 at 4:05 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> Oh also file(INSTALL) does the same thing; the "Installing:" message
> gets printed each time for the same file, and never says that it is
> "up to date".
>
> On Wed, Jul 19, 2017 at 4:04 PM, Robert Dailey <rcdailey.li...@gmail.com> 
> wrote:
>> According to the documentation for file(COPY) [1]: "Copying preserves
>> input file timestamps, and optimizes out a file if it exists at the
>> destination with the same timestamp"
>>
>> However this is not the case. My host OS is Windows 10 and I'm using
>> CMake 3.9.0-rc5. Each time my CMakeLists.txt is run, the file(COPY) is
>> copying over the file even if it didn't change. The "date modified"
>> timestamp for the destination file is updated. I do not want the copy
>> to occur if the source file has not changed (this appears to be the
>> intended behavior based on the documentation).
>>
>> Am I understanding this correctly or is this a bug?
>>
>> [1]: https://cmake.org/cmake/help/latest/command/file.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] file(COPY) is copying even if file hasn't changed

[Robert Dailey]

Oh also file(INSTALL) does the same thing; the "Installing:" message
gets printed each time for the same file, and never says that it is
"up to date".

On Wed, Jul 19, 2017 at 4:04 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> According to the documentation for file(COPY) [1]: "Copying preserves
> input file timestamps, and optimizes out a file if it exists at the
> destination with the same timestamp"
>
> However this is not the case. My host OS is Windows 10 and I'm using
> CMake 3.9.0-rc5. Each time my CMakeLists.txt is run, the file(COPY) is
> copying over the file even if it didn't change. The "date modified"
> timestamp for the destination file is updated. I do not want the copy
> to occur if the source file has not changed (this appears to be the
> intended behavior based on the documentation).
>
> Am I understanding this correctly or is this a bug?
>
> [1]: https://cmake.org/cmake/help/latest/command/file.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] file(COPY) is copying even if file hasn't changed

[Robert Dailey]

According to the documentation for file(COPY) [1]: "Copying preserves
input file timestamps, and optimizes out a file if it exists at the
destination with the same timestamp"

However this is not the case. My host OS is Windows 10 and I'm using
CMake 3.9.0-rc5. Each time my CMakeLists.txt is run, the file(COPY) is
copying over the file even if it didn't change. The "date modified"
timestamp for the destination file is updated. I do not want the copy
to occur if the source file has not changed (this appears to be the
intended behavior based on the documentation).

Am I understanding this correctly or is this a bug?

[1]: https://cmake.org/cmake/help/latest/command/file.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] How to do platform specific setup?

[Robert Dailey]

So in one of my top level CMake scripts, I have this:

```
if( ANDROID )
include( android )
_setup_android_platform()
elseif( UNIX )
include( unix )
_setup_unix_platform()
endif()

if( CMAKE_CXX_COMPILER_ID STREQUAL "Clang" )
include( clang )
_setup_clang_toolchain()
elseif( CMAKE_CXX_COMPILER_ID STREQUAL "MSVC" )
include( msvc )
_setup_msvc_toolchain()
endif()
```

This allows me to set up various global things used by all targets
defined by CMake. An example of what android's does:

```
macro( _setup_android_platform )
# Forward the android ABI from CMake to a custom variable for
portability to other toolchains
if( CMAKE_ANDROID_ARCH_ABI )
set( ANDROID_ABI ${CMAKE_ANDROID_ARCH_ABI} )
endif()

# Forcefully disable testing while cross compiling for Android
platform. It doesn't make sense
# to build tests, since we can't run them natively. We build tests
on a separate platform.
set( BUILD_TESTING OFF CACHE BOOL "Do not build unit tests when
cross compiling for Android" FORCE )

android_ndk_import_module_cpufeatures()
android_ndk_import_module_native_app_glue()

# Export ANativeActivity_onCreate(),
# Refer to: https://github.com/android-ndk/ndk/issues/381.
set( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -u
ANativeActivity_onCreate" )

add_definitions(
-DANDROID
)
endmacro()
```

And clang:

```
macro( _setup_clang_toolchain )
# Disable certain clang warnings
# These spam like crazy; disable for now
add_compile_options(
-Wno-inconsistent-missing-override
)

# Clang 3.8.0 on Ubuntu was failing with -Wno-expansion-to-defined.
# Version 3.8.2 in NDK r14b seems ok with it.
if( CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 3.8.2 )
add_compile_options(
-Wno-expansion-to-defined
)
endif()

set( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}
-Wl,--no-undefined" )
endmacro()
```

I feel like there is a better way. I recall there being some built-in
way to override CMake's platform specific setup modules, but I don't
know anything about it. Can someone offer some advice on if there is a
built in way to do 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

Re: [CMake] Best way to append "--no-undefined" to shared link flags?

[Robert Dailey]

+CMake dev list

After googling I came up with this:


set( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}
-Wl,--no-undefined" )

After talking more with the NDK devs on github though, they seem to
indicate this should happen by default (or at least, it does with the
CMake that ships with the NDK according to Dan Albert). Does
--no-defined get specified by default for other platforms? Or is it
just Android that isn't getting it?

On Tue, Jul 18, 2017 at 3:38 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> For only compilers that support it (I guess any clang/gcc compiler?),
> I want my shared libs to link with "--no-undefined". What is the best
> (most modern) way using CMake 3.9.0 and forward to do this? Is it
> still to explicitly set CMAKE_SHARED_LINKER_FLAGS? How does this
> impact using toolchain files and cross compiling? I don't want to wipe
> out any existing flags, and I'm not sure of the exact syntax the
> command line options need to follow.
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Best way to append "--no-undefined" to shared link flags?

[Robert Dailey]

+CMake dev list

After googling I came up with this:


set( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}
-Wl,--no-undefined" )

After talking more with the NDK devs on github though, they seem to
indicate this should happen by default (or at least, it does with the
CMake that ships with the NDK according to Dan Albert). Does
--no-defined get specified by default for other platforms? Or is it
just Android that isn't getting it?

On Tue, Jul 18, 2017 at 3:38 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> For only compilers that support it (I guess any clang/gcc compiler?),
> I want my shared libs to link with "--no-undefined". What is the best
> (most modern) way using CMake 3.9.0 and forward to do this? Is it
> still to explicitly set CMAKE_SHARED_LINKER_FLAGS? How does this
> impact using toolchain files and cross compiling? I don't want to wipe
> out any existing flags, and I'm not sure of the exact syntax the
> command line options need to follow.
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Best way to append "--no-undefined" to shared link flags?

[Robert Dailey]

For only compilers that support it (I guess any clang/gcc compiler?),
I want my shared libs to link with "--no-undefined". What is the best
(most modern) way using CMake 3.9.0 and forward to do this? Is it
still to explicitly set CMAKE_SHARED_LINKER_FLAGS? How does this
impact using toolchain files and cross compiling? I don't want to wipe
out any existing flags, and I'm not sure of the exact syntax the
command line options need to follow.
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Transitive behavior of target_link_libraries between shared/static

[Robert Dailey]

Maybe I'm missing something here, but that linked article doesn't
really address my specific case. And his definition is technically
correct, as long as CMake is smart enough to handle the case where
(again in my example) A does not need to be explicitly linked to D
because they were already linked into B (since it's a shared library).
Link dependencies of B should be firewalled to downstream targets.
However, include dependencies for example may be needed downstream
since B's public headers may require them.

I could create a sandbox using my example to verify the behavior, but
i thought it would be quicker to ask here to see if anyone knew.

On Tue, Jul 18, 2017 at 12:15 PM, Hendrik Sattler
<p...@hendrik-sattler.de> wrote:
>
>
> Am 18. Juli 2017 18:02:40 MESZ schrieb Eric Noulard <eric.noul...@gmail.com>:
>>2017-07-17 17:31 GMT+02:00 Robert Dailey <rcdailey.li...@gmail.com>:
>>
>>> Suppose I have the following:
>>>
>>> ```
>>> add_library( A STATIC ${files} )
>>>
>>> add_library( B SHARED ${more_files} )
>>> target_link_libraries( B PUBLIC A )
>>>
>>> add_library( C STATIC ${even_more_files} )
>>> target_link_libraries( C PUBLIC B )
>>>
>>>
>>> add_executable( D ${exe_files} )
>>> target_link_libraries( D PRIVATE C )
>>> ```
>>>
>>> Does the linker command for target `D` ever see target A's static
>>link
>>> library? I'm hoping the only thing the linker gets is `libB.so` and
>>> `libC.a`, without `libA.a`.
>>>
>>
>>I guess it does otherwise you may be missing symbols.
>>As explain by Peter some time ago:
>>  https://cmake.org/pipermail/cmake/2017-April/065347.html
>>when you
>>target_link_libraries( B PUBLIC A )
>>
>>with A being STATIC you do not really link A into B (which is shared in
>>your example)
>
> You confused PUBLIC and INTERFACE in your response.
> target_link_libraries( B PUBLIC A ) DOES link A into B but only the symbols 
> needed by B.
>
> The link to the old post has it all right.
>
> HS
>
>
> --
> 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] Copying target output file to another directory

[Robert Dailey]

This is part of a lot of complex logic to integrate ANT into CMake as
transparently as possible to assist in integrating Android support
(building Java and APK). So I do not use INSTALL targets. This is an
implementation detail since the libs are required in a specific
directory so that ANT can package them into the APK for distribution
to Android devices.

On Tue, Jul 18, 2017 at 10:54 AM, Robert Maynard
<robert.mayn...@kitware.com> wrote:
> Question: Is there a specific reason why you don't want to do this as
> part of the install step?
>
> If this can't be done at install time, you can look at using
> add_custom_command Generating File signature with a target dependency
> on ${target}
>
> On Tue, Jul 18, 2017 at 10:44 AM, Robert Dailey
> <rcdailey.li...@gmail.com> wrote:
>> So I need to copy the output *.so from a target to an arbitrary
>> directory outside the CMAKE_BINARY_DIR. I tried doing this as a post
>> build event using generator expressions:
>>
>> add_custom_command(
>> TARGET ${target} POST_BUILD VERBATIM
>> COMMAND ${CMAKE_COMMAND} -E copy "$<TARGET_FILE:${target}>" ${dir}
>> )
>>
>> This fails because I'm running it outside of the directory where
>> ${target} is defined:
>>
>> CMake Error at Core/CMake/third-party.cmake:86 (add_custom_command):
>>   TARGET 'MagickCore' was not created in this directory.
>>
>>
>> How can I do this without moving my add_custom_command() to the same
>> directory that created the target? I need to add all the custom
>> commands at the end of generation because it depends on certain global
>> properties which are not completely done being set until the very end.
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: 
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more 
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/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] Copying target output file to another directory

[Robert Dailey]

So I need to copy the output *.so from a target to an arbitrary
directory outside the CMAKE_BINARY_DIR. I tried doing this as a post
build event using generator expressions:

add_custom_command(
TARGET ${target} POST_BUILD VERBATIM
COMMAND ${CMAKE_COMMAND} -E copy "$" ${dir}
)

This fails because I'm running it outside of the directory where
${target} is defined:

CMake Error at Core/CMake/third-party.cmake:86 (add_custom_command):
  TARGET 'MagickCore' was not created in this directory.


How can I do this without moving my add_custom_command() to the same
directory that created the target? I need to add all the custom
commands at the end of generation because it depends on certain global
properties which are not completely done being set until the very end.
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Transitive behavior of target_link_libraries between shared/static

[Robert Dailey]

Suppose I have the following:

```
add_library( A STATIC ${files} )

add_library( B SHARED ${more_files} )
target_link_libraries( B PUBLIC A )

add_library( C STATIC ${even_more_files} )
target_link_libraries( C PUBLIC B )


add_executable( D ${exe_files} )
target_link_libraries( D PRIVATE C )
```

Does the linker command for target `D` ever see target A's static link
library? I'm hoping the only thing the linker gets is `libB.so` and
`libC.a`, without `libA.a`.

It seems like A to everyone outside of B should just be a set of
public include directories and compile definitions, since the link
file aspect of it should be hidden across shared library boundaries.
Hoping someone can explain how this works. I want to make sure static
libs sitting behind shared libs in the dependency tree do not get
exposed.
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Built-in way to detect if a root script is standalone or not?

[Robert Dailey]

I have logic similar to this in some of my middleware libraries' root
CMakeLists.txt:

if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR )
set( STANDALONE TRUE )
endif()

Is there a built-in way to detect 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

[CMake] ExternalProject with toolchain files for cross compiling?

[Robert Dailey]

So I'd like to use ExternalProject_Add() to pull down an external git
repository that builds with CMake. I'd like it to use the same
toolchain file that I"m using in my parent projects. However, I do not
see any explicit documentation regarding toolchain support for
ExternalProject. Do I need to explicitly pass down CMake arguments
with the toolchain file? Or does this happen transitively? I'm using
CMake 3.9.0
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Using USES_TERMINAL in ExternalProject.cmake

[Robert Dailey]

In my own personal usage of add_custom_target() and
add_custom_command(), I use USES_TERMINAL so that stdout and stderr
from commands that are actively running get output in more real-time.
I've only tested this using the Ninja generator, and seems to improve
output behavior.

Without it, I notice that commands that take a long time to complete
result in a large window of silence. When the command completes, all
of its output (sometimes thousands of lines) gets spit out all at
once. This makes things weird, especially for things like download
progress.

I noticed that ExternalProject_Add() has this same issue when run from
Ninja. I do not see real-time output of the progress. Would it work to
set USES_TERMINAL for most (if not all) custom commands and targets in
ExternalProject.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