|
|
| (4 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| =Building multiple configurations with XCode=
| | {{CMake/Template/Moved}} |
|
| |
|
| If you do release and debug builds with XCode for frameworks, XCode will create completely separate frameworks for each
| | This page has moved [https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/MacOSXLinkerAndXCodeStuff here]. |
| configuration (e.g. Release and Debug). This is how CMake supports different configurations in XCode.
| |
| | |
| There is an additional mechanism how this can be done. In the configuration dialog "Build variants" can be created, the default variant is "normal". When adding an additional name to this list, the library will be built in an additional variant and the name will be appended to the library name.
| |
| E.g. if you add "profile" to the list, additionally to the library "foolib" now also "foolib_profile" will be created within the same framework. To get different settings/compiler flags/etc. for this version, XCode variables have to be defined for this build variant. They have the same name as the normal XCode variables, but have again the name appended:
| |
| | |
| <pre>
| |
| BUILD_VARIANTS ="normal debug"
| |
| OTHER_CFLAGS_debug=" -DMY_DEBUG=1 -DDEBUG=1 -gfull -O0 -fno-inline"
| |
| OTHER_CFLAGS_normal=" -DMY_DEBUG=0 -DNODEBUG=1 -gfull -O3"
| |
| </pre>
| |
| | |
| When building something which links to that framework, the normal name is used when building. When that application starts, by default it will load the normal variant. If the developer wants to use the "profile" variant, he has to set the DYLD_IMAGE_SUFFIX environment variable accordingly. So if DYLD_IMAGE_SUFFIX is set to "profile", the application will get "foolib_profile". The same mechanism is used in the original OSX frameworks, there are "debug" variants of the frameworks available. This means if DYLD_IMAGE_SUFFIX is set to "debug", an application will get the debug versions of the OSX libs and the debug version of "foolib" (if it exists). If the developer wants only debug versions of his own libs then he has to use a different variant name.
| |
| | |
| =Versions in frameworks=
| |
| | |
| Frameworks have version directories, usually version "A" with the symbolic link "Current" pointing to it.
| |
| When an application is linked to a framework using "-framework Foo", then the link "Current" is used but the link destination is recorded in the application, so that when the application starts it doesn't matter to which version "Current" points.
| |
| | |
| If there are two versions, "A" and "B" in a framework, and "Current" points to B, but a developer wants to build his application against version "A", the dylib_file option has to be used for gcc:
| |
| <pre>
| |
| gcc -o Prog3 -dylib_file Foo.framework/Versions/B/Foo:Foo.framework/Versions/A/Foo -framework Foo
| |
| </pre>
| |
| | |
| Alternatively the library inside the framework could be used directly:
| |
| <pre>
| |
| gcc -o Prog3 Foo.framework/Versions/A/Foo
| |
| </pre>
| |
| | |
| =dylib_compatibility_version and dylib_current_version=
| |
| | |
| dylib_current_version is the current version of a dyld library (equivalent to the full versioned name of a so library). dylib_compatibility_version is the version to which the current version is compatible. I.e. the current version 1.2.3 could be compatible down to version 1.0.0 (or any other version before it, e.g. 0.5.3). This is somewhat similar to the SOVERSION of an so library, where a different SO version means a really different version of the library, but with the two dyld versions this can be used much more fine grained.
| |
| So if an executable is linked against a dyld library with compatibility version 1.0.0, but when executing the linker finds only a current version 0.9.0 the app will not start.
| |
