Find Alternative For __has_include

[bassrock]

While looking at using this for tvOS or other platforms (might be the same for watchOS2), __has_include does not work properly with Cocoapods. I am seeing this specifically in DFImageManager+DefaultManager:

#if __has_include("DFImageManagerKit+PhotosKit.h")
    [managers addObject:({
        DFPhotosKitImageFetcher *fetcher = [DFPhotosKitImageFetcher new];
        [[DFImageManager alloc] initWithConfiguration:[DFImageManagerConfiguration configurationWithFetcher:fetcher processor:processor cache:cache]];
    })];
#endif

One idea could do a conditional to check if it is cocoa pods, and if it is use the defines with pod specs, and if it is not then use the __has_include.

Reference: CocoaPods/CocoaPods#1249

[kean]

Yep, I'm aware of this issue. The easy fix for that is to stop relying on conditional compilation at all. That's the way Nuke does it. The downside - optional subspecs will no longer be "zero config", but that's not really an issue.

I hope I'll have some time on a weekend, going to work on version 1.0.0.

[bassrock]

Ok cool. Is Nuke close to feature parity for basic image caching and prefetching? Last I saw it was still experimental.

[kean]

It has all the features that I believe 95% of users need.

It doesn't have (and won't have):

• WebP support
• Progressive image decoding
• Request priorities (will be available soon)
• PhotosKit
• Image manager composition
• Memory cache revalidation

[bassrock]

Ah ok. I'll look into that then. Thanks! Great work on these frameworks!

[kean]

thanks ;)

[kean]

No more __has_include in develop branch; less stuff predefined, more power to the user.

[kean]

Ok, so everything is implemented using classes now. The only place where conditional compilation takes place is a DFImageManager+SharedManager.m, where default manager is created. And it relies on macros added to prefix header, which supports target de-duplication.