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

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

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

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

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

[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

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

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

[Robert Dailey]

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

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

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

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

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] 3.9.0-rc3: CMAKE_ANDROID_NDK_DEPRECATED_HEADERS doesn't work outside of toolchain

[Robert Dailey]

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

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

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

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

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] FindDoxygen is doing find_package() when it is included

[Robert Dailey]

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

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

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

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] FindDoxygen is doing find_package() when it is included

[Robert Dailey]

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

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

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] add_custom_target(): When is VERBATIM appropriate?

[Robert Dailey]

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

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

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

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

Powered by www.kitware.com

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

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

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

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

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

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

[Robert Dailey]

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

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

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

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

Powered by www.kitware.com

Please keep

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

[Robert Dailey]

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

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

A
A_doxygen
B
B_doxygen
C
C_doxygen

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

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

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

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

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

Would love feedback and advice on this!
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] 3.9.0-rc3: CMAKE_ANDROID_NDK_DEPRECATED_HEADERS doesn't work outside of toolchain

[Robert Dailey]

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

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

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

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

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

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

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] 3.9.0-rc3: CMAKE_ANDROID_NDK_DEPRECATED_HEADERS doesn't work outside of toolchain

[Robert Dailey]

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

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

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

Powered by www.kitware.com

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

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

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

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

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

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

[Robert Dailey]

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

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

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] 3.9.0-rc3: CMAKE_ANDROID_NDK_DEPRECATED_HEADERS doesn't work outside of toolchain

[Robert Dailey]

Hi,

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

set( CMAKE_ANDROID_NDK_DEPRECATED_HEADERS 1 )

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

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

Thanks in advance.
-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Robert Dailey]

Oh I'm using CMake 3.9.0 RC3

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

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Bug with CMAKE_ASM_COMPILER and Android NDK

[Robert Dailey]

So I have two environment variables:

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

In my toolchain file, I do this:



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

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

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



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


enable_language(ASM)


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

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

Logs:


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

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

  is not a full path to an existing compiler tool.

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


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

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Trouble with FindPNG module

[Robert Dailey]

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

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

Thanks.

On Mon, Apr 24, 2017 at 1:17 PM, Roger Leigh <rle...@codelibre.net> wrote:
> On 24/04/2017 15:54, Robert Dailey wrote:
>>
>> Sorry to bump; any info on this? I'm completely blocked :-(
>>
>> On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey <rcdailey.li...@gmail.com>
>> wrote:
>>>
>>> I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
>>>
>>> find_package(PNG REQUIRED)
>>>
>>> Which gives me the output in CMake:
>>>
>>> Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50")
>>>
>>> The CMakeCache.txt file has these variables set:
>>>
>>> PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND
>>> PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND
>>> PNG_PNG_INCLUDE_DIR:PATH=/usr/include
>>>
>>> So it found the headers, but not the libs. Why did it not find the
>>> libs? Note that my version of Ubuntu is 64-bit, and I've installed the
>>> 32-bit libs like so:
>>>
>>> $ sudo apt-get install libpng12-dev:i386
>>>
>>> Would the find module be confused because it is trying to find the
>>> 64-bit library? What's the issue?
>
>
> Sounds like that's exactly the problem.  You can only have one libpng
> *development* package installed at once.  You probably want the regular
> "libpng-dev" package installed if you want to build against the standard
> libpng.
>
> What's your goal here?  Why did you install a single i386 development
> package?
>
> If you want to build i386 binaries, it's usually simpler to build in a
> virtual machine, i.e. a chroot, container, full VM or whatever you like,
> where you have a fully 32-bit environment.  The multiarch library support is
> primarily intended for *deploying and running* 32-bit code rather than
> development.  While you can use it for development, it gets painful due to
> the conflicts with the headers and other bits in the native development
> packages.
>
>
> Regards,
> Roger
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Trouble with FindPNG module

[Robert Dailey]

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

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



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



Via the following toolchain file contents:



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



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

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

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Trouble with FindPNG module

[Robert Dailey]

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

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

Powered by www.kitware.com

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

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

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

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

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

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

[Robert Dailey]

Thanks Florent!

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

On Thu, Apr 20, 2017 at 4:14 PM, Florent Castelli
<florent.caste...@gmail.com> wrote:
> I just came back from some holidays now, I'll try to update the MR with the
> latest changes soon next week!
>
> /Florent
>
> On Apr 20, 2017 10:10 PM, "Robert Dailey" <rcdailey.li...@gmail.com> wrote:
>>
>> I may pick this up, because right now it's impossible to use libc++
>> (LLVM) with an API less than 21 since that's when clang was
>> introduced. libc is missing too many symbols that are required by
>> libc++ below API 21.
>>
>> On Thu, Apr 20, 2017 at 2:52 PM, Ben Boeckel <ben.boec...@kitware.com>
>> wrote:
>> > On Thu, Apr 20, 2017 at 14:31:58 -0500, Robert Dailey wrote:
>> >> Google is supporting unified headers for sysroot as of NDK r14:
>> >>
>> >>
>> >> https://android.googlesource.com/platform/ndk/+/master/docs/UnifiedHeaders.md
>> >>
>> >> Is there a plan to add support for this natively into CMake?
>> >
>> > There is a merge request that is in-progress, but was closed due to
>> > inactivity (lack of time on Florent's side it seems). I'd recommend
>> > coordinating with Florent to resurrect the MR.
>> >
>> > https://gitlab.kitware.com/cmake/cmake/merge_requests/492
>> >
>> > --Ben
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Robert Dailey]

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

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

Powered by www.kitware.com

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

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

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

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

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

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

[Robert Dailey]

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

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

Is there a plan to add support for this natively into CMake?
-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Robert Dailey]

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

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

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

Powered by www.kitware.com

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

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

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

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

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

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

[Robert Dailey]

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

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

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)

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

Thanks again!!

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

Powered by www.kitware.com

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

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

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

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

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

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

[Robert Dailey]

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

Is it just me or is this really nasty?


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


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

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

Powered by www.kitware.com

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

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

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

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

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

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

[Robert Dailey]

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

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

it returns a "root path" of:

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

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

What should I do?

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

Powered by www.kitware.com

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

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

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

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

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

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

[Robert Dailey]

Brad,

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

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

find_program( PYTHON_EXECUTABLE python )

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

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

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

E:/Python35/

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

Re: [cmake-developers] enable_language behavior change

[Robert Dailey]

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

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

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

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

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

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] enable_language behavior change

[Robert Dailey]

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

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

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] enable_language behavior change

[Robert Dailey]

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

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

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

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

Powered by www.kitware.com

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

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

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

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

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

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

[Robert Dailey]

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

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

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

Powered by www.kitware.com

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

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

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

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

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

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

[Robert Dailey]

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

Here is the result:

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

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

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

let me know.
-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Robert Dailey]

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

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

find_program(GIT_EXECUTABLE git)

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

My PATH on Windows is as follows:

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

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

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

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Multi-line strings with indentation ignored

[Robert Dailey]

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


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

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

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

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

Powered by www.kitware.com

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

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

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

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

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

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

[Robert Dailey]

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

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

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

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

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

[Robert Dailey]

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

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

Powered by www.kitware.com

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

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

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

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

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

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

[Robert Dailey]

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

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

Powered by www.kitware.com

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

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

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

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

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

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

[Robert Dailey]

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

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

Powered by www.kitware.com

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

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

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

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

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

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

[Robert Dailey]

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

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

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

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

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

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

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Android Support

[Robert Dailey]

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

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

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

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Android Support

[Robert Dailey]

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

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

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Android Support

[Robert Dailey]

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

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

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

Thanks in advance!!
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Android Support

[Robert Dailey]

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

On Fri, Aug 12, 2016 at 10:26 AM, Robert Goulet
 wrote:
> That's super awesome Brad!
>
> Looking forward to try this out!
>
> -Original Message-
> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf 
> Of Brad King
> Sent: Friday, August 12, 2016 11:13 AM
> To: cmake-developers@cmake.org
> Subject: [cmake-developers] Android Support
>
> Hi Folks,
>
> I've implemented native support for cross-compiling to Android with CMake 
> using either an Android NDK or an Android Standalone Toolchain.
> I plan to include this in the CMake 3.7 release.
>
> Please see the MR here:
>
>   https://gitlab.kitware.com/cmake/cmake/merge_requests/62
>
> This enables building with simple toolchain files, or even without one:
>
>   $ cmake ../src -DCMAKE_SYSTEM_NAME=Android -DCMAKE_ANDROID_NDK=/path/to/ndk
>
> Note that interface compatibility with popular third-party Android toolchain 
> files is a non-goal of this work (though we should not break them too much).
> Instead I'd like to make the support feel native within CMake.  For example, 
> the Android API level is naturally specified by CMAKE_SYSTEM_VERSION.
>
> If you're interested in this support please fetch the MR branch and try it 
> out.  The Help/manual/cmake-toolchains.7.rst manual has been updated with 
> documentation about how to use this.
>
> -Brad
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Robert Dailey]

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

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

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

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

Powered by www.

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

[Robert Dailey]

Hello,

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

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

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

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

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

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

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

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

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Natvis support in Visual Studio

[Robert Dailey]

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

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

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


0001-Support-NATVIS-files-in-VS10-generator.patch
Description: Binary data
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Natvis support in Visual Studio

[Robert Dailey]

Hello CMake devs,

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

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

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

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

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

Guidance is appreciated!
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS

[Robert Dailey]

I have the following CMake code:

get_property( predefined_folder GLOBAL PROPERTY PREDEFINED_TARGETS_FOLDER )

set_target_properties( ALL_BUILD PROPERTIES FOLDER ${predefined_folder} )

if( BUILD_TESTING )
set_target_properties( RUN_TESTS PROPERTIES FOLDER "Testing" )
endif()

However this fails stating those targets do not exist. Is there a way
I can make this work? I'd like to organize these CMake targets in my
own way in the Visual Studio solution. There have been topics
regarding this on the mailing list in the past, but they have gone
unanswered.

Specifically, why are these targets treated as if they do not exist?
Does CMake only allow you to set properties on targets created
directly by the scripts themselves (i.e. no built-in targets can be
affected)?

I'm happy to contribute a patch to this if needed.

Thanks in advance.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu

[Robert Dailey]

On Wed, Jan 13, 2016 at 3:16 PM, Alexander Neundorf <neund...@kde.org> wrote:
> On Wednesday, January 13, 2016 10:16:23 Robert Dailey wrote:
>> Running version 3.2.2 on Ubuntu 15. I run the following command:
>>
>> $ cmake .. -G"KDevelop3" -DCMAKE_C_COMPILER=gcc-4.9
>> -DCMAKE_CXX_COMPILER=g++-4.9 -DCMAKE_BUILD_TYPE=$config
>> -DCMAKE_TOOLCHAIN_FILE="../toolchains/linux_i686.toolchain.cmake"
>
> are you sure you actually want to use the KDevelop3 generator ?
> This is for the KDE3 version, and you are probably using the KDE4 version of
> KDevelop ? For that you don't need these generated project files.
>
> Actually I was thinking about removing this generator, because KDevelop3 is
> really really old, not sure whether it is still available in current Linux
> distributions.

This might explain it. I just installed kdevelop on Ubuntu 15, not
sure what version it is using. I also have never used kdevelop before
so I was not aware that it had built in support for CMake. I saw it in
the list of generators so I naturally assumed I had to use it. Note
that Eclipse is in kind of the same boat, as far as which versions it
supports and its not immediately obvious.
-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] Assertion hit in CMake for KDevelop on Ubuntu

[Robert Dailey]

On Wed, Jan 13, 2016 at 12:36 PM, Brad King <brad.k...@kitware.com> wrote:
> On 01/13/2016 11:16 AM, Robert Dailey wrote:
>> Running version 3.2.2 on Ubuntu 15. I run the following command:
> [snip]
>> cmake: ../../Source/cmTarget.cxx:722: void
>> cmTarget::GetSourceFiles(std::vector<std::__cxx11::basic_string
>>> &, const string&) const: Assertion `this->GetType() !=
>> INTERFACE_LIBRARY' failed.
>> ../frontend/Core/CMake/helper-scripts/kdevelop-linux.sh: line 13:
>> 21545 Aborted (core dumped) cmake "$DIR/../../.."
>
> Please try running with CMake 3.4 or 'master' to see if it still
> happens.  There has been substantial refactoring of this code
> since 3.2.
>
> Thanks,
> -Brad
>

3.4 isn't available to me on Ubuntu 15; do you have a custom PPA I can
add to grab the latest CMake debian package?
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu

[Robert Dailey]

Running version 3.2.2 on Ubuntu 15. I run the following command:

$ cmake .. -G"KDevelop3" -DCMAKE_C_COMPILER=gcc-4.9
-DCMAKE_CXX_COMPILER=g++-4.9 -DCMAKE_BUILD_TYPE=$config
-DCMAKE_TOOLCHAIN_FILE="../toolchains/linux_i686.toolchain.cmake"



My toolchain file is specified as follows:

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_VERSION 1)
set(CMAKE_SYSTEM_PROCESSOR "i686")

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -m32" CACHE STRING "c++ flags")
set(CMAKE_C_FLAGS   "${CMAKE_C_FLAGS} -m32" CACHE STRING "c flags")



I get the following output when I generate for KDevelop. Why is CMake
not properly generating my projects? Based on what the assertion says,
I do actually define some interface libraries, mostly to create
"dummy" targets for my third party libraries. If I have a library with
only headers and no binaries or libs, I will make them as interface
libraries. I will post a sample of this below the output below.

-- The C compiler identification is GNU 4.9.3
-- The CXX compiler identification is GNU 4.9.3
-- Check for working C compiler: /usr/bin/gcc-4.9
-- Check for working C compiler: /usr/bin/gcc-4.9 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/g++-4.9
-- Check for working CXX compiler: /usr/bin/g++-4.9 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Generating copy_dlls for configurations: Debug
-- + UI> Core/UI/CMakeLists.txt
-- + WebServices   > Core/WebServices/CMakeLists.txt
-- + Barcode   > Core/Barcode/CMakeLists.txt
-- + TestUtils > Core/UI/TestUtils/CMakeLists.txt
-- + DynamicUI > Applications/DynamicUI/CMakeLists.txt
-- + OrderEntry> Applications/OrderEntry/CMakeLists.txt
-- + PATT  > Applications/PATT/CMakeLists.txt
-- + EmailClub > Applications/EmailClub/CMakeLists.txt
-- + Survey> Applications/Survey/CMakeLists.txt
-- + SettingsManager   > Applications/SettingsManager/CMakeLists.txt
-- + zFacebook > Applications/zFacebook/CMakeLists.txt
-- + Loyalty   > Applications/Loyalty/CMakeLists.txt
-- + MessagingModule   > Applications/MessagingModule/CMakeLists.txt
-- + zApp  > Applications/zApp/CMakeLists.txt
-- + zApp_Library  > Applications/zApp/CMakeLists.txt
-- Configuring done
cmake: ../../Source/cmTarget.cxx:722: void
cmTarget::GetSourceFiles(std::vector&, const string&) const: Assertion `this->GetType() !=
INTERFACE_LIBRARY' failed.
../frontend/Core/CMake/helper-scripts/kdevelop-linux.sh: line 13:
21545 Aborted (core dumped) cmake "$DIR/../../.."
-G"KDevelop3" -DCMAKE_C_COMPILER=gcc-4.9 -DCMAKE_CXX_COMPILER=g++-4.9
-DCMAKE_BUILD_TYPE=$config
-DCMAKE_TOOLCHAIN_FILE="$DIR/../toolchains/linux_i686.toolchain.cmake"



Sample of how I define interface libraries (contents of one of my
CMakeLists.txt):

set( project_name Catch )
add_library( ${project_name} INTERFACE )
target_include_directories( ${project_name} INTERFACE include )
-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] Code style auto-formatting

[Robert Dailey]

On Wed, Nov 18, 2015 at 5:47 PM, Alan W. Irwin
<ir...@beluga.phys.uvic.ca> wrote:
> On 2015-11-17 16:44-0600 Robert Dailey wrote:
>
>> [...]Honestly all of this is a matter of taste, I don't expect
>> everyone to agree on every little detail. I think the goal should be
>> to strive for something a little more modern (determined by general
>> consensus in the open source community) and most importantly enforce
>> it. No matter what style you choose, consistency is what matters the
>> most.
>
>
> Well said.  We used similar principles in the PLplot case and the
> resulting code style consistency (implemented with uncrustify in that
> case) within that project has been quite beneficial.

Tonight I will do some testing and submit a patch + example files
converted to the style Brad suggested. We can fine-tune it as needed.
I'll probably format cmake.h / cmake.cxx as an example.

Note also that there is an extension for Visual Studio that lets you
run clang format. I've used this and it's pretty useful. The link
below (bottom of the page) has the link to download the plugin.

http://llvm.org/builds/
-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] Code style auto-formatting

[Robert Dailey]

On Thu, Nov 19, 2015 at 8:26 AM, Brad King <brad.k...@kitware.com> wrote:
> On 11/19/2015 09:22 AM, Robert Dailey wrote:
>> Tonight I will do some testing and submit a patch + example files
>> converted to the style Brad suggested. We can fine-tune it as needed.
>
> Rather than a patch please work on a script to perform the conversion.
> Then at any time we can choose to run the script as the one-shot conversion
> and commit as a robot user.  Any sweeping patch would be too big to
> post to the list anyway.  Ideally the script should be simple enough
> to cut-n-paste into a shell so we can just record it in the commit
> message.
>
> See this commit for an example of this approach:
>
>  https://cmake.org/gitweb?p=cmake.git;a=commit;h=7bbaa428

Sorry for the confusion, what I meant was a patch with just the clang
format file in it. I do not plan to perform any conversions in any
patch.
-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] Code style auto-formatting

[Robert Dailey]

On Tue, Nov 17, 2015 at 3:35 PM, Brad King <brad.k...@kitware.com> wrote:
> Hi Folks,
>
> For reference, the current CMake indentation style is:
>
>  https://en.wikipedia.org/wiki/Indent_style#Whitesmiths_style
>
> but with 2 space indentation instead of 4 as shown on that page.
> The style was popular when CMake started (year 2000) but is not
> very widely used anymore.
>
> For Emacs, see attached file (that comes from VTK folks that also
> use the style.  For Vim one can use something like:
>
>  set tabstop=2 shiftwidth=2 expandtab
>  set cindent cinoptions={1s,l1,g0,c0,t0,(0,W1s
>
> Since the style is not very popular anymore I don't know whether
> other editors can be configured for it.  For this reason I've
> been thinking about proposing use of clang-format for a while.
> We could also consider switching to a more widely-used indentation
> style outright and using clang-format to define it formally.
>
> On 11/17/2015 04:29 PM, Daniel Pfeifer wrote:
>> On Tue, Nov 17, 2015 at 10:12 PM, Robert Dailey wrote:
>>> How did you guys want to approach reformatting inconsistently
>>> formatted source files?
>>
>> I would say: As a byproduct.
>>
>> Adding a .clang-format file to CMake would be greatly appreciated. It
>> can be used to ensure that refactorings and new contributions follow
>> exactly the predefined style. However, changing existing code simply
>> because it does not match the style is something that should be
>> refused.
>
> I think we could do a one-shot conversion of existing sources.  This
> was done in our CMakeLists.txt and *.cmake files a while ago to update
> capitalization style.  We recorded the commit as done by a robot user
> instead of a specific developer's name.  It is not that hard to
> re-invoke `git blame` to see past any blame poisoning such a commit
> might introduce.  For that cost, we gain consistency in the code
> and simplicity for patches.

So I'd like to propose first of all that we explore a new coding
standard. Let's make the changes we want to make. In the meantime, I
will reflect that discussion into a clang format file. I'll provide it
as an attachment here, along with some samples of conversions of
existing files in the code base so we can get an idea of how it looks.

I agree with Brad about a mass one time conversion. BTW you can
instruct git blame to ignore whitespace changes; this would
effectively ignore the "whitespace robot" commit entirely (so you
don't even have to use a robot user if you didn't want to, but it's
still a great idea and doesn't hurt).

To get some discussion going, take a look at the BasedOnStyle option
in clang format:
http://clang.llvm.org/docs/ClangFormatStyleOptions.html

There are a couple of predefined formats you could use here. Obviously
choosing one of those as a base and then fine-tuning it to your needs
would probably be the best approach. Mozilla's standard looks
reasonable. Honestly all of this is a matter of taste, I don't expect
everyone to agree on every little detail. I think the goal should be
to strive for something a little more modern (determined by general
consensus in the open source community) and most importantly enforce
it. No matter what style you choose, consistency is what matters the
most.
-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] Code style auto-formatting

[Robert Dailey]

On Tue, Nov 17, 2015 at 6:57 AM, Paul Smith  wrote:
> On Tue, 2015-11-17 at 08:14 +, Stuermer, Michael SP/HZA-ZSEP wrote:
>> In short, there is no fully automated style checking. If someone would
>> come up with a tool & configuration I would love to use this. So far I
>> tested astyle and the C++ edition of ReSharper (unfortunately quite
>> expensive).
>
> We've used uncrustify with excellent results in the past, FWIW.
>
> It is a major hassle though.  We did a complete code reformat with a
> well-defined process, and then had all developers apply reformatting to
> their personal branches using a particular set of steps to minimize the
> insanity.
>

I'm willing to assist with a clang format file, I've worked with them
in the past. This means contributions will likely come with multiple
patch files, some containing only whitespace fixups per the clang
format.

How did you guys want to approach reformatting inconsistently
formatted source files?

Git has plenty of options to ignore whitespace in different ways, so
it's really a non-issue as far as auditability of logs and diffs go.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] User may now specify toolset through CMake GUI

[Robert Dailey]

Hello everyone,

I apologize for the long hiatus, but I've finally gotten back to this.
I've implemented the suggestions here:

* deleteCache() now clears the toolset
* When the binary directory changes, the GUI now reloads the toolset
(The toolset isn't used by anything except the first-time dialog right
now, so this wasn't a necessary change, but I did it on request. We
only show the toolset on first time setup anyway, so even if you go to
an existing binary dir it won't let you change the toolset again via
the setup wizard).
* I've refactored the generator factories a bit to specify whether or
not they support toolsets.
* A lot of places that used to only pass around a list of generator
names now pass around a composite object of name+toolset support
(boolean flag). This eventually propagates to QT code so it can
determine which generators support toolsets, so it can show/hide the
toolset fields as the generator selection changes (in the first-time
dialog).

Note that I was not able to test Code Blocks. Documentation states it
has toolset support, but I didn't see a generator for code blocks
(only an extra generator, which I did not touch). I left the extra
generators in the code base alone.

Please see the attached revised patch and let me know if there is
anything else I can do. I tested on Windows 10, using Visual Studio
2013. I installed the CTP_Nov2013 compiler and tested the toolchain
field, all is working great!

On Thu, Feb 19, 2015 at 8:19 AM, Brad King <brad.k...@kitware.com> wrote:
> On 02/17/2015 01:46 PM, Brad King wrote:
>> On 02/17/2015 01:43 PM, Robert Dailey wrote:
>>> Of course right now only Visual Studio and XCode support the toolset
>>> parameter
>>
>> Correct.  Furthermore it is supported only for VS >= 10.
>
> In response to this issue:
>
>  http://www.cmake.org/Bug/view.php?id=15411
>
> I've made this change:
>
>  cmake-gui: Reset generator platform and toolset on configure (#15411)
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1ade687d
>
> Please account for that while developing your changes.
>
> Thanks,
> -Brad
>


0001-User-may-now-specify-toolset-through-CMake-GUI.patch
Description: Binary data
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] User may now specify toolset through CMake GUI

[Robert Dailey]

I also forgot to mention that this patch is based on the 'next'
branch. Originally it was based on 'master' but I rebased it to
'next'. Let me know if this is correct. I'm assuming the master branch
is used for maintenance releases only and would not be appropriate for
such a change.

On Mon, Nov 16, 2015 at 9:50 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> Hello everyone,
>
> I apologize for the long hiatus, but I've finally gotten back to this.
> I've implemented the suggestions here:
>
> * deleteCache() now clears the toolset
> * When the binary directory changes, the GUI now reloads the toolset
> (The toolset isn't used by anything except the first-time dialog right
> now, so this wasn't a necessary change, but I did it on request. We
> only show the toolset on first time setup anyway, so even if you go to
> an existing binary dir it won't let you change the toolset again via
> the setup wizard).
> * I've refactored the generator factories a bit to specify whether or
> not they support toolsets.
> * A lot of places that used to only pass around a list of generator
> names now pass around a composite object of name+toolset support
> (boolean flag). This eventually propagates to QT code so it can
> determine which generators support toolsets, so it can show/hide the
> toolset fields as the generator selection changes (in the first-time
> dialog).
>
> Note that I was not able to test Code Blocks. Documentation states it
> has toolset support, but I didn't see a generator for code blocks
> (only an extra generator, which I did not touch). I left the extra
> generators in the code base alone.
>
> Please see the attached revised patch and let me know if there is
> anything else I can do. I tested on Windows 10, using Visual Studio
> 2013. I installed the CTP_Nov2013 compiler and tested the toolchain
> field, all is working great!
>
> On Thu, Feb 19, 2015 at 8:19 AM, Brad King <brad.k...@kitware.com> wrote:
>> On 02/17/2015 01:46 PM, Brad King wrote:
>>> On 02/17/2015 01:43 PM, Robert Dailey wrote:
>>>> Of course right now only Visual Studio and XCode support the toolset
>>>> parameter
>>>
>>> Correct.  Furthermore it is supported only for VS >= 10.
>>
>> In response to this issue:
>>
>>  http://www.cmake.org/Bug/view.php?id=15411
>>
>> I've made this change:
>>
>>  cmake-gui: Reset generator platform and toolset on configure (#15411)
>>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1ade687d
>>
>> Please account for that while developing your changes.
>>
>> Thanks,
>> -Brad
>>
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Code style auto-formatting

[Robert Dailey]

IMHO, the code style in the CMake code base is incredibly
inconsistent, but even the consistent style that is there is a giant
pain to follow by hand.

I'm constantly fighting my tooling's auto formatting. I prefer to keep
my code additions similar to surrounding code. Do you use some tool
such as clang-format to auto format code? This will make it easier to
make my style more consistent after my work is completed.

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

[cmake-developers] Visual Studio 2013 with CMake GUI on Windows

[Robert Dailey]

CMake requires Qt4, which is incompatible with VS 2013 officially. I
do not want to apply patches to get it working.

Is it possible to get CMake to use Qt5? I know this already supports
VS 2013. Is Qt5 backward compatible with Qt4 with regards to the
feature sets being utilized by CMake?

I do not have VS 2008 or 2010 available, unfortunately. I also do not
have a linux or mac platform to build on.
-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] Visual Studio 2013 with CMake GUI on Windows

[Robert Dailey]

On Fri, Nov 13, 2015 at 10:53 AM, Brad King <brad.k...@kitware.com> wrote:
> On 11/13/2015 11:42 AM, Robert Dailey wrote:
>> CMake requires Qt4, which is incompatible with VS 2013 officially. I
>> do not want to apply patches to get it working.
>>
>> Is it possible to get CMake to use Qt5?
>
> CMake already supports being built with Qt5 on Windows.
>
> Configure with CMAKE_PREFIX_PATH containing to the path to
> msvc2013_64_opengl and it should be found automatically.
> Ensure Qt5Widgets_DIR points to
>
>  msvc2013_64_opengl/lib/cmake/Qt5Widgets

Thank you Brad, I wasn't setting CMAKE_PREFIX_PATH because it didn't
show up by default in the list of cache variables after generating. I
added it manually and it just worked. At first all I was doing was
enabling QT dialog in config, regenerating, and then changed the path
that it wanted for qtmake.exe. When I pointed it at qtmake for Qt5, it
complained about requiring Qt4.
-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] C++11 support?

[Robert Dailey]

Just to be clear, does CMake code base allow for C++11 or higher? or
are you guys locked down to C++03?
-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] Bug in CMake GUI 3.2.1?

[Robert Dailey]

I am running on Windows 8.1. Screenshots attached.

On Mon, Apr 13, 2015 at 9:20 AM, Brad King brad.k...@kitware.com wrote:
 On 04/10/2015 12:26 PM, Robert Dailey wrote:
 I am noticing that after installing the official Windows installer for
 3.2.1 release, CMake GUI looks different. Menu options have GCC
 specific options and when I generate through the GUI for Visual Studio
 2013, my projects are missing preprocessor definitions like _WINDOWS,
 WIN32, etc.

 I don't see any of that behavior.  I would think such major breakage
 would have been reported pretty quickly, so something may be wrong
 locally for you.  From what environment are you running cmake-gui?

 -Brad
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] .gitattributes updates

[Robert Dailey]

Hey everyone,

This isn't a huge change but I think it is important.

I noticed that .gitattributes was not properly configured to utilize
modern Git features:

1. * text=auto to specify automatic line ending handling for files
that git detects as text files
2. Replace deprecated attribute specifications with newer versions
3. General cleanup and removal of redundant attributes

One patch file is a line-ending conversion that does nothing more than
replace CRLF with LF. This must be done since the goal is that all
files are stored natively as LF in the actual repository. Line ending
conversions are applied to the working copy as needed (e.g. LF - CRLF
on Windows for certain files, like VCPROJ)

Note that this isn't simply a cleanup change. There were actually
some things wrong with the current gitattributes:

1. Some files were not properly being handled by git
2. Git config settings on a per-machine basis affected the EOL
normalization in the repository

These changes will enforce consistency and ignore per-machine settings.

Let me know if the changes look acceptable. I'm happy to answer any questions.


0001-Add-automatic-EOL-handling-to-.gitattributes.patch
Description: Binary data


0002-Normalized-line-endings.patch
Description: Binary data
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] User may now specify toolset through CMake GUI

[Robert Dailey]

On Tue, Feb 17, 2015 at 12:08 PM, Brad King brad.k...@kitware.com wrote:
 On 02/17/2015 12:21 PM, Robert Dailey wrote:
 What would be the best way to handle detecting which generators support 
 toolset?

 The confusing piece I had to figure out last night is that there is
 simply no generator base class from which everything derives, there
 are 2 types: extra generators and generators.

 The extra generators are not of concern here.  They are only ever
 used in conjunction with real generators.  The base class for the
 latter is cmGlobalGenerator.  However, cmGlobalGeneratorFactory is
 also a candidate for this check since it exists before the actual
 generator is created.  You'll have to pick whichever works more
 cleanly for this use case.

Of course right now only Visual Studio and XCode support the toolset
parameter (according to the docs). These both happen to be global
generators. However, I was thinking of a case in the future where
Eclipse CDT4 or Code Blocks may support toolsets. Would these be
implemented through global generators anyway? Does it make sense for
extra generators to support toolset? Some educational explanation here
for my benefit would be appreciated.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] User may now specify toolset through CMake GUI

[Robert Dailey]

Fair points, I will make the changes.

What is the recommended practice for updating patches on mailing
lists? With pull requests it's easy because it picks up my changes I
push to my branch automatically. I think if I push another patch to
the mailing list it will start another email thread, which may cause
lost context since this email chain won't be connected to the new one
(not sure if that matters).

Thanks Brad.

On Mon, Feb 16, 2015 at 10:35 AM, Brad King brad.k...@kitware.com wrote:
 On 02/15/2015 03:27 PM, rcdailey.li...@gmail.com wrote:
 From: Robert Dailey rcdai...@gmail.com

 The -T parameter to CMake may now be specified through QtDialog
 (cmake-gui) via a new text field in the first-time configure
 wizard (below the generator chooser).

 Thanks for working on this.  I think QCMake::setBinaryDirectory
 also needs to check for CMAKE_GENERATOR_TOOLSET from an existing
 cache file much like it already does for CMAKE_GENERATOR.  One
 may currently use the Add Entry button to pre-define an entry
 for CMAKE_GENERATOR_TOOLSET to set this from the GUI indirectly.

 Since not all generators support this field, we should not present
 it when a non-supporting generator is selected.  This will need
 some type of query on the selected generator to be added.

 Thanks,
 -Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] How to work with QtDialog?

[Robert Dailey]

I'm making minor modifications to add -T support to cmake-gui.
However, I'm not familiar with how to develop CMake's GUI application.
Do I generate for Visual Studio 2013 (I'm on windows)? I'm able to
compile the QT dialog application and run it from Visual Studio,
however if I have to add new signals, i end up having to manually edit
the moc_* files. I assume those are generated.

Could I get some workflow tips? Thanks.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Need some pointers on learning the code

[Robert Dailey]

On Tue, May 28, 2013 at 8:22 AM, Brad King brad.k...@kitware.com wrote:
 On 05/26/2013 12:04 PM, Robert Dailey wrote:
 I haven't gotten a response yet, I guess you guys stay pretty busy :)

 Huh?  I responded here:

  
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6800/focus=6933

 Am I correct to assume that add_custom_command() still needs a CONFIG
 option to support varying numbers  names of output files per
 configuration, based on my previous description of the problem I'm
 facing?

 Yes, though I think we can use generator expressions as stated in my
 other response.

Sorry about that Brad, for some reason I didn't get your last response
in my inbox. It's not in spam either. Strange.

I like your idea of using an external script to handle this, however,
there is certain state I need access to from the last CMake run.
Specifically, I have a variable with all of the 'bin' directories
where DLLs can be found. To avoid recursive searching in my custom
target script to find them each time I build, I suppose I could store
them in a cache variable? I was just going to create a CMake script
that I run from the custom target.

The reason I went with custom commands to begin with is because I
originally used cmake's copy_if_different command, but it turned out
to be MUCH slower than the out of date checks that the custom command
did.
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Need some pointers on learning the code

[Robert Dailey]

On Wed, May 29, 2013 at 1:22 PM, Brad King brad.k...@kitware.com wrote:
 Configure the script with the list as part of its source using
 configure_file.

Simply brilliant. I love the ideas you're giving me here. I've been
using CMake for years but I still miss out on coming up with good
ideas like this.

 If you go with the external script approach use the file(COPY)
 command.  It uses a timestamp-based decision so incremental updates
 are very fast.  Underneath it is the same logic used by CMake in its
 implementation of make install.

Interesting, I always thought file(COPY) did a forced copy each time.
Going back over the documentation for it, I now see that this is
indeed documented but the wording is a bit strange so I never realized
this behavior.

Thanks a ton Brad, this saves me a ton of effort. However I still do
agree about generator expressions in OUTPUT, so I still plan to pick
this up when I can. 99% of the time I spend is digging through the
code  debugging things, to try to understand how things work.
--

Powered by www.kitware.com

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

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

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