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

Wed Nov 18 11:05:16 EST 2015

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.castelli at 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 at 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:gjasny at gmail.com]
>> Sent: Friday, November 13, 2015 2:09 PM
>> To: Bartosz Kosiorek; cmake-developers at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Create-flat-directory-structure-for-resources-in-iOS.patch
Type: application/octet-stream
Size: 3620 bytes
Desc: 0001-Create-flat-directory-structure-for-resources-in-iOS.patch
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151118/5f63b0bc/attachment.obj>