from:"Bartosz Kosiorek"

[cmake-developers] [PATCH] Update documentation for VERSION and SOVERSION for Mach-O file formats (OSX, iOS, BSD etc.)

2016-06-23 Thread Bartosz Kosiorek

Hello.

Last time I faced problem, how to set "current version" and "compatibility
version" on binaries produced by OS X.

I have updated documentation to describe how to archieve that, to make life
easier for new CMake users.

Please let me know what do you think about it.
Do you think it could be pushed into CMake 3.6 ?

Best Regards
Bartosz


0001-Add-description-of-versions-target-property-for-Mach.patch
Description: Binary data
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Multiple files support for touch and touch_nocreate

2016-05-02 Thread Bartosz Kosiorek

Hello.

I implemented multiple files support for touch and touch_nocreate.

It seems that partially it was implemented but:
1. Documentation didn't mention about multi file support for touch command
2. When some unspecified error will occur, the touching multiple files was
interrupted. `i fixed that and now it is working the same as for Linux.

Please let me know what you think about that.
Do you think it could be pushed into cmake repository?

Thanks in advance
Bartosz


0001-Add-support-of-multiple-files-for-touch-and-touch_no.patch
Description: Binary data
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake for 64Win7

2016-03-09 Thread Bartosz Kosiorek

Hello.
I checked the generation performance for our huge project for Linux and
Windows, and there is big improvement for 64bit over 32 bit for Linux.

For Windows there is no such big difference between 32bit and 64bit in
generation time:

  CMake 3.5.0 Windows 64 bits:
  End time:   9.41:45
  Start time: 9.34:45
  Difference: 7:00

  CMake 3.5.0 Windows 32 bits:
  End time:   9.50:58
  Start time: 9.44:25
  Difference: 0.06:33


Of course it depends on project. I think it will be great to have 64
bit build for Windows.


Best Regards

Bartosz



2016-03-08 8:55 GMT+01:00 Konstantin Podsvirov :

> Good day!
>
> You can try the experimental installer (based on IFW generator) from my
> website:
>
> http://ifw.podsvirov.pro/cmake/files/v3.5/cmake-3.5.0-rc3-win64-x64.exe
>
> You can also try the online version, which is based on code from branch
> "master":
>
> http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe
>
> Online installer supports online update.
>
> Good luck :-)
>
> 08.03.2016, 03:32, "LI, NING" :
> > Dear Sirs,
> >
> > There are only 32Win version of CMake( cmake-3.5.0-rc3-win32-x86.msi or
> cmake-3.5.0-rc3-win32-x86.zip ) on your web page(
> https://cmake.org/download/ ). When will the version for 64Win available?
> >
> > Thank you for the help!
> >
> > Ning.
> > ==
> > LI, Ning. Ph.D.
> > --
> > E-mail Address: l...@cec.sc.edu
> > ===The University of South Carolina===
>
> --
> Regards,
> Konstantin Podsvirov
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware 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] Changes for v3.5.0

2016-02-10 Thread Bartosz Kosiorek

Good Morning/Evening.

I have great news.
With Nighly Build 3.5.20160208 the regression was gone, and the Generation
performance is almost the as with CMake 3.4.3.

Here are details:
Version 3.2.2
real2m0.780s
user1m55.704s
sys0m2.360s

Version 3.4.3
real1m30.223s
user1m24.816s
sys0m3.004s

Version 3.5.0rc1
real6m20.086s
user6m15.836s
sys0m3.600s

Version nigtly build 3.5.20160208
real1m29.047s
user1m24.232s
sys0m3.040s

Thank you
Bartosz

2016-02-09 20:51 GMT+01:00 Brad King :

> On 02/09/2016 02:39 PM, Alan W. Irwin wrote:
> > So what branch should we follow if we want to test the on-going 3.5.x
> > effort?
> >
> > I assumed it would be "release"
>
> Yes.  I just merged several of the fixes there this morning.
>
> > but one of the key fixes to 3.5.0-rc1 is the efficiency one
> [snip]
> > Are those changes being "cooked" a bit longer or are they already in
> > the release branch under some different title?
>
> They are cooking in 'master' for few days.  This will give Bartosz
> (who reported the performance problem) some time to confirm the fixes
> work.
>
> The fixes are also available in the nightly binaries since those
> are built from 'next'.
>
> -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 3.5 generation time

2016-02-05 Thread Bartosz Kosiorek

guages: Remove cmMakefile dependency
real 3m44.070s
user 3m39.872s
sys 0m3.608s


# bad: [d566f39a640297114bd3ad933bb3279440b2f38f] cmGlobalGenerator: Remove
unneeded GetGeneratorTarget
real 7m5.141s
user 6m59.824s
sys 0m3.796s

# bad: [79c11d23405d3894a254a8c03df5ead32464b109] Xcode: Port away from
GetGeneratorTarget
real 6m33.845s
user 6m30.440s
sys 0m3.616s

# good: [45cd9e63371ae09b6ad9dbc27ac4d36c19b357af] Update libarchive
configuration within CMake
real 3m46.190s
user 3m41.800s
sys 0m3.260s

# good: [e78fcc6329483c99e61cebffbe5d82b67a3361ae] QtAutogen: Fix rcc
invocation for Qt 5.0 and 5.1 (#15644)
real 3m44.454s
user 3m39.640s
sys 0m3.524s

# good: [520ca0ff6c123250c633a3618459d0161cbc4683] cmGeneratorTarget: Add
API for property keys
real 3m43.945s
user 3m39.712s
sys 0m3.568s

# good: [63e2af0f8dbae222ebaae62b532340f3d83cbc93] CPack: Fix
CPACK_OSX_SYSROOT with symbolic CMAKE_OSX_SYSROOT (#15816)
real 3m44.176s
user 3m39.216s
sys 0m3.764s

# good: [f8eb72fe5fedbf45e66f433e6bc54e1cf0359760] Help: Clarify
documentation for MACOSX_RPATH variable.
real 3m35.856s
user 3m29.228s
sys 0m3.536s

# good: [593f347b5385a510e641eca0448f7ddf64c1c12b] VS7: Port some
implementation details to cmGeneratorTarget
real 3m46.947s
user 3m42.540s
sys 0m3.636s


# good: [85e0bb84f5eca2f77f070bce9f83024854096307] libarchive: Avoid using
'uint8_t' as bitfield type
real 3m40.737s
user 3m36.084s
sys 0m3.548s


bad: [4ce9742ae33678d8fce189d172c2fffb1a43061c] Alias: Fix access at
generate-time (#15832)
real 9m17.389s
user 9m14.324s
sys 0m3.596s

# good: [91a829c165209b96c20d17f8eb7d46d3375cc57c] Makefiles: Remove unused
variable
real 3m51.085s
user 3m46.896s
sys 0m3.592s

[b5d94065c07a3ba6db29297e55b0e01ba0ef1f9d] Merge topic
'autorcc-qt-5.1-compat'
1.
real 4m30.586s
user 4m19.812s
sys 0m4.080s
2.
real 4m23.646s
user 4m18.552s
sys 0m4.084s

# good: [6a56c8247fa874bd418c3e175c941070dafb0e76] Tests: Disable parallel
test execution while running ctest_test
real 3m49.764s
user 3m45.076s
sys 0m3.736s

# bad: [3cb726371f27948149f668d43aa58cd2a5e9be4c] Merge topic
'wix-toplevel-feature-required'
real 11m44.201s
user 11m41.232s
sys 0m3.960s

# good: [cf69630e510a5c639a93a99b315fcefea9688935] cmGeneratorTarget: Move
GetFrameworkVersion from cmTarget
real 3m52.078s
user 3m47.508s
sys 0m4.240s

# bad: [48182afd3d04cc659fc5d86ab65b403d8a2b8eff] CMake Nightly Date Stamp
real 12m6.370s
user 12m2.872s
sys 0m4.392s

# good: [a03c13a710fc4c65035e92749720b559cbeeff2e] CMake Nightly Date Stamp
real 3m54.556s
user 3m44.596s
sys 0m4.284s

# bad: [e069aa05c6a0d8e89a677fa4f00d33432191eeaa] Merge topic
'regex-explorer'
real 12m36.866s
user 12m31.864s
sys 0m4.348s

# good: [d233030f5bcfe2509b82433f7df6383cd301e34e] cmGeneratorTarget: Port
implementation to cmGeneratorTarget.
git bisect bad d233030f5bcfe2509b82433f7df6383cd301e34e
1. First clean generation
real 3m40.716s
user 3m34.908s
sys 0m3.944s
2. Second clean generation
real 3m41.351s
user 3m36.880s
sys 0m3.872s


2016-02-04 23:57 GMT+01:00 Bartosz Kosiorek <gan...@poczta.onet.pl>:

> Hi Brad
> Unfortunately after building locally, the times are totally different
> (worse).
> I don't know why it is happen.
>
> Builds for some specific commits, are not able to run properly. In that
> case I have just skip bisect commit.
> Do you have some further recommendation?
>
>
> On master the times are:
> real 8m1.255s
> user 7m56.684s
> sys 0m3.900s
>
> Bisection logs:
> git bisect log
> git bisect start
> # bad: [8a8d22cf1e5d20b7c3b32c1ec9b5f06b339c2a50] CMake 3.5.0-rc1 version
> update
> git bisect bad 8a8d22cf1e5d20b7c3b32c1ec9b5f06b339c2a50
> # good: [0aef6f2412177a236deb292654402518777f3cb0] CMake 3.4.3
> git bisect good 0aef6f2412177a236deb292654402518777f3cb0
> # skip: [49ac682d39af7fe47e79455827e2e83130193236] Merge topic
> 'vs-show-def-files'
> git bisect skip 49ac682d39af7fe47e79455827e2e83130193236
> # bad: [e069aa05c6a0d8e89a677fa4f00d33432191eeaa] Merge topic
> 'regex-explorer'
> git bisect bad e069aa05c6a0d8e89a677fa4f00d33432191eeaa
> # good: [a03c13a710fc4c65035e92749720b559cbeeff2e] CMake Nightly Date Stamp
> git bisect good a03c13a710fc4c65035e92749720b559cbeeff2e
> # skip: [59315f5b0028e4f9c4fde765196c4df38ab83b3e] Merge topic
> 'cpack-deb-compression-scheme-test'
> git bisect skip 59315f5b0028e4f9c4fde765196c4df38ab83b3e
> # bad: [48182afd3d04cc659fc5d86ab65b403d8a2b8eff] CMake Nightly Date Stamp
> git bisect bad 48182afd3d04cc659fc5d86ab65b403d8a2b8eff
> # skip: [1e8c920d0409770214a4ff517f6a4c31b9830f45] Merge topic
> 'use-generator-target'
> git bisect skip 1e8c920d0409770214a4ff517f6a4c31b9830f45
> # good: [cf69630e510a5c639a93a99b315fcefea9688935] cmGeneratorTarget: Move
> GetFrameworkVersion from cmTarget
> git bisect good cf69630e510a5c639a93a99b315fcefea9688935
> # skip: [1bfb527f561c705169f0716108e34a2b5ba5c8bb] FindPkgConfig: return
>

Re: [cmake-developers] [ANNOUNCE] CMake 3.5.0-rc1 now ready for testing!

2016-02-04 Thread Bartosz Kosiorek

Hi
I just started testing 3.5.0-rc1 on Linux and I noticed regression in
Makefile generation time.
I checked 3.5.0rc1, 3.4.3 and 3.2.2 versions, and the results are as
follows:

64bit cmake 3.5.0-rc1 Makefile Generation
1. Run
real2m36.457s
user2m32.008s
sys0m3.184s
2. Run
real2m36.764s
user2m31.672s
sys0m3.296s


64bit cmake 3.4.3 Makefile Generation
1. Run
real1m29.679s
user1m24.696s
sys0m2.920s
2. Run
real1m28.266s
user1m24.220s
sys0m2.976s

64bit cmake 3.2.2 Makefile Generation
1. Run
real1m57.894s
user1m54.160s
sys0m2.320s
2. Run
real1m57.083s
user1m53.076s
sys0m2.304s

Is it known issue?
Do you have suspects what could cause this regression?

Best Regards
Bartosz


2016-02-02 22:56 GMT+01:00 Robert Maynard :

> I am proud to announce the first CMake 3.5 release candidate.
>
> Sources and binaries are available at:
>   https://cmake.org/download/
>
> Documentation is available at:
>   https://cmake.org/cmake/help/v3.5
>
> Release notes appear below and are also published at
>   https://cmake.org/cmake/help/v3.5/release/3.5.html
>
> Some of the more significant features of CMake 3.5 are:
>
> * The precompiled Windows binary provided on "cmake.org" is now a
>   ".msi" package instead of an installer executable.  One may need to
>   manually uninstall CMake versions lower than 3.5 before installing
>   the new package.
>
> * The "cmake-gui(1)" learned an option to set the toolset to be used
>   with VS IDE and Xcode generators, much like the existing "-T" option
>   to "cmake(1)".
>
> * Find modules for Boost, FLEX, GTest, GTK2, PNG, TIFF, and XercesC
>   now provide imported targets.
>
> * The "FindOpenMP" module learned to support Clang.
>
> * A new platform file for cross-compiling in the Cray Linux
>   Environment to target compute nodes was added.  See Cross Compiling
>   for the Cray Linux Environment for usage details.
>
> * The "Compile Features" functionality is now aware of features
>   supported by Clang compilers on Windows (MinGW).
>
> * Support was added for the ARM Compiler (arm.com) with compiler id
>   "ARMCC".
>
> * When building for embedded Apple platforms like iOS CMake learned
>   to build and install combined targets which contain both a device
>   and a simulator build. This behavior can be enabled by setting the
>   "IOS_INSTALL_COMBINED" target property.
>
> * The "CPackDMG" module learned new variable to specify AppleScript
>   file run to customize appearance of "DragNDrop" installer folder,
>   including background image setting using supplied PNG or multi-
>   resolution TIFF file.  See the "CPACK_DMG_DS_STORE_SETUP_SCRIPT" and
>   "CPACK_DMG_BACKGROUND_IMAGE" variables.
>
> Deprecated and Removed Features:
>
> * The "CMakeForceCompiler" module and its macros are now deprecated.
>   See module documentation for an explanation.
>
> * The "cmake(1)" "-E time" command now properly passes arguments
>   with spaces or special characters through to the child process.
>   This may break scripts that worked around the bug with their own
>   extra quoting or escaping.
>
>
>
> CMake 3.5 Release Notes
> ***
>
> Changes made since CMake 3.4 include the following.
>
>
> New Features
> 
>
>
> GUI
> ---
>
> * The "cmake-gui(1)" gained options to control warnings about
>   deprecated functionality.
>
> * The "cmake-gui(1)" learned an option to set the toolset to be used
>   with VS IDE and Xcode generators, much like the existing "-T" option
>   to "cmake(1)".
>
> * The "cmake-gui(1)" gained a Regular Expression Explorer which may
>   be used to create and evaluate regular expressions in real-time. The
>   explorer window is available via the "Tools" menu.
>
>
> Command-Line
> 
>
> * The "-Wdev" and "-Wno-dev" "cmake(1)" options now also enable and
>   suppress the deprecated warnings output by default.
>
> * The suppression of developer warnings as errors can now be
>   controlled with the new "-Werror=dev" and "-Wno-error=dev"
>   "cmake(1)" options.
>
> * The "cmake(1)" "-E" command-line tools "copy",
>   "copy_if_different", "copy_directory", and "make_directory" learned
>   to support multiple input files or directories.
>
>
> Commands
> 
>
> * The "cmake_parse_arguments()" command is now implemented natively.
>   The "CMakeParseArguments" module remains as an empty placeholder for
>   compatibility.
>
> * The "install(DIRECTORY)" command learned to support "generator
>   expressions" in the list of directories.
>
>
> Variables
> -
>
> * The "CMAKE_ERROR_DEPRECATED" variable can now be set using the
>   "-Werror=deprecated" and "-Wno-error=deprecated" "cmake(1)" options.
>
> * The "CMAKE_WARN_DEPRECATED" variable can now be set using the
>   "-Wdeprecated" and "-Wno-deprecated" "cmake(1)" options.
>
>
> Properties
> --
>
> * The "VS_GLOBAL_" target property is now implemented for
>   VS 2010 and above.  Previously it

Re: [cmake-developers] [ANNOUNCE] CMake 3.5.0-rc1 now ready for testing!

2016-02-04 Thread Bartosz Kosiorek

Hi

One more thing.
There is huge difference in Unix Makefile generation time between 32 vs 64
bit cmake version:

32 bit CMake 3.5.0 generation time:
real5m33.310s
user5m27.268s
sys0m3.540s

64 bit  CMake 3.5.0 generation time:
real2m36.457s
user2m32.008s
sys0m3.184s

Unfortunately there no 64bit CMake version for Windows:
https://cmake.org/download/

Is it possible to create 64 bit build for Windows?

Best Regards
Bartosz

2016-02-04 11:17 GMT+01:00 Bartosz Kosiorek <gan...@poczta.onet.pl>:

> Hi
> I just started testing 3.5.0-rc1 on Linux and I noticed regression in
> Makefile generation time.
> I checked 3.5.0rc1, 3.4.3 and 3.2.2 versions, and the results are as
> follows:
>
> 64bit cmake 3.5.0-rc1 Makefile Generation
> 1. Run
> real2m36.457s
> user2m32.008s
> sys0m3.184s
> 2. Run
> real2m36.764s
> user2m31.672s
> sys0m3.296s
>
>
> 64bit cmake 3.4.3 Makefile Generation
> 1. Run
> real1m29.679s
> user1m24.696s
> sys0m2.920s
> 2. Run
> real1m28.266s
> user1m24.220s
> sys0m2.976s
>
> 64bit cmake 3.2.2 Makefile Generation
> 1. Run
> real1m57.894s
> user1m54.160s
> sys0m2.320s
> 2. Run
> real1m57.083s
> user1m53.076s
> sys0m2.304s
>
> Is it known issue?
> Do you have suspects what could cause this regression?
>
> Best Regards
> Bartosz
>
>
> 2016-02-02 22:56 GMT+01:00 Robert Maynard <robert.mayn...@kitware.com>:
>
>> I am proud to announce the first CMake 3.5 release candidate.
>>
>> Sources and binaries are available at:
>>   https://cmake.org/download/
>>
>> Documentation is available at:
>>   https://cmake.org/cmake/help/v3.5
>>
>> Release notes appear below and are also published at
>>   https://cmake.org/cmake/help/v3.5/release/3.5.html
>>
>> Some of the more significant features of CMake 3.5 are:
>>
>> * The precompiled Windows binary provided on "cmake.org" is now a
>>   ".msi" package instead of an installer executable.  One may need to
>>   manually uninstall CMake versions lower than 3.5 before installing
>>   the new package.
>>
>> * The "cmake-gui(1)" learned an option to set the toolset to be used
>>   with VS IDE and Xcode generators, much like the existing "-T" option
>>   to "cmake(1)".
>>
>> * Find modules for Boost, FLEX, GTest, GTK2, PNG, TIFF, and XercesC
>>   now provide imported targets.
>>
>> * The "FindOpenMP" module learned to support Clang.
>>
>> * A new platform file for cross-compiling in the Cray Linux
>>   Environment to target compute nodes was added.  See Cross Compiling
>>   for the Cray Linux Environment for usage details.
>>
>> * The "Compile Features" functionality is now aware of features
>>   supported by Clang compilers on Windows (MinGW).
>>
>> * Support was added for the ARM Compiler (arm.com) with compiler id
>>   "ARMCC".
>>
>> * When building for embedded Apple platforms like iOS CMake learned
>>   to build and install combined targets which contain both a device
>>   and a simulator build. This behavior can be enabled by setting the
>>   "IOS_INSTALL_COMBINED" target property.
>>
>> * The "CPackDMG" module learned new variable to specify AppleScript
>>   file run to customize appearance of "DragNDrop" installer folder,
>>   including background image setting using supplied PNG or multi-
>>   resolution TIFF file.  See the "CPACK_DMG_DS_STORE_SETUP_SCRIPT" and
>>   "CPACK_DMG_BACKGROUND_IMAGE" variables.
>>
>> Deprecated and Removed Features:
>>
>> * The "CMakeForceCompiler" module and its macros are now deprecated.
>>   See module documentation for an explanation.
>>
>> * The "cmake(1)" "-E time" command now properly passes arguments
>>   with spaces or special characters through to the child process.
>>   This may break scripts that worked around the bug with their own
>>   extra quoting or escaping.
>>
>>
>>
>> CMake 3.5 Release Notes
>> ***
>>
>> Changes made since CMake 3.4 include the following.
>>
>>
>> New Features
>> 
>>
>>
>> GUI
>> ---
>>
>> * The "cmake-gui(1)" gained options to control warnings about
>>   deprecated functionality.
>>
>> * The "cmake-gui(1)" learned an option to set the toolset to be used
>>   with VS IDE and Xc

Re: [cmake-developers] CMake 3.5 generation time

2016-02-04 Thread Bartosz Kosiorek

Hi Brad
Unfortunately after building locally, the times are totally different
(worse).
I don't know why it is happen.

Builds for some specific commits, are not able to run properly. In that
case I have just skip bisect commit.
Do you have some further recommendation?


On master the times are:
real 8m1.255s
user 7m56.684s
sys 0m3.900s

Bisection logs:
git bisect log
git bisect start
# bad: [8a8d22cf1e5d20b7c3b32c1ec9b5f06b339c2a50] CMake 3.5.0-rc1 version
update
git bisect bad 8a8d22cf1e5d20b7c3b32c1ec9b5f06b339c2a50
# good: [0aef6f2412177a236deb292654402518777f3cb0] CMake 3.4.3
git bisect good 0aef6f2412177a236deb292654402518777f3cb0
# skip: [49ac682d39af7fe47e79455827e2e83130193236] Merge topic
'vs-show-def-files'
git bisect skip 49ac682d39af7fe47e79455827e2e83130193236
# bad: [e069aa05c6a0d8e89a677fa4f00d33432191eeaa] Merge topic
'regex-explorer'
git bisect bad e069aa05c6a0d8e89a677fa4f00d33432191eeaa
# good: [a03c13a710fc4c65035e92749720b559cbeeff2e] CMake Nightly Date Stamp
git bisect good a03c13a710fc4c65035e92749720b559cbeeff2e
# skip: [59315f5b0028e4f9c4fde765196c4df38ab83b3e] Merge topic
'cpack-deb-compression-scheme-test'
git bisect skip 59315f5b0028e4f9c4fde765196c4df38ab83b3e
# bad: [48182afd3d04cc659fc5d86ab65b403d8a2b8eff] CMake Nightly Date Stamp
git bisect bad 48182afd3d04cc659fc5d86ab65b403d8a2b8eff
# skip: [1e8c920d0409770214a4ff517f6a4c31b9830f45] Merge topic
'use-generator-target'
git bisect skip 1e8c920d0409770214a4ff517f6a4c31b9830f45
# good: [cf69630e510a5c639a93a99b315fcefea9688935] cmGeneratorTarget: Move
GetFrameworkVersion from cmTarget
git bisect good cf69630e510a5c639a93a99b315fcefea9688935
# skip: [1bfb527f561c705169f0716108e34a2b5ba5c8bb] FindPkgConfig: return
actual error when a package is not found (#15810)
git bisect skip 1bfb527f561c705169f0716108e34a2b5ba5c8bb


Bisection results:
# good: [cf69630e510a5c639a93a99b315fcefea9688935] cmGeneratorTarget: Move
GetFrameworkVersion from cmTarget
real 3m52.078s
user 3m47.508s
sys 0m4.240s

# bad: [48182afd3d04cc659fc5d86ab65b403d8a2b8eff] CMake Nightly Date Stamp
real 12m6.370s
user 12m2.872s
sys 0m4.392s

# good: [a03c13a710fc4c65035e92749720b559cbeeff2e] CMake Nightly Date Stamp
real 3m54.556s
user 3m44.596s
sys 0m4.284s

# bad: [e069aa05c6a0d8e89a677fa4f00d33432191eeaa] Merge topic
'regex-explorer'
real 12m36.866s
user 12m31.864s
sys 0m4.348s

# good: [d233030f5bcfe2509b82433f7df6383cd301e34e] cmGeneratorTarget: Port
implementation to cmGeneratorTarget.
git bisect bad d233030f5bcfe2509b82433f7df6383cd301e34e
1. First clean generation
real 3m40.716s
user 3m34.908s
sys 0m3.944s
2. Second clean generation
real 3m41.351s
user 3m36.880s
sys 0m3.872s


2016-02-04 20:56 GMT+01:00 Bartosz Kosiorek <gan...@poczta.onet.pl>:

> Hi.
> I would like to mention that all my previous times, was measured for clean
> Generation (I deleted all generation files)
> I will try to make bisect build, to check where regression occur.
>
> Now I would like to present results with enabled cleaning only on first
> run:
>
> CMake 3.4.3 Unix Makefile generation
> 1. Clean run (rm -rf Output)
> real 1m31.233s
> user 1m26.136s
> sys 0m3.004s
> 2. Dirty run (no deletion)
> real 1m27.101s
> user 1m24.620s
> sys 0m2.988s
> 3. Dirty run (no deletion)
> real 1m26.237s
> user 1m23.240s
> sys 0m3.020s
> 4. Dirty run (no deletion)
> real 1m27.670s
> user 1m24.764s
> sys 0m2.816s
>
> CMake 3.5.0-rc1 Unix Makefile generation
> 1. Clean run (rm -rf Output)
> real 2m34.244s
> user 2m30.176s
> sys 0m3.220s
> 2. Dirty run (no deletion)
> real 2m35.259s
> user 2m32.400s
> sys 0m3.116s
> 3. Dirty run (no deletion)
> real 2m27.881s
> user 2m25.184s
> sys 0m3.032s
> 4. Dirty run (no deletion)
> real 2m25.139s
> user 2m22.552s
> sys 0m2.984s
>
> 2016-02-04 18:57 GMT+01:00 Brad King <brad.k...@kitware.com>:
>
>> On 02/04/2016 10:29 AM, Bartosz Kosiorek wrote:
>> > I downloaded cmakes from website:
>> > https://cmake.org/download/
>> >
>> > All generation were done on clean output (deleted all files generated
>> by cmake)
>> > on the same repository version, in the same directory.
>> > The only difference was cmake version used for configuring.
>> >
>> > How I could check what was caused such long times?
>>
>> Try also timing the second and third runs on a single build tree
>> to get timings without all the platform introspection tests.
>>
>> You could clone the CMake Git repository, build from source with
>> -DCMAKE_BUILD_TYPE=RelWithDebInfo and then run it through a
>> profiler (e.g. valgrind --tool=callgrind).  Alternatively you
>> could `git bisect` between v3.4.3 and v3.5.0-rc1 to see if there
>> is a small range of commits that causes the regression.  That
>> could really help narrow

Re: [cmake-developers] CMake 3.5 generation time (was: CMake 3.5.0-rc1 now ready for testing!)

2016-02-04 Thread Bartosz Kosiorek

Hi Brad.

I'm configuring/generating NavKit project, by using  -G "Unix Makefiles"
parameter.
I downloaded cmakes from website:
https://cmake.org/download/

All generation were done on clean output (deleted all files generated by
cmake) on the same repository version, in the same directory.
The only difference was cmake version used for configuring.

How I could check what was caused such long times?

Best Regards
Bartosz



2016-02-04 14:30 GMT+01:00 Brad King <brad.k...@kitware.com>:

> On 02/04/2016 07:09 AM, Bartosz Kosiorek wrote:
> > There is huge difference in Unix Makefile generation time between
> > 32 vs 64 bit cmake version:
> >
> > 32 bit CMake 3.5.0 generation time:
> > real5m33.310s
> > user5m27.268s
> > sys0m3.540s
> >
> > 64 bit  CMake 3.5.0 generation time:
> > real2m36.457s
> > user2m32.008s
> > sys0m3.184s
> >
> > Unfortunately there no 64bit CMake version for Windows:
> > https://cmake.org/download/
> >
> > Is it possible to create 64 bit build for Windows?
>
> Perhaps eventually, but please try running those timings with local
> builds of CMake on Windows to see if the difference carries across
> platforms.
>
> > 64bit cmake 3.5.0-rc1 Makefile Generation
> > 1. Run
> > real2m36.457s
> > user2m32.008s
> > sys0m3.184s
> > 2. Run
> > real2m36.764s
> > user2m31.672s
> > sys0m3.296s
> >
> > 64bit cmake 3.4.3 Makefile Generation
> > 1. Run
> > real1m29.679s
> > user1m24.696s
> > sys0m2.920s
> > 2. Run
> > real1m28.266s
> > user1m24.220s
> > sys0m2.976s
>
> There has been some refactoring but it has not had that effect on
> projects I've seen.  What project are you configuring?  Were both
> of these versions built the same way?  Is this consistent when
> configuring, say, CMake itself?
>
> 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] CMake 3.5 generation time

2016-02-04 Thread Bartosz Kosiorek

Hi.
I would like to mention that all my previous times, was measured for clean
Generation (I deleted all generation files)
I will try to make bisect build, to check where regression occur.

Now I would like to present results with enabled cleaning only on first run:

CMake 3.4.3 Unix Makefile generation
1. Clean run (rm -rf Output)
real 1m31.233s
user 1m26.136s
sys 0m3.004s
2. Dirty run (no deletion)
real 1m27.101s
user 1m24.620s
sys 0m2.988s
3. Dirty run (no deletion)
real 1m26.237s
user 1m23.240s
sys 0m3.020s
4. Dirty run (no deletion)
real 1m27.670s
user 1m24.764s
sys 0m2.816s

CMake 3.5.0-rc1 Unix Makefile generation
1. Clean run (rm -rf Output)
real 2m34.244s
user 2m30.176s
sys 0m3.220s
2. Dirty run (no deletion)
real 2m35.259s
user 2m32.400s
sys 0m3.116s
3. Dirty run (no deletion)
real 2m27.881s
user 2m25.184s
sys 0m3.032s
4. Dirty run (no deletion)
real 2m25.139s
user 2m22.552s
sys 0m2.984s

2016-02-04 18:57 GMT+01:00 Brad King <brad.k...@kitware.com>:

> On 02/04/2016 10:29 AM, Bartosz Kosiorek wrote:
> > I downloaded cmakes from website:
> > https://cmake.org/download/
> >
> > All generation were done on clean output (deleted all files generated by
> cmake)
> > on the same repository version, in the same directory.
> > The only difference was cmake version used for configuring.
> >
> > How I could check what was caused such long times?
>
> Try also timing the second and third runs on a single build tree
> to get timings without all the platform introspection tests.
>
> You could clone the CMake Git repository, build from source with
> -DCMAKE_BUILD_TYPE=RelWithDebInfo and then run it through a
> profiler (e.g. valgrind --tool=callgrind).  Alternatively you
> could `git bisect` between v3.4.3 and v3.5.0-rc1 to see if there
> is a small range of commits that causes the regression.  That
> could really help narrow it down.
>
> 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] Profile Cmake scripts

2016-01-05 Thread Bartosz Kosiorek

Hi Ben.

2016-01-04 17:39 GMT+01:00 Ben Boeckel :

> The
> big remaining problem is passing char* as an argument where functions do
> std::string(arg) right away. I fixed all of those which did explicit
> std::string conversions (via assignment or otherwise), but those which
> are conditional should get std::string overloads to avoid a
> malloc/copy/free penalty. There is a *lot* of work here though. The
> branch I had been working on (which is now woefully out-of-date) is 100
> commits long.
>

That's great news.
What is the branch name/link to these improvement?
Is it possible to push these improvements partially?

Maybe CMake community could continue working on that improvement?
It will be great to create ticket, in which propose solution will be
described.

BTW: Do you know why the Xcode and MS Visual Studio is slower than CMake
one ?

Here is the benchmarks for my internal project:

Xcode generation:
   real 6m31.733s
   user 4m51.862s
   sys 0m20.268s

Make generation:
   real 4m45.089s
   user 2m56.117s
   sys 0m17.481s

Ninja generation:
  real 2m48.585s
  user 2m30.712s
  sys 0m6.313s





>
> --Ben
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

2015-12-21 Thread Bartosz Kosiorek

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:

   real 6m31.733s

   user 4m51.862s

   sys 0m20.268s


Make generation:

   real 4m45.089s

   user 2m56.117s

   sys 0m17.481s


Ninja generation:

  real 2m48.585s

  user 2m30.712s

  sys 0m6.313s



Xcode generation + build time:

   real 64m3.238s

   user 353m36.825s

   sys 46m52.415s


Make generation + build time:

   real 61m2.583s

   user 358m7.464s

   sys 47m21.512s


So it seems in our case, for Generation performance step, we should use Ninja.


Best Regards

Bartosz



From: Ruslan Baratov <ruslan_bara...@yahoo.com>
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 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

Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

2015-12-11 Thread Bartosz Kosiorek

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
│   │   │   │   └── en.txt
│   │   │   └── resourcefile.txt
│   │   ├── lang
│   │   │   └── en.txt
│   │   └── mul
│   └── Current -> A
└── mul -> Versions/Current/mul


What do you think about that?

Here is the source code:

set_property(SOURCE module.modulemap
  PROPERTY MACOSX_PACKAGE_LOCATION "Modules")

set_property(
  SOURCE lang/en.txt lang/pl.txt
  PROPERTY MACOSX_PACKAGE_LOCATION "lang")

set(RESLIST 
mulres.txt
lang/pl.txt
resourcefile.txt
)

add_library(mul SHARED 
mul.c
mul.h
module.modulemap
lang/pl.txt
lang/en.txt
resourcefile.txt
mulres.txt)

# Create an iOS Framework bundle 
set_target_properties(mul PROPERTIES
  FRAMEWORK TRUE
  MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul
  MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42
  MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10
  XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer"
  PUBLIC_HEADER mul.h
  RESOURCE "${RESLIST}"
)

Thanks in advance 
Bartosz



From: clin...@elemtech.com <clin...@elemtech.com>
Sent: Friday, December 11, 2015 4:24 PM
To: Brad King
Cc: Bartosz Kosiorek; cmake-developers; Gregor Jasny
Subject: Re: [Apple/iOS/OS X] Create subdirectories in Resource directory for 
Frameworks and Application bundle.

- On Dec 11, 2015, at 7:36 AM, Brad King brad.k...@kitware.com wrote:

> On 12/10/2015 09:52 AM, Bartosz Kosiorek wrote:
>> How it is officialy supported to tell CMake to create subdirectories
>> inside "Resources" directory?
>
> I'm not particularly familiar with this infrastructure myself, but I
> do not know of any way to define such a layout now.  A new interface
> may have to be designed and implemented to achieve this.
>
> -Brad


This may not be what you are looking for.
You can place files in a bundle/framework at certain locations.
Perhaps in subdirectories under Resources/.
https://cmake.org/cmake/help/v3.4/prop_sf/MACOSX_PACKAGE_LOCATION.html

Clint
-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] Re: Create subdirectories in Resource directory for Frameworks and Application bundle.

2015-12-11 Thread Bartosz Kosiorek

Thanks Ruslan.


I will update documentation with information about such option (for Xcode 
generator)


Is it possible to mix arm and x86 architectures also for Make generator?

I'm very interesting in that bit :-)


Best Regards

Bartosz



From: Ruslan Baratov <ruslan_bara...@yahoo.com>
Sent: Saturday, December 12, 2015 2:15 AM
To: Bartosz Kosiorek
Cc: Clinton Stimpson; cmake-developers; Gregor Jasny
Subject: Re: [cmake-developers] [PATCH] Re: Create subdirectories in Resource 
directory for Frameworks and Application bundle.

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 <clin...@elemtech.com><mailto:clin...@elemtech.com>
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<mailto:clin...@elemtech.com> 
<clin...@elemtech.com><mailto: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 
<gan...@poczta.onet.pl><mailto:gan...@poczta.onet.pl>
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 "

[cmake-developers] [PATCH] Re: Create subdirectories in Resource directory for Frameworks and Application bundle.

2015-12-11 Thread Bartosz Kosiorek

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.

Best Regards
Bartosz



From: Clinton Stimpson <clin...@elemtech.com>
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 <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 <gan...@poczta.onet.pl>
> 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
> <clin...@elemtech.com<mailto:clin...@elemtech.com>>:

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

Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

2015-12-11 Thread Bartosz Kosiorek

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

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

Best Regards
Bartosz



2015-12-11 19:06 GMT+01:00 Clinton Stimpson <clin...@elemtech.com>:

>
>
> 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
> > │   │   │   │   └── en.txt
> > │   │   │   └── resourcefile.txt
> > │   │   ├── lang
> > │   │   │   └── en.txt
> > │   │   └── mul
> > │   └── Current -> A
> > └── mul -> Versions/Current/mul
> >
> >
> > What do you think about that?
> >
> > Here is the source code:
> >
> > set_property(SOURCE module.modulemap
> >   PROPERTY MACOSX_PACKAGE_LOCATION "Modules")
> >
> > set_property(
> >   SOURCE lang/en.txt lang/pl.txt
> >   PROPERTY MACOSX_PACKAGE_LOCATION "lang")
> >
> > set(RESLIST
> > mulres.txt
> > lang/pl.txt
> > resourcefile.txt
> > )
> >
> > add_library(mul SHARED
> > mul.c
> > mul.h
> > module.modulemap
> > lang/pl.txt
> > lang/en.txt
> > resourcefile.txt
> > mulres.txt)
> >
> > # Create an iOS Framework bundle
> > set_target_properties(mul PROPERTIES
> >   FRAMEWORK TRUE
> >   MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul
> >   MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42
> >   MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10
> >   XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer"
> >   PUBLIC_HEADER mul.h
> >   RESOURCE "${RESLIST}"
> > )
>
>
> Here is a CMakeLists.txt that will give you the desired layout.
> I also see that MACOSX_PACKAGE_LOCATION doesn't work with RESOURCE.
>
>
> set_property(SOURCE module.modulemap
>   PROPERTY MACOSX_PACKAGE_LOCATION "Modules")
>
> set_property(
>   SOURCE lang/pl.txt lang/en.txt
>   PROPERTY MACOSX_PACKAGE_LOCATION "Resources/lang")
>
> set(RESLIST
>

[cmake-developers] [Apple/iOS/OS X] Create subdirectories in Resource directory for Frameworks and Application bundle.

2015-12-10 Thread Bartosz Kosiorek

Hello.


With CMake 3.5 it is possible to put Resources into the Bundle (Frameworks and 
Applications)


More information:

https://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/prop_tgt/RESOURCE.rst


So with code:

  add_executable(ExecutableTarget
addDemo.c
resourcefile.txt
appresourcedir/appres.txt
  )

  target_link_libraries(ExecutableTarget heymath mul)

  set(RESOURCE_FILES
resourcefile.txt
appresourcedir/appres.txt
  )

  set_target_properties(ExecutableTarget PROPERTIES
MACOSX_BUNDLE TRUE
MACOSX_FRAMEWORK_IDENTIFIER org.cmake.ExecutableTarget
RESOURCE "${RESOURCE_FILES}"
  )

For OS X systems it will produce following directory structure::

  ExecutableTarget.app/
Contents
  Info.plist
  MacOS
ExecutableTarget
  Resources
appres.txt
resourcefile.txt


How it is officialy supported to tell CMake to create subdirectories inside 
"Resources" directory?


As the result I would like to get, following directory structure:

  ExecutableTarget.app/
Contents/
  Info.plist
  MacOS/
ExecutableTarget
  Resources/
appres.txt?

appresourcedir/

   ?resourcefile.txt?


I would like to update documentation to describe how to do that.


Thanks in advance

Bartosz

-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] Support multiple directories by "cmake -E make_directory" command

2015-12-09 Thread Bartosz Kosiorek


Hello.


With following patch, I have added support for multiple directories for 
make_directory command.


?Best Regards

Bartosz
From e189db26e60254712e3e73a11296c58d8f61fe68 Mon Sep 17 00:00:00 2001
From: Bartosz Kosiorek <gan...@poczta.onet.pl>
Date: Wed, 9 Dec 2015 15:59:43 +0100
Subject: [PATCH] Extend make_directory command to support multiple directories

---
 Help/manual/cmake.1.rst   |  9 +
 Source/cmcmd.cxx  | 19 ---
 .../E_make_directory-directory-with-parent-result.txt |  1 +
 .../E_make_directory-directory-with-parent-stderr.txt |  0
 ...ke_directory-three-directories-and-file-result.txt |  1 +
 ...ke_directory-three-directories-and-file-stderr.txt |  1 +
 .../E_make_directory-three-directories-result.txt |  1 +
 .../E_make_directory-three-directories-stderr.txt |  0
 Tests/RunCMake/CommandLine/RunCMakeTest.cmake | 14 ++
 9 files changed, 35 insertions(+), 11 deletions(-)
 create mode 100644 Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-result.txt
 create mode 100644 Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-stderr.txt
 create mode 100644 Tests/RunCMake/CommandLine/E_make_directory-three-directories-and-file-result.txt
 create mode 100644 Tests/RunCMake/CommandLine/E_make_directory-three-directories-and-file-stderr.txt
 create mode 100644 Tests/RunCMake/CommandLine/E_make_directory-three-directories-result.txt
 create mode 100644 Tests/RunCMake/CommandLine/E_make_directory-three-directories-stderr.txt

diff --git a/Help/manual/cmake.1.rst b/Help/manual/cmake.1.rst
index 4cbe976..3cd7888 100644
--- a/Help/manual/cmake.1.rst
+++ b/Help/manual/cmake.1.rst
@@ -167,7 +167,8 @@ Available commands are:
   Change the current working directory and run a command.
 
 ``compare_files  ``
-  Check if file1 is same as file2.
+  Check if  is same as . If files are the same,
+  then returns 0, if not itreturns 1.
 
 ``copy ... ``
   Copy files to  (either file or directory).
@@ -194,10 +195,10 @@ Available commands are:
   Run command in a modified environment.
 
 ``environment``
-  Display the current environment.
+  Display the current environment variables.
 
-``make_directory ``
-  Create a directory.
+``make_directory ...``
+  Create parent and  directories.
 
 ``md5sum ...``
   Compute md5sum of files.
diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx
index 6a4234f..fb7b1f5 100644
--- a/Source/cmcmd.cxx
+++ b/Source/cmcmd.cxx
@@ -68,7 +68,7 @@ void CMakeCommandUsage(const char* program)
 << "  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"
+<< "  make_directory ...   - create parent and  directories\n"
 << "  md5sum ...  - compute md5sum of files\n"
 << "  remove [-f] ... - remove the file(s), use -f to force "
"it\n"
@@ -447,15 +447,20 @@ int cmcmd::ExecuteCMakeCommand(std::vector& args)
   }
 #endif
 
-else if (args[1] == "make_directory" && args.size() == 3)
+else if (args[1] == "make_directory" && args.size() > 2)
   {
-  if(!cmSystemTools::MakeDirectory(args[2].c_str()))
+  // If error occurs we want to continue copying next files.
+  bool return_value = 0;
+  for (std::string::size_type cc = 2; cc < args.size(); cc ++)
 {
-std::cerr << "Error making directory \"" << args[2]
-  << "\".\n";
-return 1;
+if(!cmSystemTools::MakeDirectory(args[cc].c_str()))
+  {
+  std::cerr << "Error creating directory \""
+<< args[cc] << "\".\n";
+  return_value = 1;
+  }
 }
-  return 0;
+  return return_value;
   }
 
 else if (args[1] == "remove_directory" && args.size() == 3)
diff --git a/Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-result.txt b/Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-result.txt
new file mode 100644
index 000..573541a
--- /dev/null
+++ b/Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-result.txt
@@ -0,0 +1 @@
+0
diff --git a/Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-stderr.txt b/Tests/RunCMake/CommandLine/E_make_directory-directory-with-parent-stderr.txt
new file mode 100644
index 000..e69de29
diff --git a/Tests/RunCMake/CommandLine/E_make_directory-three-directories-and-file-result.txt b/Tests/RunCMake/CommandLine/E_make_directory-three-dir

[cmake-developers] [PATCH] Add support for multiple parameters in cmake -E copy_directory command

2015-12-06 Thread Bartosz Kosiorek

Hello.


I following patch I have added support for multiple source directories into 
copy_directory command.


Comments are welcomed.


Best Regards

Bartosz
From 6ff0139ae43d4ac4a503007dd6abac5dcefd1083 Mon Sep 17 00:00:00 2001
From: Bartosz Kosiorek <gan...@poczta.onet.pl>
Date: Sun, 6 Dec 2015 20:30:44 +0100
Subject: [PATCH] Add support for multiple directory for "copy_directory"
 command

---
 Help/manual/cmake.1.rst| 11 +---
 Source/cmcmd.cxx   | 30 +-
 ...ree-source-files-target-is-directory-result.txt |  1 +
 ...ree-source-files-target-is-directory-stderr.txt |  0
 ...ry-three-source-files-target-is-file-result.txt |  1 +
 ...ry-three-source-files-target-is-file-stderr.txt |  3 +++
 ...ree-source-files-target-is-not-exist-result.txt |  1 +
 ...ree-source-files-target-is-not-exist-stderr.txt |  0
 Tests/RunCMake/CommandLine/RunCMakeTest.cmake  | 17 
 Tests/RunCMake/CommandLine/copy_input/d1/d1.txt|  0
 Tests/RunCMake/CommandLine/copy_input/d2/d2.txt|  0
 Tests/RunCMake/CommandLine/copy_input/d3/d3.txt|  0
 12 files changed, 49 insertions(+), 15 deletions(-)
 create mode 100644 Tests/RunCMake/CommandLine/E_copy_directory-three-source-files-target-is-directory-result.txt
 create mode 100644 Tests/RunCMake/CommandLine/E_copy_directory-three-source-files-target-is-directory-stderr.txt
 create mode 100644 Tests/RunCMake/CommandLine/E_copy_directory-three-source-files-target-is-file-result.txt
 create mode 100644 Tests/RunCMake/CommandLine/E_copy_directory-three-source-files-target-is-file-stderr.txt
 create mode 100644 Tests/RunCMake/CommandLine/E_copy_directory-three-source-files-target-is-not-exist-result.txt
 create mode 100644 Tests/RunCMake/CommandLine/E_copy_directory-three-source-files-target-is-not-exist-stderr.txt
 create mode 100644 Tests/RunCMake/CommandLine/copy_input/d1/d1.txt
 create mode 100644 Tests/RunCMake/CommandLine/copy_input/d2/d2.txt
 create mode 100644 Tests/RunCMake/CommandLine/copy_input/d3/d3.txt

diff --git a/Help/manual/cmake.1.rst b/Help/manual/cmake.1.rst
index 086f259..4156638 100644
--- a/Help/manual/cmake.1.rst
+++ b/Help/manual/cmake.1.rst
@@ -170,13 +170,18 @@ Available commands are:
   Check if file1 is same as file2.
 
 ``copy ... ``
-  Copy files to 'destination' (either file or directory).
+  Copy files to  (either file or directory).
+  If multiple files are specified, the  must be
+  directory and it must exists.
 
-``copy_directory  ``
-  Copy directory 'source' content to directory 'destination'.
+``copy_directory ... ``
+  Copy content of ... directories to  directory.
+  If  directory is not exist, then it will be created.
 
 ``copy_if_different ... ``
   Copy files if input has changed. Destination could be file or directory.
+  If multiple files are specified, the  must be
+  directory and it must exists.
 
 ``echo [...]``
   Displays arguments as text.
diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx
index 0dc5a9a..6a4234f 100644
--- a/Source/cmcmd.cxx
+++ b/Source/cmcmd.cxx
@@ -54,12 +54,12 @@ void CMakeCommandUsage(const char* program)
   errorStream
 << "Usage: " << program << " -E  [arguments...]\n"
 << "Available commands: \n"
-<< "  chdir dir cmd [args]...   - run command in a given directory\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 ... destination  - copy files to destination "
"(either file or directory)\n"
-<< "  copy_directory source destination   - copy directory 'source' "
-   "content to directory 'destination'\n"
+<< "  copy_directory ... destination   - copy content of ... "
+   "directories to 'destination' directory\n"
 << "  copy_if_different ... destination  - copy files if it has "
"changed\n"
 << "  echo [...]- displays arguments as text\n"
@@ -197,8 +197,8 @@ int cmcmd::ExecuteCMakeCommand(std::vector& args)
 args[args.size() - 1].c_str()))
   {
   std::cerr << "Error copying file (if different) from \""
- << args[cc] << "\" to \"" << args[args.size() - 1]
- << "\".\n";
+<< args[cc] << "\" to \"" << args[args.size() - 1]
+<< "\".\n";
   return_value = 1;
   }
 }
@@ -206,16 +206,22 @@ int cmcmd::ExecuteCMakeCommand(std::vector& args)
   }
 
 // Copy directory content
-if (args[1] == "copy_directory" && ar

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

2015-12-04 Thread Bartosz Kosiorek

Thanks Brad.

Unfortunately we cannot use file(GLOB), because it is executed during
generate step,
and we would like to copy files which is created during Build step.

Currently for filtering these files, we are using "cmake -E tar" to filter
these files (so it packing and upacking).
I think it is awful solution, but I cannot find better.
What would you propose in that case?

Is it possible to introduce "cmake -E list" command with wildcard support,
to be able to filter files/directories, during Build step?
The we couid use it to "cmake -E copy" command

Best Regards
Bartosz

2015-12-04 16:35 GMT+01:00 Brad King <brad.k...@kitware.com>:

> On 12/04/2015 09:18 AM, Bartosz Kosiorek wrote:
> > Finally I manage to add wildcard support.
> > I have taken SimpleGlob.h library from:
> > https://github.com/brofield/simpleopt
>
> We don't want to do wildcard expansion in CMake commands.  We want to leave
> it up to the shell to expand wildcards on the command line, or have
> explicit
> file(GLOB) commands in CMake script code.
>
> I've applied the patches from the previous post, with a slightly
> different breakdown and some fixes to the test:
>
>  cmake: Improve '-E' help message formatting
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0be5020b
>
>  cmake: Teach -E copy[_if_different] to support multiple files (#15703)
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=384ae551
>
> 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] 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 <ruslan_bara...@yahoo.com>
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 <ruslan_bara...@yahoo.com>
> 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? d

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 <ruslan_bara...@yahoo.com>
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 <ruslan_bara...@yahoo.com>
> 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

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 <brad.k...@kitware.com>
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 <cmake-developers-boun...@cmake.org> on behalf of Brad 
King <brad.k...@kitware.com>
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] [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 <brad.k...@kitware.com>
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"
 <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 ... -

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

2015-12-02 Thread Bartosz Kosiorek

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?


Best Regards
Bartosz


From: Ruslan Baratov <ruslan_bara...@yahoo.com>
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 <cmake-developers-boun...@cmake.org> on behalf of 
> Gregor Jasny via cmake-developers <cmake-developers@cmake.org>
> 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

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

2015-12-02 Thread Bartosz Kosiorek

Hi.


This patch allows to use multiple files in commands "copy" and 
"copy_if_different".
Input files could be merged with wildcards. For example:
 ./bin/cmake -E copy bin/* CMakeFiles/* file.tar dupajasia

If wrong file path were provided as input then the error will be displayed, but 
rest of the files will be copied. For example:
./bin/cmake -E copy bin/* CMakeFiles/* wrong_file file.tar dupajasia/
Error copying file "wrong_file" to "dupajasia/".

If multipile input files were provided, then destination must be directory. 
Example:
./bin/cmake -E copy bin/* CMakeFiles/* wrong_file file.tar dupajasia/ctest
 Error: Target (copy) "dupajasia/ctest" is not a directory.

./bin/cmake -E copy bin/* dupajasia/ctest?
 Error: Target (copy) "dupajasia/ctest?" is not a directory.

If only one input file was provided, then destination could be either
file or directory:
 ./bin/cmake -E copy file.tar dupajasia/ctest

This path is starting point for fixing bug 15703:
?https://public.kitware.com/Bug/view.php?id=15703

Best Regards
Bartosz

From 8225688074386ac8633bad5e6f9fdb4a7caf9775 Mon Sep 17 00:00:00 2001
From: "Bartosz Kosiorek bartosz.kosio...@tomtom.com"
 <bartosz.kosio...@tomtom.com>
Date: Thu, 3 Dec 2015 00:43:37 +0100
Subject: [PATCH] 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"
-<< "

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

2015-12-02 Thread Bartosz Kosiorek

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?


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

[cmake-developers] [PATCH] Fix Resource directory structure for iOS Bundles (Framework and Application), update Tests and Help

2015-12-02 Thread Bartosz Kosiorek

Hello.


Patch in attachment allows to place resources in main Bundle directory (iOS 
specification), instead to always place in Resource directory (OSX 
specification.

See more:

https://public.kitware.com/Bug/view.php?id=15848

?

I tested it intensively with different generators (Makefile, Ninja), and it 
works perfectly.


I also extended existing Framework tests, to check Resource directory structure 
and Headers directory structure.

All tests on my machine passed.


Is it possible to apply this patch?

We need this fix in CMake 3.5.


Thanks in advance

Bartosz


0001-Fix-iOS-resource-directory-update-help-and-test-bug-.patch
Description: 0001-Fix-iOS-resource-directory-update-help-and-test-bug-.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] Fix Resource directory structure for iOS Bundles (Framework and Application), and update documentation

2015-11-26 Thread Bartosz Kosiorek

Good Morning/Evening.

I applied all post review comments.
Feedback is much welcomed.

Thanks in advance
Bartosz

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Friday, November 20, 2015 3:17 PM
To: Bartosz Kosiorek
Cc: cmake-developers@cmake.org; Gregor Jasny
Subject: Re: [cmake-developers] [PATCH] Fix Resource directory structure for 
iOS Bundles (Framework and Application), and update documentation

On 11/18/2015 11:05 AM, Bartosz Kosiorek wrote:
> With this simple patch in attachment I would like to do two things:

Thanks for working on this.  Here are some comments on the documentation.

> +This property may be set to a list of files to be placed in the 
> +corresponding  directory (eg. ``Resources`` directory for OS X) 
> +inside the bundle.  On non-Apple

Please wrap long lines.

> +Following example of Application Bundle:
> +::
> +  add_executable(ExecutableTarget
> +addDemo.c
> +resourcefile.txt
> +appresourcedir/appres.txt
> +  )

CMake code examples should use the `.. code-block:: cmake` directive.

> +  set_target_properties(ExecutableTarget PROPERTIES
> +MACOSX_BUNDLE TRUE
> +MACOSX_FRAMEWORK_IDENTIFIER org.cmake.ExecutableTarget
> +RESOURCE "${RESOURCE_FILES}"
> +  )
> +::

In reStructuredText syntax there is no trailing `::` in code blocks.

> +
> +will produce flat structure for iOS systems:
> +::
> +  ExecutableTarget.app
> +appres.txt
> +ExecutableTarget
> +Info.plist
> +resourcefile.txt
> +::

This can be written like this:

 will produce flat structure for iOS systems::

   ExecutableTarget.app
 appres.txt
 ExecutableTarget
 Info.plist
 resourcefile.txt

> \ No newline at end of file

Please add a trailing newline.

> Please let me know what do you think about that patch implementation.

Good start.  Please also extend the Tests/RunCMake/Framework test 
FrameworkLayout case to cover such resource files.

Thanks,
-Brad



0001-Fix-resource-directory-structure-update-help-and-tes.patch
Description: 0001-Fix-resource-directory-structure-update-help-and-tes.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] FW: [PATCH] CMake 3.4.0rc3 Apple documentation update

2015-11-20 Thread Bartosz Kosiorek

Hello
Could you please give me an feedback regarding that documentation patch?
I have some spare time to fix that.

Because I didn't tested cmake with watchOS and TVos, I wasn't mention about 
other than OSX and iOS system.
Once I have such hardware and test it, I will update documentation.

Thanks in advance
Bartosz

-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of 
Bartosz Kosiorek
Sent: Wednesday, November 11, 2015 5:48 AM
To: Gregor Jasny; cmake-developers@cmake.org
Subject: [SPAM] [cmake-developers] [PATCH] CMake 3.4.0rc3 Apple documentation 
update
Importance: Low

Hello.

I think before release CMake 3.4.0 the documentation needs to be updated, to 
reflect last changes in CMake regarding Apple platform.

I have created bug report for that issue:
https://public.kitware.com/Bug/view.php?id=15843

I also updated documentation. Please take a look at attachment.

Best Regards
Bartosz
From f4889ec1dbe8348baab544e6aa378f8cee12b2b7 Mon Sep 17 00:00:00 2001
From: Bartosz Kosiorek <gan...@poczta.onet.pl>
Date: Wed, 11 Nov 2015 05:37:15 +0100
Subject: [PATCH] Update documentation to reflect support for iOS.

---
 Help/manual/cmake-buildsystem.7.rst   |  9 ++---
 Help/prop_sf/MACOSX_PACKAGE_LOCATION.rst  | 26 +
 Help/prop_tgt/BUNDLE.rst  |  6 +++---
 Help/prop_tgt/BUNDLE_EXTENSION.rst|  4 ++--
 Help/prop_tgt/ENABLE_EXPORTS.rst  |  4 ++--
 Help/prop_tgt/FRAMEWORK.rst   | 28 +++
 Help/prop_tgt/FRAMEWORK_VERSION.rst   |  3 +++
 Help/prop_tgt/MACOSX_BUNDLE.rst   | 16 +++
 Help/prop_tgt/MACOSX_BUNDLE_INFO_PLIST.rst|  4 ++--
 Help/prop_tgt/MACOSX_FRAMEWORK_INFO_PLIST.rst |  4 ++--
 Help/prop_tgt/MACOSX_RPATH.rst|  6 +++---
 Help/prop_tgt/OSX_ARCHITECTURES_CONFIG.rst|  2 +-
 Help/prop_tgt/PRIVATE_HEADER.rst  | 10 +-
 Help/prop_tgt/PUBLIC_HEADER.rst   | 12 ++--
 Help/prop_tgt/RESOURCE.rst| 12 ++--
 Help/variable/APPLE.rst   |  4 ++--
 Help/variable/CMAKE_ENABLE_EXPORTS.rst|  8 
 Help/variable/CMAKE_HOST_SYSTEM_NAME.rst  |  2 +-
 Help/variable/CMAKE_INSTALL_NAME_DIR.rst  |  2 +-
 Help/variable/CMAKE_MACOSX_RPATH.rst  |  2 +-
 Help/variable/CMAKE_OSX_ARCHITECTURES.rst |  2 +-
 21 files changed, 97 insertions(+), 69 deletions(-)

diff --git a/Help/manual/cmake-buildsystem.7.rst b/Help/manual/cmake-buildsystem.7.rst
index bc633e6..475d241 100644
--- a/Help/manual/cmake-buildsystem.7.rst
+++ b/Help/manual/cmake-buildsystem.7.rst
@@ -95,15 +95,18 @@ Apple Frameworks
 """"""""""""""""
 
 A ``SHARED`` library may be marked with the :prop_tgt:`FRAMEWORK`
-target property to create an OS X Framework:
+target property to create an OS X or iOS Framework Bundle.
+The :prop_tgt:`MACOSX_FRAMEWORK_IDENTIFIER` sets ``CFBundleIdentifier`` key
+and it uniquely identifies the bundle. 
 
 .. code-block:: cmake
 
   add_library(MyFramework SHARED MyFramework.cpp)
   set_target_properties(MyFramework PROPERTIES
-FRAMEWORK 1
+FRAMEWORK TRUE
 FRAMEWORK_VERSION A
-)
+MACOSX_FRAMEWORK_IDENTIFIER org.cmake.MyFramework
+  )
 
 .. _`Object Libraries`:
 
diff --git a/Help/prop_sf/MACOSX_PACKAGE_LOCATION.rst b/Help/prop_sf/MACOSX_PACKAGE_LOCATION.rst
index 27f2929..1b5b97b 100644
--- a/Help/prop_sf/MACOSX_PACKAGE_LOCATION.rst
+++ b/Help/prop_sf/MACOSX_PACKAGE_LOCATION.rst
@@ -1,19 +1,21 @@
 MACOSX_PACKAGE_LOCATION
 ---
 
-Place a source file inside a Mac OS X bundle, CFBundle, or framework.
+Place a source file inside a Application Bundle (:prop_tgt:`MACOSX_BUNDLE`), 
+Core Foundation Bundle (:prop_tgt:`BUNDLE`), or Framework Bundle (:prop_tgt:`FRAMEWORK`). 
+It is applicable for OS X and iOS.
 
-Executable targets with the MACOSX_BUNDLE property set are built as
-Mac OS X application bundles on Apple platforms.  Shared library
-targets with the FRAMEWORK property set are built as Mac OS X
-frameworks on Apple platforms.  Module library targets with the BUNDLE
-property set are built as Mac OS X CFBundle bundles on Apple
+Executable targets with the :prop_tgt:`MACOSX_BUNDLE` property set are built as
+OS X or iOS application bundles on Apple platforms.  Shared library
+targets with the :prop_tgt:`FRAMEWORK` property set are built as OS X or iOS
+frameworks on Apple platforms.  Module library targets with the :prop_tgt:`BUNDLE`
+property set are built as OS X ``CFBundle`` bundles on Apple
 platforms.  Source files listed in the target with this property set
 will be copied to a directory inside the bundle or framework content
-folder specified by the property value.  For bundles the content
-folder is ".app/Contents".  For frameworks the content fol

[cmake-developers] [PATCH] Fix Resource directory structure for iOS Bundles (Framework and Application), and update documentation

2015-11-18 Thread Bartosz Kosiorek

Hello

With this simple patch in attachment I would like to do two things:

1. Fix Resources directory structure for iOS Framework and Application Bundles. 
A typical iOS application bundle contains the application executable and any 
resources used by the application (for instance, the application icon, other 
images, and localized content) in the top-level bundle directory. More 
information: 
https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html
Unfortunately currently in CMake, all iOS resources is placed in "Resources" 
directory. This patch fix that.

2. Update documentation about RESOURCE target property, to describe that 
RESOURCE property is also applicable for all Bundles (Framework Bundles, 
Application Bundles and CF Bundles). I also added example of output for 
different platforms (iOS, OS X and Linux)

More information you could find at:
https://public.kitware.com/Bug/view.php?id=15848

Please let me know what do you think about that patch implementation.

Thanks in advance
Bartosz

From: Florent Castelli <florent.caste...@gmail.com>
Sent: Tuesday, November 17, 2015 5:52 PM
To: Ruslan Baratov
Cc: Bartosz Kosiorek; CMake Developers; Gregor Jasny
Subject: Re: [cmake-developers] [PATCH] iOS Framework Bundle support

In my case, I’ve switched all my company builds from xcodebuild (or msbuild) to 
Ninja as it is much faster and parallelises the build better on all platforms. 
CI loop is much faster thanks to this.

There is some maintenance to make sure the generated Ninja and Xcode projects 
both work to support 2 different use cases (CI and normal development with easy 
access to debugger), but it’s worth it and not a cause of much problems.

The only times it doesn’t work is when you rely on “magic” features from Xcode 
like lazy include paths or some other flags that add some “mysterious” 
additional build step.
Though, a trained build engineer should know what those magical features are 
and translate them to the right command line that just works everywhere.

/Florent

> On 17 Nov 2015, at 08:42, Ruslan Baratov via cmake-developers 
> <cmake-developers@cmake.org> wrote:
>
> 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/Content

Re: [cmake-developers] [PATCH] iOS Framework Bundle support

2015-11-13 Thread Bartosz Kosiorek

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 ?

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 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] iOS Framework Bundle support

2015-11-12 Thread Bartosz Kosiorek

Hello.

With this tiny little patch, the correct directory structure for iOS Frameworks 
is created.

The changes are backward compatible (it is not touching OS X at all, only iOS 
Frameworks).
The risk of regression is very low, as the change is for iOS frameworks, and 
officially CMake 3.4 do not support iOS.

I tested it manually by using scripts from previous mail for Xcode and Makefile 
generators, under iOS 9, and it fix directory structure.
After apply this patch, iOS Frameworks created by CMake are working perfectly 
for me.

Best Regards
Bartosz

From: cmake-developers <cmake-developers-boun...@cmake.org> on behalf of 
Bartosz Kosiorek <bartosz.kosio...@tomtom.com>
Sent: Wednesday, November 11, 2015 2:19 AM
To: Gregor Jasny; cmake-developers@cmake.org
Subject: Re: [cmake-developers] [PATCH] iOS Framework Bundle support

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

Expected result:
- Correct iOS Application Bundle in directory: addDemoCmake.app
- Correct iOS Dynamic Framework Bundle in directory: 
shared_empty/mul/mul.framework/

Current result:
- Correct iOS Application Bundle in directory: addDemoCmake.app
- Incorrect iOS Dynamic Framework Bundle in directory: 
shared_empty/mul/mul.framework/
It looks like:

find mul.framework/
mul.framework/
mul.framework//Headers
mul.framework//Headers/mul.h
mul.framework//Modules
mul.framework//Modules/module.modulemap
mul.framework//mul
mul.framework//Resources
mul.framework//Resources/Info.plist
mul.framework//Versions
mul.framework//Versions/Current

What it wrong in with that Framework :
1. Xcode expect that iOS Framework have Info.plist in main Framework directory 
(mul.framework/Info.plist).
2. mul.framework//Versions/ and mul.framework//Resources is not needed and 
shouldn't be produced (Info.plist should be moved to root Framework directory)
3. mul.framework//Versions/Current symlink is pointing to not existing "A" 
version directory

Now I see that my patch should be simplified to few lines. I will provide fix 
later.
My previous wrong assumption was that CMake 3.4 do not change anything in 
creating iOS Bundles.

@Gregor Do you think it will be possible to fix that issue in CMake 3.4.0, to 
have full support for iOS (both from Application and Frameworks) ?

Best Regards
Bartosz

From: Gregor Jasny <gja...@googlemail.com>
Sent: Tuesday, November 10, 2015 9:54 PM
To: Bartosz Kosiorek; cmake-developers@cmake.org
Subject: Re: [cmake-developers] [PATCH] iOS Framework Bundle support

Hello,

On 10/11/15 16:22, Bartosz Kosiorek wrote:
> My name is Bartosz Kosiorek and I'm TomTom developer and Open Source 
> enthusiast.

I'm Gregor a part time contributor to CMake. During the last months I
mostly worked on Xcode support.

> Last time in our products, we notice that cmake is not creating correct iOS 
> Frameworks Bundle.
> For iOS Frameworks, not versioned Bundle is needed, eg.:
>
>   iOSFramework.framework/
>   iOSFramework
>   Info.plist
>   Headers
>
>
>
> Unfortunately with current version of CMake (3.4.0), it produces OS X 
> Framework Bundle, with versions inside, eg.:
>
>   MyFramework.framework/
> MyFramework -> Versions/Current/MyFramework
> Resources -> Versions/Current/Resources
> Versions/
> A/
> MyFramework
> Headers
> Resources/
>  Info.plist
> Current -> A
>
>
>
> You could test it with my example project in attachment 
> (cmake_shared_ios_framework.zip).

Unfortunately I cannot reproduce the problem. Could you please write
down the exact steps you took to compile the example in the zip file?
Please also Xcode and cmake version.

That's what I see (cmake master, Xcode generator and Xcode 7.1):

$ find _build/shared_empty/mul/Debug-iphonesimulator/mul.framework
_build/shared_empty/mul/Debug-iphonesimulator/mul.framework
_build/shared_empty/mul/Debug-iphonesimulator/mul.framework/Headers
_build/shared_empty/mul/Debug-iphonesimulator/mul.framework/Headers/mul.h
_build/shared_empty/mul/Debug-iphonesimulator/mul.framework/Info.plist
_build/shared_empty/mul/Debug-iphonesimulator/mul.framework/Modules
_build/shared_empty/mul/Debug-iphonesimulator/mul.framework/Modules/module.modulemap
_build/shared_empty/mul/Debug-iphonesimulator/mul.framework/mul

> The iOS Application Bundle was already fixed in CMake 3.4.0. Unfortunately 
>

Re: [cmake-developers] [PATCH] CMake 3.4.0rc3 Apple documentation update

2015-11-11 Thread Bartosz Kosiorek

Hi.

Unfortunately I do not know such umbrella word.

I haven't tested watchOS and tvOS with frameworks, so maybe we shouldn't
mention it, as it is not officialy supported?

Did you manage to reproduce iOS Framework issue, with my in my example? I
have have describe a way how to reproduce it in details. I'm using iOS 9
and Makefile for generate.

Best Regards
Bartosz

W dniu środa, 11 listopada 2015 Gregor Jasny via cmake-developers <
cmake-developers@cmake.org> napisał(a):
> On 11/11/15 05:48, Bartosz Kosiorek wrote:
>>
>> Hello.
>>
>> I think before release CMake 3.4.0 the documentation needs to be
updated, to reflect last changes in CMake regarding Apple platform.
>>
>> I have created bug report for that issue:
>> https://public.kitware.com/Bug/view.php?id=15843
>>
>> I also updated documentation. Please take a look at attachment.
>
> Thank you for extending the documentation. The problem I see is that
besides MacOSX and iOS there is now also watchOS and tvOS. Do we want to
mention them explicitely or is there a nice "umbrella" word for them?
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-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] iOS Framework Bundle support

2015-11-10 Thread Bartosz Kosiorek

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

Expected result:
- Correct iOS Application Bundle in directory: addDemoCmake.app
- Correct iOS Dynamic Framework Bundle in directory: 
shared_empty/mul/mul.framework/

Current result:
- Correct iOS Application Bundle in directory: addDemoCmake.app
- Incorrect iOS Dynamic Framework Bundle in directory: 
shared_empty/mul/mul.framework/
It looks like:

find mul.framework/
mul.framework/
mul.framework//Headers
mul.framework//Headers/mul.h
mul.framework//Modules
mul.framework//Modules/module.modulemap
mul.framework//mul
mul.framework//Resources
mul.framework//Resources/Info.plist
mul.framework//Versions
mul.framework//Versions/Current

What it wrong in with that Framework :
1. Xcode expect that iOS Framework have Info.plist in main Framework directory 
(mul.framework/Info.plist). 
2. mul.framework//Versions/ and mul.framework//Resources is not needed and 
shouldn't be produced (Info.plist should be moved to root Framework directory)
3. mul.framework//Versions/Current symlink is pointing to not existing "A" 
version directory

Now I see that my patch should be simplified to few lines. I will provide fix 
later.
My previous wrong assumption was that CMake 3.4 do not change anything in 
creating iOS Bundles.

@Gregor Do you think it will be possible to fix that issue in CMake 3.4.0, to 
have full support for iOS (both from Application and Frameworks) ?

Best Regards
Bartosz

From: Gregor Jasny <gja...@googlemail.com>
Sent: Tuesday, November 10, 2015 9:54 PM
To: Bartosz Kosiorek; cmake-developers@cmake.org
Subject: Re: [cmake-developers] [PATCH] iOS Framework Bundle support

Hello,

On 10/11/15 16:22, Bartosz Kosiorek wrote:
> My name is Bartosz Kosiorek and I'm TomTom developer and Open Source 
> enthusiast.

I'm Gregor a part time contributor to CMake. During the last months I
mostly worked on Xcode support.

> Last time in our products, we notice that cmake is not creating correct iOS 
> Frameworks Bundle.
> For iOS Frameworks, not versioned Bundle is needed, eg.:
>
>   iOSFramework.framework/
>   iOSFramework
>   Info.plist
>   Headers
>
>
>
> Unfortunately with current version of CMake (3.4.0), it produces OS X 
> Framework Bundle, with versions inside, eg.:
>
>   MyFramework.framework/
> MyFramework -> Versions/Current/MyFramework
> Resources -> Versions/Current/Resources
> Versions/
> A/
> MyFramework
> Headers
> Resources/
>  Info.plist
> Current -> A
>
>
>
> You could test it with my example project in attachment 
> (cmake_shared_ios_framework.zip).

Unfortunately I cannot reproduce the problem. Could you please write
down the exact steps you took to compile the example in the zip file?
Please also Xcode and cmake version.

That's what I see (cmake master, Xcode generator and Xcode 7.1):

$ find _build/shared_empty/mul/Debug-iphonesimulator/mul.framework
_build/shared_empty/mul/Debug-iphonesimulator/mul.framework
_build/shared_empty/mul/Debug-iphonesimulator/mul.framework/Headers
_build/shared_empty/mul/Debug-iphonesimulator/mul.framework/Headers/mul.h
_build/shared_empty/mul/Debug-iphonesimulator/mul.framework/Info.plist
_build/shared_empty/mul/Debug-iphonesimulator/mul.framework/Modules
_build/shared_empty/mul/Debug-iphonesimulator/mul.framework/Modules/module.modulemap
_build/shared_empty/mul/Debug-iphonesimulator/mul.framework/mul

> The iOS Application Bundle was already fixed in CMake 3.4.0. Unfortunately 
> still iOS Frameworks are not produced correctly (Xcode refuses to sign such 
> Frameworks if you would like to push it into iOS device).
>
> In attachment I added solution to produce correct iOS Framework (for OSX 
> Frameworks will be produced normally).
>
>
>
> Could you please give some comment about that?
>
> Do you think architecture of that solution is correct?

I'd go for an early return from cmOSXBundleGenerator::CreateFramework if
we're building for iOS. The code of CreateIOSFramework is just too similar.

> I would like to do next:
>
> - Refactor code, to have more explicitly names (OSX, iOS or Apple)
>
> - Update documentation
>
> - add some unit tests for creating iOS Frameworks

I would like to see a test for that topic. If you'd like to try please
have a look at:
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=744e6c49

[cmake-developers] [PATCH] CMake 3.4.0rc3 Apple documentation update

2015-11-10 Thread Bartosz Kosiorek

Hello.

I think before release CMake 3.4.0 the documentation needs to be updated, to 
reflect last changes in CMake regarding Apple platform.

I have created bug report for that issue:
https://public.kitware.com/Bug/view.php?id=15843

I also updated documentation. Please take a look at attachment.

Best Regards
Bartosz
From f4889ec1dbe8348baab544e6aa378f8cee12b2b7 Mon Sep 17 00:00:00 2001
From: Bartosz Kosiorek <gan...@poczta.onet.pl>
Date: Wed, 11 Nov 2015 05:37:15 +0100
Subject: [PATCH] Update documentation to reflect support for iOS.

---
 Help/manual/cmake-buildsystem.7.rst   |  9 ++---
 Help/prop_sf/MACOSX_PACKAGE_LOCATION.rst  | 26 +
 Help/prop_tgt/BUNDLE.rst  |  6 +++---
 Help/prop_tgt/BUNDLE_EXTENSION.rst|  4 ++--
 Help/prop_tgt/ENABLE_EXPORTS.rst  |  4 ++--
 Help/prop_tgt/FRAMEWORK.rst   | 28 +++
 Help/prop_tgt/FRAMEWORK_VERSION.rst   |  3 +++
 Help/prop_tgt/MACOSX_BUNDLE.rst   | 16 +++
 Help/prop_tgt/MACOSX_BUNDLE_INFO_PLIST.rst|  4 ++--
 Help/prop_tgt/MACOSX_FRAMEWORK_INFO_PLIST.rst |  4 ++--
 Help/prop_tgt/MACOSX_RPATH.rst|  6 +++---
 Help/prop_tgt/OSX_ARCHITECTURES_CONFIG.rst|  2 +-
 Help/prop_tgt/PRIVATE_HEADER.rst  | 10 +-
 Help/prop_tgt/PUBLIC_HEADER.rst   | 12 ++--
 Help/prop_tgt/RESOURCE.rst| 12 ++--
 Help/variable/APPLE.rst   |  4 ++--
 Help/variable/CMAKE_ENABLE_EXPORTS.rst|  8 
 Help/variable/CMAKE_HOST_SYSTEM_NAME.rst  |  2 +-
 Help/variable/CMAKE_INSTALL_NAME_DIR.rst  |  2 +-
 Help/variable/CMAKE_MACOSX_RPATH.rst  |  2 +-
 Help/variable/CMAKE_OSX_ARCHITECTURES.rst |  2 +-
 21 files changed, 97 insertions(+), 69 deletions(-)

diff --git a/Help/manual/cmake-buildsystem.7.rst b/Help/manual/cmake-buildsystem.7.rst
index bc633e6..475d241 100644
--- a/Help/manual/cmake-buildsystem.7.rst
+++ b/Help/manual/cmake-buildsystem.7.rst
@@ -95,15 +95,18 @@ Apple Frameworks
 """"""""""""""""
 
 A ``SHARED`` library may be marked with the :prop_tgt:`FRAMEWORK`
-target property to create an OS X Framework:
+target property to create an OS X or iOS Framework Bundle.
+The :prop_tgt:`MACOSX_FRAMEWORK_IDENTIFIER` sets ``CFBundleIdentifier`` key
+and it uniquely identifies the bundle. 
 
 .. code-block:: cmake
 
   add_library(MyFramework SHARED MyFramework.cpp)
   set_target_properties(MyFramework PROPERTIES
-FRAMEWORK 1
+FRAMEWORK TRUE
 FRAMEWORK_VERSION A
-)
+MACOSX_FRAMEWORK_IDENTIFIER org.cmake.MyFramework
+  )
 
 .. _`Object Libraries`:
 
diff --git a/Help/prop_sf/MACOSX_PACKAGE_LOCATION.rst b/Help/prop_sf/MACOSX_PACKAGE_LOCATION.rst
index 27f2929..1b5b97b 100644
--- a/Help/prop_sf/MACOSX_PACKAGE_LOCATION.rst
+++ b/Help/prop_sf/MACOSX_PACKAGE_LOCATION.rst
@@ -1,19 +1,21 @@
 MACOSX_PACKAGE_LOCATION
 ---
 
-Place a source file inside a Mac OS X bundle, CFBundle, or framework.
+Place a source file inside a Application Bundle (:prop_tgt:`MACOSX_BUNDLE`), 
+Core Foundation Bundle (:prop_tgt:`BUNDLE`), or Framework Bundle (:prop_tgt:`FRAMEWORK`). 
+It is applicable for OS X and iOS.
 
-Executable targets with the MACOSX_BUNDLE property set are built as
-Mac OS X application bundles on Apple platforms.  Shared library
-targets with the FRAMEWORK property set are built as Mac OS X
-frameworks on Apple platforms.  Module library targets with the BUNDLE
-property set are built as Mac OS X CFBundle bundles on Apple
+Executable targets with the :prop_tgt:`MACOSX_BUNDLE` property set are built as
+OS X or iOS application bundles on Apple platforms.  Shared library
+targets with the :prop_tgt:`FRAMEWORK` property set are built as OS X or iOS
+frameworks on Apple platforms.  Module library targets with the :prop_tgt:`BUNDLE`
+property set are built as OS X ``CFBundle`` bundles on Apple
 platforms.  Source files listed in the target with this property set
 will be copied to a directory inside the bundle or framework content
-folder specified by the property value.  For bundles the content
-folder is ".app/Contents".  For frameworks the content folder is
-".framework/Versions/".  For cfbundles the content
-folder is ".bundle/Contents" (unless the extension is changed).
-See the PUBLIC_HEADER, PRIVATE_HEADER, and RESOURCE target properties
-for specifying files meant for Headers, PrivateHeaders, or Resources
+folder specified by the property value.  For OS X Application Bundles the content
+folder is ``.app/Contents``.  For OS X Frameworks the content folder is
+``.framework/Versions/``.  For OS X CFBundles the content
+folder is ``.bundle/Contents`` (unless the extension is changed).
+See the :prop_tgt:`PUBLIC_HEADER`, :prop_tgt:`PRIVATE_HEADER`, and :p

37 matches

Mail list logo