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

Ruslan Baratov ruslan_baratov at yahoo.com
Mon Dec 21 13:59:21 EST 2015


On 21-Dec-15 17:19, Bartosz Kosiorek wrote:
>
> Thanks Ruslan for explanation.
>
>
> Currently we already building fat library for arm (armv7;armv7s;arm64) 
> and x86 (i386;x86_64).
>
>
> That's why my original assumption was that it could be easily enabled 
> for Simulator/device (armv7;armv7s;arm64;i386;x86_64).
>
> I could start working on that but if it will be too hacky, then I will 
> leave that idea.
>
>
>
> BTW I made some benchmarks of Xcode vs Make comparison for our 
> internal subproject (with "time" command). Here are results:
>
>
> Xcode generation:
>
>    real6m31.733s
>
>    user4m51.862s
>
>    sys0m20.268s
>
>
> Make generation:
>
>    real4m45.089s
>
>    user2m56.117s
>
>    sys0m17.481s
>
>
> Ninja generation:
>
>   real2m48.585s
>
>   user2m30.712s
>
>   sys0m6.313s
>
>
>
> Xcode generation + build time:
>
>    real64m3.238s
>
>    user353m36.825s
>
>    sys46m52.415s
>
>
> Make generation + build time:
>
>    real61m2.583s
>
>    user358m7.464s
>
>    sys47m21.512s
>
>
> So it seems in our case, for Generation performance step, we should 
> use Ninja.
>
Ok, thanks for sharing it. This proves what I was thinking - there is no 
difference in build time, but generate time is better for Makefile. 
Probably you can profile CMake and find some bottlenecks.

>
> Best Regards
>
> Bartosz
>
>
> ------------------------------------------------------------------------
> *From:* Ruslan Baratov <ruslan_baratov at 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_baratov at yahoo.com]
>> *Sent:* Saturday, December 12, 2015 6:49 AM
>> *To:* Bartosz Kosiorek
>> *Cc:* Clinton Stimpson; Gregor Jasny; CMake Developers
>> *Subject:* Re: [cmake-developers] Create subdirectories in Resource 
>> directory for Frameworks and Application bundle.
>>
>> On 12-Dec-15 10:08, Bartosz Kosiorek wrote:
>>
>>     Thanks Ruslan.
>>
>>     I would like to create instruction which is universal for all
>>     generators.
>>
>> I think it's not possible. E.g. IOS_INSTALL_COMBINED will work only 
>> for Xcode.
>>
>>
>> Currently we would like to support both Make/Ninja and Xcode generators,
>>
>> ...
>>
>>
>> because Make is much faster than Xcode generator, and we are using it 
>> in our CI system.
>>
>> Do you mean generate step or build? I've used to compile quite big 
>> projects like OpenCV with Xcode and according to the `top` it uses 
>> all my cores with clang++ at 100% CPU time.
>> Can you show any benchmarks? Also note that Xcode can add some 
>> additional stuff, like dSYM: 
>> https://github.com/headupinclouds/gatherer/pull/69
>>
>>
>> Make is also common for other architectures (Linux, QNX, Android etc.)
>>
>> Unfortunately
>>
>>    set(CMAKE_OSX_SYSROOT "iphoneos")
>>
>> is not working for me.
>>
>> It displays error:
>>
>>   /Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake .. && 
>> /Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake --build .
>>
>>   -- Configuring done
>>
>>   -- Generating done
>>
>>   -- Build files have been written to: 
>> /Users/warsaw/Perforce/cmake_ios_framework_with_resource2/builddir
>>
>>   [ 14%] Building C object 
>> shared_empty/heymath/CMakeFiles/heymath.dir/add.c.o
>>
>>   clang: warning: no such sysroot directory: 'iphoneos'
>>
>> ...
>>
>> Do you have some tip for that?
>>
>> Yes, this hint was for Xcode generator.
>>
>>
>> After removing "-isysroot ${CMAKE_OSX_SYSROOT}" everything works 
>> perfectly. Thanks
>>
>> Unfortunately CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET is not 
>> working with Make.
>>
>> Is it possible to introduce CMAKE_IOS_DEPLOYMENT_TARGET, as we 
>> already have CMAKE_OSX_DEPLOYMENT_TARGET?
>>
>> Since OSX_ARCHITECTURES controls iOS architectures too I think 
>> request should sounds like "Extend OSX_DEPLOYMENT_TARGET property for 
>> iOS platform".
>>
>>
>>
>> I have attached my example script which I'm using.
>>
>> ​ Could you please modify it to be better (and still support other 
>> generators)?
>>
>> I don't know how to use iOS target with Makefile generator.
>>
>> Some notes about project you've sent:
>> * You need to add instructions to codesign your bundle
>> * Instead of hardcoding `set(CMAKE_OSX_SYSROOT 
>> "/Applications/Xcode.app/.../iPhoneSimulator.sdk")` you can run 
>> `xcode-select -print-path` to detect location of default Xcode version
>> * Should be `set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} 
>> -mios-version-min=8.0")` instead of `set(CMAKE_CXX_FLAGS 
>> "-mios-version-min=8.0")` otherwise some flags may be lost
>>
>> Ruslan
>>
>> Best Regards
>>
>> Bartosz
>>
>> ------------------------------------------------------------------------
>>
>> *From:*Ruslan Baratov 
>> <ruslan_baratov at yahoo.com><mailto:ruslan_baratov at yahoo.com>
>> *Sent:* Saturday, December 12, 2015 1:58 AM
>> *To:* Bartosz Kosiorek
>> *Cc:* clinton at elemtech.com<mailto:clinton at elemtech.com>; Gregor 
>> Jasny; CMake Developers
>> *Subject:* Re: [cmake-developers] Create subdirectories in Resource 
>> directory for Frameworks and Application bundle.
>>
>> On 12-Dec-15 03:46, Bartosz Kosiorek wrote:
>>
>>     Hi
>>
>>     To enable iOS build, I'm using following settings in CMakeLists.txt:
>>
>>     set(APPLE_PLATFORM "iphonesimulator")
>>
>> I think this one not needed. Can't find any place where it parsed.
>>
>>
>> set(CMAKE_OSX_SYSROOT 
>> "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk")
>>
>> Can be set to:
>>
>> set(CMAKE_OSX_SYSROOT "iphoneos")
>>
>> in this case will support both simulator and device
>>
>>
>> set(CMAKE_C_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0")
>>
>> set(CMAKE_CXX_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} 
>> -mios-version-min=7.0")
>>
>> You can set minimum version by 
>> CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET variable.
>> In case of `CMAKE_OSX_SYSROOT` variable is set to `iphoneos` option 
>> `-isysroot` is redundant.
>>
>>
>> Do you think it should be documented?
>>
>> Where is the good place to do so?
>>
>> Maybe somewhere here:
>>
>> <https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html>https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html
>>
>> What do you think?
>>
>>>>
>> ------------------------------------------------------------------------
>>
>> *From:*clinton at elemtech.com<mailto:clinton at elemtech.com><clinton at elemtech.com><mailto:clinton at 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 
>> <gang65 at poczta.onet.pl><mailto:gang65 at 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/Conceptual/CFBundles/BundleTypes/BundleTypes.html>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>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
>>     <<mailto:clinton at elemtech.com>clinton at 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
>>         mulres.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}"
>>     )
>>
>>
>>     Now I'm wondering what does the RESOURCE target property do that
>>     MACOSX_PACKAGE_LOCATION doesn't already support?
>>
>>
>>     Clint
>>     --
>>
>>     Powered by <http://www.kitware.com>www.kitware.com
>>
>>     Please keep messages on-topic and check the CMake FAQ at:
>>     <http://www.cmake.org/Wiki/CMake_FAQ>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>http://cmake.org/cmake/help/support.html
>>     CMake Consulting:
>>     <http://cmake.org/cmake/help/consulting.html>http://cmake.org/cmake/help/consulting.html
>>     CMake Training Courses:
>>     <http://cmake.org/cmake/help/training.html>http://cmake.org/cmake/help/training.html
>>
>>     Visit other Kitware open-source projects at
>>     <http://www.kitware.com/opensource/opensource.html>http://www.kitware.com/opensource/opensource.html
>>
>>     Follow this link to subscribe/unsubscribe:
>>     <http://public.kitware.com/mailman/listinfo/cmake-developers>http://public.kitware.com/mailman/listinfo/cmake-developers
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20151222/69e705cb/attachment-0001.html>


More information about the cmake-developers mailing list