On 8/7/08, Mike Jackson <[EMAIL PROTECTED]> wrote:
> 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.
>
How are you doing your includes? Often it's not a problem, though you
may have one of the corner cases where it is.
Instead of the two-level include, e.g.
#include <SDL/SDL.h>
you can also do
#include "SDL.h"
(In fact, for cross-platform projects that don't have a standardized
include subdirectory, the latter form is better.)
-Eric
> 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 <[EMAIL PROTECTED]> 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
>>
>
>
> _______________________________________________
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
