Re: [cmake-developers] Fw: Please comment on ios-universal topic

2015-12-03 Thread Bartosz Kosiorek
Hello Ruslan

The Android supports both Universal Apk and Multi Apk.
 
https://androidbycode.wordpress.com/2015/07/07/android-ndk-a-guide-to-deploying-apps-with-native-libraries/
 
 http://developer.android.com/google/play/publishing/multiple-apks.html

It is necessary for deploy applications which support both armv7 (32bit) and 
armv8 (64bit).
There is also Intel's implementation of Android (x86)
All supported architectures you could found at:
   http://developer.android.com/ndk/guides/abis.html

It is possible to create universal library for Linux (FatElf), but it is not 
widely used:
http://stackoverflow.com/questions/10167821/why-are-universal-binaries-fatelf-not-part-of-linux-kernel

I don't know how it works with Universal Windows Platform:
https://msdn.microsoft.com/en-us/library/windows/apps/dn894631.aspx
https://msdn.microsoft.com/en-us/library/mt186162.aspx
But I suspect that it will be similar.

Best Regards
Bartosz


From: Ruslan Baratov 
Sent: Thursday, December 3, 2015 11:06 AM
To: Bartosz Kosiorek
Cc: Gregor Jasny; cmake-developers@cmake.org
Subject: Re: Fw: [cmake-developers] Please comment on ios-universal topic

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
>  

Re: [cmake-developers] Fw: Please comment on ios-universal topic

2015-12-03 Thread Bartosz Kosiorek
Hi again.

I get through link:
https://en.wikipedia.org/wiki/Fat_binary

and I think it will be better to name this property:
   INSTALL_UNIVERSAL_BINARY

Later such property name could be used also for Executables/Bundles etc.
And the result for both Libraries and Executables will be the same.

Best Regads
Bartosz



From: Bartosz Kosiorek
Sent: Thursday, December 3, 2015 12:45 PM
To: Ruslan Baratov
Cc: Gregor Jasny; cmake-developers@cmake.org
Subject: Re: Fw: [cmake-developers] Please comment on ios-universal topic

Hello Ruslan

The Android supports both Universal Apk and Multi Apk.
 
https://androidbycode.wordpress.com/2015/07/07/android-ndk-a-guide-to-deploying-apps-with-native-libraries/
 http://developer.android.com/google/play/publishing/multiple-apks.html

It is necessary for deploy applications which support both armv7 (32bit) and 
armv8 (64bit).
There is also Intel's implementation of Android (x86)
All supported architectures you could found at:
   http://developer.android.com/ndk/guides/abis.html

It is possible to create universal library for Linux (FatElf), but it is not 
widely used:
http://stackoverflow.com/questions/10167821/why-are-universal-binaries-fatelf-not-part-of-linux-kernel

I don't know how it works with Universal Windows Platform:
https://msdn.microsoft.com/en-us/library/windows/apps/dn894631.aspx
https://msdn.microsoft.com/en-us/library/mt186162.aspx
But I suspect that it will be similar.

Best Regards
Bartosz


From: Ruslan Baratov 
Sent: Thursday, December 3, 2015 11:06 AM
To: Bartosz Kosiorek
Cc: Gregor Jasny; cmake-developers@cmake.org
Subject: Re: Fw: [cmake-developers] Please comment on ios-universal topic

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 

Re: [cmake-developers] Fw: Please comment on ios-universal topic

2015-12-03 Thread 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] RFC: CMake precompiled header support and custom compiler based implementation

2015-12-03 Thread Taylor Braun-Jones
Perhaps the Paris Climate talks would be good inspiration for tackling
this feature. How many pounds of CO2 are emitted each year due to
needless header compilation CPU cycles? :-)

On Fri, Oct 30, 2015 at 1:48 AM, James Johnston
 wrote:
>> -Original Message-
>
>> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
>
>> On Behalf Of Daniel Pfeifer
>
>> Sent: Wednesday, October 28, 2015 08:57
>
>> To: Taylor Braun-Jones
>
>> Cc: CMake Developers
>
>> Subject: Re: [cmake-developers] RFC: CMake precompiled header support
>
>> and custom compiler based implementation
>
>>
>
>> On Tue, Oct 27, 2015 at 3:53 AM, Taylor Braun-Jones 
>> jones.org> wrote:
>
>> > What's the status of this PCH feature? Does it need testers? More
>
>> > design input? I'd love to see this feature in a future CMake release.
>
>> > Willing to help.
>
>>
>
>> I haven't worked on it for quite some time as I currently don't have a
>
> project
>
>> which needs it.
>
>> But I agree that we should get it into CMake, even if it does not
>
>> support
>
> all
>
>> generators yet.
>
>> Support for additional generators can be added successively.
>
>>
>
>> I will rebase my branch to master on the weekend, ie port it to
>
>> cmGeneratorTarget.
>
>> Then you are free to help with review, testing, and additional generators.
>
>>
>
>> Which generators are the most important for you?
>
>
>
> I'd also love to see some progress on PCH support, though I haven't had much
> time recently... I'd be quite happy to test however with the below compilers
> and generators - all of which we would use PCH support with:
>
>
>
> Generators:
>
>
>
> * Ninja
>
> * Visual Studio 2008 (eventually 2015)
>
> * Although we're not currently using it, CMake would be pretty broken
> without supporting: Unix Makefiles
>
>
>
> Compilers:
>
>
>
> * Visual C++ 2008 (eventually 2015): both Ninja and VS generators
>
> * Embarcadero bcc32 compiler: Ninja
>
> * GCC: Ninja
>
>
>
> Best regards,
>
>
>
> James Johnston
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-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] Extend copy and copy_if_different commands with support multiple files

2015-12-03 Thread Brad King
On 12/02/2015 07:05 PM, Bartosz Kosiorek wrote:
> This patch allows to use multiple files in commands "copy" and 
> "copy_if_different".

Good, thanks.  Please also extend the Tests/RunCMake/CommandLine test to
cover this these operations.

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] [PATCH] Fix Resource directory structure for iOS Bundles (Framework and Application), update Tests and Help

2015-12-03 Thread Brad King
On 12/02/2015 04:45 PM, Bartosz Kosiorek wrote:
> Patch in attachment allows to place resources in main Bundle directory
> (iOS specification), instead to always place in Resource directory.
> 
> https://public.kitware.com/Bug/view.php?id=15848

Thanks, applied:

 iOS: Fix framework resource directory layout (#15848)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e76ee2c0

-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][PATCH] Various Java support enhancements

2015-12-03 Thread Brad King
On 12/03/2015 06:43 AM, CHEVRIER, Marc wrote:
>  1. Fix some typo errors (introduced by myself :(

Good catch.  Sorry I didn't notice that during review.  Those typos
clearly came from the component renaming we discussed.

Applied:

 FindJava: Fix typos in IdlJ and JarSigner component implementation
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d8b251e2

I queued it for merge to 'release' for inclusion in 3.4.2.

>  2. Enable to specify manifest file as relative path
> (same behaviour as java sources)

Applied:

 UseJava: Allow relative path to manifest file just as with other sources
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=56c11eee

>  3. Add support for AIX/powerpc Java toolkits

Applied:

 FindJNI: Add support for AIX java sdk
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6fc91ffb

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] [PATCH] Extend copy and copy_if_different commands with support multiple files

2015-12-03 Thread Brad King
On 12/03/2015 11:05 AM, Bartosz Kosiorek wrote:
> After every step I will need to clean it up .

If you add these as cases in the RunCMake.CommandLine test then each one can
get its own directory and the RunCMake infrastructure will take care of
cleaning it up for each run.

-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] [PATCH] Extend copy and copy_if_different commands with support multiple files

2015-12-03 Thread Bartosz Kosiorek
When I'm trying to run test with wildcard:
run_cmake_command(E_copy-wildcard-source-files-target-is-directory 
${CMAKE_COMMAND} -E copy 
  ${RunCMake_copy_TEST_SOURCE_DIR}/directory1/* 
  ${RunCMake_copy_TEST_BINARY_DIR})

I've got an error:

Error copying file 
"/home/kosiorek/dev/perforce/cmake-dev/Tests/RunCMake/CommandLine/test_copy_command_dir/directory1/*"
 to 
"/home/kosiorek/dev/perforce/cmake-dev/builddir/Tests/RunCMake/CommandLine/test_copy_command_dir".

but when I'm running such command locally it work perfectly:

/home/kosiorek/dev/perforce/cmake-dev/builddir/bin/cmake -E copy 
/home/kosiorek/dev/perforce/cmake-dev/Tests/RunCMake/CommandLine/test_copy_command_dir/directory1/*
 
/home/kosiorek/dev/perforce/cmake-dev/builddir/Tests/RunCMake/CommandLine/test_copy_command_dir

What I'm doing wrong ?



From: Brad King 
Sent: Thursday, December 3, 2015 5:38 PM
To: Bartosz Kosiorek
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [PATCH] Extend copy and copy_if_different 
commands with support multiple files

On 12/03/2015 11:05 AM, Bartosz Kosiorek wrote:
> After every step I will need to clean it up .

If you add these as cases in the RunCMake.CommandLine test then each one can
get its own directory and the RunCMake infrastructure will take care of
cleaning it up for each run.

-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] [PATCH] Extend copy and copy_if_different commands with support multiple files

2015-12-03 Thread Bartosz Kosiorek
Hi.

I would like to create following tests for copy and copy_if_different commands:

cmake -E copy test_copy_command_dir/file1.txt 
test_copy_command_dir/target_directory1
Result: success
  E_copy-one-source-directory-target-is-directory-result.txt
  E_copy-one-source-directory-target-is-directory-stderr.txt

cmake -E copy test_copy_command_dir/directory1/file4.txt
Result: error
E_copy-one-source-file-result.txt
E_copy-one-source-file-stderr.txt

cmake -E copy test_copy_command_dir/file1.txt test_copy_command_dir/file2.txt  
test_copy_command_dir/file3.txt test_copy_command_dir/target_directory2
Result: Success
   E_copy-three-source-files-target-is-directory-result.txt
   E_copy-three-source-files-target-is-directory-stderr.txt

cmake -E copy test_copy_command_dir/file1.txt test_copy_command_dir/file2.txt  
test_copy_command_dir/file3.txt 
test_copy_command_dir/target_directory1/file4.txt
Result: Error
   E_copy-three-source-files-target-is-file-result.txt 
   E_copy-three-source-files-target-is-file-stderr.txt

cmake -E copy test_copy_command_dir/file1.txt not_existing_file.bad 
test_copy_command_dir/file2.txt   test_copy_command_dir/target_directory3
Result: Error. The correct files are copied successfuly
   E_copy-two-good-and-one-bad-source-files-target-is-directory-result.txt
   E_copy-two-good-and-one-bad-source-files-target-is-directory-stderr.txt

cmake -E copy test_copy_command_dir/*.txt 
test_copy_command_dir/target_directory4
Result: Success
   E_copy-wildcard-source-files-target-is-directory-result.txt
   E_copy-wildcard-source-files-target-is-directory-stderr.txt

cmake -E copy test_copy_command_dir/* test_copy_command_dir/directory1/file4.txt
Result: Error
   E_copy-wildcard-source-files-target-is-file-result.txt
   E_copy-wildcard-source-files-target-is-file-stderr.txt

The resource directory will be:
test_copy_command_dir
├── directory1
│   ├── file4.txt
│   └── file5.txt
├── directory2
├── file1.txt
├── file2.txt
├── file3.txt
├── target_directory1
├── target_directory2
├── target_directory3
└── target_directory4

What do you think about that?
After every step I will need to clean it up .

From: cmake-developers  on behalf of Brad 
King 
Sent: Thursday, December 3, 2015 2:45 PM
To: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [PATCH] Extend copy and copy_if_different 
commands with support multiple files

On 12/02/2015 07:05 PM, Bartosz Kosiorek wrote:
> This patch allows to use multiple files in commands "copy" and 
> "copy_if_different".

Good, thanks.  Please also extend the Tests/RunCMake/CommandLine test to
cover this these operations.

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

Powered by www.kitware.com

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

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

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

Visit other Kitware open-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] Add command line options for deprecation message control

2015-12-03 Thread Michael Scott

Thanks.  Applied with minor tweaks and merged to 'next' for testing:


That's great, thanks. Now that the patches are in, would you say it's 
better to work on adding a deprecated toggle option to the cmake-gui, or 
to work on adding support for upgrading warnings to errors?


Cheers,
Michael
--

Powered by www.kitware.com

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

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

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

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

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


[cmake-developers] [CMake 0015871]: Cmake may select incorrect default generator on windows host

2015-12-03 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15871 
== 
Reported By:Richard Lang
Assigned To:
== 
Project:CMake
Issue ID:   15871
Category:   CMake
Reproducibility:have not tried
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-12-03 17:13 EST
Last Modified:  2015-12-03 17:13 EST
== 
Summary:Cmake may select incorrect default generator on
windows host
Description: 
Looking at cmake::ActualConfigure() method in cmake.cxx (line 1265 or
thereabouts), comment indicates that in absence of a specified generator cmake
running on a native Windows host (not Cygwin) should generate for the newest
Visual Studio installation found on the system, and fall back to generating a
NMake make file if none found (which seems sensible), however as far as I can
see the code is actually going to select the OLDEST VS install.

Haven't run any test cases, this is solely from code inspection.

Steps to Reproduce: 
Run Cmake without generator specified on Windows host with more than 1 version
of visual Studio installed.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-12-03 17:13 Richard Lang   New Issue
==

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files

2015-12-03 Thread Bartosz Kosiorek
Hello.

Here is the patch with tests.

From: Brad King 
Sent: Thursday, December 3, 2015 7:07 PM
To: Bartosz Kosiorek
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [PATCH] Extend copy and copy_if_different 
commands with support multiple files

On 12/03/2015 12:31 PM, Bartosz Kosiorek wrote:
> When I'm trying to run test with wildcard:
> run_cmake_command(E_copy-wildcard-source-files-target-is-directory 
> ${CMAKE_COMMAND} -E copy
>   ${RunCMake_copy_TEST_SOURCE_DIR}/directory1/*
>   ${RunCMake_copy_TEST_BINARY_DIR})
>
> I've got an error:

The command is not running through a shell in that case so there is
no step that expands the wildcard.  This feature is not about wildcard
expansion, but about multiple inputs to the copy.  They can be
spelled out explicitly in the command invocation, or passed through
a variable containing a list populated by file(GLOB).

-Brad

From 8225688074386ac8633bad5e6f9fdb4a7caf9775 Mon Sep 17 00:00:00 2001
From: "Bartosz Kosiorek bartosz.kosio...@tomtom.com"
 
Date: Thu, 3 Dec 2015 00:43:37 +0100
Subject: [PATCH 1/2] Extend copy and copy_if_different command with support
 multiple files

This patch allows to use multiple files in command copy and copy_if_different.
Input files could be merged with wildcards.
If multipile input files were provided, then destination must be directory.
If only one input file was provided, then destination could be either
file or directory. This path is starting point for fixing bug 15703
---
 Help/manual/cmake.1.rst | 12 
 Source/cmcmd.cxx| 73 +++--
 2 files changed, 58 insertions(+), 27 deletions(-)

diff --git a/Help/manual/cmake.1.rst b/Help/manual/cmake.1.rst
index dac16bf..086f259 100644
--- a/Help/manual/cmake.1.rst
+++ b/Help/manual/cmake.1.rst
@@ -169,14 +169,14 @@ Available commands are:
 ``compare_files  ``
   Check if file1 is same as file2.
 
-``copy  ``
-  Copy file to destination (either file or directory).
+``copy ... ``
+  Copy files to 'destination' (either file or directory).
 
 ``copy_directory  ``
   Copy directory 'source' content to directory 'destination'.
 
-``copy_if_different  ``
-  Copy file if input has changed.
+``copy_if_different ... ``
+  Copy files if input has changed. Destination could be file or directory.
 
 ``echo [...]``
   Displays arguments as text.
@@ -193,10 +193,10 @@ Available commands are:
 ``make_directory ``
   Create a directory.
 
-``md5sum [...]``
+``md5sum ...``
   Compute md5sum of files.
 
-``remove [-f] [...]``
+``remove [-f] ...``
   Remove the file(s), use ``-f`` to force it.
 
 ``remove_directory ``
diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx
index 21b126b..0dc5a9a 100644
--- a/Source/cmcmd.cxx
+++ b/Source/cmcmd.cxx
@@ -52,25 +52,25 @@ void CMakeCommandUsage(const char* program)
   // If you add new commands, change here,
   // and in cmakemain.cxx in the options table
   errorStream
-<< "Usage: " << program << " -E [command] [arguments ...]\n"
+<< "Usage: " << program << " -E  [arguments...]\n"
 << "Available commands: \n"
 << "  chdir dir cmd [args]...   - run command in a given directory\n"
 << "  compare_files file1 file2 - check if file1 is same as file2\n"
-<< "  copy file destination - copy file to destination (either file "
-   "or directory)\n"
+<< "  copy ... destination  - copy files to destination "
+   "(either file or directory)\n"
 << "  copy_directory source destination   - copy directory 'source' "
"content to directory 'destination'\n"
-<< "  copy_if_different in-file out-file  - copy file if input has "
+<< "  copy_if_different ... destination  - copy files if it has "
"changed\n"
-<< "  echo [string]...  - displays arguments as text\n"
-<< "  echo_append [string]...   - displays arguments as text but no new "
+<< "  echo [...]- displays arguments as text\n"
+<< "  echo_append [...] - displays arguments as text but no new "
"line\n"
 << "  env [--unset=NAME]... [NAME=VALUE]... COMMAND [ARG]...\n"
 << "- run command in a modified environment\n"
 << "  environment   - display the current environment\n"
 << "  make_directory dir- create a directory\n"
-<< "  md5sum file1 [...]- compute md5sum of files\n"
-<< "  remove [-f] file1 file2 ... - remove the file(s), use -f to force "
+<< "  md5sum ...  - compute md5sum of files\n"
+<< "  remove [-f] ... - remove the file(s), use -f to force "
"it\n"
 << "  remove_directory dir  - remove a directory and its contents\n"
 << "  rename oldname newname- rename a file or directory "
@@ -78,7 +78,7 @@ void CMakeCommandUsage(const char* program)
 << "  tar [cxt][vf][zjJ] file.tar [file/dir1 file/dir2 

Re: [cmake-developers] [PATCH] FindTIFF: Add imported targets

2015-12-03 Thread Roger Leigh

On 02/12/2015 17:31, rle...@codelibre.net wrote:

- Add TIFF::TIFF imported target
- Document imported target
- Add testcase to test the standard variables and the imported
   target

Also:

- Add TIFF_INCLUDE_DIRS to match common practice
- Update documentation generally, including documenting
   TIFF_INCLUDE_DIRS


I hope this is now staged correctly for review.  I've pushed a 
tiff-imported-target topic branch and merged into next:


amys% ssh g...@cmake.org stage cmake merge -b next tiff-imported-target
Fetching upstream next
Merge topic 'tiff-imported-target' into next

09f36344 Help: Document addition of FindTIFF imported targets
a237b26d FindTIFF: Add imported targets and update documentation

Auto-merging Tests/CMakeLists.txt
Pushing upstream next


Kind regards,
Roger
--

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files

2015-12-03 Thread Brad King
On 12/03/2015 12:31 PM, Bartosz Kosiorek wrote:
> When I'm trying to run test with wildcard:
> run_cmake_command(E_copy-wildcard-source-files-target-is-directory 
> ${CMAKE_COMMAND} -E copy 
>   ${RunCMake_copy_TEST_SOURCE_DIR}/directory1/* 
>   ${RunCMake_copy_TEST_BINARY_DIR})
> 
> I've got an error:

The command is not running through a shell in that case so there is
no step that expands the wildcard.  This feature is not about wildcard
expansion, but about multiple inputs to the copy.  They can be
spelled out explicitly in the command invocation, or passed through
a variable containing a list populated by file(GLOB).

-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