[CMake] OS X Framework creation and DEBUG_POSTFIX

[Mike Jackson]

Thanks all for the quick OS X education on frameworks. It has been a  
long time since I tried to create one so I had forgotten all the  
nuances. I think for my project I am going to stick with a  
traditional Unix layout of Dylibs and Includes. The largest reason  
among them I think I would need to change all my includes in all my  
source files. That and the Eclipse-CDT indexer doesn't work so well  
with frameworks.

Thanks all for taking the time.
-- 
Mike Jackson   Senior Research Engineer
Innovative Management & Technology Services


On Aug 7, 2008, at 1:53 AM, E. Wing wrote:

> 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
>