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