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

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

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-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-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-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-developers] Fw: Please comment on ios-universal topic

[Ruslan Baratov via cmake-developers]

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: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware 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] [PATCH] FindBoost: Add imported targets

[Ruslan Baratov via cmake-developers]

On 17-Nov-15 15:48, Roger Leigh wrote:

On 17/11/2015 07:53, Ruslan Baratov wrote:

On 16-Nov-15 21:01, rle...@codelibre.net wrote:
I have attached a patch to add imported targets to FindBoost, in the 
form

of Boost:: (e.g. Boost::date_time) or Boost::Boost as a
generic
interface library for header-only components.

Since it's `Boost::date_time` I expect that it will be `Boost::boost`
(lowercase).


Yes, I've merged most of the previous work Brad pointed to yesterday, 
and this included this change.



On 16-Nov-15 21:39, Brad King wrote:

On 11/16/2015 09:26 AM, Florent Castelli wrote:

But one there’s one thing that comes to mind. Some compiled libraries
have dependencies on other compiled libraries.
Don’t you think it would make sense to teach FindBoost about those
so we link everything properly?

And also maybe add the native dependencies for some modules that
have one like maybe pthread or openssl.
Though, this might be hard to get right in a cross platform way.

Please look at adding these.  The imported targets should come
with all usage requirements as if they were provided by upstream
Boost.  It may be tricky to get right on all platforms but if we
do not do it then application code will have to do it instead.



One tricky part about it is that dependency can be optional. I.e.
Boost::iostreams may or may not depends on ZLIB/BZip2. Such information
is known only by build procedure. I.e. should be installed by b2 itself
or by wrapped ExternalProject_Add instructions.


For the specific case of the zlib/bzip2 dependencies, this is only the 
case when using the static libraries?  It's not exposed via the 
headers is it?
I'm not sure about all aspects it's not my main point anyway :) I'm 
saying that this kind of information can be installed by CMake project 
and I can predict that it will be hard to achieve the same in 
FindBoost.cmake when build already done and this info is lost.




Looking at the information embedded in the sources for use with 
autolinking, we could certainly process the headers for the requested 
components and pull out the referenced libraries.  This would get us 
all of the header dependencies without hardcoding anything ourselves, 
which would make it work with arbitrary versions of boost without 
having to hardcode the differences between Boost versions.


Fully supporting static linking would be much more difficult.  As you 
say, it depends upon how Boost was built. 

...

Full support here would need to wait for the upstream to generate this 
data at build time?
This is a best option but not necessary. As I said earlier if you're 
using wrapper to install boost (like ExternalProject_Add) you can add 
some extra files which will hold this info.


Ruslan
--

Powered by www.kitware.com

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

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

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

Visit other Kitware 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 Framework Bundle support

[Ruslan Baratov via cmake-developers]

On 13-Nov-15 20:59, Bartosz Kosiorek wrote:

Hello.

Main reason for using Makefile instead of Xcode is performance reason. Xcode 
generator is much slower that Makefile in our project.
The performance was improved in Cmake 3.2 but still it is much slower on Xcode. 
Similar slowness could be observed on Windows with Visual Studio generator (for 
our project).
Do you know what caused performance improve in Cmake 3.2 ?
I'm not sure, but I think this is because there are a lot of tests on 
generation step and each test creates .xcodeproj (.vcproj for Visual 
Studio) and build it. Which is much slower than creating and running 
Makefile.



We are using Makefile builds for automatic tests on farm of devices/simulators.
We strongly believe that Xcode generation should only be used for IDE context 
and not for Continuous Integration/cmd usage.
In my opinion type of CI build should match working environment exactly. 
Otherwise you can break something in Xcode and no error will be reported 
by CI since Makefile used on auto-build machine.
Makefile and Xcode project generated by CMake may not match in general, 
for example if there is no special unification code then warning flags 
will be different. Also all XCODE_ATTRIBUTES_* simply ignored for 
Makefile and no equivalent flags added. From my experience `xcodebuild` 
and `cmake --build` work quite fine with Xcode projects so see no 
problems with using cmd.


Ruslan


In cmd/CI case you want to use generators like make, ninja, fastbuild, etc.

What is your opinion about that?

Best Regards
Bartosz


-Original Message-
From: Gregor Jasny [mailto:gja...@gmail.com]
Sent: Friday, November 13, 2015 2:09 PM
To: Bartosz Kosiorek; cmake-developers@cmake.org
Subject: Re: [cmake-developers] [PATCH] iOS Framework Bundle support

On 11/11/15 02:19, Bartosz Kosiorek wrote:

Hi

Generally I created this cmake scripts to to able to test creating iOS/OSX 
Application Bundle and iOS/OSX Dynamic Framework Bundle.
By default it produces iOS application Bundle and iOS Framework Bundle.

Steps to reproduce:
1. Download and install CMake 3.4.0
2. Unpack and unpack cmake_shared_ios_framework.zip 3. cd
cmake_shared_ios_framework 4. mkdir build 5. cd build 6.
../../../cmake-3.4.0-rc3-Darwin-x86_64/CMake.app/Contents/bin/cmake ..
7. make

I wonder why anyone wants to build for iOS without the Xcode generator?


--

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] FindBoost: Add imported targets

[Ruslan Baratov via cmake-developers]

On 16-Nov-15 21:01, rle...@codelibre.net wrote:

I have attached a patch to add imported targets to FindBoost, in the form
of Boost:: (e.g. Boost::date_time) or Boost::Boost as a generic
interface library for header-only components.
Since it's `Boost::date_time` I expect that it will be `Boost::boost` 
(lowercase).


On 16-Nov-15 21:39, Brad King wrote:

On 11/16/2015 09:26 AM, Florent Castelli wrote:

But one there’s one thing that comes to mind. Some compiled libraries
have dependencies on other compiled libraries.
Don’t you think it would make sense to teach FindBoost about those
so we link everything properly?

And also maybe add the native dependencies for some modules that
have one like maybe pthread or openssl.
Though, this might be hard to get right in a cross platform way.

Please look at adding these.  The imported targets should come
with all usage requirements as if they were provided by upstream
Boost.  It may be tricky to get right on all platforms but if we
do not do it then application code will have to do it instead.



One tricky part about it is that dependency can be optional. I.e. 
Boost::iostreams may or may not depends on ZLIB/BZip2. Such information 
is known only by build procedure. I.e. should be installed by b2 itself 
or by wrapped ExternalProject_Add instructions.


Ruslan
--

Powered by www.kitware.com

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

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

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

Visit other Kitware 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: install universal iOS libraries

[Ruslan Baratov via cmake-developers]

On 28-Oct-15 00:56, Gregor Jasny wrote:

Hello,

I hope to have finished the review by end of this week.

On 25/10/15 15:34, Ruslan Baratov wrote:

+  set(cmd lipo -info "${filename}")

Minor nitpick: lipo should probably be called via xcrun. Otherwise it
might not know how to handle new architectures.

Fixed, rebased patches attached.

Ruslo


>From 75bed9fc6f7597e280b63023323cfe5c3ad6a0c1 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov 
Date: Thu, 8 Oct 2015 03:09:34 +0300
Subject: [PATCH 1/3] Get target name for universal iOS library install

Add method GetTargetNameForUniversalIosInstall to cmInstallTargetGenerator.

This method will return target name if:
 * Platform is iOS
 * Generator is Xcode
 * Target is library
 * CMake variable CMAKE_IOS_INSTALL_UNIVERSAL_LIBS or target property
   IOS_INSTALL_UNIVERSAL_LIBS is ON

Otherwise an empty string will be returned.
---
 Source/cmInstallTargetGenerator.cxx | 42 +
 Source/cmInstallTargetGenerator.h   |  5 +
 2 files changed, 47 insertions(+)

diff --git a/Source/cmInstallTargetGenerator.cxx b/Source/cmInstallTargetGenerator.cxx
index 59d06f6..a5c1ebd 100644
--- a/Source/cmInstallTargetGenerator.cxx
+++ b/Source/cmInstallTargetGenerator.cxx
@@ -861,3 +861,45 @@ cmInstallTargetGenerator::AddRanlibRule(std::ostream& os,
   os << indent << "execute_process(COMMAND \""
  << ranlib << "\" \"" << toDestDirPath << "\")\n";
 }
+
+std::string
+cmInstallTargetGenerator
+::GetTargetNameForUniversalIosInstall(cmInstallType type) const
+{
+  cmMakefile const* mf = this->Target->Target->GetMakefile();
+  if(!mf->PlatformIsAppleIos())
+{
+return "";
+}
+
+  switch(type)
+{
+case cmInstallType_STATIC_LIBRARY:
+case cmInstallType_SHARED_LIBRARY:
+case cmInstallType_MODULE_LIBRARY:
+  break;
+default:
+  return "";
+}
+
+  const char* xcode = mf->GetDefinition("XCODE");
+  if(cmSystemTools::IsOff(xcode))
+{
+// Xcode only
+return "";
+}
+
+  if(this->Target->Target->GetPropertyAsBool("IOS_INSTALL_UNIVERSAL_LIBS"))
+{
+return this->Target->GetName();
+}
+
+  const char* var = "CMAKE_IOS_INSTALL_UNIVERSAL_LIBS";
+  const char* flag = mf->GetDefinition(var);
+  if (cmSystemTools::IsOff(flag))
+{
+return "";
+}
+
+  return this->Target->GetName();
+}
diff --git a/Source/cmInstallTargetGenerator.h b/Source/cmInstallTargetGenerator.h
index ec89c05..10a1be4 100644
--- a/Source/cmInstallTargetGenerator.h
+++ b/Source/cmInstallTargetGenerator.h
@@ -108,6 +108,11 @@ protected:
   NamelinkModeType NamelinkMode;
   bool ImportLibrary;
   bool Optional;
+
+ private:
+  /** Get target name for installing universal iOS library. If target is not
+  an iOS library or universal build is disabled return empty string. */
+  std::string GetTargetNameForUniversalIosInstall(cmInstallType type) const;
 };
 
 #endif
-- 
1.9.3 (Apple Git-50)

>From 8081f5d3ef8d48da55c7930c72fcb345593ea33e Mon Sep 17 00:00:00 2001
From: Ruslan Baratov 
Date: Wed, 28 Oct 2015 06:08:43 +0600
Subject: [PATCH 2/3]  CMake module for universal iOS library install

 Add CMake module with function `install_universal_ios_library`.
 Target name and destination passed to the function. This function will be run
 after library installed: will trigger additional build instructions for missing
 platform and fuse libraries into universal in destination directory.

 Module designed to be used in `cmake_install.cmake` script.
---
 Modules/install_universal_ios_library.cmake | 352 
 1 file changed, 352 insertions(+)
 create mode 100644 Modules/install_universal_ios_library.cmake

diff --git a/Modules/install_universal_ios_library.cmake b/Modules/install_universal_ios_library.cmake
new file mode 100644
index 000..fca1c3d
--- /dev/null
+++ b/Modules/install_universal_ios_library.cmake
@@ -0,0 +1,352 @@
+#=
+# Copyright 2014-2015 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.)
+
+# Function to print messages of this module
+function(install_universal_ios_message str)
+  message("[iOS universal] ${str}")
+endfunction()
+
+# Get build settings for the current target/config/SDK by running
+# `xcodebuild -sdk ... -showBuildSettings` and parsing it's output
+function(install_universal_ios_get sdk variable resultvar)
+  if("${sdk}" STREQUAL "")
+message(FATAL_ERROR "`sdk` is empty")
+  endif()

Re: [cmake-developers] Filesystem timestamp checks

[Ruslan Baratov via cmake-developers]

On 21-Oct-15 03:25, Ben Boeckel wrote:

On Wed, Oct 21, 2015 at 01:53:42 +0600, Ruslan Baratov wrote:

On 20-Oct-15 21:42, Ben Boeckel wrote:

On Tue, Oct 20, 2015 at 04:56:47 +0600, Ruslan Baratov via cmake-developers 
wrote:

* I don't want to patch every script. To be precise I prefer to "Fix
something in one place so it works 100% and forget about it" then "Every
time I start creating script I should remember that..."

The "one place" would be make and (probably) ninja, not CMake as your
example indicates.

It's not a make or ninja issue.

Doesn't your example Makefile without CMake in the loop show this issue
without CMake being present though?
Yes. I mean "It's not **only** a make or ninja issue" so fixing make 
will not help. I'm pretty sure this "feature" is reproducible using any 
generator if file system date resolution is bad enough.

--

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] Filesystem timestamp checks

[Ruslan Baratov via cmake-developers]

On 20-Oct-15 21:42, Ben Boeckel wrote:

On Tue, Oct 20, 2015 at 04:56:47 +0600, Ruslan Baratov via cmake-developers 
wrote:

* I don't want to patch every script. To be precise I prefer to "Fix
something in one place so it works 100% and forget about it" then "Every
time I start creating script I should remember that..."

The "one place" would be make and (probably) ninja, not CMake as your
example indicates.
It's not a make or ninja issue. It's combination of "bad" date 
resolution, fast changing of file and performance of native build tool.
I can't reproduce scenario with source change on NTFS with Visual Studio 
generator, probably because Visual Studio is slow enough and play the 
role of "sleeping-guard". However I can reproduce same test on FAT32. 
And I've said already I can reproduce it on HFS with Xcode generator.


Cheers, 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] Documentation file(GLOB): ordering note

[Ruslan Baratov via cmake-developers]

Add a note that order of files is not defined
>From 9cd9fbb12ef73b72526190573cba0392ead5fd9f Mon Sep 17 00:00:00 2001
From: Ruslan Baratov 
Date: Wed, 21 Oct 2015 02:53:37 +0600
Subject: [PATCH] Documentation: file(GLOB*) order is not guaranteed

Since this command use 'readdir' under the hood the order of list is
undefined:
* http://stackoverflow.com/questions/8977441/does-readdir-guarantee-an-order
---
 Help/command/file.rst | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Help/command/file.rst b/Help/command/file.rst
index bbddd40..a441054 100644
--- a/Help/command/file.rst
+++ b/Help/command/file.rst
@@ -103,7 +103,8 @@ Generate a list of files that match the  and
 store it into the .  Globbing expressions are similar to
 regular expressions, but much simpler.  If ``RELATIVE`` flag is
 specified, the results will be returned as relative paths to the given
-path.
+path. Command doesn't guarantee any ordering. If order is important you have
+to sort list manually (e.g. using :command:`list(SORT)` command).
 
 By default ``GLOB`` lists directories - directories are omited in result if
 ``LIST_DIRECTORIES`` is set to false.
-- 
2.4.5

-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] Filesystem timestamp checks

[Ruslan Baratov via cmake-developers]

On 19-Oct-15 19:30, Brad King wrote:

On 10/15/2015 03:58 PM, Ruslan Baratov wrote:

3. Apply changes to CMakeLists.txt "immediately", CMakeLists.txt modification 
time 105
4. Run rebuild: `cmake --build _builds`. Since CMakeLists.txt (105) is not 
"newer"
then Makefile (105) there will be no regenerate command run and Makefile 
remains the same

Error can be easily reproduced on Apple HFS file system with unit = 1s (I hit this 
problem doing changes even manually) but in general that's the "feature" of 
native make tool + file system date resolution. Here is the similar test for Linux with 
ext4:
Test: https://github.com/forexample/date-resolution-test
Log: https://travis-ci.org/forexample/date-resolution-test/builds/85021483

This is a fundamental limitation of buildsystems that use file timestamps.
Your example shows that even plain "make" has this problem.  One simply
must use a workflow that does not involve changing files "immediately".
It's not that bad.  When manually entering commands it is very hard to
type that fast.  When scripting commmands the script can delay where
needed.

I've already heard all this arguments and can only reply mine again :)
* I've hit this while doing manual changes for Xcode project on Apple's 
HFS with 1s resolution
* I don't want to patch every script. To be precise I prefer to "Fix 
something in one place so it works 100% and forget about it" then "Every 
time I start creating script I should remember that..."



There are a lot of scenarios where such problems can occurs, e.g. installing 
files (reproducible on OSX and Linux):
* https://cmake.org/pipermail/cmake-developers/2015-October/026692.html

This is a separate issue because it is about CMake truncating timestamps
rather than the filesystem doing it.
Well yes, I was not very accurate with this statement, but in general 
it's very similar (if CMake truncation precision == file system date 
resolution then we have same situation) and "sleeping-guard" will fix it 
too.


As I've mentioned I have a wrapper already so I've applied the "sleep" 
functionality there. It fix all issues of 1-3 test case, so this is 
closed for me now.


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

[cmake-developers] Filesystem timestamp checks

[Ruslan Baratov via cmake-developers]

Originally from: https://cmake.org/Bug/view.php?id=15769

Here is the scenario of not triggering rebuild of project while 
CMakeLists.txt changed:

1. Create CMakeLists.txt (modification time 100 units)
2. Run generate (create project from scratch): `cmake -H. -B_builds`. 
Takes 5 units, Makefile created with modification time 105
3. Apply changes to CMakeLists.txt "immediately", CMakeLists.txt 
modification time 105
4. Run rebuild: `cmake --build _builds`. Since CMakeLists.txt (105) is 
not "newer" then Makefile (105) there will be no regenerate command run 
and Makefile remains the same


Error can be easily reproduced on Apple HFS file system with unit = 1s 
(I hit this problem doing changes even manually) but in general that's 
the "feature" of native make tool + file system date resolution. Here is 
the similar test for Linux with ext4:

Test: https://github.com/forexample/date-resolution-test
Log: https://travis-ci.org/forexample/date-resolution-test/builds/85021483

There are a lot of scenarios where such problems can occurs, e.g. 
installing files (reproducible on OSX and Linux):

* https://cmake.org/pipermail/cmake-developers/2015-October/026692.html

One more with sources:
* Create foo.cpp (100) which build executable foo
* Run generate and build foo (105)
* Modify foo.cpp "immediately" -> foo.cpp (105)
* Run build (may be repeated N times): cmake --build _builds, no changes (!)
* Run regenerate (may be repeated N times): cmake -H. -B_builds, no 
changes (!)


My excerpts from bug:

> I wouldn't expect every tool that can create a file to have an
   option to sleep after creating it.
   There is no need to sleep after each file creation it should be
   enough to sleep after generate/build step. I.e. in `cmake -H.
   -B_builds` and `cmake --build _builds` commands, but not in `cmake -E`.

   So experiencing such problems on other file systems just a matter of
   test and hardware capabilities which lead to
   unpredictable/unrepeatable bugs and makes it VERY hard to debug
   (e.g. to fix first test /*not the first, see example with sources*/
   it's not even enough to just re-run `cmake -H. -B_builds` - you
   should remove your build directory or touch files one more time
   after some pause). Again I understand that it's not a problem in
   CMake but if there is any chance to apply some "guarding"
   functionality it should be used. I'll take a look more deeply next
   week and will report my thoughts.

Any other ideas?

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] automatically download library

[Ruslan Baratov via cmake-developers]

On 08-Oct-15 18:06, Marsel Galimullin wrote:
The idea is that CMake has possibility to contact with package 
managers for download necessary libraries.

If “find_package” can’t find a library, it need to call apt-get install.
Example:
auto_downland(apt-get)
find_package (Boost COMPONENTS system thread REQUIRED) 
re:{possibility to contact with package managers} *if* you have a 
suitable package manager. And even if you have one result may differs 
for different platforms, e.g.:


* OSX, brew install boost => 1.58
* Ubuntu, apt-get install boost-dev => 1.54

Note that 'find_package(Boost)' can find any user-installed libraries or 
non-host packages for cross-compile, like building Android on Linux, or 
iOS on OSX (both issues can be solved by using ExternalProject + 
superbuild). If you and your users are okay with that then it's should 
be not so hard to implement this CMake module.


On 06-Oct-15 15:22, Marsel Galimullin wrote:


Hello!
I'm student of the University LETI and as a masrer'sthesis I want to 
developan extension to CMake. It is expected that this extension will 
automatically download missinglibrary ifinstruction such as 
«find_package (Boost COMPONENTS system thread REQUIRED)» can not find 
the package. Could you give me some advices where to begin and which 
the best direction to design, developand whether to do it?


So with all this peculiarities I've described above this will be not 
such an easy task as you might expect. You can start one from scratch 
for education or fun (or both) but if you want to do some really helpful 
stuff my advice to you is to feed "cmake package manager" request to 
your web search engine and investigate existing solutions.


On 08-Oct-15 18:41, Ryan Schmidt wrote:

On Oct 8, 2015, at 10:06 AM, Marsel Galimullin wrote:


The idea is that CMake has possibility to contact with package managers for 
download necessary libraries.
If “find_package” can’t find a library, it need to call apt-get install.
Example:
auto_downland(apt-get)
find_package (Boost COMPONENTS system thread REQUIRED)

I understand the idea, and I'm telling you that if you need this for your own 
personal project -- one that will never be included in a package management 
system -- then do whatever you like. But if you are proposing this as something 
that should be included in cmake, and you are suggesting that it could be used 
by any project that wants to -- even in projects that might someday be included 
in a package management system -- then I can tell you that this would not be 
welcomed by the people who maintain those package management systems. I am such 
a person. If I were tasked with the request to add to my package management 
system a project that wanted to control the installation of its own 
dependencies, or that in some other way tried to be in charge of downloading 
its dependencies, I would either have to rip all that code out, or more likely 
I would reject the request to add that project as being too labor-intensive. It 
is the package management system's job to download and install dependencies, 
not the job of the project's build system.

re:{I would either have to rip all that code out, or more likely I would 
reject the request to add that project as being too labor-intensive} 
this can be solved easily by adding option which is set to OFF by default:


option(USE_SUPERTOOL "Download host packages automatically" OFF)
function(auto_download ...)
  if(NOT USE_SUPERTOOL)
# do nothing
return()
  endif()
  # do install
endfunction()
auto_download(...) # by default do nothing
find_package(Boost COMPONENT system thread REQUIED) # find the packages 
you are expecting


On 08-Oct-15 18:23, Brad King wrote:

On 10/08/2015 11:06 AM, Marsel Galimullin wrote:

The idea is that CMake has possibility to contact with package managers
for download necessary libraries.
If “find_package” can’t find a library, it need to call apt-get install.
Example:
  auto_downland(apt-get)
  find_package (Boost COMPONENTS system thread REQUIRED)

This does not provide enough information to know what package to install.
This problem is not in scope for a build system.  Another tool should
be used to install dependencies ahead of time before running CMake.
The source tree could come with some kind of dependency spec file for
such a tool to use but this would be independent of the build system.

-Brad

re:{The source tree could come with some kind of dependency spec file 
for such a tool to use but this would be independent of the build 
system} As the one who is using such approach in my product I disagree 
with that completely :) CMake code and dependencies are in fact coupled 
strongly. For example:


   option(USE_GUI "Use some GUI for this project" OFF)
   if(USE_GUI)
  if(WIN32)
option(USE_QT "Use Qt GUI" ON)
  else()
option(USE_WXWIDGETS "Use WxWidgets GUI" ON)
  endif()

  # check at least one and not both

  if(USE_QT)

Re: [cmake-developers] [CMake 0015769]: OS X: Filesystem timestamp checks use only 1s resolution

[Ruslan Baratov via cmake-developers]

On 10-Oct-15 01:00, Ruslan Baratov via cmake-developers wrote:

On 08-Oct-15 21:03, Mantis Bug Tracker wrote:

The following issue has been ASSIGNED.
==
https://cmake.org/Bug/view.php?id=15769  
==

Reported By:Ruslan Baratov
Assigned To:Brad King
==
Project:CMake
Issue ID:   15769
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: resolved
Target Version: CMake 3.5
Resolution: fixed
Fixed in Version:   CMake 3.5
==
Date Submitted: 2015-10-05 10:37 EDT
Last Modified:  2015-10-08 14:03 EDT
==
Summary:OS X: Filesystem timestamp checks use only 1s
resolution
Description:
`cmake --build` command doesn't trigger reconfiguration of the project on OS X
when CMakeLists.txt changed.

Example:

add_executable(foo foo.cpp) # file foo.cpp exists

cmake -H. -B_builds
cmake --build _builds
# OK

change:
add_executable(foo foo.cpp boo.cpp) # file boo.cpp not exists
cmake --build _builds
# expected error, but no error reported

Ready-to-run example can be found:
https://github.com/forexample/cmake-osx-no-reconfigure-bug

Log from OS X machine:
*https://travis-ci.org/forexample/cmake-osx-no-reconfigure-bug/builds/83701171

Log for similar test on Linux machine:
*https://travis-ci.org/forexample/cmake-osx-no-reconfigure-bug/builds/83702953

CMake on Linux machine run reconfigure command and report an error:
   cmake -H. -B_builds --check-build-system CMakeFiles/Makefile.cmake 0
   -- Configuring done
   CMake Error at CMakeLists.txt:4 (add_executable):
 Cannot find source file:
   boo.cpp

same error expected on OS X machine
==

--
  (0039511) Brad King (manager) - 2015-10-05 14:45
  https://cmake.org/Bug/view.php?id=15769#c39511  
--

I can reproduce this when running 'make' directly without 'cmake --build':

  -cmake --build _builds
  +(cd _builds; make)

The problem is that the filesystem and/or make tool seem to have 1s timestamp
resolution.  If I change the script to do "sleep 1" before the last "cp
CMakeBad.txt CMakeLists.txt" then it works.

--
  (0039512) Brad King (manager) - 2015-10-05 14:52
  https://cmake.org/Bug/view.php?id=15769#c39512  
--

The issue may be where CMake decides whether it needs to re-run:

  
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFileTimeComparison.cxx;hb=v3.3.2#l147

The STAT_HAS_ST_MTIM code path may not be taken on this platform.

--
  (0039513) Brad King (manager) - 2015-10-05 14:54
  https://cmake.org/Bug/view.php?id=15769#c39513  
--

Indeed, on OS X "struct stat" has:

  struct timespec st_mtimespec;

instead of

  struct timespec st_mtim;

--
  (0039518) Brad King (manager) - 2015-10-06 13:27
  https://cmake.org/Bug/view.php?id=15769#c39518  
--

For reference, I've started a fix for this on the KWSys side here:

  http://review.source.kitware.com/20258/  


--
  (0039519) Brad King (manager) - 2015-10-06 14:04
  https://cmake.org/Bug/view.php?id=15769#c39519  
--

It looks like the underlying HFS filesystem only has 1s resolution:

  https://en.wikipedia.org/wiki/HFS_Plus

This may not be possible to fix without a "sleep 1" in the test script.

--
  (0039548) Brad King (manager) - 2015-10-08 14:01
  https://cmake.org/Bug/view.php?id=15769#c39548  
--

After the KWSys side learned to use st_mtimespec I've updated CMake too:

  cmFileTimeComparison: Port to OS X nanosecond times
  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8d27b407  


--
  (0039549) Brad King (manager) - 2015-10-08 1

Re: [cmake-developers] [CMake 0015769]: OS X: Filesystem timestamp checks use only 1s resolution

[Ruslan Baratov via cmake-developers]

On 08-Oct-15 21:03, Mantis Bug Tracker wrote:

The following issue has been ASSIGNED.
==
https://cmake.org/Bug/view.php?id=15769
==
Reported By:Ruslan Baratov
Assigned To:Brad King
==
Project:CMake
Issue ID:   15769
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: resolved
Target Version: CMake 3.5
Resolution: fixed
Fixed in Version:   CMake 3.5
==
Date Submitted: 2015-10-05 10:37 EDT
Last Modified:  2015-10-08 14:03 EDT
==
Summary:OS X: Filesystem timestamp checks use only 1s
resolution
Description:
`cmake --build` command doesn't trigger reconfiguration of the project on OS X
when CMakeLists.txt changed.

Example:

add_executable(foo foo.cpp) # file foo.cpp exists

cmake -H. -B_builds
cmake --build _builds
# OK

change:
add_executable(foo foo.cpp boo.cpp) # file boo.cpp not exists
cmake --build _builds
# expected error, but no error reported

Ready-to-run example can be found:
https://github.com/forexample/cmake-osx-no-reconfigure-bug

Log from OS X machine:
* https://travis-ci.org/forexample/cmake-osx-no-reconfigure-bug/builds/83701171

Log for similar test on Linux machine:
* https://travis-ci.org/forexample/cmake-osx-no-reconfigure-bug/builds/83702953

CMake on Linux machine run reconfigure command and report an error:
   cmake -H. -B_builds --check-build-system CMakeFiles/Makefile.cmake 0
   -- Configuring done
   CMake Error at CMakeLists.txt:4 (add_executable):
 Cannot find source file:
   boo.cpp

same error expected on OS X machine
==

--
  (0039511) Brad King (manager) - 2015-10-05 14:45
  https://cmake.org/Bug/view.php?id=15769#c39511
--
I can reproduce this when running 'make' directly without 'cmake --build':

  -cmake --build _builds
  +(cd _builds; make)

The problem is that the filesystem and/or make tool seem to have 1s timestamp
resolution.  If I change the script to do "sleep 1" before the last "cp
CMakeBad.txt CMakeLists.txt" then it works.

--
  (0039512) Brad King (manager) - 2015-10-05 14:52
  https://cmake.org/Bug/view.php?id=15769#c39512
--
The issue may be where CMake decides whether it needs to re-run:

  
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFileTimeComparison.cxx;hb=v3.3.2#l147

The STAT_HAS_ST_MTIM code path may not be taken on this platform.

--
  (0039513) Brad King (manager) - 2015-10-05 14:54
  https://cmake.org/Bug/view.php?id=15769#c39513
--
Indeed, on OS X "struct stat" has:

  struct timespec st_mtimespec;

instead of

  struct timespec st_mtim;

--
  (0039518) Brad King (manager) - 2015-10-06 13:27
  https://cmake.org/Bug/view.php?id=15769#c39518
--
For reference, I've started a fix for this on the KWSys side here:

  http://review.source.kitware.com/20258/

--
  (0039519) Brad King (manager) - 2015-10-06 14:04
  https://cmake.org/Bug/view.php?id=15769#c39519
--
It looks like the underlying HFS filesystem only has 1s resolution:

  https://en.wikipedia.org/wiki/HFS_Plus

This may not be possible to fix without a "sleep 1" in the test script.

--
  (0039548) Brad King (manager) - 2015-10-08 14:01
  https://cmake.org/Bug/view.php?id=15769#c39548
--
After the KWSys side learned to use st_mtimespec I've updated CMake too:

  cmFileTimeComparison: Port to OS X nanosecond times
  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8d27b407

--
  (0039549) Brad King (manager) - 2015-10-08 14:03
  https://cmake.org/Bug/view.php?id=15769#c39549
--
Marking 

Re: [cmake-developers] Patch: install universal iOS libraries

[Ruslan Baratov via cmake-developers]

On 07-Oct-15 16:57, Gregor Jasny wrote:

Hello,

thank you for working on this. This is really hairy stuff.

On 24/09/15 11:10, Ruslan Baratov via cmake-developers wrote:

Patches help to install universal iOS (device + simulator) libraries by
triggering some extra instructions (build + fuse) after "regular"
library installation finished. This behavior controlled by CMake
variable CMAKE_IOS_INSTALL_UNIVERSAL_LIBS.

some general remarks:

* iOS is not the only platform where the simulator / device situation is
problematic. Others are now watchOS and the upcoming tvOS (see
xcodebuild -showsdks). So it would make sense to replace the ios naming
in the method signatures with something more general.

It cames from PlatformIsAppleIos.


* Does the patches handle Bundles and Frameworks properly?
No. At least for now it's designed to be used only for libraries 
(cmInstall_{STATIC,SHARED,MODULE}_LIBRARY). I don't think it make sense 
to extend this feature for Bundles (simulator architectures are useless 
in AppStore and will be rejected). If Bundle use Framework with 
simulator architectures it will be rejected too. Though it make sense to 
create "development" version of Framework with simulator archs but we 
need to resign it after fuse procedure (libs are not signed).


I'm planning to try to make such patches for Frameworks next.


* This functionality should be limited to XCODE Generator

Fixed.


0001-

* Could you make the CMAKE_IOS_INSTALL_UNIVERSAL_LIBS a two staged
property like CMAKE_INSTALL_RPATH / INSTALL_RPATH. That way one would be
able to enable this behavior for only some targets
Implemented. But I'm not sure it make sense. Can you describe scenario 
when it can be helpful?


0002-CMake-module-for-universal-iOS-library-install

* Could you avoid to hard-code architecture names like i386 or armv7 in
the module?


Ok. Added function to get "real" architectures by parsing `lipo -info`. 
If it's not equal to the one specified by SDK then needless archs removed.




* In Xcode 7 (and maybe earlier) I see the following environment
variables when I install for Device:


export CORRESPONDING_SIMULATOR_PLATFORM_NAME=iphonesimulator
export CORRESPONDING_SIMULATOR_SDK_NAME=iphonesimulator9.0
export SUPPORTED_PLATFORMS="iphonesimulator iphoneos"
export SDK_NAME=iphoneos9.0

for Simulator:


export CORRESPONDING_DEVICE_PLATFORM_NAME=iphoneos
export CORRESPONDING_DEVICE_SDK_NAME=iphoneos9.0
export SDK_NAME=iphonesimulator9.0

Could you use those variables to avoid hardcoding iphoneos/simulator in
the module?

I see CORRESPONDING_*_SDK_NAME variables in Xcode 7.0 but not in 6.4.



+  install_universal_ios_remove_arch("${dev_libpath}" "i386")
+  install_universal_ios_remove_arch("${dev_libpath}" "x86_64")

Doing it the other way round (keeping only what's needed) looks saner to me.


+  install_universal_ios_remove_arch("${dev_libpath}" ...)
+
+  install_universal_ios_remove_arch("${sim_libpath}" ...)
+
+  set(cmd lipo -create ${src} ${dst} -output ${dst})

Would it be possible to just add selected architectures from src to dst
(via lipo -replace)? That way you would save some disk i/o and would
make the pruning step for src superfluous.
This is kind of "unusual" situation. In most cases this command will 
just exit with "no such architecture" error (and ignored). I've added a 
warning message if unexpected arch detected.


Rebased version of patches attached.
Github fork: https://github.com/ruslo/CMake/commits/pr.ios.universal.2

Thanks, Ruslo
>From 1576f4d44902041407ab405544e6925bc52f8285 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov <ruslan_bara...@yahoo.com>
Date: Thu, 8 Oct 2015 03:09:34 +0300
Subject: [PATCH 1/3] Get target name for universal iOS library install

Add method GetTargetNameForUniversalIosInstall to cmInstallTargetGenerator.

This method will return target name if:
 * Platform is iOS
 * Generator is Xcode
 * Target is library
 * CMake variable CMAKE_IOS_INSTALL_UNIVERSAL_LIBS or target property
   IOS_INSTALL_UNIVERSAL_LIBS is ON

Otherwise an empty string will be returned.
---
 Source/cmInstallTargetGenerator.cxx | 42 +
 Source/cmInstallTargetGenerator.h   |  5 +
 2 files changed, 47 insertions(+)

diff --git a/Source/cmInstallTargetGenerator.cxx b/Source/cmInstallTargetGenerator.cxx
index 30cf175..34728fa 100644
--- a/Source/cmInstallTargetGenerator.cxx
+++ b/Source/cmInstallTargetGenerator.cxx
@@ -869,3 +869,45 @@ cmInstallTargetGenerator::AddRanlibRule(std::ostream& os,
   os << indent << "execute_process(COMMAND \""
  << ranlib << "\" \"" << toDestDirPath << "\")\n";
 }
+
+std::string
+cmInstallTargetGenerator
+::GetTargetNameForUniversalIosInstall(cmInstallType type) const
+{
+  cmMakefile const* mf = this->Target->Targ

[cmake-developers] Patch: install universal iOS libraries

[Ruslan Baratov via cmake-developers]

Hi,

Patches help to install universal iOS (device + simulator) libraries by 
triggering some extra instructions (build + fuse) after "regular" 
library installation finished. This behavior controlled by CMake 
variable CMAKE_IOS_INSTALL_UNIVERSAL_LIBS.


= Example =

> cat CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
project(Foo)

add_library(foo foo.cpp)

install(TARGETS foo DESTINATION lib)

> cat toolchain.cmake
set(CMAKE_MACOSX_BUNDLE YES)
set(CMAKE_OSX_SYSROOT "iphoneos")
set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer")
set(MACOSX_BUNDLE_GUI_IDENTIFIER "com.example")

> rm -rf _builds _install
> cmake -H. -B_builds -GXcode -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake 
-DCMAKE_INSTALL_PREFIX=_install ...


= Current functionality =

Device one arch (default):

> cmake ...
> cmake --build _builds --target install
> lipo -info _install/lib/libfoo.a
Non-fat file: _install/lib/libfoo.a is architecture: armv7

Simulator one arch:

> cmake ...
> cmake --build _builds --target install -- -sdk iphonesimulator
> lipo -info _install/lib/libfoo.a
Non-fat file: _install/lib/libfoo.a is architecture: x86_64

Device multi arch:

> cmake ... -DCMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH=NO
> cmake --build _builds --target install
> lipo -info _install/lib/libfoo.a
Architectures in the fat file: _install/lib/libfoo.a are: armv7 arm64

Simulator multi arch:

> cmake ... -DCMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH=NO
> cmake --build _builds --target install -- -sdk iphonesimulator
> lipo -info _install/lib/libfoo.a
Architectures in the fat file: _install/lib/libfoo.a are: i386 x86_64

= This upgrade =

Device + simulator one arch:

> cmake ... -DCMAKE_IOS_INSTALL_UNIVERSAL_LIBS=YES
> cmake --build _builds --target install
> lipo -info _install/lib/libfoo.a
Architectures in the fat file: _install/lib/libfoo.a are: armv7 x86_64

Device + simulator multi arch:

> cmake ... -DCMAKE_IOS_INSTALL_UNIVERSAL_LIBS=YES 
-DCMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH=NO

> cmake --build _builds --target install
> lipo -info _install/lib/libfoo.a
Architectures in the fat file: _install/lib/libfoo.a are: i386 armv7 
x86_64 arm64


Let me know if this looks acceptable, then I will add documentation part 
and tests.


Thanks, Ruslo
>From 81665dad37f6b102449cd5f36b2ea0a666cf9d68 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov 
Date: Thu, 24 Sep 2015 11:45:44 +0300
Subject: [PATCH 1/3] Get target name for universal iOS library install

Add method GetTargetNameForUniversalIosInstall to cmInstallTargetGenerator.

This method will return target name if:
 * Platform is iOS
 * Target is library
 * CMake variable CMAKE_IOS_INSTALL_UNIVERSAL_LIBS is ON

Otherwise an empty string will be returned.
---
 Source/cmInstallTargetGenerator.cxx | 29 +
 Source/cmInstallTargetGenerator.h   |  5 +
 2 files changed, 34 insertions(+)

diff --git a/Source/cmInstallTargetGenerator.cxx b/Source/cmInstallTargetGenerator.cxx
index 30cf175..db0ed6e 100644
--- a/Source/cmInstallTargetGenerator.cxx
+++ b/Source/cmInstallTargetGenerator.cxx
@@ -869,3 +869,32 @@ cmInstallTargetGenerator::AddRanlibRule(std::ostream& os,
   os << indent << "execute_process(COMMAND \""
  << ranlib << "\" \"" << toDestDirPath << "\")\n";
 }
+
+std::string
+cmInstallTargetGenerator
+::GetTargetNameForUniversalIosInstall(cmInstallType type) const
+{
+  if(!this->Target->Target->GetMakefile()->PlatformIsAppleIos())
+{
+return "";
+}
+
+  switch(type)
+{
+case cmInstallType_STATIC_LIBRARY:
+case cmInstallType_SHARED_LIBRARY:
+case cmInstallType_MODULE_LIBRARY:
+  break;
+default:
+  return "";
+}
+
+  const char* var = "CMAKE_IOS_INSTALL_UNIVERSAL_LIBS";
+  const char* flag = this->Target->Target->GetMakefile()->GetDefinition(var);
+  if (cmSystemTools::IsOff(flag))
+{
+return "";
+}
+
+  return this->Target->GetName();
+}
diff --git a/Source/cmInstallTargetGenerator.h b/Source/cmInstallTargetGenerator.h
index a8f4a75..6335e31 100644
--- a/Source/cmInstallTargetGenerator.h
+++ b/Source/cmInstallTargetGenerator.h
@@ -109,6 +109,11 @@ protected:
   NamelinkModeType NamelinkMode;
   bool ImportLibrary;
   bool Optional;
+
+ private:
+  /** Get target name for installing universal iOS library. If target is not
+  an iOS library or universal build is disabled return empty string. */
+  std::string GetTargetNameForUniversalIosInstall(cmInstallType type) const;
 };
 
 #endif
-- 
1.9.3 (Apple Git-50)

>From 89e8b5aebb1fd8709f3a2bcff5ac77dc3e545a07 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov 
Date: Thu, 24 Sep 2015 12:04:27 +0300
Subject: [PATCH 2/3] CMake module for universal iOS library install

Add CMake module with function `install_universal_ios_library`.
Target name and destination passed to the function. This function will be run
after library installed: will trigger additional build instructions for missing
platform and fuse libraries into 

Re: [cmake-developers] Fixing bug #12506 (iOS install)

[Ruslan Baratov via cmake-developers]

On 26-Aug-15 22:53, Gregor Jasny wrote:

Hallo,

On 13/08/15 12:56, Ruslan Baratov wrote:

On 13-Aug-15 08:46, Gregor Jasny wrote:

On 13/08/15 01:44, Ruslan Baratov via cmake-developers wrote:

Sending patches with fix. Now it's possible to install simulator
libraries by:

   cmake --build _builds --config Release --target install -- -sdk
iphonesimulator

and device libraries by:

   cmake --build _builds --config Release --target install -- -sdk
iphoneos

or from Xcode IDE (build target install).

However this commands will install both libraries to the same location.
This behaviour can be improved by adding some code that will do lipo of
all libraries before install (i.e. universal libraries will be
installed). This can be achieved by using ONLY_ACTIVE_ARCHS=NO while
running Xcode build. The only question is about making install target
depends on two type of builds (-sdk iphonesimulator and -sdk iphoneos).

This was my preliminary work:

https://github.com/gjasny/CMake/commit/978dca25ac387bdec894a1ba2c934317f5f6169f


This looks great! I've spent several hours trying to figure out how
'$(EFFECTIVE_PLATFORM_NAME)' can be set to Xcode and some CMake friendly
string to cmake_install.cmake script. I didn't know Xcode understand
`${VAR}` syntax (probably it didn't, it's just expanded as an
environment variable). I've tested your fix and it works fine for me.
Since we don't need to replace string with path manually I think your
solution is neater. I've added description to commit and rebased it, see
attachment.

I just pushed the fix-ios-install topic including a test. Basically the
patch changes the invocation line of the script from

cmake -DBUILD_TYPE=Release-iphoneos -P cmake_install.cmake

to

cmake -DBUILD_TYPE=Release -DEFFECTIVE_PLATFORM_NAME=-iphoneos -P
cmake_install.cmake

and within the install script

file(INSTALL DESTINATION ${CMAKE_INSTALL_PREFIX}/lib TYPE
STATIC_LIBRARY FILES .../Release/libfoo.a)


to

file(INSTALL DESTINATION ${CMAKE_INSTALL_PREFIX}/lib TYPE
STATIC_LIBRARY FILES .../Release${EFFECTIVE_PLATFORM_NAME}/libfoo.a)


By keeping the ${EFFECTIVE_PLATFORM_NAME} a variable one is able to use
the same install script for iphoneos and iphonesimulator SDKs.

Please review and merge.

Thanks,
Gregor

Works fine for me with rebased version. Though some tests failed:

The following tests FAILED:
   14 - kwsys.testDynamicLoader (Failed)
  372 - RunCMake.FindPkgConfig (Failed)
  392 - FindPackageModeMakefileTest (Failed)

I've tried version without patches (81ad562) and see this failures too, 
so I guess it's not because of iOS fixes.


From my experience changes expected to be in format of `git 
format-patch` command, so attaching them.


Thanks, Ruslo
From daa92aa633809c196380ef544b8a193cfcd15d27 Mon Sep 17 00:00:00 2001
From: Gregor Jasny gja...@googlemail.com
Date: Thu, 20 Aug 2015 22:29:49 +0200
Subject: [PATCH 1/3] Replace CMAKE_XCODE_EFFECTIVE_PLATFORMS with call to
 PlatformIsAppleIos

Currently the CMAKE_XCODE_EFFECTIVE_PLATFORMS property acts only as
a kind of toggle switch to enable iOS project layout features.
But instead of relying on this undocumented property, better detect
the presence of an iOS SDK directly.
---
 Source/cmTarget.cxx| 5 ++---
 Tests/RunCMake/XcodeProject/XcodeBundles.cmake | 1 -
 Tests/iOSNavApp/CMakeLists.txt | 1 -
 3 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 49b3239..da314a6 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -3566,10 +3566,9 @@ bool cmTarget::ComputeOutputDir(const std::string config,
   // The generator may add the configuration's subdirectory.
   if(!conf.empty())
 {
-const char *platforms = this-Makefile-GetDefinition(
-  CMAKE_XCODE_EFFECTIVE_PLATFORMS);
+bool iosPlatform = this-Makefile-PlatformIsAppleIos();
 std::string suffix =
-  usesDefaultOutputDir  platforms ? $(EFFECTIVE_PLATFORM_NAME) : ;
+  usesDefaultOutputDir  iosPlatform ? $(EFFECTIVE_PLATFORM_NAME) : ;
 this-Makefile-GetGlobalGenerator()-
   AppendDirectoryForConfig(/, conf, suffix, out);
 }
diff --git a/Tests/RunCMake/XcodeProject/XcodeBundles.cmake b/Tests/RunCMake/XcodeProject/XcodeBundles.cmake
index d5cb51f..2cbccfa 100644
--- a/Tests/RunCMake/XcodeProject/XcodeBundles.cmake
+++ b/Tests/RunCMake/XcodeProject/XcodeBundles.cmake
@@ -6,7 +6,6 @@ enable_language(C)
 if(TEST_IOS)
   set(CMAKE_OSX_SYSROOT iphoneos)
   set(CMAKE_OSX_ARCHITECTURES armv7)
-  set(CMAKE_XCODE_EFFECTIVE_PLATFORMS -iphoneos;-iphonesimulator)
   set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED NO)
   set(CMAKE_XCODE_ATTRIBUTE_ENABLE_BITCODE NO)
 endif(TEST_IOS)
diff --git a/Tests/iOSNavApp/CMakeLists.txt b/Tests/iOSNavApp/CMakeLists.txt
index 12c3ada..1fc33e0 100644
--- a/Tests/iOSNavApp/CMakeLists.txt
+++ b/Tests/iOSNavApp/CMakeLists.txt
@@ -3,7 +3,6 @@ project(NavApp3)
 
 set(CMAKE_OSX_SYSROOT iphoneos4.3)
 set(CMAKE_OSX_ARCHITECTURES

Re: [cmake-developers] Setting up environment using ExternalProject_Add

[Ruslan Baratov via cmake-developers]

On 11-Aug-15 07:49, James Johnston wrote:

I have found it annoyingly difficult to set up an environment for a build
when using ExternalProject_Add.


I can confirm that there is an additional mess with the environment 
sometimes and not just about setting it (like vcvarsall.bat for Visual 
Studio) but with *un*setting them too. In short environment variables 
for the ExternalProject_Add are not the same as a user's environment. 
I've found myself some problems with Xcode which add tons of new 
variables but there are even cases for Makefiles (e.g. 
stackoverflow.com/questions/25160405/). I will not say it's an 
annoying thing for me but if there will be some mechanism to control 
it (better globally or even something from the box) 
ExternalProject_Add code can be simplified. I'm personally using next 
patterns:


CONFIGURE_COMMAND
@MSVC_VCVARSALL@@MSVC_ARCH@ # Set Visual Studio environment
COMMAND
... # real configure command (like bootstrap.bat or configure.bat)


BUILD_COMMAND
. /path/to/clear-all.sh  make # run make in a clean environment
   INSTALL_COMMAND
   . /path/to/clear-all.sh  make install # same for make install

include(/path/to/clear-all.cmake)
execute_process(COMMAND make @make_params@ ...) # run make in a 
clean environment


Cheers, 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] Fixing bug #12506 (iOS install)

[Ruslan Baratov via cmake-developers]

On 13-Aug-15 08:46, Gregor Jasny wrote:

Hi,

On 13/08/15 01:44, Ruslan Baratov via cmake-developers wrote:

Sending patches with fix. Now it's possible to install simulator
libraries by:

  cmake --build _builds --config Release --target install -- -sdk
iphonesimulator

and device libraries by:

  cmake --build _builds --config Release --target install -- -sdk 
iphoneos


or from Xcode IDE (build target install).

However this commands will install both libraries to the same location.
This behaviour can be improved by adding some code that will do lipo of
all libraries before install (i.e. universal libraries will be
installed). This can be achieved by using ONLY_ACTIVE_ARCHS=NO while
running Xcode build. The only question is about making install target
depends on two type of builds (-sdk iphonesimulator and -sdk iphoneos).


This was my preliminary work:
https://github.com/gjasny/CMake/commit/978dca25ac387bdec894a1ba2c934317f5f6169f 



This looks great! I've spent several hours trying to figure out how 
'$(EFFECTIVE_PLATFORM_NAME)' can be set to Xcode and some CMake friendly 
string to cmake_install.cmake script. I didn't know Xcode understand 
`${VAR}` syntax (probably it didn't, it's just expanded as an 
environment variable). I've tested your fix and it works fine for me. 
Since we don't need to replace string with path manually I think your 
solution is neater. I've added description to commit and rebased it, see 
attachment.


Thanks, Ruslo
From a85eaddb5d1df693606a3c86b754d01a0efcb4e7 Mon Sep 17 00:00:00 2001
From: Gregor Jasny gja...@googlemail.com
Date: Thu, 13 Aug 2015 13:03:02 +0300
Subject: [PATCH] Fix installation of iOS targets

Since cmTarget::ComputeOutputDir results can be used in CMake code of script
cmake_install.cmake and in Xcode internals, string ${EFFECTIVE_PLATFORM_NAME}
should be used instead of $(EFFECTIVE_PLATFORM_NAME) because it works for both.

Value of CMAKE_CFG_INTDIR can't be used in BUILD_TYPE argument of install
command since it contains $(EFFECTIVE_PLATFORM_NAME) (e.g. equals to
`Release-iphoneos`, `Debug-iphoneos`, etc.).

Fix bug: http://public.kitware.com/Bug/view.php?id=12506
---
 Source/cmGlobalGenerator.cxx | 13 -
 Source/cmTarget.cxx  |  2 +-
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index cda26cd..933839c 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -2472,7 +2472,18 @@ void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
 if ( cmakeCfgIntDir  *cmakeCfgIntDir  cmakeCfgIntDir[0] != '.' )
   {
   std::string cfgArg = -DBUILD_TYPE=;
-  cfgArg += mf-GetDefinition(CMAKE_CFG_INTDIR);
+  const char *platforms =
+mf-GetDefinition(CMAKE_XCODE_EFFECTIVE_PLATFORMS);
+  if(platforms)
+{
+cfgArg += $(CONFIGURATION);
+singleLine.push_back(cfgArg);
+cfgArg = -DEFFECTIVE_PLATFORM_NAME=$(EFFECTIVE_PLATFORM_NAME);
+}
+  else
+{
+cfgArg += mf-GetDefinition(CMAKE_CFG_INTDIR);
+}
   singleLine.push_back(cfgArg);
   }
 singleLine.push_back(-P);
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 316d85c..3ac9e8e 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -3536,7 +3536,7 @@ bool cmTarget::ComputeOutputDir(const std::string config,
 const char *platforms = this-Makefile-GetDefinition(
   CMAKE_XCODE_EFFECTIVE_PLATFORMS);
 std::string suffix =
-  usesDefaultOutputDir  platforms ? $(EFFECTIVE_PLATFORM_NAME) : ;
+  usesDefaultOutputDir  platforms ? ${EFFECTIVE_PLATFORM_NAME} : ;
 this-Makefile-GetGlobalGenerator()-
   AppendDirectoryForConfig(/, conf, suffix, out);
 }
-- 
2.4.5

-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] Fixing bug #12506 (iOS install)

[Ruslan Baratov via cmake-developers]

On 07-Aug-15 01:43, Ruslan Baratov via cmake-developers wrote:

Hi,

I'm thinking about fixing bug 
http://public.kitware.com/Bug/view.php?id=12506 and before I go deeper 
in CMake internals just want to ask is there any work-in-progress 
attempts already or hints/directions of how it can be done?


Thanks, Ruslo


Hi,

Sending patches with fix. Now it's possible to install simulator 
libraries by:


 cmake --build _builds --config Release --target install -- -sdk 
iphonesimulator


and device libraries by:

 cmake --build _builds --config Release --target install -- -sdk iphoneos

or from Xcode IDE (build target install).

However this commands will install both libraries to the same location. 
This behaviour can be improved by adding some code that will do lipo of 
all libraries before install (i.e. universal libraries will be 
installed). This can be achieved by using ONLY_ACTIVE_ARCHS=NO while 
running Xcode build. The only question is about making install target 
depends on two type of builds (-sdk iphonesimulator and -sdk iphoneos).


Ruslo
From 17aec9b5ff32f6dcbaced4b38ceeb6ccbe3a8c66 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov ruslan_bara...@yahoo.com
Date: Thu, 13 Aug 2015 02:03:35 +0300
Subject: [PATCH 1/2] Fix EFFECTIVE_PLATFORM_NAME in cmake_install.cmake

$(EFFECTIVE_PLATFORM_NAME) in Xcode will be substituted with
`-iphoneos`/`-iphonesimulator` depending on the currently enabled SDK,
however for cmake_install.cmake script this will not happen and
explicit environment variable should be used.

Working on bug: http://public.kitware.com/Bug/view.php?id=12506
---
 Source/cmInstallTargetGenerator.cxx | 24 
 1 file changed, 24 insertions(+)

diff --git a/Source/cmInstallTargetGenerator.cxx b/Source/cmInstallTargetGenerator.cxx
index 30cf175..6b6808d 100644
--- a/Source/cmInstallTargetGenerator.cxx
+++ b/Source/cmInstallTargetGenerator.cxx
@@ -84,6 +84,30 @@ void cmInstallTargetGenerator::GenerateScriptForConfig(std::ostream os,
 {
 fromDirConfig =
 this-Target-Target-GetDirectory(config, this-ImportLibrary);
+const char *platforms = this-Target-Target-GetMakefile()-GetDefinition(
+CMAKE_XCODE_EFFECTIVE_PLATFORMS);
+
+// Replace $(EFFECTIVE_PLATFORM_NAME) at the end with
+// $ENV{EFFECTIVE_PLATFORM_NAME}.
+//
+// $(EFFECTIVE_PLATFORM_NAME) in Xcode will be substituted with
+// `-iphoneos`/`-iphonesimulator` depending on the currently enabled SDK,
+// however for cmake_install.cmake script this will not happen and
+// explicit environment variable should be used.
+if (platforms)
+  {
+  const std::string oldStr = $(EFFECTIVE_PLATFORM_NAME);
+  const std::string newStr = $ENV{EFFECTIVE_PLATFORM_NAME};
+
+  if (oldStr.size() = fromDirConfig.size())
+{
+const size_t subBegin = fromDirConfig.size() - oldStr.size();
+if (fromDirConfig.compare(subBegin, oldStr.size(), oldStr) == 0)
+  {
+  fromDirConfig.replace(subBegin, oldStr.size(), newStr);
+  }
+}
+  }
 fromDirConfig += /;
 }
   std::string toDir =
-- 
1.9.3 (Apple Git-50)

From 3c031415a3a9d58b7fcb8db7866da96f3c7a534c Mon Sep 17 00:00:00 2001
From: Ruslan Baratov ruslan_bara...@yahoo.com
Date: Thu, 13 Aug 2015 02:06:52 +0300
Subject: [PATCH 2/2] Fix install arguments for iOS

CMAKE_CFG_INTDIR can't be used for the BUILD_TYPE for iOS since it equals
to `Debug-iphoneos`,`Debug-iphonesimulator` etc.

Working on bug: http://public.kitware.com/Bug/view.php?id=12506
---
 Source/cmGlobalGenerator.cxx | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index cda26cd..fb93f5c 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -2471,8 +2471,11 @@ void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
 singleLine.push_back(cmd);
 if ( cmakeCfgIntDir  *cmakeCfgIntDir  cmakeCfgIntDir[0] != '.' )
   {
+  const char *platforms = mf-GetDefinition(
+CMAKE_XCODE_EFFECTIVE_PLATFORMS);
   std::string cfgArg = -DBUILD_TYPE=;
-  cfgArg += mf-GetDefinition(CMAKE_CFG_INTDIR);
+  cfgArg += platforms ? $(CONFIGURATION) :
+mf-GetDefinition(CMAKE_CFG_INTDIR);
   singleLine.push_back(cfgArg);
   }
 singleLine.push_back(-P);
-- 
1.9.3 (Apple Git-50)

-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
http

Re: [cmake-developers] Fixing bug #12506 (iOS install)

[Ruslan Baratov via cmake-developers]

On 07-Aug-15 11:31, Gregor Jasny wrote:

Hi,

On 07/08/15 00:43, Ruslan Baratov via cmake-developers wrote:

Hi,

I'm thinking about fixing bug
http://public.kitware.com/Bug/view.php?id=12506 and before I go deeper
in CMake internals just want to ask is there any work-in-progress
attempts already or hints/directions of how it can be done?


I started to look into this and as far as I remember built a PoC for 
the case where you do not build Simulator and non-Simulator within the 
same Xcode project. But I never found the time to write down a summary 
of that complicated topic.


Currently I work around by calling from my build script:
${CMAKE} -DBUILD_TYPE=${CONFIG} -P ${BUILD_DIR}/cmake_install.cmake

I will try to attach something to the bug report within the next days.

Thanks,
Gregor


Hi,

I've tried it with simple example and have an error:

 rm -rf _builds
 cmake -H. -B_builds -GXcode -DCMAKE_INSTALL_PREFIX=`pwd`/_install
 cmake -DBUILD_TYPE=Debug -P _builds/cmake_install.cmake
-- Install configuration: Debug
CMake Error at _builds/cmake_install.cmake:32 (file):
  file INSTALL cannot find
  /.../_builds/Debug$(EFFECTIVE_PLATFORM_NAME)/libfoo.a.

Executable runs fine on device. Library builds fine too but install step 
fail. See CMakeLists.txt in attachment.


What generator and toolchain are you using?

Ruslo
cmake_minimum_required(VERSION 3.0)
project(Foo)

set(CMAKE_OSX_SYSROOT iphoneos)
set(CMAKE_XCODE_EFFECTIVE_PLATFORMS -iphoneos;-iphonesimulator)

set(CMAKE_MACOSX_BUNDLE YES)
set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY iPhone Developer)

set(MACOSX_BUNDLE_GUI_IDENTIFIER com.example)

add_executable(foo_exe foo.cpp)
add_library(foo foo.cpp)

install(TARGETS foo DESTINATION lib)
-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] Fixing bug #12506 (iOS install)

[Ruslan Baratov via cmake-developers]

Hi,

I'm thinking about fixing bug 
http://public.kitware.com/Bug/view.php?id=12506 and before I go deeper 
in CMake internals just want to ask is there any work-in-progress 
attempts already or hints/directions of how it can be done?


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

Re: [cmake-developers] [MODERN] CMake 3.3 vs Qt 5.5 vs MSVC2015

[Ruslan Baratov via cmake-developers]

On 23-Jul-15 12:32, Konstantin Podsvirov wrote:

Hi dear CMake developers!

Meet modern CMake built on MSVC2015 c QtDialog based on Qt 5.5 from today :-)

Windows 32bit:

http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe

Windows 64bit:

http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe

As always, questions and suggestions are welcome.

--
Regards,
Konstantin Podsvirov
Both versions can't start because dll missing: 
api-ms-win-crt-runtime-l1-1-0.dll

Win 7 x64

Ruslan
--

Powered by www.kitware.com

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

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

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

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

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

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

[Ruslan Baratov via cmake-developers]

On 07-May-15 00:00, Tamás Kenéz wrote:

Hi,

The search path rule #5 reads:


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

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

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

Tamas
Totally agree, since I am a reporter of this bug: 
http://public.kitware.com/Bug/view.php?id=14781
As far as I know it works only for GUI version and only on Windows. So 
does anybody really use such workflow regularly?


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] find_dependency with optional dependencies

[Ruslan Baratov via cmake-developers]

Hi,

I'm trying to figure out what is the best way to use 'find_dependency' 
if dependent package is optional (e.g. can be controlled by some build 
option):


# CMakeLists.txt
option(BOO_WITH_FOO Build Boo with Foo ON)
if(BOO_WITH_FOO)
  find_package(Foo CONFIG REQUIRED)
  target_link_libraries(... PUBLIC Foo::foo)
endif()

1. Use option BOO_WITH_FOO in configure BooConfig.cmake first:

# BooConfig.cmake.in
if(@BOO_WITH_FOO@)
  find_dependency(Foo)
endif()

this approach works fine but it obviously violates do not repeat 
yourself principle and can look quite messy if we have deal with non 
trivial chain of ifs in multiple subdirectories.


2. Use regular 'find_package' with option QUIET

# BooConfig.cmake
find_package(Foo QUIET)

this works fine too, but lead to strange compile time errors instead 
of simple CMake: FooConfig.cmake not found


Since the fact that target Foo::foo is linked is published 
(IMPORTED_LINK_INTERFACE_*) in case BOO_WITH_FOO=ON and not published 
when BOO_WITH_FOO=OFF it seems that we have enough information about 
dependency to figure out that 'find_package(Foo)' not needed if 
BOO_WITH_FOO is OFF. So may be there is a way to improve find_dependency 
behaviour so it will work fine with optional packages? Does it sounds 
reasonable?


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

Re: [cmake-developers] BundleUtilities check exit code

[Ruslan Baratov via cmake-developers]

On 10-Feb-15 19:01, Brad King wrote:

On 02/09/2015 12:17 PM, Ruslan Baratov via cmake-developers wrote:

This patch let do the check that exit code is 0, i.e. install_name_tool
exits successfully.

Applied with minor refactoring:

  BundleUtilities: Teach fixup_bundle to check install_name_tool result
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a27c13f4

Please verify that this version of the change still works for you.

Thanks, version a27c13f4 catches error 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-developers

[cmake-developers] BundleUtilities check exit code

[Ruslan Baratov via cmake-developers]

Hi,

This patch let do the check that exit code is 0, i.e. install_name_tool 
exits successfully.


Ruslan
From 74a52160f7b74907acfcbca91b925ea5589019b7 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov ruslan_bara...@yahoo.com
Date: Mon, 9 Feb 2015 20:09:41 +0300
Subject: [PATCH] fixup_bundle: check execute_process succeed

---
 Modules/BundleUtilities.cmake | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake
index fee0a7c..ad145eb 100644
--- a/Modules/BundleUtilities.cmake
+++ b/Modules/BundleUtilities.cmake
@@ -776,7 +776,18 @@ function(fixup_bundle_item resolved_embedded_item exepath 
dirs)
   # to install_name_tool:
   #
   if(changes)
-execute_process(COMMAND install_name_tool ${changes} 
${resolved_embedded_item})
+execute_process(
+COMMAND install_name_tool ${changes} ${resolved_embedded_item}
+RESULT_VARIABLE install_name_tool_result
+)
+if(NOT install_name_tool_result EQUAL 0)
+  set(msg install_name_tool ${changes} ${resolved_embedded_item})
+  set(oneline )
+  foreach(word ${msg})
+set(oneline ${oneline} ${word})
+  endforeach()
+  message(FATAL_ERROR Command failed: ${oneline})
+endif()
   endif()
 endfunction()
 
-- 
1.9.3 (Apple Git-50)

-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] New command 'file(LOCK_DIRECTORY ...)'

[Ruslan Baratov via cmake-developers]

On 17-Dec-14 21:11, Matthew Woehlke wrote:

On 2014-10-13 10:39, Brad King wrote:

On 10/10/2014 07:45 AM, Ruslan Baratov wrote:

Locking directory is equivalent to locking file `cmake.lock` in
directory /path/to/shared/directory/:

I think this can be activated buy a DIRECTORY option.

Why do we need even that? Can't CMake just test if the lock target is a
directory?
I've used boost.interprocess as a hint for implementation, as far as I 
know boost::interprocess::file_lock is not able to lock directories:
  terminate called after throwing an instance of 
'boost::interprocess::interprocess_exception'

what():  Is a directory

I'm not saying that it's not possible, just trying to use well-known 
cross-platform solution.



p.s. For a lock with no timeout, maybe there can be a built-in timeout
after which CMake displays a message what it's trying to do, so that it
doesn't just hang mysteriously.

You can use `message` command:

message(STATUS Try to lock ${file})
file(LOCK ${file})

or more complex (more user-friendly):

  while(TRUE)
file(LOCK ${file} RESULT is_locked TIMEOUT 5)
if(is_locked)
  message(Locked. ${resource_info})
  break()
endif()
string(TIMESTAMP time_now %S/%M)
message([${time_now}] Lock failed, retry... (file: ${file}))
  endwhile()


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] New command 'file(LOCK_DIRECTORY ...)'

[Ruslan Baratov via cmake-developers]

On 05-Dec-14 17:12, Brad King wrote:

On 12/05/2014 09:10 AM, Ruslan Baratov wrote:

   file: Add LOCK subcommand to do file and directory locking
   http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e6db4c5a


Great, thank you! So will this be applied to cmake 3.1.0?

No, sorry.  The feature deadline for that was almost 2 months ago.
The release candidate period has been pretty drawn out this time :(

-Brad


Okay, just curious what version it will be?

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] New command 'file(LOCK_DIRECTORY ...)'

[Ruslan Baratov via cmake-developers]

On 05-Dec-14 17:09, Brad King wrote:

On 12/05/2014 09:03 AM, Ruslan Baratov wrote:

Actually why not use 'strtoll' and 'long long' ?

I'm not sure that function or type exists portably on some of the
older host platforms we support.  The long type should be plenty
big for timeout values, and there are other strtol call sites that
already use long and could be converted to use a StringToLong
helper too.

Sending patch with 'long'.

Actually for the lock timeout use case would it make sense to change
to a floating point value so timeouts can be more granular?  Some
use cases may not want to block for a whole second between lock
attempts.

What granularity you think is appropriate, 100 ms? 10 ms? (It will be 
value in `cmSystemTools::Delay(...);`)


Ruslo
From 3ed0ad891c6108fa2a03834f9fe109ee5d628847 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov ruslan_bara...@yahoo.com
Date: Fri, 5 Dec 2014 17:18:11 +0300
Subject: [PATCH] Use 'long' for StringToInt

---
 Source/cmFileCommand.cxx   |  6 +++---
 Source/cmFileLock.cxx  |  4 ++--
 Source/cmFileLock.h|  4 ++--
 Source/cmFileLockPool.cxx  |  8 
 Source/cmFileLockPool.h| 10 ++
 Source/cmFileLockUnix.cxx  |  2 +-
 Source/cmFileLockWin32.cxx |  2 +-
 Source/cmSystemTools.cxx   |  7 ---
 Source/cmSystemTools.h |  4 ++--
 9 files changed, 25 insertions(+), 22 deletions(-)

diff --git a/Source/cmFileCommand.cxx b/Source/cmFileCommand.cxx
index a6eb8c4..42cd132 100644
--- a/Source/cmFileCommand.cxx
+++ b/Source/cmFileCommand.cxx
@@ -3521,7 +3521,7 @@ bool cmFileCommand::HandleLockCommand(
   };
   Guard guard = GUARD_PROCESS;
   std::string resultVariable;
-  unsigned timeout = static_castunsigned(-1);
+  unsigned long timeout = static_castunsigned long(-1);
 
   // Parse arguments
   if(args.size()  2)
@@ -3597,7 +3597,7 @@ bool cmFileCommand::HandleLockCommand(
 expected timeout value after TIMEOUT);
 return false;
 }
-  int scanned;
+  long scanned;
   if(!cmSystemTools::StringToInt(args[i].c_str(), scanned) || scanned  0)
 {
 cmOStringStream e;
@@ -3605,7 +3605,7 @@ bool cmFileCommand::HandleLockCommand(
 this-Makefile-IssueMessage(cmake::FATAL_ERROR, e.str());
 return false;
 }
-  timeout = static_castunsigned(scanned);
+  timeout = static_castunsigned long(scanned);
   }
 else
   {
diff --git a/Source/cmFileLock.cxx b/Source/cmFileLock.cxx
index 5f75637..e6aa5f4 100644
--- a/Source/cmFileLock.cxx
+++ b/Source/cmFileLock.cxx
@@ -28,7 +28,7 @@ cmFileLock::~cmFileLock()
 }
 
 cmFileLockResult cmFileLock::Lock(
-const std::string filename, unsigned timeout)
+const std::string filename, unsigned long timeout)
 {
   if (filename.empty())
 {
@@ -48,7 +48,7 @@ cmFileLockResult cmFileLock::Lock(
   cmFileLockResult result = this-OpenFile();
   if (result.IsOk())
 {
-if (timeout == static_castunsigned(-1))
+if (timeout == static_castunsigned long(-1))
   {
   result = this-LockWithoutTimeout();
   }
diff --git a/Source/cmFileLock.h b/Source/cmFileLock.h
index 4d922a0..dd959a7 100644
--- a/Source/cmFileLock.h
+++ b/Source/cmFileLock.h
@@ -37,7 +37,7 @@ class cmFileLock
 * @brief Lock the file.
 * @param timeoutSec Lock timeout. If -1 try until success or fatal error.
 */
-  cmFileLockResult Lock(const std::string filename, unsigned timeoutSec);
+  cmFileLockResult Lock(const std::string filename, unsigned long timeoutSec);
 
   /**
 * @brief Unlock the file.
@@ -57,7 +57,7 @@ class cmFileLock
 
   cmFileLockResult OpenFile();
   cmFileLockResult LockWithoutTimeout();
-  cmFileLockResult LockWithTimeout(unsigned timeoutSec);
+  cmFileLockResult LockWithTimeout(unsigned long timeoutSec);
 
 #if defined(_WIN32)
   typedef HANDLE FileId;
diff --git a/Source/cmFileLockPool.cxx b/Source/cmFileLockPool.cxx
index e84e71a..551a75a 100644
--- a/Source/cmFileLockPool.cxx
+++ b/Source/cmFileLockPool.cxx
@@ -60,7 +60,7 @@ void cmFileLockPool::PopFileScope()
 }
 
 cmFileLockResult cmFileLockPool::LockFunctionScope(
-const std::string filename, unsigned timeoutSec)
+const std::string filename, unsigned long timeoutSec)
 {
   if (this-IsAlreadyLocked(filename))
 {
@@ -74,7 +74,7 @@ cmFileLockResult cmFileLockPool::LockFunctionScope(
 }
 
 cmFileLockResult cmFileLockPool::LockFileScope(
-const std::string filename, unsigned timeoutSec)
+const std::string filename, unsigned long timeoutSec)
 {
   if (this-IsAlreadyLocked(filename))
 {
@@ -85,7 +85,7 @@ cmFileLockResult cmFileLockPool::LockFileScope(
 }
 
 cmFileLockResult cmFileLockPool::LockProcessScope(
-const std::string filename, unsigned timeoutSec)
+const std::string filename, unsigned long timeoutSec)
 {
   if (this-IsAlreadyLocked(filename))
 {
@@ -155,7 +155,7 @@ cmFileLockPool::ScopePool::~ScopePool()
 }
 
 cmFileLockResult cmFileLockPool::ScopePool::Lock(
-const std::string filename, unsigned 

Re: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)'

[Ruslan Baratov via cmake-developers]

On 25-Nov-14 21:29, Brad King wrote:

* The background.(bat|sh) files need to have quoting to work with
   spaces in the path.  Please try running tests with a source/build
   tree with spaces.

* Instead of background scripts, can you have a parent process take
   a lock, run a child with a timed out lock, and then release the
   lock?

Test updated, no need to use 'background.*' scripts indeed.

* The error messages currently use SetError(...); return false;.
   That is why you need the :  to get the prompt.  Instead you can
   use IssueMessage as shown in the hunk below for one example.

's,SetError,IssueMessage,g' done
I'm not quite sure about when do I need to use 'return false'/'return 
true', so I leave 'return false' everywhere.



* Please use shorter timeouts in the test if possible to make it run
   faster.  If they become spurious/problematic then we can lengthen
   them later.

* ... Then the timeout can be just 0.1s in the child and there
   is no race.

I've set timeout to 1 sec (minimal unsigned integer).

Ruslo.
From 6b874aa940a86f9a789cfae23a8c47d609587d61 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov ruslan_bara...@yahoo.com
Date: Wed, 26 Nov 2014 01:45:26 +0300
Subject: [PATCH 1/7] Add function cmSystemTools::StringToInt

---
 Source/cmSystemTools.cxx | 7 +++
 Source/cmSystemTools.h   | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index baac7b8..e247481 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -2923,3 +2923,10 @@ std::vectorstd::string cmSystemTools::tokenize(const 
std::string str,
 }
   return tokens;
 }
+
+//
+bool cmSystemTools::StringToInt(const char* str, int* value) {
+  char unused;
+  const int result = sscanf(str, %d%c, value, unused);
+  return (result == 1);
+}
diff --git a/Source/cmSystemTools.h b/Source/cmSystemTools.h
index 4455dd1..763389b 100644
--- a/Source/cmSystemTools.h
+++ b/Source/cmSystemTools.h
@@ -458,6 +458,9 @@ public:
   static std::vectorstd::string tokenize(const std::string str,
const std::string sep);
 
+  /** Convert string to int. Expected that the whole string is an integer */
+  static bool StringToInt(const char* str, int* value);
+
 #ifdef _WIN32
   struct WindowsFileRetry
   {
-- 
2.1.1

From 569bc681c0a980b87cd94184cfb83b44122d92a0 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov ruslan_bara...@yahoo.com
Date: Wed, 26 Nov 2014 01:46:14 +0300
Subject: [PATCH 2/7] Add class cmFileLockResult

---
 Source/cmFileLockResult.cxx | 111 
 Source/cmFileLockResult.h   |  85 +
 2 files changed, 196 insertions(+)
 create mode 100644 Source/cmFileLockResult.cxx
 create mode 100644 Source/cmFileLockResult.h

diff --git a/Source/cmFileLockResult.cxx b/Source/cmFileLockResult.cxx
new file mode 100644
index 000..045e7ee
--- /dev/null
+++ b/Source/cmFileLockResult.cxx
@@ -0,0 +1,111 @@
+/*
+  CMake - Cross Platform Makefile Generator
+  Copyright 2014 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.
+*/
+
+#include cmFileLockResult.h
+
+#include errno.h
+
+cmFileLockResult cmFileLockResult::MakeOk()
+{
+  return cmFileLockResult(OK, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeSystem()
+{
+#if defined(_WIN32)
+  const Error lastError = GetLastError();
+#else
+  const Error lastError = errno;
+#endif
+  return cmFileLockResult(SYSTEM, lastError);
+}
+
+cmFileLockResult cmFileLockResult::MakeTimeout()
+{
+  return cmFileLockResult(TIMEOUT, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeAlreadyLocked()
+{
+  return cmFileLockResult(ALREADY_LOCKED, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeInternal()
+{
+  return cmFileLockResult(INTERNAL, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeNoFunction()
+{
+  return cmFileLockResult(NO_FUNCTION, 0);
+}
+
+bool cmFileLockResult::IsOk() const
+{
+  return this-Type == OK;
+}
+
+std::string cmFileLockResult::GetOutputMessage() const
+{
+  switch (this-Type)
+{
+case OK:
+  return 0;
+case SYSTEM:
+#if defined(_WIN32)
+  {
+  char* errorText = NULL;
+
+  // http://stackoverflow.com/a/455533/2288008
+  DWORD flags = FORMAT_MESSAGE_FROM_SYSTEM |
+  FORMAT_MESSAGE_ALLOCATE_BUFFER |
+  FORMAT_MESSAGE_IGNORE_INSERTS;
+  ::FormatMessageA(
+  flags,
+  NULL,
+  this-ErrorValue,
+  MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
+ 

Re: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)'

[Ruslan Baratov via cmake-developers]

On 17-Nov-14 18:06, Brad King wrote:

Yes, please change to that so a proper error can be produced for the new
API when 123xyz is given as a timeout, for example.

Function added cmSystemTools::StringToInt


Please look at adding a case to the test suite for this.  An outer
process could take the lock and then execute_process a child that
tries to take the lock with a timeout.  Then check that it fails
as expected.

Done

Ruslo
From 9a3e5728173d2b5e4381d3c65556534298f7bb27 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov ruslan_bara...@yahoo.com
Date: Tue, 18 Nov 2014 02:32:27 +0300
Subject: [PATCH 1/7] Add function cmSystemTools::StringToInt

---
 Source/cmSystemTools.cxx | 7 +++
 Source/cmSystemTools.h   | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index 3247f7f..9664983 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -2925,3 +2925,10 @@ std::vectorstd::string cmSystemTools::tokenize(const 
std::string str,
 }
   return tokens;
 }
+
+//
+bool cmSystemTools::StringToInt(const char* str, int* value) {
+  char unused;
+  const int result = sscanf(str, %d%c, value, unused);
+  return (result == 1);
+}
diff --git a/Source/cmSystemTools.h b/Source/cmSystemTools.h
index 4455dd1..763389b 100644
--- a/Source/cmSystemTools.h
+++ b/Source/cmSystemTools.h
@@ -458,6 +458,9 @@ public:
   static std::vectorstd::string tokenize(const std::string str,
const std::string sep);
 
+  /** Convert string to int. Expected that the whole string is an integer */
+  static bool StringToInt(const char* str, int* value);
+
 #ifdef _WIN32
   struct WindowsFileRetry
   {
-- 
2.1.1

From 9e7e463d51a8944c8951540114e0e34824a239f5 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov ruslan_bara...@yahoo.com
Date: Tue, 18 Nov 2014 02:33:46 +0300
Subject: [PATCH 2/7] Add class cmFileLockResult

---
 Source/cmFileLockResult.cxx | 111 
 Source/cmFileLockResult.h   |  85 +
 2 files changed, 196 insertions(+)
 create mode 100644 Source/cmFileLockResult.cxx
 create mode 100644 Source/cmFileLockResult.h

diff --git a/Source/cmFileLockResult.cxx b/Source/cmFileLockResult.cxx
new file mode 100644
index 000..045e7ee
--- /dev/null
+++ b/Source/cmFileLockResult.cxx
@@ -0,0 +1,111 @@
+/*
+  CMake - Cross Platform Makefile Generator
+  Copyright 2014 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.
+*/
+
+#include cmFileLockResult.h
+
+#include errno.h
+
+cmFileLockResult cmFileLockResult::MakeOk()
+{
+  return cmFileLockResult(OK, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeSystem()
+{
+#if defined(_WIN32)
+  const Error lastError = GetLastError();
+#else
+  const Error lastError = errno;
+#endif
+  return cmFileLockResult(SYSTEM, lastError);
+}
+
+cmFileLockResult cmFileLockResult::MakeTimeout()
+{
+  return cmFileLockResult(TIMEOUT, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeAlreadyLocked()
+{
+  return cmFileLockResult(ALREADY_LOCKED, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeInternal()
+{
+  return cmFileLockResult(INTERNAL, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeNoFunction()
+{
+  return cmFileLockResult(NO_FUNCTION, 0);
+}
+
+bool cmFileLockResult::IsOk() const
+{
+  return this-Type == OK;
+}
+
+std::string cmFileLockResult::GetOutputMessage() const
+{
+  switch (this-Type)
+{
+case OK:
+  return 0;
+case SYSTEM:
+#if defined(_WIN32)
+  {
+  char* errorText = NULL;
+
+  // http://stackoverflow.com/a/455533/2288008
+  DWORD flags = FORMAT_MESSAGE_FROM_SYSTEM |
+  FORMAT_MESSAGE_ALLOCATE_BUFFER |
+  FORMAT_MESSAGE_IGNORE_INSERTS;
+  ::FormatMessageA(
+  flags,
+  NULL,
+  this-ErrorValue,
+  MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
+  (LPSTR)errorText,
+  0,
+  NULL
+  );
+
+  if (errorText != NULL)
+{
+const std::string message = errorText;
+::LocalFree(errorText);
+return message;
+}
+  else
+{
+return Internal error (FormatMessageA failed);
+}
+  }
+#else
+  return strerror(this-ErrorValue);
+#endif
+case TIMEOUT:
+  return Timeout reached;
+case ALREADY_LOCKED:
+  return File already locked;
+case NO_FUNCTION:
+  return 'GUARD FUNCTION' not used in function definition;
+case INTERNAL:
+

Re: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)'

[Ruslan Baratov via cmake-developers]

ConvertToWindowsExtendedPath fix + tests

From e994378d61e64136043d9db614762e79927766cb Mon Sep 17 00:00:00 2001
From: Ruslan Baratov ruslan_bara...@yahoo.com
Date: Fri, 14 Nov 2014 21:09:35 +0400
Subject: [PATCH 1/6] Add class cmFileLockResult

---
 Source/cmFileLockResult.cxx | 111 
 Source/cmFileLockResult.h   |  85 +
 2 files changed, 196 insertions(+)
 create mode 100644 Source/cmFileLockResult.cxx
 create mode 100644 Source/cmFileLockResult.h

diff --git a/Source/cmFileLockResult.cxx b/Source/cmFileLockResult.cxx
new file mode 100644
index 000..045e7ee
--- /dev/null
+++ b/Source/cmFileLockResult.cxx
@@ -0,0 +1,111 @@
+/*
+  CMake - Cross Platform Makefile Generator
+  Copyright 2014 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.
+*/
+
+#include cmFileLockResult.h
+
+#include errno.h
+
+cmFileLockResult cmFileLockResult::MakeOk()
+{
+  return cmFileLockResult(OK, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeSystem()
+{
+#if defined(_WIN32)
+  const Error lastError = GetLastError();
+#else
+  const Error lastError = errno;
+#endif
+  return cmFileLockResult(SYSTEM, lastError);
+}
+
+cmFileLockResult cmFileLockResult::MakeTimeout()
+{
+  return cmFileLockResult(TIMEOUT, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeAlreadyLocked()
+{
+  return cmFileLockResult(ALREADY_LOCKED, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeInternal()
+{
+  return cmFileLockResult(INTERNAL, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeNoFunction()
+{
+  return cmFileLockResult(NO_FUNCTION, 0);
+}
+
+bool cmFileLockResult::IsOk() const
+{
+  return this-Type == OK;
+}
+
+std::string cmFileLockResult::GetOutputMessage() const
+{
+  switch (this-Type)
+{
+case OK:
+  return 0;
+case SYSTEM:
+#if defined(_WIN32)
+  {
+  char* errorText = NULL;
+
+  // http://stackoverflow.com/a/455533/2288008
+  DWORD flags = FORMAT_MESSAGE_FROM_SYSTEM |
+  FORMAT_MESSAGE_ALLOCATE_BUFFER |
+  FORMAT_MESSAGE_IGNORE_INSERTS;
+  ::FormatMessageA(
+  flags,
+  NULL,
+  this-ErrorValue,
+  MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
+  (LPSTR)errorText,
+  0,
+  NULL
+  );
+
+  if (errorText != NULL)
+{
+const std::string message = errorText;
+::LocalFree(errorText);
+return message;
+}
+  else
+{
+return Internal error (FormatMessageA failed);
+}
+  }
+#else
+  return strerror(this-ErrorValue);
+#endif
+case TIMEOUT:
+  return Timeout reached;
+case ALREADY_LOCKED:
+  return File already locked;
+case NO_FUNCTION:
+  return 'GUARD FUNCTION' not used in function definition;
+case INTERNAL:
+default:
+  return Internal error;
+}
+}
+
+cmFileLockResult::cmFileLockResult(ErrorType typeValue, Error errorValue):
+Type(typeValue), ErrorValue(errorValue)
+{
+}
diff --git a/Source/cmFileLockResult.h b/Source/cmFileLockResult.h
new file mode 100644
index 000..531fb49
--- /dev/null
+++ b/Source/cmFileLockResult.h
@@ -0,0 +1,85 @@
+/*
+  CMake - Cross Platform Makefile Generator
+  Copyright 2014 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.
+*/
+
+#ifndef cmFileLockResult_h
+#define cmFileLockResult_h
+
+#include cmStandardIncludes.h
+
+#if defined(_WIN32)
+# include windows.h // DWORD
+#endif
+
+/**
+  * @brief Result of the locking/unlocking file.
+  * @note See @c cmFileLock
+  */
+class cmFileLockResult
+{
+ public:
+#if defined(_WIN32)
+  typedef DWORD Error;
+#else
+  typedef int Error;
+#endif
+
+  /**
+* @brief Successful lock/unlock.
+*/
+  static cmFileLockResult MakeOk();
+
+  /**
+* @brief Lock/Unlock failed. Read error/GetLastError.
+*/
+  static cmFileLockResult MakeSystem();
+
+  /**
+* @brief Lock/Unlock failed. Timeout reached.
+*/
+  static cmFileLockResult MakeTimeout();
+
+  /**
+* @brief File already locked.
+*/
+  static cmFileLockResult MakeAlreadyLocked();
+
+  /**
+* @brief Internal error.
+*/
+  static cmFileLockResult 

Re: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)'

[Ruslan Baratov via cmake-developers]

On 14-Nov-14 22:58, Brad King wrote:

- Please add more test cases covering all the file(LOCK)
   argument processing error messages.
Done. Also I've found parse issue which is based on `sscanf` behaviour, 
e.g. string '123xyz' will be successfully parsed as a integer (%d). Same 
issue for example in file(STRINGS) command:


 cat script.cmake
set(tmp ${CMAKE_CURRENT_LIST_DIR}/temp-file)
file(WRITE ${tmp} qwertyuiopasdfghjklzxcvbnm)
file(STRINGS ${tmp} result LIMIT_INPUT 7)
message(result(1): ${result})
file(STRINGS ${tmp} result LIMIT_INPUT 7abc) # expected error message
message(result(2): ${result})
 cmake -P script.cmake
result(1): qwertyu
result(2): qwertyu



- Please squash in the attached patch to your commit that
   adds the file(LOCK) command to CMake.  We should not need
   to build it during bootstrap.

- Instead of ::sleep you can use cmSystemTools::Delay()

Done


- We need to test whether failing to lock after a timeout
   actually works.  I tried adding a line to
   Tests/RunCMake/file/LOCK.cmake:

file(LOCK ${lfile} TIMEOUT 3)

   at the end of the file, duplicating the one before it.
   I expected to see a 3 second delay followed by a lock
   failure.  Instead it fails immediately.  Is that expected?
Yes, since we know that we already own the lock nothing will change 
after timeout - it still be locked by us.


On linux you can test timeout by:
 cat script.cmake
file(LOCK ${CMAKE_CURRENT_LIST_DIR}/file-to-lock TIMEOUT 5)
execute_process(COMMAND ${CMAKE_COMMAND} -E sleep 10)
 cmake -P script.cmake  # start one instance in background
 cmake -P script.cmake # start second instance, expected lock failed 
by timeout

CMake Error at script.cmake:1 (file):
  file : error locking file
  /.../file-to-lock (Timeout
  reached).

Ruslo
From aa6418cd5a9bad2dfa26aae657d354d02cc39d20 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov ruslan_bara...@yahoo.com
Date: Sat, 15 Nov 2014 02:10:45 +0300
Subject: [PATCH 1/6] Add class cmFileLockResult

---
 Source/cmFileLockResult.cxx | 111 
 Source/cmFileLockResult.h   |  85 +
 2 files changed, 196 insertions(+)
 create mode 100644 Source/cmFileLockResult.cxx
 create mode 100644 Source/cmFileLockResult.h

diff --git a/Source/cmFileLockResult.cxx b/Source/cmFileLockResult.cxx
new file mode 100644
index 000..045e7ee
--- /dev/null
+++ b/Source/cmFileLockResult.cxx
@@ -0,0 +1,111 @@
+/*
+  CMake - Cross Platform Makefile Generator
+  Copyright 2014 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.
+*/
+
+#include cmFileLockResult.h
+
+#include errno.h
+
+cmFileLockResult cmFileLockResult::MakeOk()
+{
+  return cmFileLockResult(OK, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeSystem()
+{
+#if defined(_WIN32)
+  const Error lastError = GetLastError();
+#else
+  const Error lastError = errno;
+#endif
+  return cmFileLockResult(SYSTEM, lastError);
+}
+
+cmFileLockResult cmFileLockResult::MakeTimeout()
+{
+  return cmFileLockResult(TIMEOUT, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeAlreadyLocked()
+{
+  return cmFileLockResult(ALREADY_LOCKED, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeInternal()
+{
+  return cmFileLockResult(INTERNAL, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeNoFunction()
+{
+  return cmFileLockResult(NO_FUNCTION, 0);
+}
+
+bool cmFileLockResult::IsOk() const
+{
+  return this-Type == OK;
+}
+
+std::string cmFileLockResult::GetOutputMessage() const
+{
+  switch (this-Type)
+{
+case OK:
+  return 0;
+case SYSTEM:
+#if defined(_WIN32)
+  {
+  char* errorText = NULL;
+
+  // http://stackoverflow.com/a/455533/2288008
+  DWORD flags = FORMAT_MESSAGE_FROM_SYSTEM |
+  FORMAT_MESSAGE_ALLOCATE_BUFFER |
+  FORMAT_MESSAGE_IGNORE_INSERTS;
+  ::FormatMessageA(
+  flags,
+  NULL,
+  this-ErrorValue,
+  MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
+  (LPSTR)errorText,
+  0,
+  NULL
+  );
+
+  if (errorText != NULL)
+{
+const std::string message = errorText;
+::LocalFree(errorText);
+return message;
+}
+  else
+{
+return Internal error (FormatMessageA failed);
+}
+  }
+#else
+  return strerror(this-ErrorValue);
+#endif
+case TIMEOUT:
+  return Timeout reached;
+case ALREADY_LOCKED:
+  return File already locked;
+case NO_FUNCTION:
+  return 'GUARD FUNCTION' not used in function definition;
+case INTERNAL:
+default:
+  return 

Re: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)'

[Ruslan Baratov via cmake-developers]

On 11-Nov-14 21:28, Brad King wrote:

* All headers and sources need to include cmStandardIncludes.h first,
   directly or indirectly through other headers.  It can affect the
   way certain standard library headers are preprocessed on some
   platforms, and needs to be consistent across all translation units.

* Please add the .cxx files to 'bootstrap' and Source/CMakeLists.txt
   rather than including them in cmBootstrapCommands*.cxx.

* The windows header should be included in lower case windows.h.

* The cerrno and cstdio headers need to be just errno.h and stdio.h
   to work on some of the older compilers.

* Please add documentation to Help/command/file.rst and anywhere else
   that is appropriate.

Done


* Please add test cases for all APIs and error cases, probably in
   Tests/RunCMake/file using the RunCMake infrastructure.
I added test LOCK.cmake but not quite understand how to execute it. Is 
it possible to run tests only from 'Tests/RunCMake/file' directory?


By the way I got the following error (Visual Studio 2013) if I include 
'cmFileLockResult.h' before 'cm_curl.h' in file 'cmFileCommand.cxx':


C:\Program Files (x86)\Windows Kits\8.1\Include\shared\ws2ipdef.h(202): 
error C2079: '_SOCKADDR_INET::Ipv4' uses undefined struct 'sockaddr_in'
C:\Program Files (x86)\Windows Kits\8.1\Include\shared\ws2ipdef.h(715): 
error C2011: 'ip_mreq' : 'struct' type redefinition
  C:\Program Files (x86)\Windows 
Kits\8.1\Include\um\winsock.h(355) : see declaration of 'ip_mreq'
C:\Program Files (x86)\Windows Kits\8.1\Include\um\ws2tcpip.h(696): 
error C3861: 'WSASetLastError': identifier not found
C:\Program Files (x86)\Windows Kits\8.1\Include\um\ws2tcpip.h(703): 
error C3861: 'WSASetLastError': identifier not found
C:\Program Files (x86)\Windows Kits\8.1\Include\um\ws2tcpip.h(742): 
error C3861: 'WSASetLastError': identifier not found
C:\Program Files (x86)\Windows Kits\8.1\Include\um\ws2tcpip.h(749): 
error C3861: 'WSASetLastError': identifier not found
C:\Program Files (x86)\Windows Kits\8.1\Include\um\ws2tcpip.h(793): 
error C3861: 'WSASetLastError': identifier not found
C:\Program Files (x86)\Windows Kits\8.1\Include\um\ws2tcpip.h(800): 
error C3861: 'WSASetLastError': identifier not found
C:\Program Files (x86)\Windows Kits\8.1\Include\um\ws2tcpip.h(841): 
error C3861: 'WSASetLastError': identifier not found
C:\Program Files (x86)\Windows Kits\8.1\Include\um\ws2tcpip.h(848): 
error C3861: 'WSASetLastError': identifier not found
...\cmake\Utilities\cmcurl/include/curl/curl.h(337): error C2079: 
'curl_sockaddr::addr' uses undefined struct 'sockaddr'


Compiles fine if 'cmFileLockResult.h' placed after 'cm_curl.h'.

Ruslo
From 55514802c135595e658f1897c123c0daf291ae81 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov ruslan_bara...@yahoo.com
Date: Thu, 13 Nov 2014 17:35:36 +0400
Subject: [PATCH 1/5] Add class cmFileLockResult

---
 Source/cmFileLockResult.cxx | 111 
 Source/cmFileLockResult.h   |  85 +
 2 files changed, 196 insertions(+)
 create mode 100644 Source/cmFileLockResult.cxx
 create mode 100644 Source/cmFileLockResult.h

diff --git a/Source/cmFileLockResult.cxx b/Source/cmFileLockResult.cxx
new file mode 100644
index 000..045e7ee
--- /dev/null
+++ b/Source/cmFileLockResult.cxx
@@ -0,0 +1,111 @@
+/*
+  CMake - Cross Platform Makefile Generator
+  Copyright 2014 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.
+*/
+
+#include cmFileLockResult.h
+
+#include errno.h
+
+cmFileLockResult cmFileLockResult::MakeOk()
+{
+  return cmFileLockResult(OK, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeSystem()
+{
+#if defined(_WIN32)
+  const Error lastError = GetLastError();
+#else
+  const Error lastError = errno;
+#endif
+  return cmFileLockResult(SYSTEM, lastError);
+}
+
+cmFileLockResult cmFileLockResult::MakeTimeout()
+{
+  return cmFileLockResult(TIMEOUT, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeAlreadyLocked()
+{
+  return cmFileLockResult(ALREADY_LOCKED, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeInternal()
+{
+  return cmFileLockResult(INTERNAL, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeNoFunction()
+{
+  return cmFileLockResult(NO_FUNCTION, 0);
+}
+
+bool cmFileLockResult::IsOk() const
+{
+  return this-Type == OK;
+}
+
+std::string cmFileLockResult::GetOutputMessage() const
+{
+  switch (this-Type)
+{
+case OK:
+  return 0;
+case SYSTEM:
+#if defined(_WIN32)
+  {
+  char* errorText = NULL;
+
+  // http://stackoverflow.com/a/455533/2288008
+ 

Re: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)'

[Ruslan Baratov via cmake-developers]

Done

On 31-Oct-14 16:39, Brad King wrote:

On 10/31/2014 09:07 AM, Ruslan Baratov wrote:

Does anybody ready to implement it or you want me to send the patches?

Please work on the patches.  You can use git format-patch to format
them and post here either inline or as attachments.

Thanks,
-Brad



From b235db704545bee59952c491c14a7eb4a5bdcde6 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov ruslan_bara...@yahoo.com
Date: Fri, 7 Nov 2014 17:22:48 +0400
Subject: [PATCH 1/4] Add class cmFileLockResult

---
 Source/cmFileLockResult.cxx | 102 
 Source/cmFileLockResult.h   |  77 +
 2 files changed, 179 insertions(+)
 create mode 100644 Source/cmFileLockResult.cxx
 create mode 100644 Source/cmFileLockResult.h

diff --git a/Source/cmFileLockResult.cxx b/Source/cmFileLockResult.cxx
new file mode 100644
index 000..d6cb16e
--- /dev/null
+++ b/Source/cmFileLockResult.cxx
@@ -0,0 +1,102 @@
+/*
+  CMake - Cross Platform Makefile Generator
+  Copyright 2014 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.
+*/
+
+#include cmFileLockResult.h
+
+cmFileLockResult cmFileLockResult::MakeOk()
+{
+  return cmFileLockResult(OK, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeSystem()
+{
+#if defined(_WIN32)
+  const Error lastError = GetLastError();
+#else
+  const Error lastError = errno;
+#endif
+  return cmFileLockResult(SYSTEM, lastError);
+}
+
+cmFileLockResult cmFileLockResult::MakeTimeout()
+{
+  return cmFileLockResult(TIMEOUT, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeAlreadyLocked()
+{
+  return cmFileLockResult(ALREADY_LOCKED, 0);
+}
+
+cmFileLockResult cmFileLockResult::MakeInternal()
+{
+  return cmFileLockResult(INTERNAL, 0);
+}
+
+bool cmFileLockResult::IsOk() const
+{
+  return this-Type == OK;
+}
+
+std::string cmFileLockResult::GetOutputMessage() const
+{
+  switch (this-Type)
+{
+case OK:
+  return 0;
+case SYSTEM:
+#if defined(_WIN32)
+  {
+  char* errorText = NULL;
+
+  // http://stackoverflow.com/a/455533/2288008
+  DWORD flags = FORMAT_MESSAGE_FROM_SYSTEM |
+  FORMAT_MESSAGE_ALLOCATE_BUFFER |
+  FORMAT_MESSAGE_IGNORE_INSERTS;
+  ::FormatMessageA(
+  flags,
+  NULL,
+  this-ErrorValue,
+  MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
+  (LPSTR)errorText,
+  0,
+  NULL
+  );
+
+  if (errorText != NULL)
+{
+const std::string message = errorText;
+::LocalFree(errorText);
+return message;
+}
+  else
+{
+return Internal error (FormatMessageA failed);
+}
+  }
+#else
+  return strerror(this-ErrorValue);
+#endif
+case TIMEOUT:
+  return Timeout reached;
+case ALREADY_LOCKED:
+  return File already locked;
+case INTERNAL:
+default:
+  return Internal error;
+}
+}
+
+cmFileLockResult::cmFileLockResult(ErrorType typeValue, Error errorValue):
+Type(typeValue), ErrorValue(errorValue)
+{
+}
diff --git a/Source/cmFileLockResult.h b/Source/cmFileLockResult.h
new file mode 100644
index 000..4d8f794
--- /dev/null
+++ b/Source/cmFileLockResult.h
@@ -0,0 +1,77 @@
+/*
+  CMake - Cross Platform Makefile Generator
+  Copyright 2014 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.
+*/
+
+#ifndef cmFileLockResult_h
+#define cmFileLockResult_h
+
+#if defined(_WIN32)
+# include Windows.h // DWORD
+#endif
+
+/**
+  * @brief Result of the locking/unlocking file.
+  * @note See @c cmFileLock
+  */
+class cmFileLockResult
+{
+ public:
+#if defined(_WIN32)
+  typedef DWORD Error;
+#else
+  typedef int Error;
+#endif
+
+  /**
+* @brief Successful lock/unlock.
+*/
+  static cmFileLockResult MakeOk();
+
+  /**
+* @brief Lock/Unlock failed. Read error/GetLastError.
+*/
+  static cmFileLockResult MakeSystem();
+
+  /**
+* @brief Lock/Unlock failed. Timeout reached.
+*/
+  static cmFileLockResult MakeTimeout();
+
+  /**
+* @brief File already locked.
+*/
+  static cmFileLockResult MakeAlreadyLocked();
+
+  /**
+* @brief Internal error.
+*/
+  static 

Re: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)'

[Ruslan Baratov via cmake-developers]

Does anybody ready to implement it or you want me to send the patches?

Ruslo

On 29-Oct-14 16:48, Brad King wrote:

On 10/28/2014 04:28 PM, Ruslan Baratov wrote:

What do you think about this:

Thanks for drafting the signature.


file(
  LOCK path
  [DIRECTORY] # if present locked file will be path/cmake.lock
(instead of path)
  [RELEASE] # do explicit unlock
  [GUARD FUNCTION|FILE|PROCESS] # if not present - set to `GUARD
PROCESS` (not used if RELEASE)
  [RESULT_VARIABLE variable] # 0 on success, error message
otherwise; if not present - any error is FATAL_ERROR
  [TIMEOUT seconds]
  # 0 - return immediately if operation failed (try_lock),
otherwise timeout (timed_lock);
  # if not present - lock until success (or error);
  # not used if RELEASE;
)

That looks good.  The TIMEOUT unit can be 'seconds' but it should
accept a floating point value to get shorter times if possible.


Boost implementation of file locking mechanism use
LockFileEx/UnlockFileEx for windows and fcntl for unix-like platforms.
These functions lock file only for current process. When process crashes
lock removed by OS automatically.

Great!


I've tried (Un)LockFileEx/fcntl on windows (including mingw and cygwin),
linux and mac - works fine for me with one exception: cygwin's lock is
not visible by win32's lock. I.e. you can synchronize multiple cygwin
processes and multiple windows normal processes, but you can't mix them.

Thanks for testing.  The windows/cygwin mixing limitation is acceptable
IMO.

Thanks,
-Brad



--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)'

[Ruslan Baratov via cmake-developers]

On 13-Oct-14 18:39, Brad King wrote:

With all the above in mind, please brainstorm and propose a more complete
signature set.  You can use the keyword/value pairing common in other
commands to avoid needing a positional argument for every value.

What do you think about this:

file(
LOCK path
[DIRECTORY] # if present locked file will be path/cmake.lock 
(instead of path)

[RELEASE] # do explicit unlock
[GUARD FUNCTION|FILE|PROCESS] # if not present - set to `GUARD 
PROCESS` (not used if RELEASE)
[RESULT_VARIABLE variable] # 0 on success, error message 
otherwise; if not present - any error is FATAL_ERROR

[TIMEOUT seconds]
# 0 - return immediately if operation failed (try_lock), 
otherwise timeout (timed_lock);

# if not present - lock until success (or error);
# not used if RELEASE;
)

?

On 13-Oct-14 18:39, Brad King wrote:

Also, please post a summary of how the implementation will work on each
platform.
Boost implementation of file locking mechanism use 
LockFileEx/UnlockFileEx for windows and fcntl for unix-like platforms.
These functions lock file only for current process. When process crashes 
lock removed by OS automatically.
In terms of boost documentation `file(LOCK ...)` locks are exclusive and 
advisory.


boost.interprocess:
http://www.boost.org/doc/libs/1_56_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.file_lock
LockFileEx:
http://msdn.microsoft.com/library/windows/desktop/aa365203%28v=vs.85%29.aspx
UnlockFileEx:
http://msdn.microsoft.com/library/windows/desktop/aa365716%28v=vs.85%29.aspx
fcntl (linux):
  http://linux.die.net/man/2/fcntl
fcntl (mac):
https://developer.apple.com/library/Mac/documentation/Darwin/Reference/ManPages/man2/fcntl.2.html

I've tried (Un)LockFileEx/fcntl on windows (including mingw and cygwin), 
linux and mac - works fine for me with one exception: cygwin's lock is 
not visible by win32's lock. I.e. you can synchronize multiple cygwin 
processes and multiple windows normal processes, but you can't mix them.


On 13-Oct-14 18:34, Ben Boeckel wrote:

Maybe we need something like the 'trap' shell builtin which runs code on
various triggers rather than something like file/directory locks...
Note that you can't set trap for SIGKILL. So if somebody will terminate 
your CMake instance by `kill -9 pid` probably you will have a problem.


--

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] New command 'file(LOCK_DIRECTORY ...)'

[Ruslan Baratov via cmake-developers]

On 08-Oct-14 16:45, Brad King wrote:

On 10/08/2014 07:52 AM, Ruslan Baratov wrote:

Okay :) I just not sure that I understand to pass to some other
process goal correctly.

That was just an example of why one might want to drop management
of the lock by CMake without actually unlocking it.  Perhaps the
code is starting a daemon and passes off responsibility for the
unlock side to the daemon process.

Okay, got it.



* we just need to `unlock` file so the other instance will use it:
file(UNLOCK_FILE /path/to/shared/file)
# now anybody can do the lock

Yes.  We also need the locking API to return information about
whether we really acquired the lock.
So it can be TRY_LOCK and LOCK. But does the TRY_LOCK really needed? 
With LOCK we can try to lock and spin until acquire, but what to do with 
TRY_LOCK? Just give up?



* we need other process to inherit the lock (what for?), i.e. move
ownership (?):
file(LOCK_FILE /path/to/shared/file)
execute_process(${CMAKE_COMMAND} --take-ownership /path/to/shared/file
...)
# unlocked by execute_process

I think all we need there is a way to ask CMake to take over
responsibility for a lock that it did not originally create.
It can also be in the file() command.

Thanks,
-Brad


Okay, so here is the commands inspired by C++:

  file(TRY_LOCK /path/to/file result) # try to lock and return TRUE 
on success (needed?)
  file(LOCK ...) # lock until unlock (unlock by further code (what if 
exit/crashed?) or by deamon)

  file(LOCK_GUARD ...) # lock for scope of current function or until exit
  file(UNLOCK ...) # explicit unlock of LOCK/LOCK_GUARD

Locking directory is equivalent to locking file `cmake.lock` in 
directory /path/to/shared/directory/:


  file(DIRECTORY_TRY_LOCK ...)
  file(DIRECTORY_LOCK /path/to/shared/directory/) # == file(LOCK 
/path/to/shared/directory/cmake.lock)

  file(DIRECTORY_LOCK_GUARD ...)
  file(DIRECTORY_UNLOCK ...)

If any of this commands failed (e.g. have no permissions) - exit with 
unsuccessful code (i.e. FATAL_ERROR) ?


* http://en.cppreference.com/w/cpp/thread/try_lock
* http://en.cppreference.com/w/cpp/thread/lock
* http://en.cppreference.com/w/cpp/thread/lock_guard
* http://en.cppreference.com/w/cpp/thread/mutex/unlock
--

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] New command 'file(LOCK_DIRECTORY ...)'

[Ruslan Baratov via cmake-developers]

On 10-Oct-14 16:58, David Cole wrote:

What is the main use case for locking files and directories from the
CMake language?

I feel slightly uncomfortable, without being able to put my finger on
exactly why, with the prospect of adding this to CMake...
I've described the situation in the first message of this thread: 
sharing resources between different cmake builds. If you want the 
particular case: I'm developing cmake-based package manager that share 
the builds of ExternalProject_Add. I'm experienced problems even when 
working on my local machine (I've started long-build in one console, 
then accidentally connect to the same shared directory in other 
console), but the main problem here is the server auto-builds which 
usually start multiple jobs simultaneously.


Behavior when there's a lock that still exists (by bug/mistake) after
CMake is done running is going to be strange and possibly
hard-to-diagnose / hard-to-understand.
That's *exactly* the problem I have and why I start this discussion. 
Currently I'm using mkdir command which return 0 only if directory 
created by current process (just to clarify, not the cmake -E 
make_directory). This works fine for me (tested on windows (mingw, 
cygwin), linux and mac). But I can't (or I don't know how) make remove 
this directory when I Ctrl+C my build (or abort the job on jenkins 
server). My current implementation just keep spinning with message: 
Directory locked by cmake, build started in directory 
cmake-binary-dir at timestamp.


Let's make sure the use case is quite strong before we accept the
possibility of stale locks in CMake.
Command `file(LOCK_GUARD ...)` will cover 100% of my needs. Other 
commands that I've mentioned used to cover suggestions from Brad K. (may 
be I've just understand them wrong).


Ruslo

Thanks, David C. On Fri, Oct 10, 2014 at 7:45 AM, Ruslan Baratov via 
cmake-developers cmake-developers@cmake.org wrote:

On 08-Oct-14 16:45, Brad King wrote:

On 10/08/2014 07:52 AM, Ruslan Baratov wrote:

Okay :) I just not sure that I understand to pass to some other
process goal correctly.

That was just an example of why one might want to drop management
of the lock by CMake without actually unlocking it.  Perhaps the
code is starting a daemon and passes off responsibility for the
unlock side to the daemon process.

Okay, got it.



* we just need to `unlock` file so the other instance will use it:
file(UNLOCK_FILE /path/to/shared/file)
# now anybody can do the lock

Yes.  We also need the locking API to return information about
whether we really acquired the lock.

So it can be TRY_LOCK and LOCK. But does the TRY_LOCK really needed? With
LOCK we can try to lock and spin until acquire, but what to do with
TRY_LOCK? Just give up?



* we need other process to inherit the lock (what for?), i.e. move
ownership (?):
file(LOCK_FILE /path/to/shared/file)
execute_process(${CMAKE_COMMAND} --take-ownership /path/to/shared/file
...)
# unlocked by execute_process

I think all we need there is a way to ask CMake to take over
responsibility for a lock that it did not originally create.
It can also be in the file() command.

Thanks,
-Brad


Okay, so here is the commands inspired by C++:

   file(TRY_LOCK /path/to/file result) # try to lock and return TRUE on
success (needed?)
   file(LOCK ...) # lock until unlock (unlock by further code (what if
exit/crashed?) or by deamon)
   file(LOCK_GUARD ...) # lock for scope of current function or until exit
   file(UNLOCK ...) # explicit unlock of LOCK/LOCK_GUARD

Locking directory is equivalent to locking file `cmake.lock` in directory
/path/to/shared/directory/:

   file(DIRECTORY_TRY_LOCK ...)
   file(DIRECTORY_LOCK /path/to/shared/directory/) # == file(LOCK
/path/to/shared/directory/cmake.lock)
   file(DIRECTORY_LOCK_GUARD ...)
   file(DIRECTORY_UNLOCK ...)

If any of this commands failed (e.g. have no permissions) - exit with
unsuccessful code (i.e. FATAL_ERROR) ?

* http://en.cppreference.com/w/cpp/thread/try_lock
* http://en.cppreference.com/w/cpp/thread/lock
* http://en.cppreference.com/w/cpp/thread/lock_guard
* http://en.cppreference.com/w/cpp/thread/mutex/unlock

--

Powered by www.kitware.com

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

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

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

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