Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Boxed NSObjects fail for Cocoapods installation #28

Open
kylealanhale opened this issue Apr 5, 2016 · 7 comments
Open

Boxed NSObjects fail for Cocoapods installation #28

kylealanhale opened this issue Apr 5, 2016 · 7 comments

Comments

@kylealanhale
Copy link

kylealanhale commented Apr 5, 2016

When installing the framework via Cocoapods, NSObject subclasses aren't properly boxed, due to the compiler conditional in Box.swift.

Here's a temporary workaround hook for a project's Podfile:

post_install do |installer|
    installer.pods_project.targets.each do |target|
        if target.name == "GRMustache.swift"
            target.build_configurations.each do |config|
                config.build_settings['OTHER_SWIFT_FLAGS'] ||= ['$(inherited)', '-DOBJC']
            end
        end
    end
end
@groue
Copy link
Owner

groue commented Apr 5, 2016

@kylealanhale Thank you for the notice, let me have a look.

@groue
Copy link
Owner

groue commented Oct 23, 2016

Damned, I forgot this issue for the 2.0.0 release.

@groue
Copy link
Owner

groue commented Oct 23, 2016

@kylealanhale, @AMTourky Do you know what is needed in the podspec for the OBJC swift flag to be automatically set?

@sahandnayebaziz
Copy link

Currently having this issue... Thought I'd have to manually override for boxed items! Any update on this?

@kylealanhale
Copy link
Author

@groue @sahandnayebaziz It's been a while, but I'm not sure that it was a problem with the podspec; if so, maybe the modification I made to my podfile in the original report will be helpful. But if I'm remembering correctly, it would be better to remove the OBJC check and handle that scenario differently. (Also, it looks like the code in question was moved during the 2.0.0 refactor; it's now here.)

@herrernst
Copy link
Contributor

I've lost some hours debugging this when switching from the ObjC version GRMustache to GRMustache.swift for rendering of my NSObject, so I propose at least adding a note to the README with #71.

herrernst added a commit to herrernst/GRMustache.swift that referenced this issue Feb 7, 2020
@herrernst
Copy link
Contributor

Same problem also happens when using as Swift package, probably not fixable because in a Swift package it's not possible to have Obj-C source files.

But maybe GRMustacheKeyAccess could be rewritten in Swift now? At least the problematic example in the implementation note from here now works in Swift:

// IMPLEMENTATION NOTE
//
// This code comes from Objective-C GRMustache.
//
// It is still written in Objective-C because
// +[GRMustacheKeyAccess isSafeMustacheKey:forObject:] used to need the
// [[object class] safeMustacheKeys] for classes that would conform to the
// now removed GRMustacheSafeKeyAccess protocol.
//
// Swift would not let us do that (see example below):
//
// ::
//
// import Foundation
//
// @objc protocol P {
// static func f() -> String
// }
//
// class C : NSObject, P {
// class func f() -> String { return "C" }
// }
//
// // Expect "C", But we get the error:
// // accessing members of protocol type value 'P.Type' is unimplemented
// (C.self as P.Type).f()
//

Screen Shot 2020-02-07 at 13 54 42

Unfortunately I'm not able to do it ATM.

herrernst added a commit to herrernst/GRMustache.swift that referenced this issue Nov 9, 2022
add objc files as separate target

see groue#28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants