[CMake] OS X Framework creation and DEBUG_POSTFIX

[E. Wing]

On 8/6/08, Bill Hoffman <bill.hoffman at kitware.com> wrote:
> Mike Jackson wrote:
>> I have the following:
>>
>>   SET_TARGET_PROPERTIES(${MXADATAMODEL_LIB_NAME} PROPERTIES
>>       #DEBUG_OUTPUT_NAME ${MXA_LIBRARY_RELEASE}
>>       #RELEASE_OUTPUT_NAME ${MXA_LIBRARY_RELEASE}
>>       FRAMEWORK TRUE
>>       FRAMEWORK_VERSION ${MXADATAMODEL_VER}
>>       RESOURCE ""
>>       DEBUG_POSTFIX _debug
>>   )
>>
>> and when I compile in Debug mode I don't seem to get what I _think_ I
>> should get.
>>
>> I get MXADatModel.framework/MXADataModel
>>
>> I would have thought I would get MXADatModel.framework/MXADataModel_debug
>>
>> Thoughts?
>>
> It was told to me by "Mac experts", that the debug post fix should be
> ignored for frameworks.   I am pretty sure the above won't work as the
> name of folder should match the name of the library.  I am not sure what
> the above would do for you anyway.  Perhaps Eric Wing could comment
> more.  I think he was the one that had the request to make the debug
> postfix ignored in framework creation.    Eric?
>
>
> -Bill


I claimed debug postfix should be ignored because it was doing a very
bad thing. In the case where the postfix is 'd' for example, it was
changing the framework name from Foo.framework to Food.framework. This
will guarantee breakage in your code if you include headers like:
#include <Foo/Header.h>. Because the path is based on the framework
name, you would have to change all your source code to #include
<Food/Header.h> for a debug version. (And change it all back for a
non-debug version.)

Furthermore, Xcode itself doesn't do anything different out of the box
for the naming of Debug vs Release versions. By default, if you build
a framework with the Debug Build Configuration, and again with the
Release Build Configuration, you will get the exact same file
manifest.

What Mike is suggesting is an advanced Xcode feature called Build
Variants which I think we have discussed, but I assumed it was so
niche, that it wasn't worth pursuing at the time.

Even with Build Variants, it doesn't work quite the way Mike described
(unless something has changed recently). And Build Variants are not a
direct mapping to CMake debug postfix.


First, I think Xcode assumes certain preset DYLD_IMAGE_SUFFIX names,
namely _profile and _debug. I think you can define your own, but some
of the UI is biased towards the above two. So I don't think it is a
direct mapping to CMake's debug postfix in the sense that CMake's is
more variable.


Second, Xcode doesn't build the framework quite like how you describe
even with build variants.
Instead of:
MXADatModel.framework/MXADataModel_debug,

you get the standard framework, plus a 2 new binaries.

MXADatModel.framework/
    Headers@  -> Versions/Current/Headers
    MXADataModel@ -> Versions/Current/MXADataModel
    Resources@ -> Versions/Current/Resources
    Versions/
        Current@ -> A
        A/
            MXADataModel
            MXADataModel_debug
            MXADataModel_profile

Notice that that the symlink is still to the non_suffixed version. To
run under the debug or profile, you are expected to run under the
DYLD_IMAGE_SUFFIX environmental variable set to one of those. (Again,
Xcode has some very basic UI support for doing this.) It is this
environmental variable that tells the loader to look for the other
binaries in the framework. The symlink itself does not change.

Note that every framework that offers that matching suffix will be
pulled in. Because of this, some people will manually go into the
framework and change the symlinks around so they either don't need to
define DYLD_IMAGE_SUFFIX, or they don't pull in all the frameworks,
but just the ones they want.

But changing the symlink is manual hacking. And because of that, I
don't really expect CMake to improve on this.


Third, Xcode needs to give specific build_variant build switches for
each variant. These I guess are similar to CMake's offering of
different flags for Release, Debug, etc, except that these are
orthogonal settings. CMake's offering maps to "Build Configurations".
This setting is a "Build Variant" which is more analogous to
architecture specific flags, i.e. for every Build Configuration, you
can define flags for each variant and architecture for that one Build
Configuration. (So notice you can have a Debug version of the
framework with a _debug variant, but you can also have a Release
version with a _debug variant, with potentially different optimization
flags for each.) So again, this really isn't a direct mapping to
CMake's Debug Postfix option.

Out of the box, Xcode doesn't define any useful flags for the preset
build_variants. To be useful, I think CMake needs to offer a special
interface for this which means we need a matrix of settings, or I
think we need to be able to supply a xcconfig file that has presets we
can define and CMake knows how to read these. (I've discussed the
xcconfig idea in the past too which might solve the issue of how to
get access to about 80% of the Xcode features without requiring CMake
to know about any of them and write special code for them.)

-Eric