Re: [cmake-developers] Android variables

[Ruslan Baratov via cmake-developers]

On 13-Nov-16 00:48, Florent Castelli wrote:
> On 12/11/2016 13:35, Ruslan Baratov wrote:
>> On 12-Nov-16 19:09, Florent Castelli wrote:
>>> On 12/11/2016 06:53, Ruslan Baratov wrote:
>>>> On 12-Nov-16 08:21, Florent Castelli wrote:
>>>>> On 10/11/2016 16:05, Ruslan Baratov via cmake-developers wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I wonder if it's possible to introduce next variables describing
>>>>>> Android
>>>>>> tools:
>>>>>> * C preprocessor. Similar to CMAKE_CXX_COMPILER the variable that
>>>>>> will
>>>>>> contain the path to preprocessor. Example:
>>>>>>* CMAKE_CXX_COMPILER =
>>>>>> /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++
>>>>>>
>>>>>>
>>>>>>* CMAKE_C_PREPROCESSOR =
>>>>>> /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-cpp
>>>>>>
>>>>>>
>>>>>> * ANDROID_TOOLCHAIN_MACHINE_NAME. In fact I'm not sure what this
>>>>>> variable mean but it's an important part of move from taka-no-me
>>>>>> toolchain to CMake 3.7. I guess it's like
>>>>>>* CMAKE_CXX_COMPILER =
>>>>>> /toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-4.9/prebuilt/linux-x86_64/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++
>>>>>>
>>>>>>
>>>>>>
>>>>>> Of course if I'm not missing something and they are not already
>>>>>> somewhere :)
>>>>>>
>>>>>> Ruslo
>>>>> How about ${CMAKE_C/CXX_COMPILER} -E to call the preprocessor?
>>>> I have no idea and not planning to test it because the old code was
>>>> using `cpp` preprocessor and I see no point of changing it.
>>> Well, you can define your preprocessor to be "${CMAKE_C_COMPILER}
>>> -E" locally and it will work with GCC-like compilers.
>>> That's a more robust way to call it as there is no
>>> CMAKE_C_PREPROCESSOR standard value in any CMake file.
>>> Nobody should call "cpp" manually anymore, but use the compiler
>>> driver instead to do it for you.
>>>
>>> That's why there's no standard CPP variable in CMake, it's not
>>> needed at all.
>>> For the same reasons, you rarely have to call the linker directly,
>>> it's usually done through the compiler driver.
>> Just like I said I'm not using it - this variable needed for 3rd
>> party package. I have no idea how it was used, the only thing I know
>> is that if I remove this variable the package stop working.
> Then just set it yourself as I said. You don't even need 3.7.0, you
> can just override it in the current version of CMake and previous
> toolchain you used.
I'm trying to move to 3.7.0 variables (that now became standard) and
drop old toolchain. And you're giving me advice to not rely on 3.7.0 and
use previous toolchain?

> The 3rd party package using it should still work.
> Use small incremental steps, in order to migrate. It will be easier.
That's exactly what I'm doing now.

>
>>
>>>
>>>>> Calling it directly is kind of dangerous though since you will
>>>>> probably be missing the proper language information and other options
>>>>> that might affect the predefined preprocessor defines.
>>>> I'm not calling it directly, it was used by `configure` script of
>>>> 3rd party.
>>>>
>>>>> gcc has different binaries for different target archs and has some
>>>>> defines baked in, but this won't apply to Clang that uses only one
>>>>> binary and a target triple.
>>>> For clang based android toolchain the
>>>> CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX
>>>> variable points to the directory with gcc, so it will find `cpp`
>>>> preprocessor too. I don't know if it's good or bad :)
>>>
>>> I think that's an implementation detail you shouldn't rely on. The
>>> compilers in the NDK are changing, GCC is deprecated and you
>>> shouldn't expect that.
>>> Clang is mostly self contained and using very little from the GCC
>>> distribution (binutils), it will be gone at some point, so you
>>> should be ready for the future.
>> My goal now is to move from taka-no-me to CMake 3.7+ Android. I don't
>> bother about the destiny of GCC distribution. When this stuff will
>> change the problems

Re: [cmake-developers] Android variables

[Ruslan Baratov via cmake-developers]

On 12-Nov-16 19:09, Florent Castelli wrote:
> On 12/11/2016 06:53, Ruslan Baratov wrote:
>> On 12-Nov-16 08:21, Florent Castelli wrote:
>>> On 10/11/2016 16:05, Ruslan Baratov via cmake-developers wrote:
>>>> Hi,
>>>>
>>>> I wonder if it's possible to introduce next variables describing
>>>> Android
>>>> tools:
>>>> * C preprocessor. Similar to CMAKE_CXX_COMPILER the variable that will
>>>> contain the path to preprocessor. Example:
>>>>* CMAKE_CXX_COMPILER =
>>>> /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++
>>>>
>>>>
>>>>* CMAKE_C_PREPROCESSOR =
>>>> /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-cpp
>>>>
>>>>
>>>> * ANDROID_TOOLCHAIN_MACHINE_NAME. In fact I'm not sure what this
>>>> variable mean but it's an important part of move from taka-no-me
>>>> toolchain to CMake 3.7. I guess it's like
>>>>* CMAKE_CXX_COMPILER =
>>>> /toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-4.9/prebuilt/linux-x86_64/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++
>>>>
>>>>
>>>>
>>>> Of course if I'm not missing something and they are not already
>>>> somewhere :)
>>>>
>>>> Ruslo
>>> How about ${CMAKE_C/CXX_COMPILER} -E to call the preprocessor?
>> I have no idea and not planning to test it because the old code was
>> using `cpp` preprocessor and I see no point of changing it.
> Well, you can define your preprocessor to be "${CMAKE_C_COMPILER} -E"
> locally and it will work with GCC-like compilers.
> That's a more robust way to call it as there is no
> CMAKE_C_PREPROCESSOR standard value in any CMake file.
> Nobody should call "cpp" manually anymore, but use the compiler driver
> instead to do it for you.
>
> That's why there's no standard CPP variable in CMake, it's not needed
> at all.
> For the same reasons, you rarely have to call the linker directly,
> it's usually done through the compiler driver.
Just like I said I'm not using it - this variable needed for 3rd party
package. I have no idea how it was used, the only thing I know is that
if I remove this variable the package stop working.

>
>>> Calling it directly is kind of dangerous though since you will
>>> probably be missing the proper language information and other options
>>> that might affect the predefined preprocessor defines.
>> I'm not calling it directly, it was used by `configure` script of 3rd
>> party.
>>
>>> gcc has different binaries for different target archs and has some
>>> defines baked in, but this won't apply to Clang that uses only one
>>> binary and a target triple.
>> For clang based android toolchain the CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX
>> variable points to the directory with gcc, so it will find `cpp`
>> preprocessor too. I don't know if it's good or bad :)
>
> I think that's an implementation detail you shouldn't rely on. The
> compilers in the NDK are changing, GCC is deprecated and you shouldn't
> expect that.
> Clang is mostly self contained and using very little from the GCC
> distribution (binutils), it will be gone at some point, so you should
> be ready for the future.
My goal now is to move from taka-no-me to CMake 3.7+ Android. I don't
bother about the destiny of GCC distribution. When this stuff will
change the problems will appear in both taka-no-me and CMake 3.7+.

>
> If you're updating CMake and changing the toolchain file, then I would
> expect that some work has to be done, including making changes to the
> invocation of a 3rd party script that is using custom variables from
> the old toolchain.
There is a tricky part about that. I do define variables like
CMAKE_SYSTEM_VERSION or CMAKE_ANDROID_ARCH_ABI and CMake gives me back
CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX. But
CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX is only available **after** toolchain
processed hence I can't use such variable in toolchain to create my
custom variables. So if we want to have everything play nice this should
be defined in CMake.

> Overall, I consider that taka-no-me Android toolchain to be tech debt.
> It hasn't been updated for a long time, doesn't work with recent NDK
> (unless you resort to use a standalone toolchain), locks people with
> some custom variables making them believe they are standard and has
> tons of other small bugs and issues.
> I understand its appeal for most people, but to me, it has caused more
> trouble than help.
Just like I said before, those variables needed in 3rd party t

Re: [cmake-developers] Android variables

[Ruslan Baratov via cmake-developers]

On 12-Nov-16 08:21, Florent Castelli wrote:
> On 10/11/2016 16:05, Ruslan Baratov via cmake-developers wrote:
>> Hi,
>>
>> I wonder if it's possible to introduce next variables describing Android
>> tools:
>> * C preprocessor. Similar to CMAKE_CXX_COMPILER the variable that will
>> contain the path to preprocessor. Example:
>>   * CMAKE_CXX_COMPILER =
>> /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++
>>
>>   * CMAKE_C_PREPROCESSOR =
>> /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-cpp
>>
>> * ANDROID_TOOLCHAIN_MACHINE_NAME. In fact I'm not sure what this
>> variable mean but it's an important part of move from taka-no-me
>> toolchain to CMake 3.7. I guess it's like
>>   * CMAKE_CXX_COMPILER =
>> /toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-4.9/prebuilt/linux-x86_64/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++
>>
>>
>> Of course if I'm not missing something and they are not already
>> somewhere :)
>>
>> Ruslo
>
> How about ${CMAKE_C/CXX_COMPILER} -E to call the preprocessor?
I have no idea and not planning to test it because the old code was
using `cpp` preprocessor and I see no point of changing it.

> Calling it directly is kind of dangerous though since you will
> probably be missing the proper language information and other options
> that might affect the predefined preprocessor defines.
I'm not calling it directly, it was used by `configure` script of 3rd party.

> gcc has different binaries for different target archs and has some
> defines baked in, but this won't apply to Clang that uses only one
> binary and a target triple.
For clang based android toolchain the CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX
variable points to the directory with gcc, so it will find `cpp`
preprocessor too. I don't know if it's good or bad :)

Ruslo

> You'll also lose the c/c++ language definition (unless you pass -x
> c++), language standard in use...

-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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 variables

[Ruslan Baratov via cmake-developers]

On 11-Nov-16 21:09, Brad King wrote:
> On 11/10/2016 10:46 PM, Ruslan Baratov wrote:
>> the value 
>> "${CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX}cpp${CMAKE_CXX_ANDROID_TOOLCHAIN_SUFFIX}"
> This expression is the documented way to get the paths to the Android tools.
> I see no reason to add a pre-evaluated copy for every tool.
Reason is the same as with CMAKE_GDBSERVER variable. Instead of forcing
users to redefine (probably with different names) this variable each
time we can do it once in CMake.

>
>> ANDROID_TOOLCHAIN_MACHINE_NAME?
> In your original message it looked like you needed this only to construct
> the path above.
Nope, this one needed too.

>
>> get_filename_component(ANDROID_TOOLCHAIN_MACHINE_NAME 
>> "${CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX}" NAME)
>> string(REGEX REPLACE "-$" "" ANDROID_TOOLCHAIN_MACHINE_NAME 
>> "${ANDROID_TOOLCHAIN_MACHINE_NAME}")
> AFAICT the only meaning this value has is exactly what that code expresses.
>
> What is your use case for getting this value and why is it needed separately?
Even if they may not be needed in regular CMake code such variables can
be useful "outside". Autotools based projects use
ANDROID_TOOLCHAIN_MACHINE_NAME variable: `./configure
--host=${ANDROID_TOOLCHAIN_MACHINE_NAME}`. Preprocessor is required too:
`CPP=${CMAKE_C_PREPROCESSOR} ./configure`. Variables
ANDROID_NDK_HOST_SYSTEM_NAME and ANDROID_COMPILER_VERSION is used in
tool `androiddeployqt` which do build Qt application for Android.

Ruslo

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Android variables

[Ruslan Baratov via cmake-developers]

On 10-Nov-16 23:05, Ruslan Baratov via cmake-developers wrote:
>  * CMAKE_CXX_COMPILER =
> /toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-4.9/prebuilt/linux-x86_64/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++
Actually there are more variables here, ANDROID_COMPILER_VERSION and
ANDROID_NDK_HOST_SYSTEM_NAME:
 
/toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-${ANDROID_COMPILER_VERSION}/prebuilt/${ANDROID_NDK_HOST_SYSTEM_NAME}/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++

ANDROID_COMPILER_VERSION is similar to
CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION. However
CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION is designed to be set by user as far
as I understand. It is empty by default.
ANDROID_NDK_HOST_SYSTEM_NAME called _ANDROID_HOST_DIR in CMake 3.7 and
used only internally. What about making it public?

Ruslo
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Android variables

[Ruslan Baratov via cmake-developers]

Okay, thanks. But this doesn't answer my question. So can we introduce
new variable CMAKE_C_PREPROCESSOR with the value
|"${CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX}cpp${CMAKE_CXX_ANDROID_TOOLCHAIN_SUFFIX}"?
Similar to CMAKE_C_COMPILER, CMAKE_CXX_COMPILER, CMAKE_AR. What about
ANDROID_TOOLCHAIN_MACHINE_NAME? Your proposal is to parse the last
component of |||CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX? Does this one look good:

||

||get_filename_component(ANDROID_TOOLCHAIN_MACHINE_NAME
"${CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX}" NAME)||
||string(REGEX REPLACE "-$" ""
||ANDROID_TOOLCHAIN_MACHINE_NAME||
"${||ANDROID_TOOLCHAIN_MACHINE_NAME||}")
||

||?

Ruslo

||On 11-Nov-16 00:29, Brad King wrote:
> On 11/10/2016 10:05 AM, Ruslan Baratov via cmake-developers wrote:
>> variables describing Android tools:
> See:
>
> * 
> https://cmake.org/cmake/help/v3.7/variable/CMAKE_LANG_ANDROID_TOOLCHAIN_PREFIX.html
> * 
> https://cmake.org/cmake/help/v3.7/variable/CMAKE_LANG_ANDROID_TOOLCHAIN_SUFFIX.html
> * 
> https://gitlab.kitware.com/cmake/cmake/blob/v3.7.0-rc3/Tests/RunCMake/Android/common.cmake#L9-13
>
> -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] Android variables

[Ruslan Baratov via cmake-developers]

Hi,

I wonder if it's possible to introduce next variables describing Android
tools:
* C preprocessor. Similar to CMAKE_CXX_COMPILER the variable that will
contain the path to preprocessor. Example:
 * CMAKE_CXX_COMPILER =
/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++
 * CMAKE_C_PREPROCESSOR =
/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-cpp
* ANDROID_TOOLCHAIN_MACHINE_NAME. In fact I'm not sure what this
variable mean but it's an important part of move from taka-no-me
toolchain to CMake 3.7. I guess it's like
 * CMAKE_CXX_COMPILER =
/toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-4.9/prebuilt/linux-x86_64/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++

Of course if I'm not missing something and they are not already somewhere :)

Ruslo
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Adding Cmake version in online documentation

[Ruslan Baratov via CMake]

On 09-Nov-16 23:00, Nils Gladitz wrote:
> On 09.11.2016 15:52, Ruslan Baratov wrote:
>> Can you show the real code? The code that in your opinion doesn't
>> violate the "right way of policy usage"?
>
> It is not a question about code. It is a question about context and
> use case.
You just said that all the code I've showed is not correct and conflicts
with policies nature. So I have to ask you about the real code, because
looks like in your "world" there is no valid case of `cmake_policy`
usage and the only correct way to set policies is to use
`cmake_minimum_required` command. Hence it's not surprising that you
can't distinguish `cmake_minimum_required` and behavior controlled by
`cmake_policy`.

>
> Valid context as the documentation states would e.g. be a project that
> is no longer maintained where you have no intention of ever migrating
> to a newer CMake version.
So why the project in the middle of the migration process is not a valid
case? It is maintained but the exact migration step is paused, but I
have an intention to improve the code in future. Anyway even if the
project is no longer maintained, then what we have? We have
`cmake_minimum_required` with the version that fits **features** the
code has and `cmake_policy` to control the **behavior** of different
cmake versions.

> Or as I said cmake's testsuite.
>
> If you insist on actual code e.g. this is part of the tests that I
> wrote for CMP0054:
> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/RunCMake/CMP0054/CMP0054-NEW.cmake;h=23a912476024ba09fcf741e04f999b64a6e91450;hb=refs/heads/master
>
The internal CMake stuff is out of the scope of discussion. If policies
are the internals why do we need them in the documentation?

Ruslo


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Adding Cmake version in online documentation

[Ruslan Baratov via CMake]

Can you show the real code? The code that in your opinion doesn't
violate the "right way of policy usage"?

On 09-Nov-16 22:14, Nils Gladitz wrote:
> On 09.11.2016 14:57, Ruslan Baratov wrote:
>>
>> Again policies are not meant to be feature toggles.
>> You can do a lot of things and there may be valid use cases but in
>> general policies are not meant to be used this way.
>> This is made explicit in CMake's documentation on policies.
>> They exist to preserve backwards compatibility not to pick and choose
>> behaviours.
>>
>> So can you show an example of "valid" use of `cmake_policy` command?
>>
>
> To quote the documentation:
> "A policy is a deprecation mechanism and not a reliable feature
> toggle. A policy should almost never be set to |OLD|, except to
> silence warnings in an otherwise frozen or stable codebase, or
> temporarily as part of a larger migration path."
>
> Beyond that valid use would be e.g. cmake's own testsuite which needs
> to be able to toggle individual policies to verify their behaviour.
>
> Nils
>

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Adding Cmake version in online documentation

[Ruslan Baratov via CMake]

On 09-Nov-16 19:51, Nils Gladitz wrote:
> On 09.11.2016 12:04, Ruslan Baratov wrote:
>> On 09-Nov-16 16:22, Nils Gladitz wrote:
>>> On 09.11.2016 04:29, Ruslan Baratov wrote:
 On 08-Nov-16 23:33, Nils Gladitz wrote:
> On 11/08/2016 04:17 PM, Ruslan Baratov wrote:
>
>> Except it's exactly opposite :) `cmake_minimum_required` is about
>> new
>> features/commands, and policies is about behavior.
>
> I don't agree and you can not separate the two.
> cmake_minimum_required() initializes the policies based on the
> given version.
 So what? From the user's perspective the "initialization of
 policies" is like a syntactic sugar so you don't have to write
 endless `cmake_policy(SET CMP00xx NEW)`. Nothing to do how to deal
 with them further.
>>>
>>> You can't simultaneously argue that cmake_minimum_required() isn't
>>> about policies (behaviours) and at the same time syntactic sugar for
>>> those very same policies.
>> You're playing with words instead of using arguments.
>
> There was no word play involved.
> You say cmake_minimum_required() is not about behaviour yet it
> initializes all policies which are purely about behaviour.
>From documentation
(https://cmake.org/cmake/help/latest/command/cmake_minimum_required.html):

The |cmake_minimum_required(VERSION)| command implicitly invokes the
|cmake_policy(VERSION)|


command


So this macro do implicitly invokes the cmake_policy comand:

macro(printvar a)
  cmake_policy(VERSION 3.0)
  message("Variable a: ${a}")
endmacro()

Can we said that 'printvar' affect behaviour? Sure! But what is the
point of this statement in the scope of this discussion?

So similar to your statement:

Strictly speaking cmake_minimum_required(VERSION) is not about command
availability but rather about behavior (cmake policies).


I can say now:

Strictly speaking 'printvar' is not about printing variable but
rather about behavior (cmake policies).

It's hard to argue with this...

>
>>
>>>
>>> Policy warnings aren't meant to indicate errors in your code but
>>> changes in behaviour that will happen if you were to increase your
>>> minimum required version.
>> Policy CMP0038 doesn't agree with you:
>> https://cmake.org/cmake/help/latest/policy/CMP0038.html
>  
> No policies are still primarily about behaviour changes. That is true
> for CMP0038 as well.
>
> The old behaviour is to ignore this issue in user code. The new
> behaviour is to produce an error.
I said that "most of them will be about bugs in my code", so not all of
them about bugs. However you said "warnings aren't meant to indicate
errors" - this statement is wrong, and I have proved it with the link.
The statement that "policies is all about behaviour" is 50% of what I'm
trying to say here.

> When maintainers get this warning they are informed that their code
> will break as soon as they increase their minimum required version.
No, it will not break always because they can control it with policies,
in our case setting policy to OLD will do the trick.

>
> The same is true for CMP0054. The policy warning did find many errors
> in user code but the warning is primarily about the change in behaviour.
And why behaviour changed? Because the way how variables interpreted
before CMP0054 was confusing, dangerous and depend on the value of
unrelated variables from the current scope.

>
>> Yes, like this:
>>
>> cmake_minimum_required(VERSION 2.8)
>> project(foo)
>>
>> if(POLICY CMP0038)cmake_policy(SET CMP0038 OLD) endif()
>>
>> Now CMake 3.0 users will not see the warning and CMake 2.8 users
>> **don't have to upgrade**.
>
> Yes but I don't see what point you are trying to make ... they didn't
> have to upgrade without the explicit policy set either.
> And the policy warnings aren't meant for users they are meant for
> maintainers.
Originally you said that "Given your second example you likely shouldn't
be touching the policy at all". I describe the example when it make
sense and provide the reasons. If you're not interested about warnings
and your users doesn't report the problems they see, then yes, probably
it's fine for you to not to touch the policies.

>
> In fact all that setting it to OLD does is suppress the warning.
>> Actually this statement is wrong. Take a look at this example:
>>
>> # CMakeLists.txt
>> cmake_minimum_required(VERSION 3.0)
>> project(fooVERSION 1.2.3)
>> cmake_policy(SET CMP0038 OLD) # Do not remove this!
>> add_library(foofoo.cpp)
>> target_link_libraries(foofoo)
>>
>> if you remove `cmake_policy(SET CMP0038 OLD)` this example will
>> produce **error**. It may happens when you want to use new
>> **feature** `project(VERSION)` from 3.0, hence you set
>> `cmake_minimum_required(VERSION 3.0)` and simultaneously you have
>> code which produce warning about CMP0038. By setting
>> 

Re: [CMake] Adding Cmake version in online documentation

[Ruslan Baratov via CMake]

On 09-Nov-16 16:22, Nils Gladitz wrote:
> On 09.11.2016 03:47, Ruslan Baratov wrote:
>> On 09-Nov-16 06:01, Nils Gladitz wrote:
>>> I think the git tag creation dates should roughly equate release dates:
>>>  https://cmake.org/gitweb?p=cmake.git;a=tags
>> What about the future releases? There was a page
>> https://cmake.org/Bug/changelog_page.php before but it's no longer valid
>> as far as I understand.
>
> https://gitlab.kitware.com/cmake/cmake/milestones
>
> I wouldn't consider those dates to be anything but very rough
> estimates though.
>
> Nils

Ok, thanks. At least something :)

Ruslo

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Adding Cmake version in online documentation

[Ruslan Baratov via CMake]

On 09-Nov-16 16:22, Nils Gladitz wrote:
> On 09.11.2016 04:29, Ruslan Baratov wrote:
>> On 08-Nov-16 23:33, Nils Gladitz wrote:
>>> On 11/08/2016 04:17 PM, Ruslan Baratov wrote:
>>>
 Except it's exactly opposite :) `cmake_minimum_required` is about new
 features/commands, and policies is about behavior.
>>>
>>> I don't agree and you can not separate the two.
>>> cmake_minimum_required() initializes the policies based on the given
>>> version.
>> So what? From the user's perspective the "initialization of policies"
>> is like a syntactic sugar so you don't have to write endless
>> `cmake_policy(SET CMP00xx NEW)`. Nothing to do how to deal with them
>> further.
>
> You can't simultaneously argue that cmake_minimum_required() isn't
> about policies (behaviours) and at the same time syntactic sugar for
> those very same policies.
You're playing with words instead of using arguments.

>
>>
>>>
   If you have command
 `if(IN_LIST)` since 3.3 you can't manipulate policies in such way that
 it will work with CMake 2.8. However if you have warning about policy
 CMP0054 (since CMake 3.2) you can set policy to old without changing
 `cmake_minimum_required` (hence without forcing your CMake 2.8
 users to
 upgrade to CMake 3.2).
>>>
>>> Coincidentally I implemented both of those policies :)
>>>
>>> Given your second example you likely shouldn't be touching the
>>> policy at all.
>> I have to. If my code use features from CMake 2.8 I do set
>> `cmake_minimum_required(VERSION 2.8)`. But some users may have CMake
>> 3.2 installed. Do they must downgrade CMake? Of course not. But if
>> I'm not touching policies there will be warnings around. If I'm good
>> developer I will investigate the root of the warnings and fix them.
>> Actually most of them will be about bugs in my code or dangerous
>> behavior, so it does improve 2.8 too.
>
> Policy warnings aren't meant to indicate errors in your code but
> changes in behaviour that will happen if you were to increase your
> minimum required version.
Policy CMP0038 doesn't agree with you:
https://cmake.org/cmake/help/latest/policy/CMP0038.html

> As such they can often be worked around by using behaviour that is
> consistent between versions but they are not meant to indicate errors
> to be fixed.
>
> Instead they are meant to encourage you to embrace the new behaviours
> and abandon the old (which will require porting work) since the old
> are by definition deprecated and may be removed in the future (though
> so far CMake has been very conservative about this).
>
>>
>>>
>>> A policy warning does not force your users to use a new CMake version.
>> Well that's what I said.
>
> You said you are not forcing your users to upgrade by setting a policy
> to OLD.
Yes, like this:

cmake_minimum_required(VERSION 2.8)
project(foo)

if(POLICY CMP0038)cmake_policy(SET CMP0038 OLD) endif()

Now CMake 3.0 users will not see the warning and CMake 2.8 users **don't
have to upgrade**.

> Which implied that not setting the policy to OLD would force your
> users to upgrade ... which it doesn't.
No, it doesn't imply this :) Not setting policy to OLD in this case
produce warnings that I have to deal with.

>
>>
>>> In fact all that setting it to OLD does is suppress the warning.
Actually this statement is wrong. Take a look at this example:

# CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
project(fooVERSION 1.2.3)
cmake_policy(SET CMP0038 OLD) # Do not remove this!
add_library(foofoo.cpp)
target_link_libraries(foofoo)

if you remove `cmake_policy(SET CMP0038 OLD)` this example will produce
**error**. It may happens when you want to use new **feature**
`project(VERSION)` from 3.0, hence you set
`cmake_minimum_required(VERSION 3.0)` and simultaneously you have code
which produce warning about CMP0038. By setting `cmake_policy(SET
CMP0038 OLD)` you suppress the error, i.e. change **behaviour**.

>> It's better than emitting zillion of warnings to the output, right?
>> You can suppress one type and fix another, set TODOs, etc.
>
> Policy warnings are intended to encourage you to switch to new
> behaviours since the old ones are deprecated.
> In actively maintained projects they are not meant to be suppressed.
Why not? If you're not planning to fix them right now? I'm not saying
you have to ignore them, you have to do fixes, but why not suppress and
say work on other fixes?

>
>>
>>> CMake will use the old behavior in either case.
>>>
>>> The warnings guide developers when they do bump their
>>> cmake_minimum_required(VERSION).
>>> By just suppressing it behavior changes might go unnoticed when the
>>> bump does happen.
>> There are 3 components in the equation: the **real** CMake version,
>> the version in `cmake_minimum_required` and the default policies for
>> such version. Can you provide an example of what you mean?
>
> cmake_minimum_required(VERSION 3.0)
>
> set(ONE 1)
>
> if(1 STREQUAL "ONE")
> 

Re: [CMake] Adding Cmake version in online documentation

[Ruslan Baratov via CMake]

On 08-Nov-16 23:33, Nils Gladitz wrote:
> On 11/08/2016 04:17 PM, Ruslan Baratov wrote:
>
>> On 08-Nov-16 22:22, Nils Gladitz wrote:
>>> Strictly speaking cmake_minimum_required(VERSION) is not about command
>>> availability but rather about behavior (cmake policies).
>> Except it's exactly opposite :) `cmake_minimum_required` is about new
>> features/commands, and policies is about behavior.
>
> I don't agree and you can not separate the two.
> cmake_minimum_required() initializes the policies based on the given
> version.
So what? From the user's perspective the "initialization of policies" is
like a syntactic sugar so you don't have to write endless
`cmake_policy(SET CMP00xx NEW)`. Nothing to do how to deal with them
further.

>
>>   If you have command
>> `if(IN_LIST)` since 3.3 you can't manipulate policies in such way that
>> it will work with CMake 2.8. However if you have warning about policy
>> CMP0054 (since CMake 3.2) you can set policy to old without changing
>> `cmake_minimum_required` (hence without forcing your CMake 2.8 users to
>> upgrade to CMake 3.2).
>
> Coincidentally I implemented both of those policies :)
>
> Given your second example you likely shouldn't be touching the policy
> at all.
I have to. If my code use features from CMake 2.8 I do set
`cmake_minimum_required(VERSION 2.8)`. But some users may have CMake 3.2
installed. Do they must downgrade CMake? Of course not. But if I'm not
touching policies there will be warnings around. If I'm good developer I
will investigate the root of the warnings and fix them. Actually most of
them will be about bugs in my code or dangerous behavior, so it does
improve 2.8 too.

>
> A policy warning does not force your users to use a new CMake version.
Well that's what I said.

> In fact all that setting it to OLD does is suppress the warning.
It's better than emitting zillion of warnings to the output, right? You
can suppress one type and fix another, set TODOs, etc.

> CMake will use the old behavior in either case.
>
> The warnings guide developers when they do bump their
> cmake_minimum_required(VERSION).
> By just suppressing it behavior changes might go unnoticed when the
> bump does happen.
There are 3 components in the equation: the **real** CMake version, the
version in `cmake_minimum_required` and the default policies for such
version. Can you provide an example of what you mean?

Ruslo
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Adding Cmake version in online documentation

[Ruslan Baratov via CMake]

On 09-Nov-16 06:01, Nils Gladitz wrote:
> On 08.11.2016 20:26, Albrecht Schlosser wrote:
>
>>
>> I'd like to have a list of release dates (I'm not sure if there is
>> one) as well as the exact version a feature was introduced to write
>> CMakeLists.txt files that run on really old CMake versions.
>>
>
> I think the git tag creation dates should roughly equate release dates:
> https://cmake.org/gitweb?p=cmake.git;a=tags 

What about the future releases? There was a page
https://cmake.org/Bug/changelog_page.php before but it's no longer valid
as far as I understand.

Ruslo
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Adding Cmake version in online documentation

[Ruslan Baratov via CMake]

On 08-Nov-16 22:11, Dvir Yitzchaki wrote:
> But how do you know which version to declare on cmake_minimum_required?
I do hit this too. This would be a very useful feature. Sometimes I have
to manually "scan" the docs to figure out some simple facts about newly
introduces variables/commands.


On 08-Nov-16 22:22, Nils Gladitz wrote:
> On 11/08/2016 03:11 PM, Dvir Yitzchaki wrote:
>
>> But how do you know which version to declare on cmake_minimum_required?
>> If this feature will be added it won't be far from writing a script
>> that scans the commands you use and outputs the first appropriate
>> version.
>>
>
> Strictly speaking cmake_minimum_required(VERSION) is not about command
> availability but rather about behavior (cmake policies).
Except it's exactly opposite :) `cmake_minimum_required` is about new
features/commands, and policies is about behavior. If you have command
`if(IN_LIST)` since 3.3 you can't manipulate policies in such way that
it will work with CMake 2.8. However if you have warning about policy
CMP0054 (since CMake 3.2) you can set policy to old without changing
`cmake_minimum_required` (hence without forcing your CMake 2.8 users to
upgrade to CMake 3.2).

Ruslo
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Remove RPATH on install

[Ruslan Baratov via cmake-developers]

On 28-Sep-16 23:34, Brad King wrote:

On 09/28/2016 04:09 PM, Ruslan Baratov via cmake-developers wrote:

` -Wl,-rpath,` to CMAKE_EXE_LINKER_FLAGS.

That adds it in a way that hides its presence from CMake.  CMake has its
own way to specify RPATH entries in the build tree.  It will replace the
build-tree-only entries with install-tree-only entries (if any) during
installation.
I'm not aware of any better ways to apply global settings for all 
targets without modifying CMakeLists.txt



   Any entries it doesn't know about are assumed to be added
by the toolchain and are thus preserved.

I can't save them because it's full path hence will be not relocatable.



If one uses target_link_libraries to link each executable explicitly
to the shared library via absolute path to the library file then IIRC
CMake will put the RPATH in the build tree for that and remove it on
installation.

Yep, I know.




adding new one, like CMAKE_INSTALL_DELETE_RPATH?

We don't actually define any kind of first-class RPATH-update operation.
It is only an implementation detail that we edit the RPATH on installation.
In principle the design is that there is a build tree RPATH and an install
tree RPATH.  On non-ELF platforms we actually need to re-run the linker
to produce the install tree version.  Therefore CMAKE_INSTALL_DELETE_RPATH
would not fit within our model.

Ok


Instead one could add a BUILD_RPATH target property with CMAKE_BUILD_RPATH
variable that specifies additional entries to put in the build tree RPATH.
This would be the build-tree equivalent to the INSTALL_PATH target property.


Should work too. I will do the tests and send a patch.

Ruslo

--

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Remove RPATH on install

[Ruslan Baratov via cmake-developers]

Hi,

I want to link the library to all executables in project so I'm adding 
` -Wl,-rpath,` to CMAKE_EXE_LINKER_FLAGS. That works 
fine however after install step this RPATH was not removed and full path 
to  remains as part of executable in LC_RPATH. As far as I 
understand there is no such variable for now in CMake that holds the 
list of RPATH directories that need to be removed on install step. If it 
is true what about adding new one, like CMAKE_INSTALL_DELETE_RPATH? Just 
for the record  is not a part of CMAKE_INSTALL_PREFIX or 
CMAKE_BINARY_DIR.


Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Downloading file from S3 private bucket

[Ruslan Baratov via cmake-developers]

Circumstances changed, we are not interested in this feature anymore at 
this moment.


Just for the record workarounds using external call to 'openssl' can be 
found here:

* https://gitlab.kitware.com/cmake/cmake/merge_requests/105
* https://gitlab.kitware.com/cmake/cmake/merge_requests/108

Ruslo

On 13-Sep-16 16:28, Ruslan Baratov wrote:

On 13-Sep-16 15:58, Brad King wrote:

On 09/13/2016 07:42 AM, Ruslan Baratov via cmake-developers wrote:

Will it be okay if CMake will optionally depend on OpenSSL?
Or other third party crypto library?

Currently the only place that needs it is through `curl`, and
that uses either OpenSSL or the Windows-native or macOS-native
APIs for TLS.
So your suggestion is to extend 'file' command? Like 
`file(DOWNLOAD|UPLOAD   S3_KEY  S3_SECRET )`?



It looks like curl does support HMAC.


I don't know, will take a look. We need this functionality:

  echo -n "${stringToSign}" | openssl sha1 -hmac "${secret}" -binary | 
base64


Ruslo



--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Downloading file from S3 private bucket

[Ruslan Baratov via cmake-developers]

On 13-Sep-16 15:58, Brad King wrote:

On 09/13/2016 07:42 AM, Ruslan Baratov via cmake-developers wrote:

Will it be okay if CMake will optionally depend on OpenSSL?
Or other third party crypto library?

Currently the only place that needs it is through `curl`, and
that uses either OpenSSL or the Windows-native or macOS-native
APIs for TLS.
So your suggestion is to extend 'file' command? Like 
`file(DOWNLOAD|UPLOAD   S3_KEY  S3_SECRET )`?



It looks like curl does support HMAC.


I don't know, will take a look. We need this functionality:

  echo -n "${stringToSign}" | openssl sha1 -hmac "${secret}" -binary | 
base64


Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Downloading file from S3 private bucket

[Ruslan Baratov via cmake-developers]

Hi,

Currently I'm investigating possibilities of downloading files from 
private S3 bucket using CMake. The only real issue I see for now is the 
computing of HMAC + SHA1. This look like a work for some new 
cryptographic module in family of 'string' functions similar to 
'string(MD5|SHA1|...)'. So if we are talking about new command 
'string(HMAC SHA1)' what will be the right path to implement it?  I took 
a brief look at hashing functions and it seems that it was not using 
OpenSSL (what I was thinking before). Will it be okay if CMake will 
optionally depend on OpenSSL? Or other third party crypto library?


Also I know that it's possible to use Query String Request 
Authentication.  It means I can create URL with key and signature in 
query part first, then put it into file(DOWNLOAD) command. However HMAC 
+ SHA1 in CMake itself offer more opportunities and sounds more solid 
for me.


Thoughts?

Ruslo

--

Powered by www.kitware.com

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

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

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

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

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

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

[Ruslan Baratov via CMake]

On 17-Aug-16 04:29, Florent Castelli wrote:


The Boost source download is cached outside of the build directory 
in a unique folder.

So it’s effectively only done once for all platforms and then reused.
This is true for local machines and for custom build servers like 
your personal Jenkins. For Travis/AppVeyor you have to create root 
folder with 3rd parties from scratch for each build (at least for 
free public accounts).
Yes. If you're using a free shared service, that's not something you 
can count on.
If you host your CI, you can do neat tricks like this, use ccache or 
other similar techs.

What if you don't need "tricks" and make everything plain and simple?







You’ll also have symbols and the sources available for debugging 
properly, and they’re

not always available with a binary distribution.
Just to clarify: with Hunter you're creating binaries from sources, 
so everything you install with `cmake --build _builds --target 
install` (or `./b2 install` for Boost) is available.
So you build each dependency separately, install them, and then use 
them in your top level dependency.

No, in shared root folder.

That works, but you have the extra overhead of the instrumentation for 
the whole build.
Even a no-op build will have to recurse in the build folder for each 
dependency and run again, which is slow.
This is why I prefer Ninja to the Makefile generator: it has a global 
view of everything and you get a quick no-op build.

Not sure I understand that. What is the overhead?








Of course building from source is not an option for such monsters 
like Qt or OpenCV. Ready-to-use binaries is something critical for 
real life applications. There is no way to test everything on 
Travis/AppVeyor without this feature.


Well, you don’t have to use Travis or AppVeyor.
It's the most powerful and easy to setup services I know. If you know 
any better solutions please share.
Well, you don't have a full control on the environment, so I wouldn't 
say it's the most powerful.
Please share your solution. I have worked with Jenkins before and will 
not say that it's something easy customizable. Shareable folder - yes, 
good, but other stuff is a complete pain.
You can setup Travis in a seconds, add AppVeyor and you got Linux, OSX, 
Windows testing. How much time will take to start and tune Jenkins 
master and connect several slaves with different OSes on them?
Then add bunch of projects and tune them, then create dev branches for 
testing and so on.



Convenient for sure. It probably fits smaller structures very well.
Bigger companies have the resources to host their own service most of 
the time and requirements that
force them to do so. Those are probably the ones that will have the 
manpower to handle a super-build type

build system.
Why do not have both? Hunter can share downloads/root/cache on local 
folder for such CIs like Jenkins/custom so you don't need to rebuild 
everything.
At the same time binaries from server can be downloaded for 
"build-from-scratch" environment like Travis.


Anyway what about users? So you think it's okay to spend several hours 
of building from sources to just to run simple example of your product?







Spotify isn’t at the same scale as most
projects hosted there and we have different requirements and resources.
Admittedly, Spotify doesn’t use Qt anymore, so this isn’t a problem 
for us.
It's not about Qt, it's about expandability. Use 20 of smaller 
libraries and you will have quite the same issues.
As I said before, if I have build scripts for 20 small libraries and I 
want to update a build flag affecting the ABI, I don't have to do 
anything but just change the flag once.
In your case, you'll have to tweak the 20 build scripts for each 
library to reflect it.
The dependencies are only intermediate products you use for the final 
one. I don't want to deal with them constantly.
It's not true, I don't need to tweak 20 scripts, I just need to tweak 
one toolchain file.








Note that by integrating everything in the same project, you also 
have proper dependencies
and you will only build what you need. You may save some time by 
doing that.

And caching is important, when done in the right way!
With Hunter you're installing only what you need too, it does respect 
options like FOO_WITH_OPENSSL or FOO_WITH_QT, it download only 
binaries for toolchain you're currently working on, etc.


Don't want to make a discussion too broad. You said that it's hard to 
manage binaries for a lot of configuration, I'm saying that it's 
possible and is very handy.
I'm not saying it's impossible. I'm saying the overhead of managing 
binaries is just a burden we shouldn't have to accept in the C/C++ world.
If you can build build everything from source all the time in a 
super-build, why wouldn't you do it?
Because it's not practical. I have such experience with Gentoo, I prefer 
do something useful instead of watching on "emerge world" progress. 
Super-build doesn't scale, what if 

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

[Ruslan Baratov via CMake]

On 17-Aug-16 08:36, Elizabeth A. Fischer wrote:

> > I don't think CMake is the best place to do it,
> Can you provide any details? I personally think that CMake is a
> natural and the only place where it should be done.

The most important reason here is because there are combinatorially
many versions of a package you COULD install, depending on what
versions of its dependencies you link with, and CMake provides nothing
to address that issue.

CMake provides an abstraction. "Slots" that you need to fill:

  if(FOO_WITH_TESTS)
# need to have GTest installed
find_package(GTest)
  endif()
  if(FOO_WITH_OPENSSL)
# need to have OpenSSL installed
find_package(OpenSSL)
  endif()

And it should drive package manager. At least I find that approach 
natural and convenient, see no problems with it.
You can have as much combinations of versions/options/dependencies as 
you need:

* https://docs.hunter.sh/en/latest/overview/customization/hunter-id.html
* https://docs.hunter.sh/en/latest/overview/customization/config-id.html


  See here for an overview of how Spack
addresses the combinatorial versioning issue (which no other
auto-builder does, to the best of my knowledge):

http://hpcugent.github.io/easybuild/files/SC14_BoF_Spack.pdf
That's what I was talking about. I think that there is no need to 
introduce new funky syntax like "spack install mpileaks@1.1.2 %gcc@4.7.3 
+debug".
We already have CMAKE_CXX_COMPILER and 
CMAKE_BUILD_TYPE/CMAKE_CONFIGURATION_TYPES. Version can be set by CMake 
options too.

Effectively you can do:

  option(FOO_STABLE_BUILD "Stable build" ON)
  option(FOO_EXPERIMENTAL_BUILD "Experimental build" OFF)

  if(APPLE AND IOS AND FOO_STABLE_BUILD)
hunter_config(BooPackage VERSION "1.0")
  endif()

  if(WIN32 AND FOO_EXPERIMENTAL_BUILD)
hunter_config(BooPackage VERSION "2.0-beta" CMAKE_ARGS 
BOO_NEW_STUFF=YES)

  endif()



Once you've built something, it's nice to be able to re-use it.  If I
have a top-level CMake project that automatically builds three
dependencies, will other projects be able to make use of those
dependencies I've built?

Yes, libraries should be installed to the shared root, not to local folder:
* https://docs.hunter.sh/en/latest/overview/shareable.html


  Or do they become private?
No. Though you can make it private by setting CMake variable. It will 
use separate directory just like virtualenv do.



  If libraries
cannot be shared between applications, you will get a LOT of library
bloat, especially among the low-level libraries that get repeated
numerous times.  Admittedly, this may not be such an issue in some
environments where people are really only focused on building one
thing.

If you make a project, you might see it as a "top-level" project.  But 
someone else might want to build something bigger on top of your 
work.  You can never assume that "this package is top-level and no one 
will ever depend on it."

No issue here, see notes above.



Another obvious problem with using CMake for everything is that not
all packages come with CMake builds; most do not, in fact. Even if we
CAN re-write all the buils into CMake, that is a lot of extra effort.
As Florent has discovered, upstream authors do not always see a CMake
build in a favorable light, and these re-worked builds are not always
as functional as the original.  Moreover... writing a Spack recipe is 
an order of magnitude easier than writing a CMake build.  Usually, 
it's just a matter of calling `configure` or `cmake` with the right 
options.
Again, converting to CMake is a best option, but not the only possible 
one. E.g. OpenSSL, Boost, autotool-based package like X11 can be used as is:
* 
https://github.com/ruslo/hunter/blob/b4c370e32798cc3da74c37e4156c3bfc77add379/cmake/projects/Boost/hunter.cmake#L21
* 
https://github.com/ruslo/hunter/blob/b4c370e32798cc3da74c37e4156c3bfc77add379/cmake/projects/OpenSSL/hunter.cmake#L17
* 
https://github.com/ruslo/hunter/blob/b4c370e32798cc3da74c37e4156c3bfc77add379/cmake/projects/x11/hunter.cmake#L20




Although we can maybe imagine a world in which everyone eventually
abandons Autotools for CMake, it is still not realistic to expect that
Python, Haskell or Java programs will ever come with CMake builds.
This would be OK if each language exited in its own silo. But they
don't.  Python packages (built with setuptools) routinely depend on
C-based packages (built with Autotools or CMake).  By being agnostic
to the build system, auto-builders (like Spack, Macports, HomeBrew,
etc) are able to make packages work together, regardless of the build
system chosen for each one.

That's exactly what Hunter do, but using CMake as a driver.



In the sense that CMake is a Turing-complete language, there's no
fundamental reason you CAN'T write a meta-builder in CMake.  But
gosh... the language sure is arcane (but still better than Autotools
by a long shot).  I like to imagine that if CMake were starting off
today, it would be written in Python.
Language is a 

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

[Ruslan Baratov via CMake]

On 16-Aug-16 16:37, Florent Castelli wrote:
Well, I tried upstreaming the new build scripts to some projects and 
it didn’t go well.

Some of the reasons I’ve heard of:
- Windows developpers don’t use CMake, they have project files on the 
repository.

  The CMake files for Windows will never be updated.
They can coexists, it's easier then maintaining forks. If only C++ code 
changed you got new version "for free".


- I installed CMake 2.8.6 five years ago and I don’t want to update 
yet again!
  People relying on old versions is quite common and any attempt to 
raise the min
  version will be frowned upon (see the discussion in the LLVM mailing 
lists for example).
You can add `if(CMAKE_VERSION VERSION_LESS ...)` condition. It's hard to 
support such hairy configuration but anyway.



- We prefer to use autotools and don’t want to have to learn CMake.
  That’s fair. But also, no one likes to build an autotools backed 
project for Android or iOS.
Just for your info Hunter use build scheme for autotools project: 
https://github.com/ruslo/hunter/blob/b4c370e32798cc3da74c37e4156c3bfc77add379/cmake/modules/hunter_autotools_project.cmake
It can create universal iOS libraries and works for Android. There are a 
lot of efforts made by Alexandre Pretyman so this can be possible, it 
has some peculiarities. I guess he can clarify anything if you need details.


Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

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

[Ruslan Baratov via CMake]

On 13-Aug-16 03:12, Elizabeth A. Fischer wrote:
I don't think CMake is the best place to do it, for a number of 
reasons.  I would not try to re-invent the wheel here.


Can you provide any details? I personally think that CMake is a natural 
and the only place where it should be done.



On 16-Aug-16 15:52, Elizabeth A. Fischer wrote:
But any approach that requires every build to be ported to CMake will 
be difficult and labor-prone to scale.  Writing a meta-build recipe is 
usually much easier.


It is difficult indeed but it's the only way to reach the goal. I have 
kind of a meta-build recipe for the Boost, it was the first non-cmake 
recipe I've added and it's almost 3 year of improvements behind but it's 
still far from what I get in CMake from the box (of course it's not 3 
years of development of just this recipe, but anyway). Just take a look 
at this code:


  add_executable(foo foo.cpp)
  add_library(boo boo.cpp)

With CMake:

   No options: you got executable and static library on host
   BUILD_SHARED_LIBS: you got shared library
   CMAKE_MACOSX_BUNDLE: you got bundle instead of executable
   CMAKE_TOOLCHAIN_FILE=android.cmake: you got library for Android
   CMAKE_TOOLCHAIN_FILE=ios.cmake: you got armv7 library for iOS
   CMAKE_TOOLCHAIN_FILE=ios.cmake + CMAKE_IOS_INSTALL_COMBINED: you got
   armv7 + arm64 + i386 + x86_64 universal library
   /* your toolchain file here */: ...
   Debug: you compile with -O0 for *nix or /Od for MSVC
   MinSizeRel: you compile with -Os for *nix or /O1
   /* your custom build type here */: ...
   Any usage requirements? Propagated AUTOMATICALLY to any project that
   use your library: compiler flags, definitions, dependent libraries, etc.
   Optional dependencies? No problems, usage requirements propagated
   too. Same code! No changes needed.
   Usage requirements change from one version to another? Again, no
   problems.

So I choose to add CMakeLists.txt almost in all cases when new package 
needed. Exceptions are big libraries with a lot of components such as Qt 
or Boost, it's unmaintainable approach, inevitable evil :(


Ruslo

-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Ruslan Baratov via CMake]

On 16-Aug-16 17:04, Florent Castelli wrote:


On 16 Aug 2016, at 15:29, Ruslan Baratov > wrote:


On 16-Aug-16 13:52, Florent Castelli wrote:
For example, Boost is used by 5 platforms: Windows, OSX, Linux, 
Android and iOS.

Each platform has a different CPU target (or many 32/64bit, x86/ARM).
Each platform has many compilers.
Some platforms have instrumentation options (Debug / Release, ASan, 
MSan…) and really need

to be compiled properly, otherwise you’ll end up with false positives.
The matrix of builds is REALLY hard to track. Each time we update 
Boost, we had to update

a lot of things.

Not a problem for Hunter.

Linux, OSX, Windows, iOS 9.3, iOS 8.2, Android, GCC, Clang, ASan, 
LeakSan, ThreadSan, Static Analyzer,  libstdc++, libc++, MinGW, 
Visual Studio 2008-2015:

* https://travis-ci.org/ingenue/hunter/builds/140317830
* https://ci.appveyor.com/project/ingenue/hunter/build/1.0.665

This list is not even full, I guess I can add more toolchains in 
future (GCC variations and C++ standards).


To test all matrix I need to push one commit to pkg.boost branch, to 
upload binaries to server I need to push one commit to upload.boost 
branch (upload ALL toolchains at one shot). To reuse all updates 
users just need to set new URL/SHA1 of HunterGate module: 
https://github.com/ruslo/hunter/releases


Overall, building boost takes 10s on our developers’ machines. The 
sources aren’t changed often,

so the cost is pretty low.
What kind of hardware do they have? And what libraries you mean? It 
takes about 20 seconds on my Linux machine just to unpack 80 MB of 
Boost release archive. It's even worse on Windows, it takes several 
minutes for some strange reason even on SSD + Core i7. Using binaries 
in such cases is a huge time saver because there is no need to 
compile anything and there is no a lot of junk that they put into 
release archive (if you remove docs and tests 80 MB became 15 MB).


I consider the time to download Boost isn’t part of the build.
I'm not counting that. It takes 20 seconds just to unpack archive that 
already downloaded. Anyway I'm just wondering what is possible to do 
with Boost for 10 seconds. Install header-only libraries? Build 1-2 
libraries? All of them? :)


The Boost source download is cached outside of the build directory in 
a unique folder.

So it’s effectively only done once for all platforms and then reused.
This is true for local machines and for custom build servers like your 
personal Jenkins. For Travis/AppVeyor you have to create root folder 
with 3rd parties from scratch for each build (at least for free public 
accounts).




You’ll also have symbols and the sources available for debugging 
properly, and they’re

not always available with a binary distribution.
Just to clarify: with Hunter you're creating binaries from sources, so 
everything you install with `cmake --build _builds --target install` (or 
`./b2 install` for Boost) is available.





Of course building from source is not an option for such monsters 
like Qt or OpenCV. Ready-to-use binaries is something critical for 
real life applications. There is no way to test everything on 
Travis/AppVeyor without this feature.


Well, you don’t have to use Travis or AppVeyor.
It's the most powerful and easy to setup services I know. If you know 
any better solutions please share.



Spotify isn’t at the same scale as most
projects hosted there and we have different requirements and resources.
Admittedly, Spotify doesn’t use Qt anymore, so this isn’t a problem 
for us.
It's not about Qt, it's about expandability. Use 20 of smaller libraries 
and you will have quite the same issues.




Note that by integrating everything in the same project, you also have 
proper dependencies
and you will only build what you need. You may save some time by doing 
that.

And caching is important, when done in the right way!
With Hunter you're installing only what you need too, it does respect 
options like FOO_WITH_OPENSSL or FOO_WITH_QT, it download only binaries 
for toolchain you're currently working on, etc.


Don't want to make a discussion too broad. You said that it's hard to 
manage binaries for a lot of configuration, I'm saying that it's 
possible and is very handy.


Ruslo
-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Ruslan Baratov via CMake]

On 16-Aug-16 13:52, Florent Castelli wrote:

For example, Boost is used by 5 platforms: Windows, OSX, Linux, Android and iOS.
Each platform has a different CPU target (or many 32/64bit, x86/ARM).
Each platform has many compilers.
Some platforms have instrumentation options (Debug / Release, ASan, MSan…) and 
really need
to be compiled properly, otherwise you’ll end up with false positives.
The matrix of builds is REALLY hard to track. Each time we update Boost, we had 
to update
a lot of things.

Not a problem for Hunter.

Linux, OSX, Windows, iOS 9.3, iOS 8.2, Android, GCC, Clang, ASan, 
LeakSan, ThreadSan, Static Analyzer,  libstdc++, libc++, MinGW, Visual 
Studio 2008-2015:

* https://travis-ci.org/ingenue/hunter/builds/140317830
* https://ci.appveyor.com/project/ingenue/hunter/build/1.0.665

This list is not even full, I guess I can add more toolchains in future 
(GCC variations and C++ standards).


To test all matrix I need to push one commit to pkg.boost branch, to 
upload binaries to server I need to push one commit to upload.boost 
branch (upload ALL toolchains at one shot). To reuse all updates users 
just need to set new URL/SHA1 of HunterGate module: 
https://github.com/ruslo/hunter/releases



Overall, building boost takes 10s on our developers’ machines. The sources 
aren’t changed often,
so the cost is pretty low.
What kind of hardware do they have? And what libraries you mean? It 
takes about 20 seconds on my Linux machine just to unpack 80 MB of Boost 
release archive. It's even worse on Windows, it takes several minutes 
for some strange reason even on SSD + Core i7. Using binaries in such 
cases is a huge time saver because there is no need to compile anything 
and there is no a lot of junk that they put into release archive (if you 
remove docs and tests 80 MB became 15 MB).


Of course building from source is not an option for such monsters like 
Qt or OpenCV. Ready-to-use binaries is something critical for real life 
applications. There is no way to test everything on Travis/AppVeyor 
without this feature.


Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

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

[Ruslan Baratov via CMake]

Hi, Robert

According to your GitHub account you've send a trivial patch about a 
year ago to the Hunter (https://github.com/ruslo/hunter) package 
manager. So I wonder what is your experience, have you tried it? Have 
you run into some troubles?


Thanks, Ruslo

On 12-Aug-16 22:59, Robert Dailey wrote:

Hello,

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

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

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

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

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

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

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

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



--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [patch] One more pattern for extracting file name from URL

[Ruslan Baratov via cmake-developers]

On 05-Jul-16 23:26, Brad King wrote:

On 07/05/2016 04:13 PM, Ruslan Baratov wrote:

Works fine on my tests.

Thanks for testing!


However I still vote for using default value for 'fname' instead
of FATAL_ERROR.

I think that behavior would be surprising.
Not such surprising as some error in internal CMake module with no 
detail description how it can be fixed. My point is that if it will work 
in most cases then why not? Most users will not even notice this.





If something bad will happen user always can use DOWNLOAD_NAME.

Example of the test that will fail with current version but works
fine with default name:

 URL "http://tinyurl.com/jn86pmc;

In that case one can just use DOWNLOAD_NAME.  Auto-extraction of
the filename from the URL is a convenience for a common case, but
in principle DOWNLOAD_NAME could always be used.
The problem with DOWNLOAD_NAME is about generalizing code. If I have 100 
ExternalProject_Add commands with such URLs then I have to add 100 
DOWNLOAD_NAME. In my case I have a bunch of templates for 
ExternalProject_Add and to introduce this feature either I have:
* test URL for the pattern in similar way CMake do and predict the fact 
that CMake will fail to extract name (not stable, what if CMake logic 
changed? DRY violation)
* force some name unconditionally like archive.tar (most of the projects 
works fine and now for no reason archives will have another names)
* add about 20-30 lines of code to core modules, for each 
ExternalProject_Add template add parsing logic and 1 line for each 
package version declaration on user side


And all this without introducing any useful features, just to suppress 
CMake error for 0.01% of cases.


Anyway I've found workaround that I will use for such URLs. According to 
my tests most of the servers ignore fragments in URL and CMake can 
extract name from them. E.g. this works:


   cmake_minimum_required(VERSION 3.5)

   include(ExternalProject)

   ExternalProject_Add(
foo
URL "http://tinyurl.com/jn86pmc#a.tar;
URL_HASH SHA1=9c29c30fff99b7c1479b2e9d4926dcc3f8d364e0
CONFIGURE_COMMAND ""
BUILD_COMMAND ""
INSTALL_COMMAND ""
   )

Ruslo
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [patch] One more pattern for extracting file name from URL

[Ruslan Baratov via cmake-developers]

On 05-Jul-16 22:03, Brad King wrote:

On 07/01/2016 03:35 PM, Brad King wrote:

I don't think we should duplicate the

   "(\\.|=)(7z|tar|tar\\.bz2|tar\\.gz|tar\\.xz|tbz2|tgz|txz|zip)$"

expression.  The stripping of ?.* can be done earlier, or done as
part of the main match.

Please try this commit:

  ExternalProject: Match filenames in URLs with query strings and anchors
  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=57c337e2

Thanks,
-Brad

Works fine on my tests. However I still vote for using default value for 
'fname' instead of FATAL_ERROR. If something bad will happen user always 
can use DOWNLOAD_NAME.


Example of the test that will fail with current version but works fine 
with default name:


   cmake_minimum_required(VERSION 3.5)

   include(ExternalProject)

   ExternalProject_Add(
foo
URL "http://tinyurl.com/jn86pmc;
URL_HASH SHA1=9c29c30fff99b7c1479b2e9d4926dcc3f8d364e0
CONFIGURE_COMMAND ""
BUILD_COMMAND ""
INSTALL_COMMAND ""
   )

Ruslo
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [patch] One more pattern for extracting file name from URL

[Ruslan Baratov via cmake-developers]

On 05-Jul-16 20:31, Ben Boeckel wrote:

On Tue, Jul 05, 2016 at 19:49:46 +0300, Ruslan Baratov wrote:

Archive can be unpacked by "cmake -E tar xf" which detect type
automatically as far as I understand. At least this one used internally
by ExternalProject (see the testing I've made before).

CMake is not my go-to tool for extracting files though (and similarly
for others I imagine), so running `tar xf archive.tar` and getting an
error because it is actually a .tar.gz (or even a .zip) file is not
nice.
Well it's never too late to learn something new. Also `tar` is not 
widely used on Windows so to write nice code you should convert it to 
`cmake -E tar`. That the whole point of `cmake -E` feature.
I don't see the problem here, it was used internally, unpack archive for 
you and you can do what you want with **unpacked** sources. Anyway you 
can always force the name with |DOWNLOAD_NAME.|



So even if it seems that archive name is `|archive.tar.gz` it should be
downloaded to
`||gitlab-ce-v8.9.3-5e546d9b4728fc9c9623992a678cbea9eb2098f1.tar.gz`. So
I think it's easily can be file with another extension.|

Here's another idea: add an `OUTPUT_FILE ` keyword argument to
`file(DOWNLOAD)` to get the actual filename after content disposition
resolution (probably similar for 30x rewrites). This would also be
useful for things other than ExternalProject.

--Ben

Good idea, I'll be happy to see this feature in future CMake releases.

Ruslo
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [patch] One more pattern for extracting file name from URL

[Ruslan Baratov via cmake-developers]

On 05-Jul-16 18:50, Ben Boeckel wrote:

On Tue, Jul 05, 2016 at 18:43:25 +0300, Ruslan Baratov wrote:

By default not, goes to -prefix/src/archive.tar .

Right, but if a download directory is set, this won't work. Can the
project name at least be added to the name?
If user are forcing directory then it is user's responsibility I think. 
For example GitHub releases goes without name of the project so both:


* https://github.com/ruslo/polly/archive/v0.10.1.tar.gz
* https://github.com/ruslo/hunter/archive/v0.10.1.tar.gz

will be downloaded to v0.10.1.tar.gz - this filename extracted from URL 
by CMake. In general patch made in a code branch where was FATAL_ERROR 
before, so it doesn't affect backward compatibility.




Though I'm partial to keeping the extension still; if I need to add a
patch to a project, it'd be nice if the extension weren't a lie when I
go to extract the tarball.
Archive can be unpacked by "cmake -E tar xf" which detect type 
automatically as far as I understand. At least this one used internally 
by ExternalProject (see the testing I've made before).


Also note that in fact name of the file extracted from URL can differ 
from real:

|
> curl --head 
https://gitlab.com/gitlab-org/gitlab-ce/repository/archive.tar.gz\?ref\=v8.9.3 
| grep file
Content-Disposition: attachment; 
filename="gitlab-ce-v8.9.3-5e546d9b4728fc9c9623992a678cbea9eb2098f1.tar.gz"|


So even if it seems that archive name is `|archive.tar.gz` it should be 
downloaded to 
`||gitlab-ce-v8.9.3-5e546d9b4728fc9c9623992a678cbea9eb2098f1.tar.gz`. So 
I think it's easily can be file with another extension.|


Ruslo
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [patch] One more pattern for extracting file name from URL

[Ruslan Baratov via cmake-developers]

Got another idea. We can use default name like 'archive.tar'. Seems that 
internal type of archive determined automatically and doesn't depends on 
the filename. I've tried one example for each extension: 7z, tar.bz2, 
tar.gz, tar.xz, tbz2, tgz, txz, zip and it just works. Patch attached.


Ruslo

On 01-Jul-16 15:01, Ruslan Baratov via cmake-developers wrote:

Hi,

With attached patch it's possible to extract name from URLs like 
'https://.../archive.tar.gz?a=x=y'.


Ruslo 



>From 5284eedbd1b038aab2eab73252eb41914afb14e1 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov <ruslan_bara...@yahoo.com>
Date: Tue, 5 Jul 2016 16:17:12 +0300
Subject: [PATCH] Use default filename if extracting from URL failed

---
 Modules/ExternalProject.cmake | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index 2ff18fc..4c35c8b 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -1880,7 +1880,10 @@ function(_ep_add_download_command name)
 if (no_extract)
   get_filename_component(fname "${url}" NAME)
 elseif(NOT "${fname}" MATCHES "(\\.|=)(7z|tar|tar\\.bz2|tar\\.gz|tar\\.xz|tbz2|tgz|txz|zip)$")
-  message(FATAL_ERROR "Could not extract tarball filename from url:\n  ${url}")
+  # Do not put warning message here. If everything works OK it will
+  # only distract. If unpack will fail the standard name can be found in logs.
+  # (see _ep_write_extractfile_script function)
+  set(fname "archive.tar")
 endif()
 string(REPLACE ";" "-" fname "${fname}")
 set(file ${download_dir}/${fname})
-- 
1.9.1

-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] Document -H and -B

[Ruslan Baratov via cmake-developers]

On 01-Jul-16 15:58, Brad King wrote:


* Allow the form `-H  -B ` with the new names.

I don't see the point of introducing new options. Developers will still 
use -H/-B because it's backward compatible, well known and will work 
100% because of internal CMake testing. That said if you want to improve 
the current behavior of -H/-B (like confusing with --help/no spaces 
between -H and ) I can take a look. Otherwise I'm 
not interested (usually it means that the improvement will be abandoned).


Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [patch] One more pattern for extracting file name from URL

[Ruslan Baratov via cmake-developers]

On 01-Jul-16 16:04, Ben Boeckel wrote:

On Fri, Jul 01, 2016 at 08:58:16 -0400, Brad King wrote:

Also, the `([^/]*)\\?.*` part of the regex should be more
like `([^/?]*)\\?.*` to avoid eagerly matching early `?`.

This should also probably skip '#' characters for URLs with anchors.

--Ben

'fragement' goes after 'query' so as far as I understand it's not necessary.
https://en.wikipedia.org/wiki/Uniform_Resource_Locator#Syntax

Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [patch] One more pattern for extracting file name from URL

[Ruslan Baratov via cmake-developers]

On 01-Jul-16 15:58, Brad King wrote:

On 07/01/2016 08:01 AM, Ruslan Baratov via cmake-developers wrote:

With attached patch it's possible to extract name from URLs like
'https://.../archive.tar.gz?a=x=y'.

Thanks.


  elseif(NOT "${fname}" MATCHES 
"(\\.|=)(7z|tar|tar\\.bz2|tar\\.gz|tar\\.xz|tbz2|tgz|txz|zip)$")
-  message(FATAL_ERROR "Could not extract tarball filename from url:\n  
${url}")
+  # Try: https://.../archive.tar.gz?a=x=y
+  string(REGEX MATCH "^.*/([^/]*)\\?.*$" match_result "${url}")
+  set(fname "${CMAKE_MATCH_1}")
+  if(NOT "${fname}" MATCHES 
"(\\.|=)(7z|tar|tar\\.bz2|tar\\.gz|tar\\.xz|tbz2|tgz|txz|zip)$")
+message(FATAL_ERROR "Could not extract tarball filename from url:\n  
${url}")
+  endif()

Please try to structure the logic right in the if/elseif part.
Matching in those also sets `CMAKE_MATCH_*` variables so one
does not need to double-match.
'elseif' part try to find 'archive.tar.gz' in '${fname}', then 
'string(REGEX' try to match it in '${url}'. There is no reusing of 
'CMAKE_MATCH_*'.




Also, the `([^/]*)\\?.*` part of the regex should be more
like `([^/?]*)\\?.*` to avoid eagerly matching early `?`.
We can't have question mark ('?') in path as far as I understand, it 
should be percent-encoded, will be |'%3F'.|||

https://en.wikipedia.org/wiki/Uniform_Resource_Locator#Syntax
https://en.wikipedia.org/wiki/Percent-encoding

Ruslo
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How do you handle recursive dependencies in CMake

[Ruslan Baratov via CMake]

Hi,

On 30-Jun-16 16:01, Sven Baars wrote:

I don't think this is a solution to the problem, since then it seems
like the build will still fail for all our users unless they also build
all their packages from inside hunter.
What do you mean by "from inside hunter"? Users have to add 
'hunter_add_package(YourProject)' + 'find_package(YourProject CONFIG 
REQUIRED)' this is true. You want to avoid that?



  If I wanted it to work just for
myself I could just use hardcoded paths. The problem is that I want a
portable way such that users can build my projects without losing
dependency information.
Hunter will download all dependencies automatically. 
YourProjectConfig.cmake should contain all dependencies too so 
'find_package(YourProject CONFIG REQUIRED)' is enough.



  In the current situation they are forced to
copy-paste all of my CMakeLists.txt files and add their own stuff to
that. At least if I follow the guides on the wiki/the advice that I got
so far. That is, unless I misunderstand something, which I hope I do,
but no one pointed that out yet.

Sven

Ruslo



On 06/30/2016 02:41 PM, Nicholas Braden wrote:

If find_project is not enough, and ExternalProject's only problem is
build duplication, then I think it makes sense to consider a
CMake-based dependency manager such as hunter:
https://github.com/ruslo/hunter


On Thu, Jun 30, 2016 at 3:59 AM, Sven Baars  wrote:

This is a reply to the options that Ray gave. Here I will use the
package dependencies C -> B -> A{1,2}:

1)  The "ad-hoc" method I first mentioned by setting
CMAKE_LIBRARY_OUTPUT_DIRECTORY.

As far as I understand, this would mean that every user of all of the
different projects would have to be forced to use this, and would not be
allowed to "install" anything anywhere else, which doesn't seem nice.

2)  ExternalProject which will grab a repository and build it.

This will not work. One of the projects I use is Trilinos, which has
build of around 1GB. I don't want to pull and build that for every
project I have. Also the build flags that are used sometimes differ per
machine, not per project, so it would be nice if I could build it only
once per machine.

Also, in a more generalized sense, this would also mean that every
project I pull with ExtenalProject should also pull its own dependencies
with ExternalProject. So then if every project on my system used CMake,
this would mean that I would recursively rebuild my entire system for
every project I have. This doesn't seem right.

3)  Some Find_Package () mechanism that will do a search for it.

The point I had is that we actually try to use this. However, the
find_package does not find all dependencies. And we don't know in
package C whether it depends on A1 or A2, because of build flags/CMake
checks that were used for project B. So we can't just do a find_package
for either A1 or A2, because we don't know which one was used unless we
perform all the CMake checks that were done in project B (in some cases
10k+ lines of CMake code).

4)  Your option of including *.cmake files that provide the paths
[sorry, I might have misunderstood it].

This, so far, is the only option, because then B can tell us that it
used A2, not A1. This can just be done by providing absolute paths to
the libraries that were used in the compilation of B. But we are looking
for a standardized way to do this. I'd prefer to not have a lot of
custom code in all of my libraries.

Now some more information:

On supercomputers it is very common that every library on the system is
installed in a different directory. This is so every user can load their
own version of the library without breaking the system for others.
Therefore, you will never find libraries that are installed in the
standard system directories where CMake looks for the libraries. By
using PATH you can make it able to find the place where to look for the
FoobarConfig.cmake files, which is great when you want to build project
B, and this is also done automatically on all supercomputers I work on,
but those config files do not contain information on where the actual
libraries of project A are when you build project C. I guess Cfyz and me
think they should in some standardized way.

Sven
--

Powered by www.kitware.com

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

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

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

Visit other Kitware 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 

[cmake-developers] [patch] One more pattern for extracting file name from URL

[Ruslan Baratov via cmake-developers]

Hi,

With attached patch it's possible to extract name from URLs like 
'https://.../archive.tar.gz?a=x=y'.


Ruslo
>From 0bab30e859541dde51e9e21d3a22ec80a649a30a Mon Sep 17 00:00:00 2001
From: Ruslan Baratov 
Date: Fri, 1 Jul 2016 14:55:29 +0300
Subject: [PATCH] Add pattern for extracting file name from URL

Add one more pattern like 'https://.../archive.tar.gz?a=x=y'
to try to extract name of the archive from URL
---
 Modules/ExternalProject.cmake | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index 2ff18fc..96f315f 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -1880,7 +1880,12 @@ function(_ep_add_download_command name)
 if (no_extract)
   get_filename_component(fname "${url}" NAME)
 elseif(NOT "${fname}" MATCHES "(\\.|=)(7z|tar|tar\\.bz2|tar\\.gz|tar\\.xz|tbz2|tgz|txz|zip)$")
-  message(FATAL_ERROR "Could not extract tarball filename from url:\n  ${url}")
+  # Try: https://.../archive.tar.gz?a=x=y
+  string(REGEX MATCH "^.*/([^/]*)\\?.*$" match_result "${url}")
+  set(fname "${CMAKE_MATCH_1}")
+  if(NOT "${fname}" MATCHES "(\\.|=)(7z|tar|tar\\.bz2|tar\\.gz|tar\\.xz|tbz2|tgz|txz|zip)$")
+message(FATAL_ERROR "Could not extract tarball filename from url:\n  ${url}")
+  endif()
 endif()
 string(REPLACE ";" "-" fname "${fname}")
 set(file ${download_dir}/${fname})
-- 
1.9.1

-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] Document -H and -B

[Ruslan Baratov via cmake-developers]

On 01-Jul-16 00:14, Shawn Waldon wrote:
On Thu, Jun 30, 2016 at 5:10 PM, Ruslan Baratov 
> wrote:


On 30-Jun-16 23:57, Shawn Waldon wrote:

On Thu, Jun 30, 2016 at 4:54 PM, Ruslan Baratovwrote:

On 30-Jun-16 23:40, Brad King wrote:

On 06/30/2016 04:28 PM, Ruslan Baratov wrote:

On 30-Jun-16 23:18, Brad King wrote:

On 06/30/2016 03:56 PM, Ruslan Baratov wrote:

What is the public-use way to specify
source-tree and build-tree by
cmake options simultaneously?

cd $build && cmake $src

Will not work if $build not exists.

mkdir -p "$build" && cd "$build" && cmake "$src"


Next issue is that this command change directory, how can I
move back to the directory where I was working on?


mkdir -p "$build" && pushd "$build" && cmake "$src" && popd


Doesn't go back if `cmake "$src"` failed

I think Brad may have a better idea with the subshell. But to modify 
this to work even if `cmake "$src"` failed:


mkdir -p "$build" && pushd "$build" && cmake "$src"; popd

> echo $?
0

for the CMakeLists.txt with errors
-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] Document -H and -B

[Ruslan Baratov via cmake-developers]

On 01-Jul-16 00:02, Brad King wrote:

On 06/30/2016 04:57 PM, Shawn Waldon wrote:

 mkdir -p "$build" && pushd "$build" && cmake "$src" && popd

Or use a ()-enclosed subshell:

  (mkdir -p "$build" && cd "$build" && cmake "$src")

-Brad

Okay, this one seems to work. Also you haven't show how `src` defined, 
e.g. I can't do 'src=.' so it should be src="`pwd`"


So instead of "cmake -H. -B_builds" we have (src="`pwd`" build=_builds 
mkdir -p "$build" && cd "$build" && cmake "$src")

And it's only for *nix.

What about Windows?

Such options definitely would be useful in CMake.

Ruslo


--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [patch] Document -H and -B

[Ruslan Baratov via cmake-developers]

On 30-Jun-16 23:57, Shawn Waldon wrote:

On Thu, Jun 30, 2016 at 4:54 PM, Ruslan Baratovwrote:

On 30-Jun-16 23:40, Brad King wrote:

On 06/30/2016 04:28 PM, Ruslan Baratov wrote:

On 30-Jun-16 23:18, Brad King wrote:

On 06/30/2016 03:56 PM, Ruslan Baratov wrote:

What is the public-use way to specify source-tree
and build-tree by
cmake options simultaneously?

cd $build && cmake $src

Will not work if $build not exists.

mkdir -p "$build" && cd "$build" && cmake "$src"


Next issue is that this command change directory, how can I move
back to the directory where I was working on?


mkdir -p "$build" && pushd "$build" && cmake "$src" && popd


Doesn't go back if `cmake "$src"` failed

-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] Document -H and -B

[Ruslan Baratov via cmake-developers]

On 30-Jun-16 23:40, Brad King wrote:

On 06/30/2016 04:28 PM, Ruslan Baratov wrote:

On 30-Jun-16 23:18, Brad King wrote:

On 06/30/2016 03:56 PM, Ruslan Baratov wrote:

What is the public-use way to specify source-tree and build-tree by
cmake options simultaneously?

cd $build && cmake $src

Will not work if $build not exists.

mkdir -p "$build" && cd "$build" && cmake "$src"


Next issue is that this command change directory, how can I move back to 
the directory where I was working 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] [patch] Document -H and -B

[Ruslan Baratov via cmake-developers]

On 30-Jun-16 23:18, Brad King wrote:

On 06/30/2016 03:56 PM, Ruslan Baratov wrote:

What is the public-use way to specify source-tree and build-tree by
cmake options simultaneously?

cd $build && cmake $src


Will not work if $build not exists.

--

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] Document -H and -B

[Ruslan Baratov via cmake-developers]

On 30-Jun-16 22:31, Brad King wrote:

On 06/30/2016 03:23 PM, Ruslan Baratov via cmake-developers wrote:

Patch with undocumented options -H/-B.

These are undocumented because they are internal options that
are not meant for public use.
What is the public-use way to specify source-tree and build-tree by 
cmake options simultaneously?
If there is no such, what is the problem with making existing options 
public?


Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [patch] Document -H and -B

[Ruslan Baratov via cmake-developers]

Hi,

Patch with undocumented options -H/-B.

Ruslo
>From 6c378bd6622ca26c43225787494d60f1a9867b22 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov 
Date: Thu, 30 Jun 2016 22:17:14 +0300
Subject: [PATCH] Document -H and -B options

---
 Help/manual/OPTIONS_BUILD.txt | 20 
 Help/manual/cmake.1.rst   |  1 +
 2 files changed, 21 insertions(+)

diff --git a/Help/manual/OPTIONS_BUILD.txt b/Help/manual/OPTIONS_BUILD.txt
index b428a74..1caa954 100644
--- a/Help/manual/OPTIONS_BUILD.txt
+++ b/Help/manual/OPTIONS_BUILD.txt
@@ -1,3 +1,23 @@
+``-H``
+ Path to directory with CMakeLists.txt.
+
+ There must be no spaces between ``-H`` and 
+ (otherwise option will be interpreted as synonym to ``--help``). Always must
+ be used with ``-B`` option. Example:
+
+ ::
+
+   cmake -H. -B_builds
+
+ Use current directory as a source tree (i.e. start with
+ ``./CMakeLists.txt``) and put generated files to the ``./_builds`` folder.
+
+``-B``
+ Path to directory where CMake will store generated files.
+
+ There must be no spaces between ``-B`` and . Always
+ must be used with ``-H`` option.
+
 ``-C ``
  Pre-load a script to populate the cache.
 
diff --git a/Help/manual/cmake.1.rst b/Help/manual/cmake.1.rst
index 8f7c336..593bb2d 100644
--- a/Help/manual/cmake.1.rst
+++ b/Help/manual/cmake.1.rst
@@ -9,6 +9,7 @@ Synopsis
 .. parsed-literal::
 
  cmake [] ( | )
+ cmake -H -B []
  cmake [(-D =)...] -P 
  cmake --build  [...] [-- ...]
  cmake -E  [...]
-- 
1.9.1

-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] [iOS] What is the correct way to add resources to an XCode project

[Ruslan Baratov via CMake]

Hi,

I have used two approaches which is not based on assets directories.

First is to save icons to resources with special names. In this case 
Xcode will add them automatically, see:
* 
https://github.com/forexample/testapp/blob/9202304134862f043af740af27dc7efb3b3f565d/CMakeLists.txt#L28


Second is to save icons to resources too, but you can control names of 
pictures. You have to update *.plist file in this case.
* custom names: 
https://github.com/ruslo/weather/blob/56eee62eaac327e1a048165aaa868c2f3a71972f/Source/weather/ui/ios/icons/app/sugar.cmake#L15
* plist file: 
https://github.com/ruslo/weather/blob/56eee62eaac327e1a048165aaa868c2f3a71972f/Source/weather/ui/ios/views/plist.in#L35
* adding to resources: 
https://github.com/ruslo/weather/blob/56eee62eaac327e1a048165aaa868c2f3a71972f/Source/weather/ui/ios/CMakeLists.txt#L49


Also according to my reverse engineering skills next xcode variables 
used to define assets directories for icons and launch images:

* ASSETCATALOG_COMPILER_APPICON_NAME
* ASSETCATALOG_COMPILER_LAUNCHIMAGE_NAME

This means you can experiment with target properties:
* XCODE_ATTRIBUTE_ASSETCATALOG_COMPILER_APPICON_NAME
* XCODE_ATTRIBUTE_ASSETCATALOG_COMPILER_LAUNCHIMAGE_NAME

I have never used them before, so have no idea about it's working or not.

Ruslo

On 29-Jun-16 00:01, Roman Wüger wrote:

No one?

The target property RESOURCE does only allow files but no directories.

Regards
Roman



Am 22.06.2016 um 17:22 schrieb Roman Wüger :

Hello,

I read the mailing list but did find a way which works.

At the moment I use Xcode 7.3.1 and CMake 3.5.2 which creates a project for iOS 
9.3.

All I want is to add the directory "Images.xcassets" and a second directory 
structure to be copied to the Resource folder listed in XCode.

When I manually drag'n drop the directories into the Resource folder as 
reference or as group everything is working. How can I archive this with CMake?

Thanks and regards
Roman
--

Powered by www.kitware.com

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

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

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

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

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



--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [patch] iOS combined, some fixes

[Ruslan Baratov via cmake-developers]

Great, thank you!

On 25-Jun-16 14:56, Gregor Jasny wrote:

On 21/06/16 18:48, Ruslan Baratov wrote:

Is the patch applied? Let me know if there are any questions left about it.

Pushed into next. Sorry for the delay.





--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMake terminology

[Ruslan Baratov via CMake]

On 25-Jun-16 10:44, Craig Scott wrote:
One of the slight wrinkles here is that the distinction between 
configure and generation times is now a little stronger due to 
generator expressions. In order to really understand generator 
expressions, you cannot really avoid getting your head around 
configure and generate being distinct parts of the process. 
Personally, I tend to gloss over the distinction when explaining 
things so as not to distract the reader, but if I'm explaining 
something to do with generator expressions, then the distinction has 
to be made and I deliberately use the terms /configure/ and 
/generation/ stages.
I'm not sure I understand the link between "generator expressions" and 
"confusing configure+generate stage". Do you mean "generator 
expressions" on "configure+generate stage" vs "build stage"?




Also, as Ruslo points out, cmake can be used like a front end to the 
build step proper (i.e. cmake --build ...). I still see this as the 
/build/ though, not a cmake-specific step per se. If you treated that 
as a cmake step, then one could argue the whole build is cmake because 
cmake can be used to invoke the test and package targets too. I doubt 
many people think this way, so personally I feel it is clearer to 
refer to the /build/ stage as simply that without bringing cmake into 
the terminology.
Okay, I agree. "cmake build step" sounds weird, it should be just "build 
step" which can be triggered by "cmake --build" command. Also to be 
pedantic: it's CTest for testing stage and CPack for packing stage, not 
CMake (or you mean CMake tools?).




So in summary, here's the set of terminology I use (hopefully similar 
to what others intuitively expect):


Workflow stages in general:  cmake (or project setup) --> build --> 
test --> package


If talking about generator expressions:  configure --> generate --> 
build --> test --> package
This one reminds me about ExternalProject_Add command. It has "Configure 
step" with "CONFIGURE_COMMAND". This is where "cmake -H. -B_builds" 
happens :)


So for now I see two choices:
* invent new name for configure+generate :) well, this seems like a huge 
overkill...
* use words "configure" and "generate" interchangeably for command line 
cmake, depending on context, e.g.:

 * "you can add `-D` on __configure step__ to modify cache..."
 * "you can add `-G Xcode` on __generate step__ to create Xcode project 
instead of Makefile..."


Ruslo





On Sat, Jun 25, 2016 at 5:02 PM, Eric Noulard <eric.noul...@gmail.com 
<mailto:eric.noul...@gmail.com>> wrote:


Hi there,

I'd like to give my opinion here.
I agree that the fact that the cmake ui (qt or curse) makes it
possible to separate configure from generate
is an implementation detail. In fact one could perfectly decide
that the "configure" step should "generate "
each time it is run. Making it two-step save some time for big
project but I have already seen people forgetting
to generate and asking themselves why they didn't get any makefiles...

Nevertheless from a user point of view explaining that there are
different "time" because CMake is a buid system **generator** and
not a build tool seems very important to me.

Some action may be run during CMake time some may be done during
Build time.
For me CMake run is configure+generate.

    I did gave a tutorial which is now a bit outdated where I tried to
picture this.
See attached file or:
https://github.com/TheErk/CMake-tutorial

my 2 cents.

2016-06-25 2:33 GMT+02:00 Ruslan Baratov via CMake
<cmake@cmake.org <mailto:cmake@cmake.org>>:

There is cmake **build** step: cmake --build _builds

So in GUI it's:
 * cmake configure
 * cmake generate
 * IDE build (which you can do with cmake --build so it can be
called "cmake build" step)

in cmd:
 * cmake configure+generate
 * cmake build

Also I can call it "cmake step" in docs about some C++
project, but if the docs about cmake itself I think this term
is too wide


On 25-Jun-16 02:13, Craig Scott wrote:

In documentation, blog articles, etc. I just call it the
"cmake" step (or sometimes the "project setup" step if
talking in a more project-wide sense). For many users, the
separate configure and generate steps are somewhat of an
implementation detail, so it makes more sense to give it a
single term. I'm not aware of any generally accepted term,
but the ones I use seem to be fairly easy to understand,
especially for those new to CMake. YMMV.

On Saturday, 25 June 2016, Ruslan Barat

Re: [CMake] CMake terminology

[Ruslan Baratov via CMake]

On 25-Jun-16 10:02, Eric Noulard wrote:

Hi there,

I'd like to give my opinion here.
I agree that the fact that the cmake ui (qt or curse) makes it 
possible to separate configure from generate
is an implementation detail. In fact one could perfectly decide that 
the "configure" step should "generate "
each time it is run. Making it two-step save some time for big project 
but I have already seen people forgetting

to generate and asking themselves why they didn't get any makefiles...

Nevertheless from a user point of view explaining that there are 
different "time" because CMake is a buid system **generator** and not 
a build tool seems very important to me.


Some action may be run during CMake time some may be done during Build 
time.

For me CMake run is configure+generate.

I did gave a tutorial which is now a bit outdated where I tried to 
picture this.

See attached file or:
https://github.com/TheErk/CMake-tutorial

my 2 cents.
Actually it doesn't conflicts with steps notions. "cmake time" for GUI = 
"cmake configure" step + "cmake generate" step, "cmake time" for 
command-line = "cmake configure+generate" step.
Also by one step you can trigger events from different "times", i.e. 
"cmake --build _builds --target install" will run "Install time" which 
can trigger commands from "Build time", which even can trigger commands 
from "CMake time" (if CMakeLists.txt changed for example).





2016-06-25 2:33 GMT+02:00 Ruslan Baratov via CMake <cmake@cmake.org 
<mailto:cmake@cmake.org>>:


There is cmake **build** step: cmake --build _builds

So in GUI it's:
 * cmake configure
 * cmake generate
 * IDE build (which you can do with cmake --build so it can be
called "cmake build" step)

in cmd:
 * cmake configure+generate
 * cmake build

Also I can call it "cmake step" in docs about some C++ project,
but if the docs about cmake itself I think this term is too wide


On 25-Jun-16 02:13, Craig Scott wrote:

In documentation, blog articles, etc. I just call it the "cmake"
step (or sometimes the "project setup" step if talking in a more
project-wide sense). For many users, the separate configure and
generate steps are somewhat of an implementation detail, so it
makes more sense to give it a single term. I'm not aware of any
generally accepted term, but the ones I use seem to be fairly
easy to understand, especially for those new to CMake. YMMV.

On Saturday, 25 June 2016, Ruslan Baratov via CMake
<cmake@cmake.org <mailto:cmake@cmake.org>> wrote:

On 24-Jun-16 23:49, Robert Maynard wrote:

Please run the configure and generate steps by

It's too long :)

Also it doesn't express the fact that it's a single action,
consider:
  "To add variables on configure and generate steps use '-D'"
  "Before running configure and generate steps note that old
variables from cache can be used"
  etc.



On Fri, Jun 24, 2016 at 4:40 PM, Ruslan Baratov
<ruslan_bara...@yahoo.com> wrote:

On 24-Jun-16 23:25, Robert Maynard wrote:

cmake from the command line is still running the
two stages, it just
doesn't allow for feedback/input from the user
between the two stages.

Yes, I understand that. Question is about the name of
the step. I.e. when I
do write manual what should I choose
   Please run configure step by: cmake -H. -B_builds
or
   Please run generate step by: cmake -H. -B_builds
?

May be both versions are correct? Or both incorrect?

Ruslo


On Fri, Jun 24, 2016 at 4:06 PM, Ruslan Baratov
via CMake
<cmake@cmake.org> wrote:

Hi,

I have a question about CMake terminology.
When we are using CMake GUI
there
are two buttons "Configure" and "Generate",
hence we have two stages:

1. Configure step, when we do configuring
project, effectively creating
file
with cache variables (which we can modify)
without really generating
native
tools files like Makefile/*.sln/etc.

2. Generate step, when we do generating
project using file with cache
   

Re: [CMake] CMake terminology

[Ruslan Baratov via CMake]

There is cmake **build** step: cmake --build _builds

So in GUI it's:
 * cmake configure
 * cmake generate
 * IDE build (which you can do with cmake --build so it can be called 
"cmake build" step)


in cmd:
 * cmake configure+generate
 * cmake build

Also I can call it "cmake step" in docs about some C++ project, but if 
the docs about cmake itself I think this term is too wide


On 25-Jun-16 02:13, Craig Scott wrote:
In documentation, blog articles, etc. I just call it the "cmake" step 
(or sometimes the "project setup" step if talking in a more 
project-wide sense). For many users, the separate configure and 
generate steps are somewhat of an implementation detail, so it makes 
more sense to give it a single term. I'm not aware of any generally 
accepted term, but the ones I use seem to be fairly easy to 
understand, especially for those new to CMake. YMMV.


On Saturday, 25 June 2016, Ruslan Baratov via CMake <cmake@cmake.org 
<mailto:cmake@cmake.org>> wrote:


On 24-Jun-16 23:49, Robert Maynard wrote:

Please run the configure and generate steps by

It's too long :)

Also it doesn't express the fact that it's a single action, consider:
  "To add variables on configure and generate steps use '-D'"
  "Before running configure and generate steps note that old
variables from cache can be used"
  etc.



On Fri, Jun 24, 2016 at 4:40 PM, Ruslan Baratov
<ruslan_bara...@yahoo.com> wrote:

On 24-Jun-16 23:25, Robert Maynard wrote:

cmake from the command line is still running the two
stages, it just
doesn't allow for feedback/input from the user between
the two stages.

Yes, I understand that. Question is about the name of the
step. I.e. when I
do write manual what should I choose
   Please run configure step by: cmake -H. -B_builds
or
   Please run generate step by: cmake -H. -B_builds
?

May be both versions are correct? Or both incorrect?

        Ruslo


On Fri, Jun 24, 2016 at 4:06 PM, Ruslan Baratov via CMake
<cmake@cmake.org> wrote:

Hi,

I have a question about CMake terminology. When we
are using CMake GUI
there
are two buttons "Configure" and "Generate", hence
we have two stages:

1. Configure step, when we do configuring project,
effectively creating
file
with cache variables (which we can modify) without
really generating
native
tools files like Makefile/*.sln/etc.

2. Generate step, when we do generating project
using file with cache
variables, i.e. create those Makefile/*.sln/etc.

The question is about command line version of
CMake. Since we do creating
file with cache and generate native tools files in
one step what is the
right term? Is it a configure step because we read
user's '-D' and create
cache file?  Is it a generate step because native
tools files generated
at
the end? May be there is a third name to describe
the fact that it's
configure+generate step?

Thanks, Ruslo
--

Powered by www.kitware.com <http://www.kitware.com>

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

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

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

Visit other Kitware 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 <http://www.kitware.com>

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

Kitware offers 

Re: [CMake] CMake terminology

[Ruslan Baratov via CMake]

On 24-Jun-16 23:49, Robert Maynard wrote:

Please run the configure and generate steps by

It's too long :)

Also it doesn't express the fact that it's a single action, consider:
  "To add variables on configure and generate steps use '-D'"
  "Before running configure and generate steps note that old variables 
from cache can be used"

  etc.




On Fri, Jun 24, 2016 at 4:40 PM, Ruslan Baratov
<ruslan_bara...@yahoo.com> wrote:

On 24-Jun-16 23:25, Robert Maynard wrote:

cmake from the command line is still running the two stages, it just
doesn't allow for feedback/input from the user between the two stages.

Yes, I understand that. Question is about the name of the step. I.e. when I
do write manual what should I choose
   Please run configure step by: cmake -H. -B_builds
or
   Please run generate step by: cmake -H. -B_builds
?

May be both versions are correct? Or both incorrect?

Ruslo



On Fri, Jun 24, 2016 at 4:06 PM, Ruslan Baratov via CMake
<cmake@cmake.org> wrote:

Hi,

I have a question about CMake terminology. When we are using CMake GUI
there
are two buttons "Configure" and "Generate", hence we have two stages:

1. Configure step, when we do configuring project, effectively creating
file
with cache variables (which we can modify) without really generating
native
tools files like Makefile/*.sln/etc.

2. Generate step, when we do generating project using file with cache
variables, i.e. create those Makefile/*.sln/etc.

The question is about command line version of CMake. Since we do creating
file with cache and generate native tools files in one step what is the
right term? Is it a configure step because we read user's '-D' and create
cache file?  Is it a generate step because native tools files generated
at
the end? May be there is a third name to describe the fact that it's
configure+generate step?

Thanks, Ruslo
--

Powered by www.kitware.com

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

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

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

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

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





--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMake terminology

[Ruslan Baratov via CMake]

On 24-Jun-16 23:25, Robert Maynard wrote:

cmake from the command line is still running the two stages, it just
doesn't allow for feedback/input from the user between the two stages.
Yes, I understand that. Question is about the name of the step. I.e. 
when I do write manual what should I choose

  Please run configure step by: cmake -H. -B_builds
or
  Please run generate step by: cmake -H. -B_builds
?

May be both versions are correct? Or both incorrect?

Ruslo



On Fri, Jun 24, 2016 at 4:06 PM, Ruslan Baratov via CMake
<cmake@cmake.org> wrote:

Hi,

I have a question about CMake terminology. When we are using CMake GUI there
are two buttons "Configure" and "Generate", hence we have two stages:

1. Configure step, when we do configuring project, effectively creating file
with cache variables (which we can modify) without really generating native
tools files like Makefile/*.sln/etc.

2. Generate step, when we do generating project using file with cache
variables, i.e. create those Makefile/*.sln/etc.

The question is about command line version of CMake. Since we do creating
file with cache and generate native tools files in one step what is the
right term? Is it a configure step because we read user's '-D' and create
cache file?  Is it a generate step because native tools files generated at
the end? May be there is a third name to describe the fact that it's
configure+generate step?

Thanks, Ruslo
--

Powered by www.kitware.com

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

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

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

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

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



--

Powered by www.kitware.com

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

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

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

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

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

[CMake] CMake terminology

[Ruslan Baratov via CMake]

Hi,

I have a question about CMake terminology. When we are using CMake GUI 
there are two buttons "Configure" and "Generate", hence we have two stages:


1. Configure step, when we do configuring project, effectively creating 
file with cache variables (which we can modify) without really 
generating native tools files like Makefile/*.sln/etc.


2. Generate step, when we do generating project using file with cache 
variables, i.e. create those Makefile/*.sln/etc.


The question is about command line version of CMake. Since we do 
creating file with cache and generate native tools files in one step 
what is the right term? Is it a configure step because we read user's 
'-D' and create cache file?  Is it a generate step because native tools 
files generated at the end? May be there is a third name to describe the 
fact that it's configure+generate step?


Thanks, Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [patch] iOS combined, some fixes

[Ruslan Baratov via cmake-developers]

Is the patch applied? Let me know if there are any questions left about it.

On 15-Jun-16 23:38, Ruslan Baratov via cmake-developers wrote:

On 15-Jun-16 22:59, Gregor Jasny wrote:

Hello,

Thanks for the patch!

On 15/06/16 16:41, Ruslan Baratov wrote:

Sending some fixes found by testing with Xcode 7.3

We were chasing some errors regarding the unified build some time ago.
But it appeared some for of heisenbug: the more I looked the less likely
it happened.

Is the error 100% reproducible for you?

Yes - for the Travis VM with xcode7.3 image. Not - for my local machine.


  And do you know what goes wrong?
Yes, I've leaved a note in the comments section. There are some 
messages in error stream, they are not related to lipo location. Here 
is example of the log with error:


CMake Error at

/Users/travis/build/ingenue/hunter/_ci/cmake/share/cmake-3.5/Modules/CMakeIOSInstallCombined.cmake:102
(message):
Command failed (File name too long): 2016-05-31 18:37:15.058
xcodebuild[6590:18239] Build settings from command line:
2016-05-31 18:37:15.059 xcodebuild[6590:18239] TOOLCHAINS =
com.apple.dt.toolchain.XcodeDefault
2016-05-31 18:37:15.059 xcodebuild[6590:18239]
XCODE_DEFAULT_TOOLCHAIN_OVERRIDE =

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo;-info;/Users/travis/build/ingenue/hunter/_testing/Hunter/_Base/7f9eaa4/f53c868/1c14a4b/Build/GTest/Build/GTest-Release-prefix/src/GTest-Release-build/googlemock/Release-iphonesimulator/libgmock.a



Does the

list(LENGTH _lipo_path len)
if(NOT len EQUAL 1)

take paths with spaces into account?
Nope as far as I know. In fact it doesn't catch the error I've seen, I 
decide to add some sanity checks just to be sure.


Ruslo




-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [patch] iOS combined, some fixes

[Ruslan Baratov via cmake-developers]

On 15-Jun-16 22:59, Gregor Jasny wrote:

Hello,

Thanks for the patch!

On 15/06/16 16:41, Ruslan Baratov wrote:

Sending some fixes found by testing with Xcode 7.3

We were chasing some errors regarding the unified build some time ago.
But it appeared some for of heisenbug: the more I looked the less likely
it happened.

Is the error 100% reproducible for you?

Yes - for the Travis VM with xcode7.3 image. Not - for my local machine.


  And do you know what goes wrong?
Yes, I've leaved a note in the comments section. There are some messages 
in error stream, they are not related to lipo location. Here is example 
of the log with error:


   CMake Error at
   
/Users/travis/build/ingenue/hunter/_ci/cmake/share/cmake-3.5/Modules/CMakeIOSInstallCombined.cmake:102
   (message):
   Command failed (File name too long): 2016-05-31 18:37:15.058
   xcodebuild[6590:18239] Build settings from command line:
   2016-05-31 18:37:15.059 xcodebuild[6590:18239] TOOLCHAINS =
   com.apple.dt.toolchain.XcodeDefault
   2016-05-31 18:37:15.059 xcodebuild[6590:18239]
   XCODE_DEFAULT_TOOLCHAIN_OVERRIDE =
   
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain
   
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo;-info;/Users/travis/build/ingenue/hunter/_testing/Hunter/_Base/7f9eaa4/f53c868/1c14a4b/Build/GTest/Build/GTest-Release-prefix/src/GTest-Release-build/googlemock/Release-iphonesimulator/libgmock.a




Does the

list(LENGTH _lipo_path len)
if(NOT len EQUAL 1)

take paths with spaces into account?
Nope as far as I know. In fact it doesn't catch the error I've seen, I 
decide to add some sanity checks just to be sure.


Ruslo
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [patch] iOS combined, some fixes

[Ruslan Baratov via cmake-developers]

Hi,

Sending some fixes found by testing with Xcode 7.3

Ruslo
>From 2026570b6f3c7c950ffbb83effa5a176d9133c89 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov 
Date: Tue, 14 Jun 2016 23:44:41 +0300
Subject: [PATCH 1/2] CMakeIOSInstallCombined: add some sanity checks

---
 Modules/CMakeIOSInstallCombined.cmake | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Modules/CMakeIOSInstallCombined.cmake b/Modules/CMakeIOSInstallCombined.cmake
index 1256f56..e2a0fee 100644
--- a/Modules/CMakeIOSInstallCombined.cmake
+++ b/Modules/CMakeIOSInstallCombined.cmake
@@ -251,6 +251,13 @@ function(ios_install_combined target destination)
 )
   endif()
   set(_lipo_path ${output})
+  list(LENGTH _lipo_path len)
+  if(NOT len EQUAL 1)
+message(FATAL_ERROR "Unexpected xcrun output: ${_lipo_path}")
+  endif()
+  if(NOT EXISTS "${_lipo_path}")
+message(FATAL_ERROR "File not found: ${_lipo_path}")
+  endif()
 
   set(CURRENT_CONFIG "${CMAKE_INSTALL_CONFIG_NAME}")
   set(CURRENT_TARGET "${target}")
-- 
2.7.4 (Apple Git-66)

>From ea14e3f5c019fda1cba449f66df879d651b43cef Mon Sep 17 00:00:00 2001
From: Ruslan Baratov 
Date: Wed, 15 Jun 2016 00:16:03 +0300
Subject: [PATCH 2/2] CMakeIOSInstallCombined: do not merge content of OUTPUT
 and ERROR variables

---
 Modules/CMakeIOSInstallCombined.cmake | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/Modules/CMakeIOSInstallCombined.cmake b/Modules/CMakeIOSInstallCombined.cmake
index e2a0fee..57a1fe0 100644
--- a/Modules/CMakeIOSInstallCombined.cmake
+++ b/Modules/CMakeIOSInstallCombined.cmake
@@ -237,17 +237,21 @@ function(ios_install_combined target destination)
   endif()
 
   set(cmd xcrun -f lipo)
+
+  # Do not merge OUTPUT_VARIABLE and ERROR_VARIABLE since latter may contain
+  # some diagnostic information even for the successful run.
   execute_process(
   COMMAND ${cmd}
   RESULT_VARIABLE result
   OUTPUT_VARIABLE output
-  ERROR_VARIABLE output
+  ERROR_VARIABLE error_output
   OUTPUT_STRIP_TRAILING_WHITESPACE
   ERROR_STRIP_TRAILING_WHITESPACE
   )
   if(NOT result EQUAL 0)
 message(
-FATAL_ERROR "Command failed (${result}): ${cmd}\n\nOutput:\n${output}"
+FATAL_ERROR "Command failed (${result}): ${cmd}\n\nOutput:\n${output}\nOutput(error):\n${error_output}"
 )
   endif()
   set(_lipo_path ${output})
-- 
2.7.4 (Apple Git-66)

-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] ExternalProject: fix retry logic if error occurs

[Ruslan Baratov via cmake-developers]

It's a little bit tricky to split refactor/new functionality exact but 
I've created several patches with step-by-step changes. Hope this helps 
in review.


Ruslo

On 18-May-16 22:50, Brad King wrote:

On 05/18/2016 03:30 PM, Ruslan Baratov via cmake-developers wrote:

I've attached patch with applying retry logic in cases when status code
is not zero.

Thanks.  Please split the patch to perform the refactoring into
the ExternalProject-$step.cmake.in files first and then make the
logic changes as a second patch.  Also please add an explanation
of the logic change to the second commit message similar to what
you wrote in the original email.

-Brad



>From 5b4149ddc436f83bff4b7636884f86e9200b9fe7 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov <ruslan_bara...@yahoo.com>
Date: Thu, 19 May 2016 14:38:06 +0300
Subject: [PATCH 1/6] ExternalProject refactoring: uppercase variables

Use uppercase variables for future 'configure_file' command.
---
 Modules/ExternalProject.cmake | 54 +--
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index 7dad6e5..a7fc1f9 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -847,25 +847,25 @@ endif()
 
 endfunction(_ep_write_gitupdate_script)
 
-function(_ep_write_downloadfile_script script_filename remote local timeout no_progress hash tls_verify tls_cainfo)
+function(_ep_write_downloadfile_script script_filename REMOTE LOCAL timeout no_progress hash tls_verify tls_cainfo)
   if(timeout)
-set(timeout_args TIMEOUT ${timeout})
-set(timeout_msg "${timeout} seconds")
+set(TIMEOUT_ARGS TIMEOUT ${timeout})
+set(TIMEOUT_MSG "${timeout} seconds")
   else()
-set(timeout_args "# no TIMEOUT")
-set(timeout_msg "none")
+set(TIMEOUT_ARGS "# no TIMEOUT")
+set(TIMEOUT_MSG "none")
   endif()
 
   if(no_progress)
-set(show_progress "")
+set(SHOW_PROGRESS "")
   else()
-set(show_progress "SHOW_PROGRESS")
+set(SHOW_PROGRESS "SHOW_PROGRESS")
   endif()
 
   if("${hash}" MATCHES "${_ep_hash_regex}")
 string(CONCAT hash_check
-  "if(EXISTS \"${local}\")\n"
-  "  file(\"${CMAKE_MATCH_1}\" \"${local}\" hash_value)\n"
+  "if(EXISTS \"${LOCAL}\")\n"
+  "  file(\"${CMAKE_MATCH_1}\" \"${LOCAL}\" hash_value)\n"
   "  if(\"x\${hash_value}\" STREQUAL \"x${CMAKE_MATCH_2}\")\n"
   "return()\n"
   "  endif()\n"
@@ -875,15 +875,15 @@ function(_ep_write_downloadfile_script script_filename remote local timeout no_p
 set(hash_check "")
   endif()
 
-  set(tls_verify_code "")
-  set(tls_cainfo_code "")
+  set(TLS_VERIFY_CODE "")
+  set(TLS_CAINFO_CODE "")
 
   # check for curl globals in the project
   if(DEFINED CMAKE_TLS_VERIFY)
-set(tls_verify_code "set(CMAKE_TLS_VERIFY ${CMAKE_TLS_VERIFY})")
+set(TLS_VERIFY_CODE "set(CMAKE_TLS_VERIFY ${CMAKE_TLS_VERIFY})")
   endif()
   if(DEFINED CMAKE_TLS_CAINFO)
-set(tls_cainfo_code "set(CMAKE_TLS_CAINFO \"${CMAKE_TLS_CAINFO}\")")
+set(TLS_CAINFO_CODE "set(CMAKE_TLS_CAINFO \"${CMAKE_TLS_CAINFO}\")")
   endif()
 
   # now check for curl locals so that the local values
@@ -892,28 +892,28 @@ function(_ep_write_downloadfile_script script_filename remote local timeout no_p
   # check for tls_verify argument
   string(LENGTH "${tls_verify}" tls_verify_len)
   if(tls_verify_len GREATER 0)
-set(tls_verify_code "set(CMAKE_TLS_VERIFY ${tls_verify})")
+set(TLS_VERIFY_CODE "set(CMAKE_TLS_VERIFY ${tls_verify})")
   endif()
   # check for tls_cainfo argument
   string(LENGTH "${tls_cainfo}" tls_cainfo_len)
   if(tls_cainfo_len GREATER 0)
-set(tls_cainfo_code "set(CMAKE_TLS_CAINFO \"${tls_cainfo}\")")
+set(TLS_CAINFO_CODE "set(CMAKE_TLS_CAINFO \"${tls_cainfo}\")")
   endif()
 
   file(WRITE ${script_filename}
 "${hash_check}message(STATUS \"downloading...
- src='${remote}'
- dst='${local}'
- timeout='${timeout_msg}'\")
+ src='${REMOTE}'
+ dst='${LOCAL}'
+ timeout='${TIMEOUT_MSG}'\")
 
-${tls_verify_code}
-${tls_cainfo_code}
+${TLS_VERIFY_CODE}
+${TLS_CAINFO_CODE}
 
 file(DOWNLOAD
-  \"${remote}\"
-  \"${local}\"
-  ${show_progress}
-  ${timeout_args}
+  \"${REMOTE}\"
+  \"${LOCAL}\"
+  ${SHOW_PROGRESS}
+  ${TIMEOUT_ARGS}
   STATUS status
   LOG log)
 
@@ -921,7 +921,7 @@ list(GET status 0 status_code)
 list(GET status 1 status_string)
 
 if(NOT status_code EQUAL 0)
-  message(FATA

[cmake-developers] [Patch] ExternalProject: fix retry logic if error occurs

[Ruslan Baratov via cmake-developers]

Hi,

For now download retry attempt occurs in ExternalProject only if hash of 
archive mismatch. If error happens then script stop with FATAL_ERROR 
(example: 
https://ci.appveyor.com/project/ingenue/hunter/build/1.0.448/job/22kdl633f9w503ut). 
I've attached patch with applying retry logic in cases when status code 
is not zero.


Quite the same happening in 
https://github.com/Kitware/CMake/commit/30a94eecdb5c580d83a224848b78d186643e8105 
fix. Since `if(NOT status_code EQUAL 0)` trigger FATAL_ERROR, retry 
logic in `_ep_write_verifyfile_script` function is not reached. I've set 
default retry number to 5 with pauses 0, 5, 5, 15, 60 seconds. I left 
some space for future improvements if needed (90, 300, 1200=20min) 
probably can be controlled by some variable that will be available for 
users.


Ruslo
>From ce18b27a792ebbb79822b610e6d8e5077007d6cb Mon Sep 17 00:00:00 2001
From: Ruslan Baratov 
Date: Wed, 18 May 2016 22:06:35 +0300
Subject: [PATCH] ExternalProject: fix retry logic

Retry download if error occurs. Refactor ExternalProject module.
---
 Modules/ExternalProject-download.cmake.in | 161 ++
 Modules/ExternalProject-verify.cmake.in   |  48 +
 Modules/ExternalProject.cmake | 155 ++--
 3 files changed, 264 insertions(+), 100 deletions(-)
 create mode 100644 Modules/ExternalProject-download.cmake.in
 create mode 100644 Modules/ExternalProject-verify.cmake.in

diff --git a/Modules/ExternalProject-download.cmake.in b/Modules/ExternalProject-download.cmake.in
new file mode 100644
index 000..5b73cd8
--- /dev/null
+++ b/Modules/ExternalProject-download.cmake.in
@@ -0,0 +1,161 @@
+#=
+# Copyright 2008-2013 Kitware, Inc.
+# Copyright 2016 Ruslan Baratov
+#
+# Distributed under the OSI-approved BSD License (the "License");
+# see accompanying file Copyright.txt for details.
+#
+# This software is distributed WITHOUT ANY WARRANTY; without even the
+# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+# See the License for more information.
+#=
+# (To distribute this file outside of CMake, substitute the full
+#  License text for the above reference.)
+
+cmake_minimum_required(VERSION 3.5)
+
+function(check_file_hash has_hash hash_is_good)
+  if("${has_hash}" STREQUAL "")
+message(FATAL_ERROR "has_hash Can't be empty")
+  endif()
+
+  if("${hash_is_good}" STREQUAL "")
+message(FATAL_ERROR "hash_is_good Can't be empty")
+  endif()
+
+  if("@ALGO@" STREQUAL "")
+# No check
+set("${has_hash}" FALSE PARENT_SCOPE)
+set("${hash_is_good}" FALSE PARENT_SCOPE)
+return()
+  endif()
+
+  set("${has_hash}" TRUE PARENT_SCOPE)
+
+  message(STATUS "verifying file...
+   file='@LOCAL@'")
+
+  file("@ALGO@" "@LOCAL@" actual_value)
+
+  if(NOT "${actual_value}" STREQUAL "@EXPECT_VALUE@")
+set("${hash_is_good}" FALSE PARENT_SCOPE)
+message(STATUS "@ALGO@ hash of
+@LOCAL@
+  does not match expected value
+expected: '@EXPECT_VALUE@'
+  actual: '${actual_value}'")
+  else()
+set("${hash_is_good}" TRUE PARENT_SCOPE)
+  endif()
+endfunction()
+
+function(sleep_before_download attempt)
+  if(attempt EQUAL 0)
+return()
+  endif()
+
+  if(attempt EQUAL 1)
+message(STATUS "Retrying...")
+return()
+  endif()
+
+  set(sleep_seconds 0)
+
+  if(attempt EQUAL 2)
+set(sleep_seconds 5)
+  elseif(attempt EQUAL 3)
+set(sleep_seconds 5)
+  elseif(attempt EQUAL 4)
+set(sleep_seconds 15)
+  elseif(attempt EQUAL 5)
+set(sleep_seconds 60)
+  elseif(attempt EQUAL 6)
+set(sleep_seconds 90)
+  elseif(attempt EQUAL 7)
+set(sleep_seconds 300)
+  else()
+set(sleep_seconds 1200)
+  endif()
+
+  message(STATUS "Retry after ${sleep_seconds} seconds (attempt #${attempt}) ...")
+
+  execute_process(COMMAND "${CMAKE_COMMAND}" -E sleep "${sleep_seconds}")
+endfunction()
+
+if("@LOCAL@" STREQUAL "")
+  message(FATAL_ERROR "LOCAL can't be empty")
+endif()
+
+if("@REMOTE@" STREQUAL "")
+  message(FATAL_ERROR "REMOTE can't be empty")
+endif()
+
+if(EXISTS "@LOCAL@")
+  check_file_hash(has_hash hash_is_good)
+  if(has_hash)
+if(hash_is_good)
+  message(STATUS "File already exists and hash match (skip download):
+  file='@LOCAL@'
+  @ALGO@='@EXPECT_VALUE@'"
+  )
+  return()
+else()
+  message(STATUS "File already exists but hash mismatch. Removing...")
+  file(REMOVE "@LOCAL@")
+endif()
+  else()
+message(STATUS "File already exists but no hash specified (use URL_HASH):
+  file='@LOCAL@'
+Old file will be removed and new file downloaded from URL."
+)
+file(REMOVE "@LOCAL@")
+  endif()
+endif()
+
+set(retry_number 5)
+
+foreach(i RANGE ${retry_number})
+  sleep_before_download(${i})
+
+  message(STATUS "downloading...
+   src='@REMOTE@'
+   dst='@LOCAL@'
+  

Re: [CMake] in source makefile / helper script that enables building out of source?

[Ruslan Baratov via CMake]

On 11-May-16 16:58, Steve Lorimer wrote:
I've recently changed over from using boost-build 
(http://www.boost.org/build/) to cmake.


Boost build builds in-source.

I've become quite used to building and searching etc from the source root

~/src $ b2 module
~/src $ git grep foo


This work flow has been broken because I'm not using out of source builds

~/src/build $ make module
~/src/build $ git grep... dang it! 
~/src/build $ cd ..
~/src $ git grep foo
~/src $ make modu... dang it! 
~/src $ cd build
~/src/build $ make module

I can't be the only one who wants to have the benefit of out of source 
builds and be able to build from in-source.

Will `-C` help?

~/src $ make -C build module

or in cross-platform fashion:

~/src $ cmake --build build
~/src $ cmake --build build --target foo --config Debug

Ruslo


I imagine it would be relatively simple to create a makefile which 
navigates to a known build directory (eg: build or debug or...), 
executes make there, and then changes directory back to where it was 
called from.


Before I do just this, I thought it better to try leverage the open 
source community - hence asking the question.


Does anyone have a script or makefile which does just this?

TIA
Steve




-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

This one looks like a plan. However I will not be able to work on the 
feature till ~15 May. So if anybody have a free time to start this work 
- feel free to do it and share patches :)


Thanks, Ruslo

On 22-Apr-16 20:36, Brad King wrote:

On 04/20/2016 09:50 AM, Ruslan Baratov wrote:

1) add_compile_warnings
* similar to add_definitions, add_compile_options
* modify COMPILE_WARNINGS directory property (append)
2) target_compile_warnings
* similar to target_compile_options, target_compile_definitions
* modify COMPILE_WARNINGS target property (append)
3) source_files_compile_warnings
* similar to set_source_files_properties
* modify COMPILE_WARNINGS sources property (append)

Sounds good.  Note that cmTarget has dedicated storage with backtrace
information for other build system properties.  Please use the same
pattern for these.  I also suggest getting the directory/target level
working first and work on source files later.  The infrastructure for
the latter is not as mature so it may need more work.


*_compile_warnings(

DISABLE  # add =off to COMPILE_WARNINGS
property
ENABLE  # add =on to COMPILE_WARNINGS
property
TREAT_AS_ERROR  # add =error to
COMPILE_WARNINGS property
)

Sounds good.


* all (compiler specific "all", e.g. /Wall or -Wall)
* default
* level
* none
* everything (all possible warnings for compiler, if there is no such
option use maximum level plus some warnings explicitly)

Okay.  Let's drop level for now for the reason you outlined.
We can always add it later.


Properties will be set in form =on|off|error, e.g.:

add_compile_warnings(DISABLE undef unused ENABLE inline TREAT_AS_ERROR 
everything)

will set COMPILE_WARNINGS directory property to:

undef=off unused=off inline=on everything=error

Good.


In case of any conflicts return CMake warning for developer message
(cmake -Wdev/cmake -Wno-dev).

Good.


Directory properties affect targets and sources, target properties
affect sources of this target. E.g.:

  add_compile_warnings(DISABLE undef)
  target_compile_warnings(foo DISABLE unused)

effectively equivalent to:

  target_compile_warnings(foo DISABLE undef unused)

Question: do we need to control this? probably by
'target_compile_warnings(foo DISABLE unused IGNORE DIRECTORY)' ?

It should be possible to merge the directory/target/source settings
with proper precedence.  I don't understand your example well enough
to see what "IGNORE DIRECTORY" would mean.  Either way, such information
needs to be encoded somehow in the property values.


 may expand to nothing in case warning make no sense for
current language or warning not implemented by compiler:

Okay.


After this feature implemented we need to introduce new policy to avoid
adding warnings flags to CMAKE_CXX_FLAGS by default (e.g. "/W3" added by
default for Visual Studio).

Yes.


Warnings should not be propagated via INTERFACE because unlike
definitions or other compiler flags they doesn't affect final binary or
compatibility.

Okay.


On 29-Mar-16 22:42, Ruslan Baratov wrote:

One more note. Properties is a good abstraction and works great for
the native CMake project. But there is a tricky scenario about them -
when we need to create ExternalProject_Add for the non-CMake project.

Would be nice to have this one.

This is beyond the scope of this change and affects all flags, so
let's defer this for a later time.


Is it possible in general to control warnings globally? Imagine I have
target that should ignore all warnings for any reason. If you able to
control warnings globally this target will generate tons of useless
messages. How to enable warnings for all targets except this one?

This thread has not yet designed any means for a user to control
warnings globally (e.g. via a cache entry).  Project code should
be able to offer such options manually, but it would also be nice
to have a CMake-defined setting.  The semantics of such a setting
will need to be defined carefully to allow the project to override
(or not override) settings for specific targets.

-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 API for warnings

[Ruslan Baratov via cmake-developers]

On 26-Apr-16 01:58, Brad King wrote:

On 04/23/2016 12:11 AM, Ruslan Baratov wrote:

It means ignoring directory properties. So by default we will inherit settings.

[snip]

To disable inheriting we need to add extra argument (?) to *_compile_warnings:

  add_compile_warnings(DISABLE warn-A)
  target_compile_warnings(foo DISABLE warn-B IGNORE DIRECTORY)

We don't have such a feature for any of the other build settings so
there is no precedent for how to represent this or its exact semantics.


Okay, fair enough, let's skip it.

Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

On 22-Apr-16 20:36, Brad King wrote:

On 04/20/2016 09:50 AM, Ruslan Baratov wrote:

1) add_compile_warnings
* similar to add_definitions, add_compile_options
* modify COMPILE_WARNINGS directory property (append)
2) target_compile_warnings
* similar to target_compile_options, target_compile_definitions
* modify COMPILE_WARNINGS target property (append)
3) source_files_compile_warnings
* similar to set_source_files_properties
* modify COMPILE_WARNINGS sources property (append)

Sounds good.  Note that cmTarget has dedicated storage with backtrace
information for other build system properties.  Please use the same
pattern for these.  I also suggest getting the directory/target level
working first and work on source files later.  The infrastructure for
the latter is not as mature so it may need more work.


*_compile_warnings(

DISABLE  # add =off to COMPILE_WARNINGS
property
ENABLE  # add =on to COMPILE_WARNINGS
property
TREAT_AS_ERROR  # add =error to
COMPILE_WARNINGS property
)

Sounds good.


* all (compiler specific "all", e.g. /Wall or -Wall)
* default
* level
* none
* everything (all possible warnings for compiler, if there is no such
option use maximum level plus some warnings explicitly)

Okay.  Let's drop level for now for the reason you outlined.
We can always add it later.


Properties will be set in form =on|off|error, e.g.:

add_compile_warnings(DISABLE undef unused ENABLE inline TREAT_AS_ERROR 
everything)

will set COMPILE_WARNINGS directory property to:

undef=off unused=off inline=on everything=error

Good.


In case of any conflicts return CMake warning for developer message
(cmake -Wdev/cmake -Wno-dev).

Good.


Directory properties affect targets and sources, target properties
affect sources of this target. E.g.:

  add_compile_warnings(DISABLE undef)
  target_compile_warnings(foo DISABLE unused)

effectively equivalent to:

  target_compile_warnings(foo DISABLE undef unused)

Question: do we need to control this? probably by
'target_compile_warnings(foo DISABLE unused IGNORE DIRECTORY)' ?

It should be possible to merge the directory/target/source settings
with proper precedence.  I don't understand your example well enough
to see what "IGNORE DIRECTORY" would mean.  Either way, such information
needs to be encoded somehow in the property values.


It means ignoring directory properties. So by default we will inherit 
settings. Target will inherit directory properties:


add_compile_warnings(DISABLE warn-A)
target_compile_warnings(foo DISABLE warn-B)

COMPILE_WARNINGS of target 'foo' property value:

warn-A=off warn-B=off

Sources:

add_compile_warnings(ENABLE warn-A)
target_compile_warnings(foo ENABLE warn-B)
source_files_compile_warnings(foo.cpp ENABLE warn-C)

COMPILE_WARNINGS of 'foo.cpp' property value:

warn-A=on warn-B=on warn-C=on

To disable inheriting we need to add extra argument (?) to 
*_compile_warnings:


add_compile_warnings(DISABLE warn-A)
target_compile_warnings(foo DISABLE warn-B IGNORE DIRECTORY)

COMPILE_WARNINGS of target 'foo' property value (warn-A from directory 
properties ignored):


warn-B=off

Same with IGNORE TARGET:

add_compile_warnings(ENABLE warn-A)
target_compile_warnings(foo ENABLE warn-B)
source_files_compile_warnings(foo.cpp ENABLE warn-C IGNORE TARGET)

COMPILE_WARNINGS of 'foo.cpp' property value (warn-B from target 
ignored, directory not):


warn-C=on warn-A=on

Ignoring both:

add_compile_warnings(ENABLE warn-A)
target_compile_warnings(foo ENABLE warn-B)
source_files_compile_warnings(foo.cpp ENABLE warn-C IGNORE TARGET 
DIRECTORY)


Result:

warn-C=on




 may expand to nothing in case warning make no sense for
current language or warning not implemented by compiler:

Okay.


After this feature implemented we need to introduce new policy to avoid
adding warnings flags to CMAKE_CXX_FLAGS by default (e.g. "/W3" added by
default for Visual Studio).

Yes.


Warnings should not be propagated via INTERFACE because unlike
definitions or other compiler flags they doesn't affect final binary or
compatibility.

Okay.


On 29-Mar-16 22:42, Ruslan Baratov wrote:

One more note. Properties is a good abstraction and works great for
the native CMake project. But there is a tricky scenario about them -
when we need to create ExternalProject_Add for the non-CMake project.

Would be nice to have this one.

This is beyond the scope of this change and affects all flags, so
let's defer this for a later time.


Is it possible in general to control warnings globally? Imagine I have
target that should ignore all warnings for any reason. If you able to
control warnings globally this target will generate tons of useless
messages. How to enable warnings for all targets except this one?

This thread has not yet designed any means for a user to control
warnings globally (e.g. via a 

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

So here is a summary of this feature so far:

Introducing new 3 functions for controlling compiler warnings:

1) add_compile_warnings
  * similar to add_definitions, add_compile_options
  * modify COMPILE_WARNINGS directory property (append)
2) target_compile_warnings
  * similar to target_compile_options, target_compile_definitions
  * modify COMPILE_WARNINGS target property (append)
3) source_files_compile_warnings
  * similar to set_source_files_properties
  * modify COMPILE_WARNINGS sources property (append)

Same API for all:

  *_compile_warnings(
  
  DISABLE  # add =off to COMPILE_WARNINGS 
property
  ENABLE  # add =on to COMPILE_WARNINGS 
property
  TREAT_AS_ERROR  # add =error to 
COMPILE_WARNINGS property

  )

General warning-id's:

  * all (compiler specific "all", e.g. /Wall or -Wall)
  * default
  * level
  * none
  * everything (all possible warnings for compiler, if there is no such 
option use maximum level plus some warnings explicitly)


Group warnings-id's:

  * inline # MSVC: 4711 (automatic-inline), 4714 (force-not-inlined), 
4710 (not-inlined), 4514 (unreferenced-inline)
  * compatibility-c++98 # Clang: `-Wc++98-compat`, 
`-Wc++98-compat-pedantic`


Simple warning-id examples:

  * undef  # Clang/GCC: `-Wunder`; MSVC: 4668
  * shift-sign-overflow # Clang: `-Wshift-sign-overflow`, GCC: nothing, 
MSVC: nothing

  * inherits-via-dominance # Clang/GCC: nothing, MSVC: 4250

Since I'm expecting cross-platform behaviour here I think that such 
general warnings-id like 'all', 'default', 'level' might
be confusing since different compilers with the same levels will define 
different groups of warnings (no tests/examples, I'm just pretty sure 
about that).

So I'm afraid we will end with code like this:

  if(MSVC)
add_compile_warnings(ENABLE level3)
  else()
add_compile_warnings(ENABLE level4)
  endif()

I think that goal of this feature is to avoid such compiler specific 
switches.


Note that there is no such problem with 'none', 'everything', 
group/simple warning-id.


Properties will be set in form =on|off|error, e.g.:

  add_compile_warnings(DISABLE undef unused ENABLE inline 
TREAT_AS_ERROR everything)


will set COMPILE_WARNINGS directory property to:

  undef=off unused=off inline=on everything=error

Generator expressions can be used for config-specific warnings:

  set(debug_off $<$:off>)
  set(non_debug_error $<$:error>)

  set_directory_properties(... COMPILE_WARNINGS 
undef=${debug_off}${non_debug_error} ${old_warnings})


In case of any conflicts return CMake warning for developer message 
(cmake -Wdev/cmake -Wno-dev).


Implementation details:

  Abstracted unmodified  will be kept until the very last 
point when we need real flags generated. E.g. do not expand 'everything' 
on any step since this will

  mask possible configuration errors:

add_compile_warnings(DISABLE all ENABLE undef) # OK: turn off 
everything except 'undef'
add_compile_warnings(DISABLE warning-A warning-B ... undef ... 
warning-Y warning-Z ENABLE undef) # ERROR: user want undef=on and undef=off


  Directory properties affect targets and sources, target properties 
affect sources of this target. E.g.:


add_compile_warnings(DISABLE undef)
target_compile_warnings(foo DISABLE unused)

  effectively equivalent to:

target_compile_warnings(foo DISABLE undef unused)

  Question: do we need to control this? probably by 
'target_compile_warnings(foo DISABLE unused IGNORE DIRECTORY)' ?


   may expand to nothing in case warning make no sense for 
current language or warning not implemented by compiler:


add_compile_warnings(ENABLE switch-enum)
add_executable(foo foo.c) # C target, no warning will be added
add_executable(boo boo.cpp) # C++ target, -Wswitch-enum will be added

add_compile_warning(ENABLE inherits-via-dominance)
add_executable(foo foo.cpp) # Clang/GCC: nothing, MSVC: 4250

After this feature implemented we need to introduce new policy to avoid 
adding warnings flags to CMAKE_CXX_FLAGS by default (e.g. "/W3" added by 
default for Visual Studio).


Warnings should not be propagated via INTERFACE because unlike 
definitions or other compiler flags they doesn't affect final binary or 
compatibility.


Questions that is not touched so far:

On 29-Mar-16 22:42, Ruslan Baratov wrote:
> One more note. Properties is a good abstraction and works great for 
the native CMake project. But there is a tricky scenario about them - 
when we need to create ExternalProject_Add for the non-CMake project.
> E.g. when I have CMAKE_POSITION_INDEPENDENT_CODE variable set to 
`YES` I need to add `-fPIC` to the flags manually, or check 
`CXX_STANDARD 11` and add `-std=c++11`. I guess I can handle such simple 
cases but I can predict that for warnings it will be a huge pain.

> How CMake can help me avoid violating DRY?

Would be nice to have this one. Like 'expand_compiler_flags(cxxflags 
LANGUAGE CXX CONFIGURATION Debug)' => add 'CXXFLAGS=${cxxflags}' 

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

On 13-Apr-16 01:00, Brad King wrote:

Hi Ruslo,

Sorry for taking so long to respond here.  I've been hoping to find time
to think through the design deeply but I don't know when that may happen.
Here is some more feedback.  I invite others to jump in here.  Without
more interest I'm hesitant to proceed.

On 04/05/2016 02:03 PM, Ruslan Baratov wrote:

Report an error in case of any type of conflicts.

Yes.


new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may control this.

I'd prefer to avoid extra knobs if possible.

Okay, what about CMake warning for developer? (cmake -Wdev/cmake -Wno-dev)




You mean this:

  compatibility-c++98=off
  inline=off
  special-members=off
  catch-semantic-changed=off
  covered-switch-default=off
  inherits-via-dominance=off
  name-length-exceeded=off
  padded=off
  this-used-in-init=off
  EVERYTHING=on
  EVERYTHING=error

versus this one:

  DISABLE
compatibility-c++98
inline
special-members
catch-semantic-changed
covered-switch-default
inherits-via-dominance
name-length-exceeded
padded
this-used-in-init
  ENABLE
EVERYTHING
  TREAT_AS_ERROR
EVERYTHING

Consider examples where we don't have the full list ahead of time and
are instead appending.

-


   Or, what if we want to check the current property
value to see if some setting is already present?

What do you mean?


   Compilers use flags like

   -Wxyz -Wno-abc -Whjk=error

and not

   -WDISABLE $w1 $w2 -WENABLE $w3 $w4
I don't think the reason of approach used in compilers is about been 
convenient for user to analyze command line flags. CMake can do much 
better job here.
All I'm trying to say about ENABLE/DISABLE lists is that if user will 
have N warnings to enable and M warnings to disable he will not write N 
times *=on and M times *=off and probably will just create helper functions:


function(enable_warnings_list ...)
  foreach(warning ...)
list(APPEND result ${warning}=on)
  endforeach()
endif()

So instead of writing extra different modules by a lot of developers why 
not support this from the box?




so IMO the individual values are easier to reason about.  Also one could
imagine having the value come from a generator expression, e.g.

foo=$
As far as I understand we should allow on/off/error, so effectively it 
will be:


foo=$<$:off>$<$:error>

so how about this:

   compile_warnings(DISABLE foo CONFIGURATION Debug)
   compile_warnings(ERROR foo CONFIGURATION NOT Debug)

?




I'd like to find another name that captures the idea of enabling most warnings.

Agree. May be EVERYTHING? Or ALLWARNINGS, FULLSET?

I don't think "everything" or "all" has a meaningful implementation
available on all compilers.  I was actually saying the opposite.
We should not try to provide such an abstraction and instead have
one called "most" or "high" or something like that.
I'm pretty sure all compilers have flag to enable all kind of available 
warnings (it may not call "All", e.g. -Weverything for Clang). Even if 
there is such compiler we can use maximum level + adding extra warnings 
explicitly. There must be abstracted group that allow to enable 
everything. Also I think that LEVEL/MOST/ALL groups doesn't make a 
lot of practical sense since every compiler have different kind of 
warnings enabled by such groups, so it's not cross-platformic friendly.


Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

Sounds good?

On 06-Apr-16 01:03, Ruslan Baratov via cmake-developers wrote:

On 05-Apr-16 21:03, Brad King wrote:

On 03/31/2016 12:47 PM, Ruslan Baratov wrote:

What about 3 properties containing list of 's (groups
unexpanded):

* COMPILE_WARNINGS_DISABLE # e.g. "shift-sign-overflow;unused"
* COMPILE_WARNINGS_ENABLE # e.g. "ALL"
* COMPILE_WARNINGS_TREAT_AS_ERROR # e.g. group + specific: 
"inline;undef"

We would need to define behavior when a warning appears in more than
one list.


Report an error in case of any type of conflicts. It may happens not 
only when same type appears in both DISABLE and ENABLE but for example 
when warning already defined by some group. E.g. "EVERYTHING;undef" is 
the same as "EVERYTHING". If user okay with having intersections (for 
any reason) new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may 
control this.



   Perhaps we need to define some kind of `=on/off/error/no-error`
syntax for each list entry.


You mean this:

compatibility-c++98=off
inline=off
special-members=off
catch-semantic-changed=off
covered-switch-default=off
inherits-via-dominance=off
name-length-exceeded=off
padded=off
this-used-in-init=off
EVERYTHING=on
EVERYTHING=error

versus this one:

DISABLE
  compatibility-c++98
  inline
  special-members
  catch-semantic-changed
  covered-switch-default
  inherits-via-dominance
  name-length-exceeded
  padded
  this-used-in-init
ENABLE
  EVERYTHING
TREAT_AS_ERROR
  EVERYTHING

?

Second variant looks clearer for me.



The name "ALL" may not be representative.  Even -Wall does not really 
enable
all possible warnings on some compilers.  I'd like to find another 
name that
captures the idea of enabling most warnings.  Or we could try to 
subsume it

into an interface for the warning level, with -Wall considered "high".


Agree. May be EVERYTHING? Or ALLWARNINGS, FULLSET?




I'm not sure about mixing more languages. I think it will be similar to
COMPILE_OPTIONS (?), see no language specification in
`add_compile_options` command.
Right.  We do have the COMPILE_LANGUAGE genex for some limited use 
cases.

Its documentation even includes a COMPILE_OPTIONS example. However, it
also documents that it is not possible to implement fully on VS IDE
generators.  For example, VS does not distinguish between C and C++
flags.  The same set is always used for both.


Since /Wall can be set by 'target_compile_options' then abstracting it 
by `target_compile_warnings(... ENABLE ALL)` should not be a problem I 
think.




Another option is to have the warning names themselves have a language
in them, similar to the COMPILE_FEATURES names.


See no point of this one. So say we have switch-enum warning which is 
only for C++, why do we need cxx-switch-enum? There is no 
c-switch-enum or any other *-switch-enum. If we are talking about 
'undef' why do we need c-undef and cxx-undef? It mean the same and I 
think will be set or unset simultaneously.


Ruslo


--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

On 05-Apr-16 21:03, Brad King wrote:

On 03/31/2016 12:47 PM, Ruslan Baratov wrote:

What about 3 properties containing list of 's (groups
unexpanded):

* COMPILE_WARNINGS_DISABLE # e.g. "shift-sign-overflow;unused"
* COMPILE_WARNINGS_ENABLE # e.g. "ALL"
* COMPILE_WARNINGS_TREAT_AS_ERROR # e.g. group + specific: "inline;undef"

We would need to define behavior when a warning appears in more than
one list.


Report an error in case of any type of conflicts. It may happens not 
only when same type appears in both DISABLE and ENABLE but for example 
when warning already defined by some group. E.g. "EVERYTHING;undef" is 
the same as "EVERYTHING". If user okay with having intersections (for 
any reason) new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may 
control this.



   Perhaps we need to define some kind of `=on/off/error/no-error`
syntax for each list entry.


You mean this:

compatibility-c++98=off
inline=off
special-members=off
catch-semantic-changed=off
covered-switch-default=off
inherits-via-dominance=off
name-length-exceeded=off
padded=off
this-used-in-init=off
EVERYTHING=on
EVERYTHING=error

versus this one:

DISABLE
  compatibility-c++98
  inline
  special-members
  catch-semantic-changed
  covered-switch-default
  inherits-via-dominance
  name-length-exceeded
  padded
  this-used-in-init
ENABLE
  EVERYTHING
TREAT_AS_ERROR
  EVERYTHING

?

Second variant looks clearer for me.



The name "ALL" may not be representative.  Even -Wall does not really enable
all possible warnings on some compilers.  I'd like to find another name that
captures the idea of enabling most warnings.  Or we could try to subsume it
into an interface for the warning level, with -Wall considered "high".


Agree. May be EVERYTHING? Or ALLWARNINGS, FULLSET?




I'm not sure about mixing more languages. I think it will be similar to
COMPILE_OPTIONS (?), see no language specification in
`add_compile_options` command.

Right.  We do have the COMPILE_LANGUAGE genex for some limited use cases.
Its documentation even includes a COMPILE_OPTIONS example.  However, it
also documents that it is not possible to implement fully on VS IDE
generators.  For example, VS does not distinguish between C and C++
flags.  The same set is always used for both.


Since /Wall can be set by 'target_compile_options' then abstracting it 
by `target_compile_warnings(... ENABLE ALL)` should not be a problem I 
think.




Another option is to have the warning names themselves have a language
in them, similar to the COMPILE_FEATURES names.


See no point of this one. So say we have switch-enum warning which is 
only for C++, why do we need cxx-switch-enum? There is no c-switch-enum 
or any other *-switch-enum. If we are talking about 'undef' why do we 
need c-undef and cxx-undef? It mean the same and I think will be set or 
unset simultaneously.


Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

On 31-Mar-16 20:37, Brad King wrote:

On 03/29/2016 11:24 AM, Ruslan Baratov wrote:

OTOH many such switches are
so specific that they should not be abstracted and can instead be
added to COMPILE_OPTIONS with a $ genex guard.

What about generating nothing for such cases?

Yes, that makes sense.  I was just discussing alternatives.  Simon's
post contains an example of a granular flag that makes sense to try
to abstract.


I think these warning properties should perhaps be done as usage
requirements with propagation through INTERFACE_* properties.  I'd
need to see some example use cases spelled out though.

But not if target is installed. It will be quite inconvenient if 3rd
party package add some flags to local targets. Is it possible to support
it from the box?

Yes, let's skip propagation until a valid use case is raised in the
future, if any.  Likely the directory properties can be used to specify
project-wide warning configurations without propagating across targets.


Great.


What about this:

  compile_warnings # modify directory properties
  target_compile_warnings # modify target properties
  sources_compile_warnings # modify source properties

Let's start by getting the directory/target/source properties worked
out.  First we need to figure out how to make the properties work with
language-specific warning flags and such.  We can add command porcelain
for them later.


Same API for all:

 *_compile_warnings( DISABLE 
ENABLE  TREAT_AS_ERROR ) # may be plus 'APPEND'
for extending instead of overwriting (?)

Somehow this needs to be encoded in a COMPILE_WARNINGS property or
group of properties.  They should support generator expressions for
per-configuration warnings.


What about 3 properties containing list of 's (groups 
unexpanded):


* COMPILE_WARNINGS_DISABLE # e.g. "shift-sign-overflow;unused"
* COMPILE_WARNINGS_ENABLE # e.g. "ALL"
* COMPILE_WARNINGS_TREAT_AS_ERROR # e.g. group + specific: "inline;undef"

I don't know how it will happen in CMake's internals but I think at the 
point of generating the real flags we know the language of the 
source/target and can exclude language specific warnings. I.e. if 
'switch-enum' is set for C++ target we can generate '-Wswitch-enum' but 
if target is pure C we will add no flags.


I'm not sure about mixing more languages. I think it will be similar to 
COMPILE_OPTIONS (?), see no language specification in 
`add_compile_options` command.



General warning-id's:

* ALL
* DEFAULT
* LEVEL

And `NONE`.


Ok




Group warnings-id's:

Yes, but either the warning names or the property names will need to
allow for language-specific warnings.  We need to be able to control
warnings for C, C++, Fortran, etc. separately.  OTOH it would also
be nice to be able to set C and C++ warnings together since many of
them are common.

Ideas?


See above.

Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] EFFECTIVE_PLATFORM_NAME not expanded in TARGET_* generator expressions on iOS

[Ruslan Baratov via CMake]

The note about CMAKE_IOS_INSTALL_COMBINED is related to value of 
CMAKE_OSX_SYSROOT. `${EFFECTIVE_PLATFORM_NAME}` as far as I understand 
used on build step too, it's not only installation 
(`cmTarget::ComputeOutputDir`). As alternative you can try to hardcode 
`LIBRARY_OUTPUT_DIRECTORY` so both simulator and device will have same 
predictable location. I don't know about CMake internals in such depth 
to answer question about generator expression.


Ruslo

On 29-Mar-16 22:51, Vladimír Vondruš wrote:

Hm... this is unfortunate. Would it be possible to keep the 
${EFFECTIVE_PLATFORM_NAME} in place for the install step but return it 
substituted when one asks explicitly using generator expression? From what I 
understood in the docs, the CMAKE_IOS_INSTALL_COMBINED is doing something 
additional during installation step and does not affect generator step -- so I 
think a behavior specific for installation and CMAKE_IOS_INSTALL_COMBINED could 
be separated from direct use of generator expressions. Or am I completely out 
of touch?

Thank you
mosra

__

Od: Ruslan Baratov 
Komu: "Vladimír Vondruš" 
Datum: 29.03.2016 15:20
Předmět: Re: [CMake] EFFECTIVE_PLATFORM_NAME not expanded in TARGET_* generator 
expressions on iOS

CC: cmake@cmake.org
On 29-Mar-16 16:14, Vladimír Vondruš wrote:

I saw that commit, yes. Since there is no additional round of variable expansion, wouldn't it 
be better to expand the ${EFFECTIVE_PLATFORM_NAME} to at least something fixed (based on the 
value of CMAKE_OSX_SYSROOT), instead of making the generator expression unusable in all cases? 
It seems reasonable to me that if I set CMAKE_OSX_SYSROOT to "iPhoneSimulator", the 
output of $ would be something like

  /path/to/my/build/dir/Debug-iphonesimulator/something.framework

instead of:

  /path/to/my/build/dir/Debug${EFFECTIVE_PLATFORM_NAME}/something.framework

Because the latter is unusable, with the former I have at least the ability to 
use it with a single fixed SDK.

Thanks
mosra

As far as I know you have to set CMAKE_OSX_SYSROOT to "iphoneos" so
Xcode project will contain both simulator and device configuration.
Without this change such feature like CMAKE_IOS_INSTALL_COMBINED will
not work. In other words substituting `${EFFECTIVE_PLATFORM_NAME}` may
fit your needs but will broke CMAKE_IOS_INSTALL_COMBINED for everybody
(at least if this behaviour will be unconditional).

Ruslo


__

Od: Ruslan Baratov 
Komu: "Vladimír Vondruš" 
Datum: 21.03.2016 14:56
Předmět: Re: [CMake] EFFECTIVE_PLATFORM_NAME not expanded in TARGET_* generator 
expressions on iOS

CC: cmake@cmake.org
On 21-Mar-16 19:42, Vladimír Vondruš wrote:

Hello,

I came across this problem when trying to use XCTest macros ( 
https://cmake.org/cmake/help/latest/module/FindXCTest.html ) on iOS. When 
compiling for OSX, ctest properly executes all test cases, but when targeting 
iOS or iOS simulator, all the test cases fail similarly to the following:

   25: Test command: /Applications/Xcode.app/Contents/Developer/usr/bin/xctest 
"/Users/mosra/Code/corrade/build-ioss/src/Corrade/Utility/Test/Debug${EFFECTIVE_PLATFORM_NAME}/UtilityTypeTraitsTestRunner.xctest/../.."
   25: Environment variables:
   25:  
DYLD_FRAMEWORK_PATH=/Users/mosra/Code/corrade/build-ioss/src/Corrade/Utility/Test/Debug${EFFECTIVE_PLATFORM_NAME}/UtilityTypeTraitsTest.framework/..
   25: Test timeout computed to be: 9.99988e+06
   25: 2016-03-21 12:41:38.799 xctest[31113:31078264] The bundle “Test” 
couldn’t be loaded because its executable couldn’t be located. Try reinstalling 
the bundle.
   25/28 Test #25: UtilityTypeTraitsTest ...***Failed0.04 
sec

As you can see, the `${EFFECTIVE_PLATFORM_NAME}` is not being expanded to 
`-iphonesimulator` and thus the file is not found. The problem is that the 
`$` generator expression does not expand the 
variable. On the other hand, installation works without an issue, because the 
`cmake_install.cmake` scripts do additional round of variable expansion that 
(accidentally?) fixes this. The relevant part of the CMake source is here: 
https://github.com/Kitware/CMake/blob/cd569b962dbeaa7ea718021c16582cddd158df3a/Source/cmGeneratorTarget.cxx#L5063

   From the source it looks like the generator is just putting the 
"${EFFECTIVE_PLATFORM_NAME}" output and hopes that someone later expands it. 
That's the case with install scripts (so they work), but not with generator expressions. 
The `TARGET_LINKER_FILE_DIR` is not the only affected, the problem is the same for all 
`TARGET_*` generator expressions.

Currently I'm working around this by partially hardcoding the path, but that's 
far from ideal and I would like to avoid that:

   if(CMAKE_OSX_SYSROOT MATCHES "iPhoneOS")
   set(platform_name 

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

On 28-Mar-16 21:05, Brad King wrote:

On 03/28/2016 01:49 AM, Geoffrey Viola wrote:

Thanks for the feedback. I’ll have to look more in-depth at Xcode specific 
issues.

Take a look at this approach:
* https://github.com/ruslo/sugar/wiki/Cross-platform-warning-suppression

I took a look at your repository. It’s very sophisticated.

I'd prefer to see an approach that abstracts the warning levels
in a similar way to COMPILE_FEATURES, COMPILE_DEFINITIONS,
INCLUDE_DIRECTORIES, etc.  Project code would set directory or
target properties to specify warning levels and the generators
would map them to the proper flags or project file settings
automatically.

Something like this has long been missing for compiler warnings
and optimization levels.

-Brad

One more note. Properties is a good abstraction and works great for the 
native CMake project. But there is a tricky scenario about them - when 
we need to create ExternalProject_Add for the non-CMake project.
E.g. when I have CMAKE_POSITION_INDEPENDENT_CODE variable set to `YES` I 
need to add `-fPIC` to the flags manually, or check `CXX_STANDARD 11` 
and add `-std=c++11`. I guess I can handle such simple cases but I can 
predict that for warnings it will be a huge pain.

How CMake can help me avoid violating DRY?

Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

On 29-Mar-16 21:24, Brad King wrote:

On 03/29/2016 09:09 AM, Ruslan Baratov wrote:

As a general note obviously I've used another approach because I decide
to create CMake module which can be used with regular CMake versions :)
Of course implementing this in CMake "from the box" is best.

Are we talking about levels only or about control of exact kind of
warnings too (like `-Wswitch`/`-wswitch`/`-Werror=switch`)?

At a minimum we should support levels (e.g. all, default, none) that
are generic enough to have mappings to flags on every compiler.  Later
one could consider more granular switches with enumerated options that
may not all have flags on every compiler.



OTOH many such switches are
so specific that they should not be abstracted and can instead be
added to COMPILE_OPTIONS with a $ genex guard.

What about generating nothing for such cases? E.g. code:

  try {
  }
  catch (...) {
  }

produce "catch-semantic-changed" warning on MSVC but it's okay for 
Clang. So we can add `/w4571` for MSVC and nothing for other compilers.




I think these warning properties should perhaps be done as usage
requirements with propagation through INTERFACE_* properties.  I'd
need to see some example use cases spelled out though.
But not if target is installed. It will be quite inconvenient if 3rd 
party package add some flags to local targets. Is it possible to support 
it from the box? Requirements are handy when we are talking about 
different code generated with different compile flags. Warnings have 
different nature. Fact that we are using `-Wall` or not using `-Wall` 
doesn't change final binary or affect compatibility.




Once such directory/target properties are available then we could look
at making them take over the role of providing default warning flags
instead of putting them in the CMAKE__FLAGS* variables.  That may
need a policy as you pointed out earlier.

-Brad

Great.


What about this:

compile_warnings # modify directory properties
target_compile_warnings # modify target properties
sources_compile_warnings # modify source properties

Same API for all:

   *_compile_warnings( DISABLE  
ENABLE  TREAT_AS_ERROR ) # may be plus 'APPEND' 
for extending instead of overwriting (?)


General warning-id's:

  * ALL
  * DEFAULT
  * LEVEL

Group warnings-id's:

  * inline # MSVC: 4711 (automatic-inline), 4714 (force-not-inlined), 
4710 (not-inlined), 4514 (unreferenced-inline)
  * compatibility-c++98 # Clang: `-Wc++98-compat`, 
`-Wc++98-compat-pedantic`


Simple warning-id examples:

  * undef  # Clang/GCC: `-Wunder`; MSVC: 4668
  * shift-sign-overflow # Clang: `-Wshift-sign-overflow`, GCC: nothing, 
MSVC: nothing

  * inherits-via-dominance # Clang/GCC: nothing, MSVC: 4250

Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] EFFECTIVE_PLATFORM_NAME not expanded in TARGET_* generator expressions on iOS

[Ruslan Baratov via CMake]

On 29-Mar-16 16:14, Vladimír Vondruš wrote:

I saw that commit, yes. Since there is no additional round of variable expansion, wouldn't it 
be better to expand the ${EFFECTIVE_PLATFORM_NAME} to at least something fixed (based on the 
value of CMAKE_OSX_SYSROOT), instead of making the generator expression unusable in all cases? 
It seems reasonable to me that if I set CMAKE_OSX_SYSROOT to "iPhoneSimulator", the 
output of $ would be something like

 /path/to/my/build/dir/Debug-iphonesimulator/something.framework

instead of:

 /path/to/my/build/dir/Debug${EFFECTIVE_PLATFORM_NAME}/something.framework

Because the latter is unusable, with the former I have at least the ability to 
use it with a single fixed SDK.

Thanks
mosra
As far as I know you have to set CMAKE_OSX_SYSROOT to "iphoneos" so 
Xcode project will contain both simulator and device configuration. 
Without this change such feature like CMAKE_IOS_INSTALL_COMBINED will 
not work. In other words substituting `${EFFECTIVE_PLATFORM_NAME}` may 
fit your needs but will broke CMAKE_IOS_INSTALL_COMBINED for everybody 
(at least if this behaviour will be unconditional).


Ruslo



__

Od: Ruslan Baratov 
Komu: "Vladimír Vondruš" 
Datum: 21.03.2016 14:56
Předmět: Re: [CMake] EFFECTIVE_PLATFORM_NAME not expanded in TARGET_* generator 
expressions on iOS

CC: cmake@cmake.org
On 21-Mar-16 19:42, Vladimír Vondruš wrote:

Hello,

I came across this problem when trying to use XCTest macros ( 
https://cmake.org/cmake/help/latest/module/FindXCTest.html ) on iOS. When 
compiling for OSX, ctest properly executes all test cases, but when targeting 
iOS or iOS simulator, all the test cases fail similarly to the following:

  25: Test command: /Applications/Xcode.app/Contents/Developer/usr/bin/xctest 
"/Users/mosra/Code/corrade/build-ioss/src/Corrade/Utility/Test/Debug${EFFECTIVE_PLATFORM_NAME}/UtilityTypeTraitsTestRunner.xctest/../.."
  25: Environment variables:
  25:  
DYLD_FRAMEWORK_PATH=/Users/mosra/Code/corrade/build-ioss/src/Corrade/Utility/Test/Debug${EFFECTIVE_PLATFORM_NAME}/UtilityTypeTraitsTest.framework/..
  25: Test timeout computed to be: 9.99988e+06
  25: 2016-03-21 12:41:38.799 xctest[31113:31078264] The bundle “Test” 
couldn’t be loaded because its executable couldn’t be located. Try reinstalling 
the bundle.
  25/28 Test #25: UtilityTypeTraitsTest ...***Failed0.04 sec

As you can see, the `${EFFECTIVE_PLATFORM_NAME}` is not being expanded to 
`-iphonesimulator` and thus the file is not found. The problem is that the 
`$` generator expression does not expand the 
variable. On the other hand, installation works without an issue, because the 
`cmake_install.cmake` scripts do additional round of variable expansion that 
(accidentally?) fixes this. The relevant part of the CMake source is here: 
https://github.com/Kitware/CMake/blob/cd569b962dbeaa7ea718021c16582cddd158df3a/Source/cmGeneratorTarget.cxx#L5063

  From the source it looks like the generator is just putting the 
"${EFFECTIVE_PLATFORM_NAME}" output and hopes that someone later expands it. 
That's the case with install scripts (so they work), but not with generator expressions. 
The `TARGET_LINKER_FILE_DIR` is not the only affected, the problem is the same for all 
`TARGET_*` generator expressions.

Currently I'm working around this by partially hardcoding the path, but that's 
far from ideal and I would like to avoid that:

  if(CMAKE_OSX_SYSROOT MATCHES "iPhoneOS")
  set(platform_name "-iphoneos")
  elseif(CMAKE_OSX_SYSROOT MATCHES "iPhoneSimulator")
  set(platform_name "-iphonesimulator")
  endif()
  set(target_linker_file_dir 
${CMAKE_CURRENT_BINARY_DIR}/$${platform_name}/${target}.xctest)

Is there any way to fix this directly in CMake? Also the above workaround works 
only when targeting single SDK and not when having single generated project for 
both the device and the simulator.

Thank you a lot for your help.

mosra

I doubt I can help with the problem but just for your information:
* it wasn't fixed "accidentally", it was a fix for #12506:
https://github.com/Kitware/CMake/commit/48fe617e667d2e6b1e471cfb56346de51f984ba5
* there is no "additional round" of variable expansion,
EFFECTIVE_PLATFORM_NAME initialized from Xcode's environment variable
EFFECTIVE_PLATFORM_NAME on installation

As far as I understand the main general problem with iOS
device/simulator support is that CMake doesn't have multi-toolchain
feature from the box. So for now all this stuff worked by generating
some "universal" code that do work for both SDKs. The real SDK can be
triggered by additional explicit option, i.e.:
* cmake --build _builds -- -sdk iphoneos # trigger iphoneos SDK
* cmake --build _builds -- -sdk iphonesimulator # trigger
iphonesimulator SDK

Ruslo



--

Powered by www.kitware.com

Please keep messages on-topic and 

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

On 28-Mar-16 12:49, Geoffrey Viola wrote:


Thanks for the feedback. I’ll have to look more in-depth at Xcode 
specific issues.


> Take a look at this approach:
> * https://github.com/ruslo/sugar/wiki/Cross-platform-warning-suppression

I took a look at your repository. It’s very sophisticated.

What exactly is sophisticated? API of `sugar_generate_warning_flags` 
function? Probably this is because it covering much more functionality 
that your approach, no? Also you can use this to create new function 
with more simple API. That is you can make `set_warning_level_high` 
using call to `sugar_generate_warning_flags` but there is no function 
(at least in the currently attached patch) that can set `-Wall` in 
cross-platform fashion for only one target.


The API that I’m supporting has global commands for simple, small 
projects and then a slightly more sophisticated set of commands around 
targets and source files. It’s supposed to remove the need of knowing 
compiler specific flags from the user, although they can be manually 
edited in CMake as always.


May be I'm missing something but there is no need to know compiler 
specific flags when using `sugar_generate_warning_flags`. In sense that 
when you set `conversion` then module will add `-Wconversion` for Clang 
and GCC, `4244` for MSVC and CLANG_WARN_SUSPICIOUS_IMPLICIT_CONVERSION 
for Xcode. From my practice there must be an abstraction that is linked 
to the exact type of warning because without `-Werror` warnings are 
quite useless and if you combine it with `-Wall -Weverything` there will 
be a lot of warning that I don't want to fix, like `-Wpadded` that 
produce warning like for every C++ class definition in the project.


The choice of flags for the various compilers are different between 
the two APIs. My API merely turns the warnings up without triggering 
false positives. It may miss some useful warnings. For example, my API 
uses /W4 instead of /Wall for MSVC. I’ve seen /Wall provide some 
additional useful warnings, but also some distracting, informational 
ones. There are a few users who agree that some of the /Wall warnings 
are more informational at 
http://stackoverflow.com/questions/4001736/whats-up-with-the-thousands-of-warnings-in-standard-headers-in-msvc-wall. 
Also, I should probably include –Wextra for the GCC warnings like 
yours does.


I think you should not make such decisions in code like "I know that /W4 
is better than /Wall" or "I'm sure -Wshadow is useless". That definitely 
up to user.


Ruslo


From: Ruslan Baratov [mailto:ruslan_bara...@yahoo.com]
Sent: Sunday, March 27, 2016 4:17 PM
To: Geoffrey Viola 
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] CMake API for warnings

I like an effort but not an implementation:
* It would be nice to not to set flags globally since we have more 
fine control options like target_compile_options (i.e. different 
target may have different warning settings)
* this will not work for Xcode since warnings should be set by 
XCODE_ATTRIBUTE_* properties


Take a look at this approach:
* https://github.com/ruslo/sugar/wiki/Cross-platform-warning-suppression

Though I think it should be simplified. Best implementation I see so far:
* Remove `RESULT_PROPERTIES`:  implement warning flags -> 
XCODE_ATTRIBUTE_* mapping in CMake itself
* Remove `CLEAR_GLOBAL` option: add user variable checking to CMake so 
it will not set `/W3` (or any other warning flags) by default. May be 
introduce new policy (?)


Ruslo

On 27-Mar-16 12:10, Geoffrey Viola wrote:

CMake should support an API to manage compiler warnings to simplify a 
common problem. Using more compilers with high levels of warnings 
means cheap static analysis and better conformance to standard C++.


Compiler warnings are an easy way to increase program reliability. A 
use case would be to increase compilation warnings on all internal 
code, ignore warnings on all 3rd party code, and treat all warnings as 
errors.


Attached is an initial attempt to control warnings in CMake. The API 
has a short name (e.g. set_warnings_as_errors) for simplicity and a 
more technical name (e.g. set_warnings_as_errors_folder) to specify 
scope. Note that the short name acts on CMake’s folder scope and is 
meant to be global. The current compilers considered are GCC, clang, 
Green Hills, and MSVC. A CMake Warning is issued if the macro does not 
support a specific compiler so that conformance can be guaranteed.


Thanks,

Geoffrey Viola

This message contains confidential information and is intended only 
for the recipient. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately if you have received this e-mail by mistake and delete 
this e-mail from your system. Finally, the recipient should check this 
email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus 

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

On 28-Mar-16 21:05, Brad King wrote:

On 03/28/2016 01:49 AM, Geoffrey Viola wrote:

Thanks for the feedback. I’ll have to look more in-depth at Xcode specific 
issues.

Take a look at this approach:
* https://github.com/ruslo/sugar/wiki/Cross-platform-warning-suppression

I took a look at your repository. It’s very sophisticated.

I'd prefer to see an approach that abstracts the warning levels
in a similar way to COMPILE_FEATURES, COMPILE_DEFINITIONS,
INCLUDE_DIRECTORIES, etc.  Project code would set directory or
target properties to specify warning levels and the generators
would map them to the proper flags or project file settings
automatically.
As a general note obviously I've used another approach because I decide 
to create CMake module which can be used with regular CMake versions :) 
Of course implementing this in CMake "from the box" is best.


Are we talking about levels only or about control of exact kind of 
warnings too (like `-Wswitch`/`-wswitch`/`-Werror=switch`)?


Ruslo



Something like this has long been missing for compiler warnings
and optimization levels.

-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 API for warnings

[Ruslan Baratov via cmake-developers]

I like an effort but not an implementation:
* It would be nice to not to set flags globally since we have more fine 
control options like target_compile_options (i.e. different target may 
have different warning settings)
* this will not work for Xcode since warnings should be set by 
XCODE_ATTRIBUTE_* properties


Take a look at this approach:
* https://github.com/ruslo/sugar/wiki/Cross-platform-warning-suppression

Though I think it should be simplified. Best implementation I see so far:
* Remove `RESULT_PROPERTIES`:  implement warning flags -> 
XCODE_ATTRIBUTE_* mapping in CMake itself
* Remove `CLEAR_GLOBAL` option: add user variable checking to CMake so 
it will not set `/W3` (or any other warning flags) by default. May be 
introduce new policy (?)


Ruslo

On 27-Mar-16 12:10, Geoffrey Viola wrote:


CMake should support an API to manage compiler warnings to simplify a 
common problem. Using more compilers with high levels of warnings 
means cheap static analysis and better conformance to standard C++.


Compiler warnings are an easy way to increase program reliability. A 
use case would be to increase compilation warnings on all internal 
code, ignore warnings on all 3^rd party code, and treat all warnings 
as errors.


Attached is an initial attempt to control warnings in CMake. The API 
has a short name (e.g. set_warnings_as_errors) for simplicity and a 
more technical name (e.g. set_warnings_as_errors_folder) to specify 
scope. Note that the short name acts on CMake’s folder scope and is 
meant to be global. The current compilers considered are GCC, clang, 
Green Hills, and MSVC. A CMake Warning is issued if the macro does not 
support a specific compiler so that conformance can be guaranteed.


Thanks,

Geoffrey Viola

This message contains confidential information and is intended only 
for the recipient. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately if you have received this e-mail by mistake and delete 
this e-mail from your system. Finally, the recipient should check this 
email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by 
this email.





-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] EFFECTIVE_PLATFORM_NAME not expanded in TARGET_* generator expressions on iOS

[Ruslan Baratov via CMake]

On 21-Mar-16 19:42, Vladimír Vondruš wrote:

Hello,

I came across this problem when trying to use XCTest macros ( 
https://cmake.org/cmake/help/latest/module/FindXCTest.html ) on iOS. When 
compiling for OSX, ctest properly executes all test cases, but when targeting 
iOS or iOS simulator, all the test cases fail similarly to the following:

 25: Test command: /Applications/Xcode.app/Contents/Developer/usr/bin/xctest 
"/Users/mosra/Code/corrade/build-ioss/src/Corrade/Utility/Test/Debug${EFFECTIVE_PLATFORM_NAME}/UtilityTypeTraitsTestRunner.xctest/../.."
 25: Environment variables:
 25:  
DYLD_FRAMEWORK_PATH=/Users/mosra/Code/corrade/build-ioss/src/Corrade/Utility/Test/Debug${EFFECTIVE_PLATFORM_NAME}/UtilityTypeTraitsTest.framework/..
 25: Test timeout computed to be: 9.99988e+06
 25: 2016-03-21 12:41:38.799 xctest[31113:31078264] The bundle “Test” 
couldn’t be loaded because its executable couldn’t be located. Try reinstalling 
the bundle.
 25/28 Test #25: UtilityTypeTraitsTest ...***Failed0.04 sec

As you can see, the `${EFFECTIVE_PLATFORM_NAME}` is not being expanded to 
`-iphonesimulator` and thus the file is not found. The problem is that the 
`$` generator expression does not expand the 
variable. On the other hand, installation works without an issue, because the 
`cmake_install.cmake` scripts do additional round of variable expansion that 
(accidentally?) fixes this. The relevant part of the CMake source is here: 
https://github.com/Kitware/CMake/blob/cd569b962dbeaa7ea718021c16582cddd158df3a/Source/cmGeneratorTarget.cxx#L5063

 From the source it looks like the generator is just putting the 
"${EFFECTIVE_PLATFORM_NAME}" output and hopes that someone later expands it. 
That's the case with install scripts (so they work), but not with generator expressions. 
The `TARGET_LINKER_FILE_DIR` is not the only affected, the problem is the same for all 
`TARGET_*` generator expressions.

Currently I'm working around this by partially hardcoding the path, but that's 
far from ideal and I would like to avoid that:

 if(CMAKE_OSX_SYSROOT MATCHES "iPhoneOS")
 set(platform_name "-iphoneos")
 elseif(CMAKE_OSX_SYSROOT MATCHES "iPhoneSimulator")
 set(platform_name "-iphonesimulator")
 endif()
 set(target_linker_file_dir 
${CMAKE_CURRENT_BINARY_DIR}/$${platform_name}/${target}.xctest)

Is there any way to fix this directly in CMake? Also the above workaround works 
only when targeting single SDK and not when having single generated project for 
both the device and the simulator.

Thank you a lot for your help.

mosra

I doubt I can help with the problem but just for your information:
* it wasn't fixed "accidentally", it was a fix for #12506: 
https://github.com/Kitware/CMake/commit/48fe617e667d2e6b1e471cfb56346de51f984ba5
* there is no "additional round" of variable expansion, 
EFFECTIVE_PLATFORM_NAME initialized from Xcode's environment variable 
EFFECTIVE_PLATFORM_NAME on installation


As far as I understand the main general problem with iOS 
device/simulator support is that CMake doesn't have multi-toolchain 
feature from the box. So for now all this stuff worked by generating 
some "universal" code that do work for both SDKs. The real SDK can be 
triggered by additional explicit option, i.e.:

* cmake --build _builds -- -sdk iphoneos # trigger iphoneos SDK
* cmake --build _builds -- -sdk iphonesimulator # trigger 
iphonesimulator SDK


Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake aliasing system

[Ruslan Baratov via cmake-developers]

I've openned new issue for further discussion:
* https://github.com/ruslo/CMake/issues/3

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


>> git commit --author="John Doe" --email="john@example.com" 
<mailto:john@example.com> --branch="master"

>> git push --remote="git://awesome.example.com <http://awesome.example.com/>"
> This is a complete nonsense!

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

Tamas

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


On 15-Mar-16 02:42, Tamás Kenéz wrote:

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

cmakeini -c ipad -H. -DTHIS_WILL_BE_FORWARDED=AS_IT_IS

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

As you can see I'm already using script `build.py` and there is
not enough power for now (even if it extends CMake basic
functionality a lot) so I was thinking to introduce global/local
ini-configuration file anyway. Then I realize that most of the
`build.py` functions can be implemented in such ini-configuration.
So why not use CMake? Why for example not extend CMake GUI with
this feature support? Why do users need to install some extra
tools instead of just one?

Global/local configuration files in not something special. Git for
example has same system, yes it increase complexity but literally
every user store setting there.
Just imagine you have to write something like this every commit +
push:

> git commit --author="John Doe" --email="john@example.com"
<mailto:john@example.com> --branch="master"
> git push --remote="git://awesome.example.com
<http://awesome.example.com>"

This is a complete nonsense!

So I'm planning to make a fork anyway and do some experiments even
if it will not accepted to upstream.

Ruslo



Tamas

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

On 14-Mar-16 21:59, Brad King wrote:

On 03/12/2016 08:04 AM, Ruslan Baratov via
cmake-developers wrote:

I guess it is a well known fact that cmake command is
almost never
executed alone and for non-trivial examples usually
hold some extra
arguments (home directory, build directory, verbosity
level, toolchains,
options, ...). Also I guess that such commands
doesn't change from
day-to-day development process and an obvious way to
reduce typing is to
create wrapper build scripts (.bat or .sh, I
personally use a Python one).

Sorry, I don't think something like this belongs
upstream.  It can easily
be done with shell aliases or other custom scripts.

I've got quite opposite experience. It's hard to say that
family of custom scripts (+ a lot of environment variables in
.bashrc)  is an "easy shell scripting", example:
*

https://github.com/ruslo/polly/blob/162cd157d1d05261a7a708435197d883c4209005/bin/build.py

 We shouldn't increase the complexity of the CMake
command line interface further.

To be clear this feature required only one new CMake option.
The rest is responsibility of some pre-build parsing module.

In general I feel sad that CMake will not became more
user-friendly in this exact part. Though the only proves of
my point that can be provided here is a users experience.
Since I don't see any feedback here I'm out of arguments...

Ruslo

-- 


Powered by www.kitware.com <http://www.kitware.com>

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

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

 

Re: [cmake-developers] CMake aliasing system

[Ruslan Baratov via cmake-developers]

On 15-Mar-16 02:42, Tamás Kenéz wrote:
I also doubt this belongs to upstream. But you could write a single, 
generic script which forwards its arguments to cmake and also accepts 
and processes the additional parameters along the way. I don't think 
we'd lose anything:


cmakeini -c ipad -H. -DTHIS_WILL_BE_FORWARDED=AS_IT_IS

This is the approach I took as I needed features like you described. 
But if there would be a mature, versatile, community-tested script I'd 
be willing to use it and contribute to it.
As you can see I'm already using script `build.py` and there is not 
enough power for now (even if it extends CMake basic functionality a 
lot) so I was thinking to introduce global/local ini-configuration file 
anyway. Then I realize that most of the `build.py` functions can be 
implemented in such ini-configuration. So why not use CMake? Why for 
example not extend CMake GUI with this feature support? Why do users 
need to install some extra tools instead of just one?


Global/local configuration files in not something special. Git for 
example has same system, yes it increase complexity but literally every 
user store setting there.

Just imagine you have to write something like this every commit + push:

> git commit --author="John Doe" --email="john@example.com" 
--branch="master"

> git push --remote="git://awesome.example.com"

This is a complete nonsense!

So I'm planning to make a fork anyway and do some experiments even if it 
will not accepted to upstream.


Ruslo



Tamas

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


On 14-Mar-16 21:59, Brad King wrote:

On 03/12/2016 08:04 AM, Ruslan Baratov via cmake-developers wrote:

I guess it is a well known fact that cmake command is
almost never
executed alone and for non-trivial examples usually hold
some extra
arguments (home directory, build directory, verbosity
level, toolchains,
options, ...). Also I guess that such commands doesn't
change from
day-to-day development process and an obvious way to
reduce typing is to
create wrapper build scripts (.bat or .sh, I personally
use a Python one).

Sorry, I don't think something like this belongs upstream.  It
can easily
be done with shell aliases or other custom scripts.

I've got quite opposite experience. It's hard to say that family
of custom scripts (+ a lot of environment variables in .bashrc) 
is an "easy shell scripting", example:

*

https://github.com/ruslo/polly/blob/162cd157d1d05261a7a708435197d883c4209005/bin/build.py

 We shouldn't increase the complexity of the CMake command
line interface further.

To be clear this feature required only one new CMake option. The
rest is responsibility of some pre-build parsing module.

In general I feel sad that CMake will not became more
user-friendly in this exact part. Though the only proves of my
point that can be provided here is a users experience. Since I
don't see any feedback here I'm out of arguments...

Ruslo

-- 


Powered by www.kitware.com <http://www.kitware.com>

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

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

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

Visit other Kitware 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 aliasing system

[Ruslan Baratov via cmake-developers]

On 14-Mar-16 21:59, Brad King wrote:

On 03/12/2016 08:04 AM, Ruslan Baratov via cmake-developers wrote:

I guess it is a well known fact that cmake command is almost never
executed alone and for non-trivial examples usually hold some extra
arguments (home directory, build directory, verbosity level, toolchains,
options, ...). Also I guess that such commands doesn't change from
day-to-day development process and an obvious way to reduce typing is to
create wrapper build scripts (.bat or .sh, I personally use a Python one).

Sorry, I don't think something like this belongs upstream.  It can easily
be done with shell aliases or other custom scripts.
I've got quite opposite experience. It's hard to say that family of 
custom scripts (+ a lot of environment variables in .bashrc)  is an 
"easy shell scripting", example:
* 
https://github.com/ruslo/polly/blob/162cd157d1d05261a7a708435197d883c4209005/bin/build.py



   We shouldn't increase the complexity of the CMake command line interface 
further.
To be clear this feature required only one new CMake option. The rest is 
responsibility of some pre-build parsing module.


In general I feel sad that CMake will not became more user-friendly in 
this exact part. Though the only proves of my point that can be provided 
here is a users experience. Since I don't see any feedback here I'm out 
of arguments...


Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Support CMAKE_IOS_INSTALL_COMBINED for single architecture targets

[Ruslan Baratov via cmake-developers]

Hi,

Though user can explicitly set CMAKE_IOS_INSTALL_COMBINED=OFF for 
targets with empty list of supported architectures for given SDK (say 
simulator) I think it make sense to handle this case correctly in CMake 
module too. Patch with fix and test attached.


Thanks, Ruslo
>From 1fb0986da2b6ec0df8c0785ead984a1171c16c04 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov 
Date: Mon, 14 Mar 2016 17:27:53 +0700
Subject: [PATCH] Fix iOS combined feature for single architecture targets

If list of valid target architectures is empty for given SDK then there will
be no VALID_ARCHS build setting returned by Xcode. Return "" (empty string)
explicitly in this case. This may happens if CMAKE_IOS_INSTALL_COMBINED is ON
but only one architecture used in target.
---
 Modules/CMakeIOSInstallCombined.cmake  | 12 ++-
 Tests/RunCMake/XcodeProject/RunCMakeTest.cmake | 20 +
 ...OSInstallCombinedSingleArch-install-check.cmake | 25 ++
 .../XcodeIOSInstallCombinedSingleArch.cmake| 19 
 4 files changed, 75 insertions(+), 1 deletion(-)
 create mode 100644 Tests/RunCMake/XcodeProject/XcodeIOSInstallCombinedSingleArch-install-check.cmake
 create mode 100644 Tests/RunCMake/XcodeProject/XcodeIOSInstallCombinedSingleArch.cmake

diff --git a/Modules/CMakeIOSInstallCombined.cmake b/Modules/CMakeIOSInstallCombined.cmake
index f052a3b..1256f56 100644
--- a/Modules/CMakeIOSInstallCombined.cmake
+++ b/Modules/CMakeIOSInstallCombined.cmake
@@ -52,7 +52,14 @@ function(_ios_install_combined_get_build_setting sdk variable resultvar)
   endif()
 
   if(NOT output MATCHES " ${variable} = ([^\n]*)")
-message(FATAL_ERROR "${variable} not found.")
+if("${variable}" STREQUAL "VALID_ARCHS")
+  # VALID_ARCHS may be unset by user for given SDK
+  # (e.g. for build without simulator).
+  set("${resultvar}" "" PARENT_SCOPE)
+  return()
+else()
+  message(FATAL_ERROR "${variable} not found.")
+endif()
   endif()
 
   set("${resultvar}" "${CMAKE_MATCH_1}" PARENT_SCOPE)
@@ -72,6 +79,9 @@ function(_ios_install_combined_get_valid_archs sdk resultvar)
   list(REMOVE_ITEM valid_archs "") # remove empty elements
   list(REMOVE_DUPLICATES valid_archs)
 
+  string(REPLACE ";" " " printable "${valid_archs}")
+  _ios_install_combined_message("Architectures (${sdk}): ${printable}")
+
   set("${resultvar}" "${valid_archs}" PARENT_SCOPE)
 endfunction()
 
diff --git a/Tests/RunCMake/XcodeProject/RunCMakeTest.cmake b/Tests/RunCMake/XcodeProject/RunCMakeTest.cmake
index 395c74b..b77d5d4 100644
--- a/Tests/RunCMake/XcodeProject/RunCMakeTest.cmake
+++ b/Tests/RunCMake/XcodeProject/RunCMakeTest.cmake
@@ -97,6 +97,7 @@ if(NOT XCODE_VERSION VERSION_LESS 7)
 endif()
 
 if(NOT XCODE_VERSION VERSION_LESS 6)
+  # XcodeIOSInstallCombined
   set(RunCMake_TEST_BINARY_DIR ${RunCMake_BINARY_DIR}/XcodeIOSInstallCombined-build)
   set(RunCMake_TEST_NO_CLEAN 1)
   set(RunCMake_TEST_OPTIONS
@@ -114,6 +115,7 @@ if(NOT XCODE_VERSION VERSION_LESS 6)
   unset(RunCMake_TEST_NO_CLEAN)
   unset(RunCMake_TEST_OPTIONS)
 
+  # XcodeIOSInstallCombinedPrune
   set(RunCMake_TEST_BINARY_DIR ${RunCMake_BINARY_DIR}/XcodeIOSInstallCombinedPrune-build)
   set(RunCMake_TEST_NO_CLEAN 1)
   set(RunCMake_TEST_OPTIONS
@@ -130,4 +132,22 @@ if(NOT XCODE_VERSION VERSION_LESS 6)
   unset(RunCMake_TEST_BINARY_DIR)
   unset(RunCMake_TEST_NO_CLEAN)
   unset(RunCMake_TEST_OPTIONS)
+
+  # XcodeIOSInstallCombinedSingleArch
+  set(RunCMake_TEST_BINARY_DIR ${RunCMake_BINARY_DIR}/XcodeIOSInstallCombinedSingleArch-build)
+  set(RunCMake_TEST_NO_CLEAN 1)
+  set(RunCMake_TEST_OPTIONS
+"-DCMAKE_INSTALL_PREFIX:PATH=${RunCMake_TEST_BINARY_DIR}/_install"
+"-DCMAKE_IOS_INSTALL_COMBINED=YES")
+
+  file(REMOVE_RECURSE "${RunCMake_TEST_BINARY_DIR}")
+  file(MAKE_DIRECTORY "${RunCMake_TEST_BINARY_DIR}")
+
+  run_cmake(XcodeIOSInstallCombinedSingleArch)
+  run_cmake_command(XcodeIOSInstallCombinedSingleArch-build ${CMAKE_COMMAND} --build .)
+  run_cmake_command(XcodeIOSInstallCombinedSingleArch-install ${CMAKE_COMMAND} --build . --target install)
+
+  unset(RunCMake_TEST_BINARY_DIR)
+  unset(RunCMake_TEST_NO_CLEAN)
+  unset(RunCMake_TEST_OPTIONS)
 endif()
diff --git a/Tests/RunCMake/XcodeProject/XcodeIOSInstallCombinedSingleArch-install-check.cmake b/Tests/RunCMake/XcodeProject/XcodeIOSInstallCombinedSingleArch-install-check.cmake
new file mode 100644
index 000..3c11ae0
--- /dev/null
+++ b/Tests/RunCMake/XcodeProject/XcodeIOSInstallCombinedSingleArch-install-check.cmake
@@ -0,0 +1,25 @@
+function(verify_architecture file)
+  execute_process(
+COMMAND xcrun lipo -info ${RunCMake_TEST_BINARY_DIR}/_install/${file}
+OUTPUT_VARIABLE lipo_out
+ERROR_VARIABLE lipo_err
+RESULT_VARIABLE lipo_result)
+  if(NOT lipo_result EQUAL "0")
+message(SEND_ERROR "lipo -info failed: ${lipo_err}")
+return()
+  endif()
+
+  string(REGEX MATCHALL "is architecture: [^ \n\t]+" 

[cmake-developers] CMake aliasing system

[Ruslan Baratov via cmake-developers]

Hi,

I guess it is a well known fact that cmake command is almost never 
executed alone and for non-trivial examples usually hold some extra 
arguments (home directory, build directory, verbosity level, toolchains, 
options, ...). Also I guess that such commands doesn't change from 
day-to-day development process and an obvious way to reduce typing is to 
create wrapper build scripts (.bat or .sh, I personally use a Python one).


I have next suggestion of how it can be unified: introduce ini-like file 
(say ${HOME}/.configs/cmake/alias) with alias sections with frequently 
used generators/arguments.


Example of such file:

  [default]
var: CMAKE_VERBOSE_MAKEFILE=ON
home: .
build-dir: _builds/default

  [clean]
cmd: cmake -E remove_directory _builds

  [vs-12]
inherit: default
generator: Visual Studio 12 2013
build-dir: _builds/vs-12

  [iphone]
inherit: default
generator: Xcode
build-dir: _builds/ios-9-2
var: CMAKE_TOOLCHAIN_FILE=/.../ios-9-2.cmake

  [ipad]
inherit: default
generator: Xcode
build-dir: _builds/ios-9-1
var: CMAKE_TOOLCHAIN_FILE=/.../ios-9-1.cmake

Usage:

  > cmake -c clean ipad

effectively equivalent to:

  > cmake -E remove_directory _builds
  > cmake -H. -B_builds/ios-9-2 -DCMAKE_VERBOSE_MAKEFILE=ON -GXcode 
-DCMAKE_TOOLCHAIN_FILE=/.../ios-9-2.cmake


Name of the options may be:

  -c # classes (sectioins can be inherited)
  -a # alias
  -m # meta-targets

For now it's just a thought and I have no idea how it will work on 
practice so I can create a fork for experimenting. And if it will work 
fine for me I'm planning to add such feature to CMake upstream, so I'm 
ready to hear an appropriate implementation details.


Thoughts?

Ruslo

--

Powered by www.kitware.com

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

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

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

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

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

[CMake] file(SHA1) vs string(SHA1) consistency

[Ruslan Baratov via CMake]

Hi,

Following code produce same SHA1 on Linux:

   cmake_minimum_required(VERSION 3.0)

   set(test_string "a\nb")
   set(test_file "test.file")

   string(SHA1 sha1_string "${test_string}")

   file(WRITE "${test_file}" "${test_string}")
   file(SHA1 "${test_file}" sha1_file)

   message("sha1:")
   message("  ${sha1_file}")
   message("  ${sha1_string}")

result:

   sha1:
  fcd127ffa1016069006ad91f3f361248f9bdf272
  fcd127ffa1016069006ad91f3f361248f9bdf272

but not same SHA1 on Windows:

   sha1:
  ec6cb5b8c69f8b476a380c9b6e38e18c2733ae7b
  fcd127ffa1016069006ad91f3f361248f9bdf272

I think this is because of DOS end of lines. Two thoughts:
* file(SHA1) and string(SHA1) should be the same on same input string
* since CMake is a cross-platform tool I think it make sense that 
command `file(WRITE "..." "a\nb")` produce identical files on all platforms
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] compiler independent compiler flags

[Ruslan Baratov via CMake]

On 17-Feb-16 17:23, Nagy-Egri Máté Ferenc via CMake wrote:


Unfortunately, I cannot help you in this regard, though I am surprised 
how little attention this question gained. I too feel that CMake could 
do better both in this regard. While ABI detection is very well done, 
BUILD_TYPE seems to be the only compiler agnostic option available.



...

I do not know how to set warning levels for eg. in a compiler agnostic 
manner


Just for your information: 
http://stackoverflow.com/questions/2368811/how-to-set-warning-level-in-cmake/24379666#24379666


Ruslo
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Namespaces

[Ruslan Baratov via cmake-developers]

On 29-Jan-16 01:17, Stephen Kelly wrote:

Pau Garcia i Quiles wrote:


add_subdirectory(pugixml/scripts)
add_subdirectory(QtZeroConf)
add_subdirectory(QtDropBox)
add_subdirectory(websocketpp)

This is an easy way to work with third-party dependences.

Unfortunately this is 'easy, obvious and wrong'.
This is wrong because of CMake limitations. Actually I was thinking 
about "namespacing" subdirectories too. From my point of view we can add 
namespace prefix every time when command 'project' called.

Project Foo:

== standalone ==
project(Foo)
add_library(foo ...) # add target foo

== as a subdirectory ==
project(Boo)
add_subdirectory(Foo)
# target Foo::foo

Since regular variables has different scope there is no need to do any 
updates for them, we need only to do something with globals: targets, 
cache variables, global properties (?).



My problem comes from the fact several of these third-party libraries use
common variable names, e. g. BUILD_SHARED, BUILD_TESTS, etc).

And indeed this is why.


Has some kind of namespacing been considered for add_subdirectory?

E. g.

add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF)

And what if someone builds your project with -DBUILD_SHARED=ON? Are you
going to use

  set(QTZEROCONF_BUILD_SHARED ${BUILD_SHARED})
  add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF)

for every variable you're wrapping? Or do you want cmake to do that for
every variable in scope when the directory is added? How would cmake decide
which variables to namespace?
I think this can be solved by adding extra suboptions to 
add_subdirectory command.




You should use ExternalProject instead, or fork the buildsystem of those
projects to integrate them into your project. Not that I recommend the
latter for you though :). That's what cmake does when integrating 3rd party
code.
As far as I understand `add_subdirectory(3rdParty/package)` approach 
used in CMake sources:
* zlib: 
https://github.com/Kitware/CMake/blob/5335d275527d4f58e4f2992d307c1c62cd94dd3c/CMakeLists.txt#L306
* curl: 
https://github.com/Kitware/CMake/blob/5335d275527d4f58e4f2992d307c1c62cd94dd3c/CMakeLists.txt#L337
* bzip2: 
https://github.com/Kitware/CMake/blob/5335d275527d4f58e4f2992d307c1c62cd94dd3c/CMakeLists.txt#L355


Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] What is the best way to handle Boost dependencies in a package config file

[Ruslan Baratov via CMake]

On 27-Jan-16 20:08, Johnson, Matt (GE Healthcare) wrote:

-Original Message-
From: Ruslan Baratov [mailto:ruslan_bara...@yahoo.com]
Sent: Wednesday, January 27, 2016 2:18 AM
To: Johnson, Matt (GE Healthcare)
Cc: cmake@cmake.org
Subject: Re: [CMake] What is the best way to handle Boost dependencies in
a package config file

On 27-Jan-16 09:54, Johnson, Matt (GE Healthcare) wrote:

I like package config files.  I want to use more of them.  However, I have a

dependency on boost.  While boost has a Find module, it doesn't have a
package config file.  I'm not going to be able to depend on the users of my
package building boost via cmake (also, is that still an active thing?).

It seems like the best I could hope for is to generate the package config file,

then hack it up to deal with the boost stuff.  Has anyone already solved this
problem or have any tips?  I found this Hunter package manager
(https://urldefense.proofpoint.com/v2/url?u=https-
3A__github.com_ruslo_hunter=CwIC-
g=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=qts7iZJBjQRtedrrc
qcDRKGTou2a2ZKSs95InlFGa34=h5ntMfnYSIOG1mQp_twkUPunK5Nz0q9
HBqa7Ld4B_hs=zi9sk8NwKokHEqrLyGA5a_yrRxLdHF9P7ID23wgrWPY=
), but it seems a bit heavyweight when all I want is boost.
--

Also, I can't have my build system going out and downloading the packages

- they all have to come from an internal source.
Just for your information you can use "file://" links instead of regular
"https://urldefense.proofpoint.com/v2/url?u=http-3A__=CwIC-
g=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=qts7iZJBjQRtedrrc
qcDRKGTou2a2ZKSs95InlFGa34=h5ntMfnYSIOG1mQp_twkUPunK5Nz0q9
HBqa7Ld4B_hs=ts63TtZeGvflnLyyJ8pKESTjxabuzNCPmS0fGn_1L7E= " in
both hunter.cmake and HunterGate so there is no need to "go out" - you can
be completely offline.

Ruslo

Ruslo - thanks for that.  I'm seriously going to look into Hunter more.  From 
my cursory glance at it, it's a seriously impressive bit of cmake scripting.

--



Can  I ask you a few follow ups?
1. in the case of boost, what it is doing is using the find package module, 
then creating import targets based off the information.  Correct?
In general yes, but also some information passed from 
ExternalProject_Add recipe, like optional dependency. So it differs from 
approach "just add BoostConfig.cmake file" after boost installed.

Templates:
* 
https://github.com/ruslo/hunter/blob/master/cmake/templates/BoostConfig.cmake.in
* 
https://github.com/ruslo/hunter/blob/master/cmake/templates/BoostBZip2Dependency.cmake.in 
(optional boost.iostreams -> bzip2 dependency)



2. If I require a newer version of boost than what is listed in the gate file, 
I'd need to  update hunter.cmake and HunterGate,  correct?
URL/SHA1 of HunterGate command doesn't hold version of Boost to be 
precise. It holds version of archive with several versions of Boost 
(Boost/hunter.cmake: 1.55, 1.56, ...) and default version 
(configs/default.cmake: 1.58). User can choose non-default version by 
adding custom local config.cmake file: 
https://github.com/ruslo/hunter/wiki/example.custom.config.id. If you 
need version that is not listed in Boost/hunter.cmake you have to add it 
to Boost/hunter.cmake and create new archive. There is feature request 
that can allow to do it locally so it will be improved in future.



3. If I want to distribute my package to others, they too would need  to use 
Hunter, correct?  Since boost doesn't have a package config file in  its 
distribution, the dependency targets (e.g. Boost::regex) wouldn't exist on 
their system)  Any tips on this?
Well somebody have to install such extra code with Boost::* targets 
anyway, the easiest way is to delegate this job to Hunter. Also if you 
add your package to Hunter archive then users can add your package just 
by `hunter_add_package(Foo)` without even knowing about Boost and type 
of Boost targets. This is package distribution design.



Thanks again for your hard  work on  Hunter.  I've done a bit of cmake to 
download and install some dependencies in the past.  Yours is WAY nicer than 
what I came up with.

Matt


Thanks, Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] What is the best way to handle Boost dependencies in a package config file

[Ruslan Baratov via CMake]

On 27-Jan-16 09:54, Johnson, Matt (GE Healthcare) wrote:

I like package config files.  I want to use more of them.  However, I have a 
dependency on boost.  While boost has a Find module, it doesn't have a package 
config file.  I'm not going to be able to depend on the users of my package 
building boost via cmake (also, is that still an active thing?).

It seems like the best I could hope for is to generate the package config file, 
then hack it up to deal with the boost stuff.  Has anyone already solved this 
problem or have any tips?  I found this Hunter package manager 
(https://github.com/ruslo/hunter), but it seems a bit heavyweight when all I 
want is boost.

--

Also, I can't have my build system going out and downloading the packages - 
they all have to come from an internal source.

Just for your information you can use "file://" links instead of regular 
"http://; in both hunter.cmake and HunterGate so there is no need to "go 
out" - you can be completely offline.


Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMake based package manager

[Ruslan Baratov via CMake]

On 11-Jan-16 18:42, Cristian Adam wrote:

Ruslan Baratov via CMake <cmake@...> writes:


Hi,

I'm developing a project that is a kind of wrapper of
ExternalProject_Add and
allow it to be more reusable. User interface is quite simple.

For anybody interested, here is a github project:

* https://github.com/ruslo/hunter

Recently posted on reddit:
https://www.reddit.com/r/cpp/comments/40cfbk/hunter_crossplatform_packag
e_manager_for_c/

Any thoughts of including such a project in CMake?
Just for your information there is no need to include all this project, 
the entry point to everything is HunterGate.cmake module (500 lines of 
CMake code): 
https://github.com/hunter-packages/gate/blob/master/cmake/HunterGate.cmake


I will be happy to add it to CMake's standard modules so users can avoid 
one copy/paste step, if CMake's team is interested.


Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Tests with assert and Release build type

[Ruslan Baratov via CMake]

On 24-Dec-15 19:46, Magnus Therning wrote:

I'm *not* mixing stuff built with `-g` and stuff built without it.
Actually I don't see anything bad about mixing `-g` code with code 
without `-g`.



   I'm
also *not* mixing linking with debug- and non-debug libraries.
Since we cover a lot of aspects please specify what you mean by debug 
and non-debug libraries.



I'm only mixing stuff build with `-DNDEBUG` and stuff built without it.

see below

On 24-Dec-15 19:48, Magnus Therning wrote:

Ruslan Baratov writes:


On 22-Dec-15 04:07, Magnus Therning wrote:

It is possible to hit situation when ODR will be violated, e.g. if
somebody define optional member in structure with "#if defined(NDEBUG)"
condition. Something like this:
http://stackoverflow.com/questions/20833226/library-headers-and-define

Yes, if we ever start using the NDEBUG macro to control anything in our
code then I'll have to worry about this, as it stands right now it's
only the `assert` from `assert.h` that cares about it.
Even if you care only about `assert` somebody can define different type 
of structures based on value of NDEBUG. I'm talking about 3rd party 
library that you can use and you can't control. If this will lead to ODR 
violation then bug is NOT in 3rd party code, but in YOUR code. That's my 
point. You can mix c++11 with c++98, libc++ with libstdc++, mingw with 
cygwin, mingw with Visual Studio, NDEBUG with non NDEBUG, and it MAY 
works, but when something suddenly will stop working with very obscure 
errors that it's YOUR fault and not 3rd party.//



If I'm reading you correctly you are advocating I simply get rid of the
use of those asserts altogether instead.
I'm not sure what you mean. I'm just telling that if you want do some 
runtime checks even when NDEBUG is OFF then you should introduce your 
own macro FOO_DEBUG. Difference is about global/local affects.


Ruslo
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Tests with assert and Release build type

[Ruslan Baratov via CMake]

On 22-Dec-15 04:07, Magnus Therning wrote:

Ruslan Baratov writes:


On 20-Dec-15 01:31, Magnus Therning wrote:

Ruslan Baratov writes:


How about using RelWithDebInfo? See:
http://stackoverflow.com/a/28124715/2288008

Hmm, I'm probably missing something but how does that solve the issue
with some targets requiring NDEBUG to be *undefined* and other targets
requiring NDEBUG to be defined?

I don't think that building targets with different NDEBUG values is a
good idea. More correct approach will be to introduce custom macro to
allow checks (i.e. FOO_NDEBUG/FOO_DEBUG).

Why not?
It is possible to hit situation when ODR will be violated, e.g. if 
somebody define optional member in structure with "#if defined(NDEBUG)" 
condition. Something like this: 
http://stackoverflow.com/questions/20833226/library-headers-and-define




/M

--
Magnus Therning  OpenPGP: 0x927912051716CE39
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

We act as though comfort and luxury were the chief requirements of
life, when all that we need to make us happy is something to be
enthusiastic about.
  -- Albert Einstein


--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Tests with assert and Release build type

[Ruslan Baratov via CMake]

On 20-Dec-15 01:31, Magnus Therning wrote:

Ruslan Baratov writes:


How about using RelWithDebInfo? See:
http://stackoverflow.com/a/28124715/2288008

Hmm, I'm probably missing something but how does that solve the issue
with some targets requiring NDEBUG to be *undefined* and other targets
requiring NDEBUG to be defined?
I don't think that building targets with different NDEBUG values is a 
good idea. More correct approach will be to introduce custom macro to 
allow checks (i.e. FOO_NDEBUG/FOO_DEBUG).




/M


On 18-Dec-15 20:55, Magnus Therning wrote:

I'm sure I'm not the first one to run into the conflict between a desire
to test the code shipped to customers and the desire to at the same time
define NDEBUG to make sure tests don't have their `assert` turned into
NOOPs.

Is there some nice way of handling this?

I can always remove -DNDEBUG from the CFLAGS for tests (possibly by
defining a new macro, `ADD_EXECUTABLE_TEST()` or something). Another
option is to `#undef NDEBUG` in the source of tests.

If there's some more or less standard way to address this I'd like to
use that.

/M

--
Magnus Therning  OpenPGP: 0x927912051716CE39
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

There's a big difference between making something easy to use and
making it productive.
   -- Adam Bosworth




--
Magnus Therning  OpenPGP: 0x927912051716CE39
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

C++ is history repeated as tragedy. Java is history repeated as farce.
  -- Scott McKay


--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

[Ruslan Baratov via cmake-developers]

On 21-Dec-15 17:19, Bartosz Kosiorek wrote:


Thanks Ruslan for explanation.


Currently we already building fat library for arm (armv7;armv7s;arm64) 
and x86 (i386;x86_64).



That's why my original assumption was that it could be easily enabled 
for Simulator/device (armv7;armv7s;arm64;i386;x86_64).


I could start working on that but if it will be too hacky, then I will 
leave that idea.




BTW I made some benchmarks of Xcode vs Make comparison for our 
internal subproject (with "time" command). Here are results:



Xcode generation:

   real6m31.733s

   user4m51.862s

   sys0m20.268s


Make generation:

   real4m45.089s

   user2m56.117s

   sys0m17.481s


Ninja generation:

  real2m48.585s

  user2m30.712s

  sys0m6.313s



Xcode generation + build time:

   real64m3.238s

   user353m36.825s

   sys46m52.415s


Make generation + build time:

   real61m2.583s

   user358m7.464s

   sys47m21.512s


So it seems in our case, for Generation performance step, we should 
use Ninja.


Ok, thanks for sharing it. This proves what I was thinking - there is no 
difference in build time, but generate time is better for Makefile. 
Probably you can profile CMake and find some bottlenecks.




Best Regards

Bartosz



*From:* Ruslan Baratov 
*Sent:* Saturday, December 19, 2015 6:27 PM
*To:* Bartosz Kosiorek
*Cc:* Clinton Stimpson; Gregor Jasny; CMake Developers
*Subject:* Re: [cmake-developers] Create subdirectories in Resource 
directory for Frameworks and Application bundle.

On 18-Dec-15 22:46, Bartosz Kosiorek wrote:


Thank you all for your tips/advice.


From our experience IDE generators (eg. Visual Studio, Xcode) is 
much slower than Make or Ninja. I will attach benchmarks later.



Unfortunately I'm unable to build Universal libraries for x86 and arm 
architectures by using Makefile.


This feature will work only for Xcode. For Makefile generator 
variable/property IOS_INSTALL_COMBINED is ignored. Xcode and Makefile 
differs in internals. Xcode can hold in build directory all variants 
of library like Release/Debug + Simulator/Device:


Debug-iphoneos/libfoo.a # xcodebuild -sdk iphoneos -config Debug
Debug-iphonesimulator/libfoo.a # xcodebuild -sdk iphonesimulator 
-config Debug

Release-iphoneos/libfoo.a # xcodebuild -sdk iphoneos -config Release
Release-iphonesimulator/libfoo.a # xcodebuild -sdk iphonesimulator 
-config Release


Makefile holds only one variant so building both Simulator/Device in 
one project is tricky. You can build/install several libraries by 
Makefile and combine them with lipo using some external script.



See attached logs.


It seems that two different SDK's (iPhoneOS and 
iPhoneSimulator) needs to be used in that case.


Do you know how it could be fixed?

Maybe I should add "CMAKE_OSX_SYSROOT "iphoneos" support for other 
generators?


What do you think about that idea?


Thanks in advance

Bartosz​


PS

I'm attaching the script which I'm using for testing purposes.

To reproduce it just run command (from command line):

   cd builddir && cmake .. && cmake --build .




*From:*Ruslan Baratov [mailto:ruslan_bara...@yahoo.com]
*Sent:* Saturday, December 12, 2015 6:49 AM
*To:* Bartosz Kosiorek
*Cc:* Clinton Stimpson; Gregor Jasny; CMake Developers
*Subject:* Re: [cmake-developers] Create subdirectories in Resource 
directory for Frameworks and Application bundle.


On 12-Dec-15 10:08, Bartosz Kosiorek wrote:

Thanks Ruslan.

I would like to create instruction which is universal for all
generators.

I think it's not possible. E.g. IOS_INSTALL_COMBINED will work only 
for Xcode.



Currently we would like to support both Make/Ninja and Xcode generators,

...


because Make is much faster than Xcode generator, and we are using it 
in our CI system.


Do you mean generate step or build? I've used to compile quite big 
projects like OpenCV with Xcode and according to the `top` it uses 
all my cores with clang++ at 100% CPU time.
Can you show any benchmarks? Also note that Xcode can add some 
additional stuff, like dSYM: 
https://github.com/headupinclouds/gatherer/pull/69



Make is also common for other architectures (Linux, QNX, Android etc.)

Unfortunately

   set(CMAKE_OSX_SYSROOT "iphoneos")

is not working for me.

It displays error:

  /Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake .. && 
/Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake --build .


  -- Configuring done

  -- Generating done

  -- Build files have been written to: 
/Users/warsaw/Perforce/cmake_ios_framework_with_resource2/builddir


  [ 14%] Building C object 
shared_empty/heymath/CMakeFiles/heymath.dir/add.c.o


  clang: warning: no such sysroot directory: 'iphoneos'

...

Do you have some tip for that?

Yes, this hint was for Xcode generator.


After removing "-isysroot ${CMAKE_OSX_SYSROOT}" everything works 
perfectly. Thanks


Unfortunately 

Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

[Ruslan Baratov via cmake-developers]

On 18-Dec-15 22:46, Bartosz Kosiorek wrote:


Thank you all for your tips/advice.


From our experience IDE generators (eg. Visual Studio, Xcode) is 
much slower than Make or Ninja. I will attach benchmarks later.



Unfortunately I'm unable to build Universal libraries for x86 and arm 
architectures by using Makefile.


This feature will work only for Xcode. For Makefile generator 
variable/property IOS_INSTALL_COMBINED is ignored. Xcode and Makefile 
differs in internals. Xcode can hold in build directory all variants of 
library like Release/Debug + Simulator/Device:


Debug-iphoneos/libfoo.a # xcodebuild -sdk iphoneos -config Debug
Debug-iphonesimulator/libfoo.a # xcodebuild -sdk iphonesimulator -config 
Debug

Release-iphoneos/libfoo.a # xcodebuild -sdk iphoneos -config Release
Release-iphonesimulator/libfoo.a # xcodebuild -sdk iphonesimulator 
-config Release


Makefile holds only one variant so building both Simulator/Device in one 
project is tricky. You can build/install several libraries by Makefile 
and combine them with lipo using some external script.



See attached logs.


It seems that two different SDK's (iPhoneOS and iPhoneSimulator) needs 
to be used in that case.


Do you know how it could be fixed?

Maybe I should add "CMAKE_OSX_SYSROOT "iphoneos" support for other 
generators?


What do you think about that idea?


Thanks in advance

Bartosz​


PS

I'm attaching the script which I'm using for testing purposes.

To reproduce it just run command (from command line):

   cd builddir && cmake .. && cmake --build .




*From:*Ruslan Baratov [mailto:ruslan_bara...@yahoo.com]
*Sent:* Saturday, December 12, 2015 6:49 AM
*To:* Bartosz Kosiorek
*Cc:* Clinton Stimpson; Gregor Jasny; CMake Developers
*Subject:* Re: [cmake-developers] Create subdirectories in Resource 
directory for Frameworks and Application bundle.


On 12-Dec-15 10:08, Bartosz Kosiorek wrote:

Thanks Ruslan.

I would like to create instruction which is universal for all
generators.

I think it's not possible. E.g. IOS_INSTALL_COMBINED will work only 
for Xcode.



Currently we would like to support both Make/Ninja and Xcode generators,

...


because Make is much faster than Xcode generator, and we are using it 
in our CI system.


Do you mean generate step or build? I've used to compile quite big 
projects like OpenCV with Xcode and according to the `top` it uses all 
my cores with clang++ at 100% CPU time.
Can you show any benchmarks? Also note that Xcode can add some 
additional stuff, like dSYM: 
https://github.com/headupinclouds/gatherer/pull/69



Make is also common for other architectures (Linux, QNX, Android etc.)

Unfortunately

   set(CMAKE_OSX_SYSROOT "iphoneos")

is not working for me.

It displays error:

  /Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake .. && 
/Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake --build .


  -- Configuring done

  -- Generating done

  -- Build files have been written to: 
/Users/warsaw/Perforce/cmake_ios_framework_with_resource2/builddir


  [ 14%] Building C object 
shared_empty/heymath/CMakeFiles/heymath.dir/add.c.o


  clang: warning: no such sysroot directory: 'iphoneos'

...

Do you have some tip for that?

Yes, this hint was for Xcode generator.


After removing "-isysroot ${CMAKE_OSX_SYSROOT}" everything works 
perfectly. Thanks


Unfortunately CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET is not 
working with Make.


Is it possible to introduce CMAKE_IOS_DEPLOYMENT_TARGET, as we already 
have CMAKE_OSX_DEPLOYMENT_TARGET?


Since OSX_ARCHITECTURES controls iOS architectures too I think request 
should sounds like "Extend OSX_DEPLOYMENT_TARGET property for iOS 
platform".




I have attached my example script which I'm using.

​Could you please modify it to be better (and still support other 
generators)?


I don't know how to use iOS target with Makefile generator.

Some notes about project you've sent:
* You need to add instructions to codesign your bundle
* Instead of hardcoding `set(CMAKE_OSX_SYSROOT 
"/Applications/Xcode.app/.../iPhoneSimulator.sdk")` you can run 
`xcode-select -print-path` to detect location of default Xcode version
* Should be `set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} 
-mios-version-min=8.0")` instead of `set(CMAKE_CXX_FLAGS 
"-mios-version-min=8.0")` otherwise some flags may be lost


Ruslan

Best Regards

Bartosz



*From:*Ruslan Baratov 


*Sent:* Saturday, December 12, 2015 1:58 AM
*To:* Bartosz Kosiorek
*Cc:* clin...@elemtech.com; Gregor Jasny; 
CMake Developers
*Subject:* Re: [cmake-developers] Create subdirectories in Resource 
directory for Frameworks and Application bundle.


On 12-Dec-15 03:46, Bartosz Kosiorek wrote:

Hi

To enable iOS build, I'm using following settings in CMakeLists.txt:

set(APPLE_PLATFORM "iphonesimulator")

I think this 

Re: [CMake] Tests with assert and Release build type

[Ruslan Baratov via CMake]

How about using RelWithDebInfo? See: 
http://stackoverflow.com/a/28124715/2288008


Ruslo

On 18-Dec-15 20:55, Magnus Therning wrote:

I'm sure I'm not the first one to run into the conflict between a desire
to test the code shipped to customers and the desire to at the same time
define NDEBUG to make sure tests don't have their `assert` turned into
NOOPs.

Is there some nice way of handling this?

I can always remove -DNDEBUG from the CFLAGS for tests (possibly by
defining a new macro, `ADD_EXECUTABLE_TEST()` or something). Another
option is to `#undef NDEBUG` in the source of tests.

If there's some more or less standard way to address this I'd like to
use that.

/M

--
Magnus Therning  OpenPGP: 0x927912051716CE39
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

There's a big difference between making something easy to use and
making it productive.
  -- Adam Bosworth




-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] Re: Create subdirectories in Resource directory for Frameworks and Application bundle.

[Ruslan Baratov via cmake-developers]

On 12-Dec-15 07:26, Bartosz Kosiorek wrote:

Hi
I have updated current documentation with examples, to reflect current status 
of CMake in OSX/iOS support.

Such information is very useful for novice CMake developers,
and it saves an hours of digging through mailing list and websites.

This is true, totally agree.

+If user would like to build for iPhone device, it could specify::
+
+  set(CMAKE_OSX_ARCHITECTURES "armv7;armv7s;arm64")


Note that:
* you can mix simulator and device architectures here
* if more than one architecture set then `ONLY_ACTIVE_ARCH` will be set 
to `NO`. it is useful for install/archive stage but will slow down your 
development process. at least it worth to mention 
CMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH variable usage

* I think newly created IOS_INSTALL_COMBINED should be mentioned too
* also architectures can be set using next Xcode attributes:

  set_target_properties(
  foo
  PROPERTIES
  XCODE_ATTRIBUTE_ARCHS[sdk=iphoneos*] armv7
  XCODE_ATTRIBUTE_VALID_ARCHS[sdk=iphoneos*] armv7
  XCODE_ATTRIBUTE_ARCHS[sdk=iphonesimulator*] x86_64
  XCODE_ATTRIBUTE_VALID_ARCHS[sdk=iphonesimulator*] x86_64
  )

note that to specify several architectures you need to use space as a 
separator (unlike CMake list):


  set_target_properties(
  foo
  PROPERTIES
  XCODE_ATTRIBUTE_ARCHS[sdk=iphoneos*] "armv7 arm64"
  XCODE_ATTRIBUTE_VALID_ARCHS[sdk=iphoneos*] "armv7 arm64"
  )

Ruslan


Best Regards
Bartosz



From: Clinton Stimpson 
Sent: Friday, December 11, 2015 10:16 PM
To: Bartosz Kosiorek
Cc: cmake-developers; Gregor Jasny
Subject: Re: Create subdirectories in Resource directory for Frameworks and 
Application bundle.

On Friday, December 11, 2015 08:46:56 PM Bartosz Kosiorek wrote:

Hi

To enable iOS build, I'm using following settings in CMakeLists.txt:


set(APPLE_PLATFORM "iphonesimulator")
set(CMAKE_OSX_SYSROOT
"/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platf
orm/Developer/SDKs/iPhoneSimulator.sdk")

  set(CMAKE_C_FLAGS "-isysroot

${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") set(CMAKE_CXX_FLAGS "-isysroot
${CMAKE_OSX_SYSROOT} -mios-version-min=7.0")
Do you think it should be documented?

Where is the good place to do so?
Maybe somewhere here:
https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html



What do you think?


I'm thinking it'll be better to integrate that at the Modules/Platform/ level.
For example, there is code in Darwin-Clang.cmake for the -mmacosx-version-min
flag.

Perhaps iOS can be toggled with CMAKE_GENERATOR_PLATFORM.
Brad, what do you think?

Or maybe toggled with CMAKE_OSX_SYSROOT, and if the SDK is pointing to another
platform than OS X, we can switch between
-mios-version-min= and -mmacosx-version-min=

Clint



​



From: clin...@elemtech.com 
Sent: Friday, December 11, 2015 8:21 PM
To: Bartosz Kosiorek
Cc: Bartosz Kosiorek; cmake-developers; Gregor Jasny
Subject: Re: [cmake-developers] Create subdirectories in Resource directory
for Frameworks and Application bundle.

- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek 
wrote:

  Hi

Because there is difference between OS X and iOS Bundles directory structure
(see: Apple specification
https://developer.apple.com/library/mac/documentation/CoreFoundation/Concep
tual/CFBundles/BundleTypes/BundleTypes.html), in trunk (In CMake 3.5)
RESOURCE property create corresponding directory structure. I have already
fix that with:
https://public.kitware.com/Bug/view.php?id=15848
Ok.  I hadn't been following all your work.
Also, I didn't see a toggle in the CMake code you sent to choose an iOS
bundle instead of OS X bundles.  How is that toggled?
So RESOURCE gives you a level of abstraction:
For OSX:
it will create "Resource" directory

For iOS it will create "flat" directory structure.

In your example "Resource" directory will be created in both cases (for OSX
and iOS).

  Which is wrong:

For OSX: it should  create "Resource" directory
For iOS it will create "flat" directory structure.

I could provide patch to fix that issue, if you agree with that.
What do you think about that?
Do you think the same should be applied to "Headers"?

I think the abstraction seems reasonable, as well as what you are proposing.
  However, I'm not an Apple guru.

  I wonder if there are other Apple experts

that can weigh in this if better feedback is needed.
Clint


Best Regards
Bartosz



2015-12-11 19:06 GMT+01:00 Clinton Stimpson
>:
On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote:


Thanks Clint



Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with
RESOURCE

  property. For every resource which is marked as RESOURCE, will

be placed in root "Resources" directory.



The CMake code below create following directory structure for OS X:



── 

Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

[Ruslan Baratov via cmake-developers]

On 12-Dec-15 10:08, Bartosz Kosiorek wrote:


Thanks Ruslan.


I would like to create instruction which is universal for all generators.

I think it's not possible. E.g. IOS_INSTALL_COMBINED will work only for 
Xcode.



Currently we would like to support both Make/Ninja and Xcode generators,


...

because Make is much faster than Xcode generator, and we are using it 
in our CI system.


Do you mean generate step or build? I've used to compile quite big 
projects like OpenCV with Xcode and according to the `top` it uses all 
my cores with clang++ at 100% CPU time.
Can you show any benchmarks? Also note that Xcode can add some 
additional stuff, like dSYM: 
https://github.com/headupinclouds/gatherer/pull/69



Make is also common for other architectures (Linux, QNX, Android etc.)


Unfortunately

   set(CMAKE_OSX_SYSROOT "iphoneos")

is not working for me.

It displays error:


  /Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake .. && 
/Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake --build .

  -- Configuring done
  -- Generating done
  -- Build files have been written to: 
/Users/warsaw/Perforce/cmake_ios_framework_with_resource2/builddir
  [ 14%] Building C object 
shared_empty/heymath/CMakeFiles/heymath.dir/add.c.o

  clang: warning: no such sysroot directory: 'iphoneos'
...
Do you have some tip for that?

Yes, this hint was for Xcode generator.




After removing "-isysroot ${CMAKE_OSX_SYSROOT}" everything works 
perfectly. Thanks


Unfortunately CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET is not 
working with Make.
Is it possible to introduce CMAKE_IOS_DEPLOYMENT_TARGET, as we already 
have CMAKE_OSX_DEPLOYMENT_TARGET?
Since OSX_ARCHITECTURES controls iOS architectures too I think request 
should sounds like "Extend OSX_DEPLOYMENT_TARGET property for iOS platform".




I have attached my example script which I'm using.
​Could you please modify it to be better (and still support other 
generators)?

I don't know how to use iOS target with Makefile generator.

Some notes about project you've sent:
* You need to add instructions to codesign your bundle
* Instead of hardcoding `set(CMAKE_OSX_SYSROOT 
"/Applications/Xcode.app/.../iPhoneSimulator.sdk")` you can run 
`xcode-select -print-path` to detect location of default Xcode version
* Should be `set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} 
-mios-version-min=8.0")` instead of `set(CMAKE_CXX_FLAGS 
"-mios-version-min=8.0")` otherwise some flags may be lost


Ruslan


Best Regards
Bartosz






*From:* Ruslan Baratov 
*Sent:* Saturday, December 12, 2015 1:58 AM
*To:* Bartosz Kosiorek
*Cc:* clin...@elemtech.com; Gregor Jasny; CMake Developers
*Subject:* Re: [cmake-developers] Create subdirectories in Resource 
directory for Frameworks and Application bundle.

On 12-Dec-15 03:46, Bartosz Kosiorek wrote:


Hi

To enable iOS build, I'm using following settings in CMakeLists.txt:


set(APPLE_PLATFORM "iphonesimulator")

I think this one not needed. Can't find any place where it parsed.

set(CMAKE_OSX_SYSROOT 
"/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk")

Can be set to:

set(CMAKE_OSX_SYSROOT "iphoneos")

in this case will support both simulator and device


set(CMAKE_C_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0")
set(CMAKE_CXX_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} 
-mios-version-min=7.0")
You can set minimum version by 
CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGETvariable.
In case of `CMAKE_OSX_SYSROOT` variable is set to `iphoneos` option 
`-isysroot` is redundant.




Do you think it should be documented?

Where is the good place to do so?
Maybe somewhere here:
https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html


What do you think?

​



*From:* clin...@elemtech.com 
*Sent:* Friday, December 11, 2015 8:21 PM
*To:* Bartosz Kosiorek
*Cc:* Bartosz Kosiorek; cmake-developers; Gregor Jasny
*Subject:* Re: [cmake-developers] Create subdirectories in Resource 
directory for Frameworks and Application bundle.




- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek 
 wrote:


Hi

Because there is difference between OS X and iOS Bundles
directory structure (see: Apple specification

https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html),

in trunk (In CMake 3.5) RESOURCE property create corresponding
directory structure.
I have already fix that with:
https://public.kitware.com/Bug/view.php?id=15848

Ok.  I hadn't been following all your work.
Also, I didn't see a toggle in the CMake code you sent to choose an 
iOS bundle instead of OS X bundles.  How is that toggled?


So RESOURCE gives you a level of abstraction:
For OSX:
it 

Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

[Ruslan Baratov via cmake-developers]

On 12-Dec-15 03:46, Bartosz Kosiorek wrote:


Hi

To enable iOS build, I'm using following settings in CMakeLists.txt:


set(APPLE_PLATFORM "iphonesimulator")

I think this one not needed. Can't find any place where it parsed.

set(CMAKE_OSX_SYSROOT 
"/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk")

Can be set to:

   set(CMAKE_OSX_SYSROOT "iphoneos")

in this case will support both simulator and device


set(CMAKE_C_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0")
set(CMAKE_CXX_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} 
-mios-version-min=7.0")
You can set minimum version by 
CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET variable.
In case of `CMAKE_OSX_SYSROOT` variable is set to `iphoneos` option 
`-isysroot` is redundant.




Do you think it should be documented?

Where is the good place to do so?
Maybe somewhere here:
https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html


What do you think?

​



*From:* clin...@elemtech.com 
*Sent:* Friday, December 11, 2015 8:21 PM
*To:* Bartosz Kosiorek
*Cc:* Bartosz Kosiorek; cmake-developers; Gregor Jasny
*Subject:* Re: [cmake-developers] Create subdirectories in Resource 
directory for Frameworks and Application bundle.




- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek 
 wrote:


Hi

Because there is difference between OS X and iOS Bundles directory
structure (see: Apple specification

https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html),

in trunk (In CMake 3.5) RESOURCE property create corresponding
directory structure.
I have already fix that with:
https://public.kitware.com/Bug/view.php?id=15848

Ok.  I hadn't been following all your work.
Also, I didn't see a toggle in the CMake code you sent to choose an 
iOS bundle instead of OS X bundles.  How is that toggled?


So RESOURCE gives you a level of abstraction:
For OSX:
it will create "Resource" directory

For iOS it will create "flat" directory structure.

In your example "Resource" directory will be created in both cases
(for OSX and iOS).
Which is wrong:
For OSX: it should  create "Resource" directory
For iOS it will create "flat" directory structure.

I could provide patch to fix that issue, if you agree with that.
What do you think about that?
Do you think the same should be applied to "Headers"?


I think the abstraction seems reasonable, as well as what you are 
proposing.  However, I'm not an Apple guru.
I wonder if there are other Apple experts that can weigh in this if 
better feedback is needed.


Clint



Best Regards
Bartosz



2015-12-11 19:06 GMT+01:00 Clinton Stimpson >:



On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote:
> Thanks Clint
>
> Unfortunately MACOSX_PACKAGE_LOCATION is not working
correctly with RESOURCE
> property. For every resource which is marked as RESOURCE,
will be placed in
> root "Resources" directory.
>
> The CMake code below create following directory structure
for OS X:
>
> ── mul.framework
> ├── Headers -> Versions/Current/Headers
> ├── Resources -> Versions/Current/Resources
> ├── Versions
> │   ├── A
> │   │   ├── Headers
> │   │   │   └── mul.h
> │   │   ├── Modules
> │   │   │   └── module.modulemap
> │   │   ├── Resources
> │   │   │   ├── Info.plist
> │   │   │   ├── mulres.txt
> │   │   │   ├── pl.txt
> │   │   │   └── resourcefile.txt
> │   │   ├── lang
> │   │   │   └── en.txt
> │   │   └── mul
> │   └── Current -> A
> └── mul -> Versions/Current/mul
>
>
> As you can see eveything which is marked as "RESOURCE" will
be placed in
> Versions/A/ directory My expectation will be that
lang/pl.txt and
> lang/en.txt should be in Resources/lang/ directory. Here is
complete
> directory structure:
>
> ── mul.framework
> ├── Headers -> Versions/Current/Headers
> ├── Resources -> Versions/Current/Resources
> ├── Versions
> │   ├── A
> │   │   ├── Headers
> │   │   │   └── mul.h
> │   │   ├── Modules
> │   │   │   └── module.modulemap
> │   │   ├── Resources
> │   │   │   ├── Info.plist
> │   │   │   ├── mulres.txt
> │   │   │   ├── lang
> │   │   │   │   └── pl.txt
> │   

Re: [cmake-developers] Please comment on ios-universal topic

[Ruslan Baratov via cmake-developers]

On 10-Dec-15 13:55, Gregor Jasny wrote:

Hello,

On 09/12/15 10:21, Ruslan Baratov wrote:

IOS_INSTALL_COMBINED_BINARY


Just to clarify you want to leave only one variable
IOS_INSTALL_COMBINED_BINARY for the device + simulator on iOS platforms.
Other platforms (in future) will be controlled by using *_ARCHITECTURES
variables, right?


Right. Any objections to that property name?

Thanks,
Gregor


TL;DR I'm finding it a little bit confusing but can't propose any better 
alternatives so I have no objections :)


Some thoughts:
* arm64 + armv7 is a universal binary, arm64 + armv7 + i386 - well, 
still universal binary too :)
* OSX_ARCHITECTURES affect architectures on iOS. Probably it should be 
IOS_ARCHITECTURES or just ARCHITECTURES (though MACOSX_BUNDLE works same 
way)
* OSX_ARCHITECTURES=armv7 -> build armv7, OSX_ARCHITECTURES=armv7,arm64 
-> build universal armv7+arm64, but OSX_ARCHITECTURES=armv7,arm64,i386 
doesn't build armv7+arm64+i386 binary
* hard to say anything about future improvements, like if it will be 
easier to implement universal binary in build directory on Android, then 
*_ARCHITECTURES looks better. but if it will be easier to build one 
architecture then add extra code to add more on install then 
INSTALL_UNIVERSAL_BINARY for all platforms looks better


Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to set environment variables with spaces in commands

[Ruslan Baratov via CMake]

On 10-Dec-15 12:52, Attila Krasznahorkay wrote:

Hi QP,

Probably not the intended solution, but what I’m doing in such cases is that in 
a patch step I create a shell script that does the configuration for me. With 
all the environment settings and everything. Like:

PATCH_COMMAND ${CMAKE_COMMAND} -E echo “cd someDir/; CC=\”something\” ./configure” 
> configure.sh
CONFIGURE_COMMAND sh configure.sh

...


Unfortunately this makes the code quite unportable, as it will only work on 
POSIX platforms like this.
Even on *nix platforms such code will not always works as expected. As 
documentation states 
(https://cmake.org/cmake/help/v3.4/module/ExternalProject.html):


   Behavior of shell operators like |&&| is not defined.

I've hit this on practice by using `LOG_* 1` feature. You can try this 
example (I've moved PATCH_COMMAND to CONFIGURE_COMMAND since there is no 
LOG_PATCH option):


   https://gist.github.com/ruslo/e8c7be03521f167ae8f0


Result:

   [ 62%] Performing configure step for 'Foo'
   cd /.../Foo-prefix/src/Foo-build && /.../cmake -P
   /.../Foo-prefix/src/Foo-stamp/Foo-configure-.cmake
   CMake Error at /.../Foo-prefix/src/Foo-stamp/Foo-configure-.cmake:16
   (message):
  Command failed: 1

The reason of the failure is because CMake collect all arguments into 
one command and run execute_process:


   set(command "/.../cmake;-E;echo;cd ..;>;configure.sh")
   execute_process(COMMAND ${command} RESULT_VARIABLE result)

which of course doesn't make sense.

This makes writing ExternalProject_Add steps with modification of 
environment quite non-trivial task (at least doing it correctly). This 
feature definitely missing in CMake. I've mentioned it once already: 
https://cmake.org/pipermail/cmake-developers/2015-August/026053.html


but I've changed my mind about the approach because of LOG_* issue. Now 
I do the next:


* wrap each step with CMake script, i.e. instead of `CC=something 
./configure` do


   set(ENV{CC} "something")
   execute_process(COMMAND ./configure ...)

* run CMake script in *_COMMAND:

   CONFIGURE_COMMAND
   "${CMAKE_COMMAND}" -P "/path/to/configure.cmake"

This makes it cross-platform and *_LOG friendly but require more tricks. 
Like if you're building in source (non-cmake packages) you have to copy 
script before execution since CMake will remove source directory on 
DOWNLOAD step. Which makes it looks like this:


   CONFIGURE_COMMAND
   "${CMAKE_COMMAND}" -E copy "/path/to/source/configure.cmake"
   "/path/to/unpacked/configure.cmake"
   COMMAND
   "${CMAKE_COMMAND}" -P "/path/to/unpacked/configure.cmake"

PS I'm hitting problems in ExternalProject with environment variables 
all the time. E.g. at this moment fixing MinGW + Boost: 
https://github.com/ruslo/hunter/pull/273


Ruslo


  But I guess that’s the case anyway once you start setting environment 
variables.

Cheers,
Attila

P.S. I often create build.sh and install.sh scripts as well in additional patch 
commands.


On Dec 10, 2015, at 5:35 AM, Qingping Hou  wrote:

Hi all,

I am trying to setup an ExternalProject in cmake but got stuck in the
configuration step. I am using ccache to speed up the compilation:

```
ExternalProject_Add(
  ...
  CONFIGURE_COMMAND CC="ccache arm-linux-gnueabihf-gcc" ./configure
  ...
)
```

However, when cmake generates the Makefile, it moves the quotes around
and breaks the command:

```
"CC=ccache arm-linux-gnueabihf-gcc" ./configure
```

I have tried various escaping method to try to get it work properly
without any luck. Is this a bug or an unintended feature?

Thanks,
QP
--

Powered by www.kitware.com

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

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

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

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

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


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Please comment on ios-universal topic

[Ruslan Baratov via cmake-developers]

On 09-Dec-15 04:51, Gregor Jasny wrote:


Hello,

On 02/12/15 13:44, Bartosz Kosiorek wrote:

I would like to propose to rename property name to INSTALL_IOS_UNIVERSAL_LIBS.

My thoughts about the property name:

I added the necessary functionality to also combine Frameworks and App
Bundles. So the _LIBS suffix now got misleading. And I think that
providing a different property for libraries, frameworks and app bundles
is not really helpful. To combine all targets one could set the CMAKE_
prefixed variable, to combine only some, one could set the property on
the target itself.

Deploying applications which support both armv7 (32bit) and armv8
(64bit) is already working by setting both architectures in the
OSX_ARCHITECTURES property because both are covered by the device SDK.

So technically we already support UNIVERSAL libraries. What we don't
support is combining device and simulator builds. So how about replacing
UNIVERSAL with COMBINED?

IOS_INSTALL_COMBINED_BINARY


Just to clarify you want to leave only one variable IOS_INSTALL_COMBINED_BINARY 
for the device + simulator on iOS platforms. Other platforms (in future) will 
be controlled by using *_ARCHITECTURES variables, right?

Ruslo

--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Fw: Please comment on ios-universal topic

[Ruslan Baratov via cmake-developers]

On 03-Dec-15 14:57, Bartosz Kosiorek wrote:

Thanks Ruslan for feedback.

I think that this new property should work also for FRAMEWORK and should 
support both OSX and iOS
In that way it is already done for:
  -  for SHARED library adding FRAMEWORK property produce correct Framework for 
iOS or OSX (for Cmake 3.5 the documentation was already updated), and standard 
library for other platforms
  - for MACOSX_BUNDLE (the name of property is very confusing). It will produce 
BUNDLE for OSX or iOS.
  - even standard SHARED library produce different results according to 
platform (.so file on Linux, .dll on Windows, .dylib on OSX)

I strongly believe that this new CMake's property should follow this convention.

Currently I'm working in project which must support multiple platforms (Linux, 
Windows, OSX, iOS, Android, QNX etc.).
And I very like CMake for automagicaly adopting to platform/architecture/OS.

Because "Universal Library" is generic name, which is applicable for all 
platforms (Fat library is used on Apple machines),
I would like to propose following  property name:
 INSTALL_UNIVERSAL_LIBRARY

For now it will be applicable only on iOS (OS X?), but it could be extended to 
other platforms (Android).
Of course all supported platforms should be noticed in documentation.

What do you think about that idea:
Adding one property which will adopt to platform on which is build?
Actually it make sense to me. We just need to add a note to the 
documentation that only Xcode + iOS libs supported for now and add new 
types/platforms in future.


By the way does any other platform except Apple's OSX and iOS support 
fat libraries? You've mentioned Android (?) I've found this link about 
Linux: 
https://en.wikipedia.org/wiki/Fat_binary#FatELF:_Universal_Binaries_for_Linux 
(quote: `developer Ryan Gordon declared FatELF to be dead`)


Ruslo




Best Regards
Bartosz


From: Ruslan Baratov 
Sent: Thursday, December 3, 2015 4:09 AM
To: Bartosz Kosiorek
Cc: Gregor Jasny; cmake-developers@cmake.org
Subject: Re: Fw: [cmake-developers] Please comment on ios-universal topic

On 02-Dec-15 19:44, Bartosz Kosiorek wrote:

Hi.

Currently we already support similar target properties:
- INSTALL_NAME_DIR
- INSTALL_RPATH
- INSTALL_RPATH_USE_LINK_PATH

It will be great to follow the same name convention.

Because this new property is only applicable for INSTALL step, I would like to 
propose to rename property name to INSTALL_IOS_UNIVERSAL_LIBS.

What do you think about that idea?

It's hard for me to decide what is better because
IOS_INSTALL_UNIVERSAL_LIBS just came from my mind and I've used it for a
while already. So now it looks solid for no reason :)

However first note:
INSTALL_RPATH can be read as when we do INSTALL change RPATH to ...
(any platform)
ANDROID_API -//- when we are on ANDROID use next API ...
WIN32_EXECUTABLE -//- when we are on WIN32 use bla-bla for EXECUTABLE
OSX_ARCHITECTURES -//- when we are on OSX use ARCHITECTURES
MACOSX_BUNDLE -//- when we are on MACOSX create BUNDLE

So new property can be read as:
IOS_INSTALL_UNIVERSAL_LIBS when we are on IOS do INSTALL_UNIVERSAL_LIBS
INSTALL_IOS_UNIVERSAL_LIBS when we do INSTALL make IOS_UNIVERSAL_LIBS
(does it mean that when we are on Linux we can install iOS libs? does it
mean that when we are on OSX without iOS toolchain we can do iOS libs?)

Second note is about future improvements of this feature, installing
universal libs on OSX or installing universal frameworks, pattern
_INSTALL_UNIVERSAL_:

 IOS_INSTALL_UNIVERSAL_LIBS
 IOS_INSTALL_UNIVERSAL_FRAMEWORKS

OSX_INSTALL_UNIVERSAL_LIBS
OSX_INSTALL_UNIVERSAL_FRAMEWORKS

INSTALL_UNIVERSAL_LIBS # on both OSX and iOS
INSTALL_UNIVERSAL_FRAMEWORKS # on both OSX and iOS

IOS_INSTALL_UNIVERSAL # both libs and frameworks
OSX_INSTALL_UNIVERSAL # both libs and frameworks

INSTALL_UNIVERSAL # both libs and frameworks, both OSX and iOS

?

Ruslo


From: cmake-developers  on behalf of Gregor Jasny 
via cmake-developers 
Sent: Tuesday, December 1, 2015 3:22 PM
To: CMake Developers; Ruslan Baratov
Subject: [cmake-developers] Please comment on ios-universal topic

Hello,

During the last days I worked on the iOS Universal Install topic which
now would benefit from a review. Especially the core changes could need
a third pair of eyes:

https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=8fb23b42cfc2fb7490e8645fff328add9c231713

I will now concentrate on adding more tests during the next days.

Thank you,
Gregor

--

Powered by www.kitware.com

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

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

CMake Support: 

Re: [CMake] Best way to handle application data path for local run vs. installation

[Ruslan Baratov via CMake]

On 03-Dec-15 16:59, Johannes Zarl-Zierl wrote:

I.e. it could be replaced with a string of the same length or a
shorter one, but not a longer one.

CMake works around this by extending the build RPATH artificially with
":" at the end I think, patchelf works around this by making the whole
executable one page bigger if the new entry is longer.

Just an implementation notes, doesn't change the fact that it can be
done and it's designed to be modifiable.

This is only nitpicking about a side-topic, but: Just because it can be done
does not mean that it was designed for that purpose.
If it succeed it doesn't break the things. And for every C++ string 
changing trick can be created counter-example (yes, synthetic, but 
anyway) that violates logic or even crash an application. At least in 
the form how I see it will be implemented.



You argument is like saying that a wrench was designed to be used as a hammer
(after all, you can hit a nail with it).
I've never seen manual to the wrench but if one exists I doubt there is 
a section "how to hit a nail with wrench". But I see chrpath tool on 
Linux and install_name_tool on OSX.


Will you be okay if I change "designed" to "can be done correctly"?

Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Best way to handle application data path for local run vs. installation

[Ruslan Baratov via CMake]

On 04-Dec-15 03:47, Alexander Neundorf wrote:


On Thursday, December 03, 2015 09:27:29 Ruslan Baratov via CMake wrote:

> On 03-Dec-15 04:34, Alexander Neundorf wrote:

> > On Wednesday, December 02, 2015 12:27:42 Ruslan Baratov wrote:

> > If RPATH was _designed_ to be patchable, tools could just do it,

> > instead of having to implement workarounds for longer strings. E.g.

> > the linker would support a command line argument how much space it

> > should reserve for the RPATH entry, or something like that.

>

> I think it's not possible. As far as I know there is no limitation for

> path size on Linux for example. Hence it's not possible to predict what

> size for path to library user want to use by setting RPATH.

More nitpicking about the meaning of "designed" ;-) :

CMake knows the length of the build RPATH and the length of the 
install RPATH. Let's say the build RPATH has a length of 100, and the 
install RPATH has a length of 150, it could, during linking, give the 
build RPATH to the linker, and also something like --rpath-size=150, 
and the linker would make the field for the RPATH 150 bytes big, so it 
could be patched easly later on.


This is what I would consider the minimum support if it was "designed" 
to be patched.


Instead cmake has to add 50 ":" at the end of the build RPATH. :-/

...

> > The idea above was only for solving the question "am I installed ?"

> > yes/no, not "where am I installed ?".

>

> Then I don't understand how it's planned to be used. I thought that in

> build directory you changing "_I_M_NOT_INSTALLED_" to

> "/path/to/build/directory" so resources can be found there, and on

> install you change it to "/path/to/install/directory". So my guess is

> not correct?

Nothing is planned, just some ideas.

The idea was, during install, to set the first byte of that special 
string to '\0', and in the code you test whether the string is empty ( 
-> it has been patched, so it is installed) or not (still the original 
"_I_M_NOT_INSTALLED_").


With that information, the developer can then do whatever he wants. 
e.g. when not installed, search just in $CMAKE_BINARY_DIR (which could 
be configured into some other string), and if installed, search in 
some other way.


Will not work, just like I said compiler is smart enough to figure out 
if the first char in string literal is '\0' or not. Just make some 
testing: https://gist.github.com/ruslo/04d8993800ee78513d1c


The only one possibility to implement what you want I see in creating 
new dynamic library (probably by CMake) with one literal:


// 3rd party library API
const char* path_to_install();

void parse_resources() {
  const char* x = path_to_install();
  assert(x != 0);
  if (x[0] == '\0') {
// OK, can't be optimized since it's an external library
  }
  else {
// load resources
  }
}

So CMake should create such library in build directory and then 
re-create and install it with new string in install directory. Of course 
if you move such library it will not work :) So still doesn't make sense 
to me...


Ruslo

-- 

Powered by www.kitware.com

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

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

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

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

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