[cmake-developers] [PATCH] Bug fix: Dylibs inside .framework folders fails in BundleUtilities.cmake.

Christian Askeland christian.askeland at gmail.com
Sun Feb 7 11:25:29 EST 2016


> On 5. feb. 2016, at 16.22, Brad King <brad.king at kitware.com> wrote:
> 
> On 02/04/2016 01:34 PM, Christian Askeland wrote:
>> The specific cause is when e.g.
>> 
>> /Library/Frameworks/GStreamer.framework/Versions/1.0/lib/libgio-2.0.0.dylib
>> 
>> is detected by fixup_bundle. BundleUtilities.cmake/set_bundle_key_values()
>> interprets this as a framework, thus doing a string replace that creates an
>> embedded_item that is equal to the original path, i.e. it is not embedded.
>> 
>> The fix is to rely on the correct framework detection in
>> GetPrerequisite.cmake/gp_item_default_embedded_path() instead.
> [snip]
>> -    if(item MATCHES "[^/]+\\.framework/")
>> +    # Use default_embedded_path from gp_item_default_embedded_path() to query whether the item is a framework
>> +    if(default_embedded_path MATCHES "/Frameworks")
> 
> If the project uses gp_item_default_embedded_path_override then
> we cannot rely on the value from gp_item_default_embedded_path.

Good point, I didn't see that one.

> Is there another way to detect whether the item is actually the
> main framework library itself or just something else inside one?
> 

We could reuse the check from gp_item_default_embedded_path(), instead of looking at the result from that function:

 if((item NOT MATCHES "\\.dylib$") AND (item MATCHES "[^/]+\\.framework/"))

I haven't tested the line above, but can do so tomorrow and post a new patch, if it looks reasonable.

> Thanks,
> -Brad
> 


-Christian


More information about the cmake-developers mailing list