We don't have explicit support for api notes in SwiftPM. We discussed it, and it something which probably makes sense, but no one has worked on a design or implementation yet.
- Daniel > On May 12, 2017, at 11:32 AM, Michael Gottesman via swift-users > <swift-users@swift.org> wrote: > > +Ankit > > Michael > >> On May 12, 2017, at 10:10 AM, Geordie J via swift-users >> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote: >> >> To continue this thread: I managed to annotate a bunch of C APIs with >> modulename.apinotes. This works with Xcode (to a certain degree - pointers, >> enums, and especially OpaquePointers are tricky). I’m now trying to build my >> package with SwiftPM and it doesn’t seem to recognise the apinotes file. >> >> @Doug Gregor, would you be able to advise as to whether apinotes works with >> SwiftPM (on Linux) and whether it requires some extra settings that I may be >> unaware of? >> >> Thanks and best regards for the weekend, >> Geordie >> >> >>> Am 08.05.2017 um 00:51 schrieb Geordie Jay <geo...@gmail.com >>> <mailto:geo...@gmail.com>>: >>> >>> I'm having the same issue. The renames seem to work, as in they disappear >>> from the global scope with a fixit to rename to the new (namespaced) >>> version if I type in the name manually, but they don't appear as static >>> members of the enum type, regardless of how I call them. Would appreciate >>> some help with this too. >>> >>> Cheers, >>> Geordie >>> Rick Mann <rm...@latencyzero.com <mailto:rm...@latencyzero.com>> schrieb am >>> So. 7. Mai 2017 um 23:06: >>> I'm trying to use apinotes for this third-party C library (call it >>> "Lib.dylib"). It has an enum lgs_error_t: >>> >>> typedef enum { >>> lgs_error_none = 0, >>> lgs_error_invalid_handle = -1, >>> lgs_error_null = -2, >>> lgs_error_invalid_parameter = -3, >>> lgs_error_invalid_operation = -4, >>> lgs_error_queue_full = -5 >>> } lgs_error_t; >>> >>> So I wrote apinotes ("Lib.apinotes") that look like this, next to the >>> .dylib, and part of my Xcode iOS app target: >>> >>> Enumerators: >>> # lgs_error_t >>> >>> - Name: lgs_error_none >>> SwiftName: lgs_error_t.none >>> - Name: lgs_error_invalid_handle >>> SwiftName: lgs_error_t.invalidHandle >>> - Name: lgs_error_null >>> SwiftName: lgs_error_t.nullParameter >>> - Name: lgs_error_invalid_parameter >>> SwiftName: lgs_error_t.invalideParameter >>> - Name: lgs_error_invalid_operation >>> SwiftName: lgs_error_t.invalidOperation >>> - Name: lgs_error_queue_full >>> SwiftName: lgs_error_t.queueFull >>> >>> But this line of code fails: >>> >>> var err: lgs_error_t = .nullParameter >>> Type 'lgs_error_t' has no member 'nullParameter' >>> >>> Am I missing something else? >>> >>> > On May 4, 2017, at 16:55 , Douglas Gregor via swift-users >>> > <swift-users@swift.org <mailto:swift-users@swift.org>> wrote: >>> > >>> > >>> >> On May 3, 2017, at 4:10 PM, Geordie J via swift-users >>> >> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote: >>> >> >>> >> Hi everyone, >>> >> >>> >> I’m about to start on another big project with Swift on Android and >>> >> would like to annotate that JNI headers as much as possible before I do: >>> >> specifically I’d like to make _Nonnull and CF_SWIFT_NAME annotations to >>> >> the headers found in a user's jni.h. >>> >> >>> >> The question is: is it possible to annotate headers this without >>> >> changing the original header files? Specifically I’m looking for an >>> >> options that allows annotations in a separate file, probably one that is >>> >> read when loading the package’s module.modulemap. >>> >> >>> >> I’d like to distribute the annotations in a SwiftPM package that also >>> >> exposes the original (hopefully annotated) headers. Up until now I’ve >>> >> been using Swift to override methods in code, but this isn’t as clean or >>> >> extensible and I fear it may have other (particularly performance) >>> >> implications. >>> >> >>> >> I guess the alternative would be to just maintain and distribute a >>> >> modified version of jni.h with the annotations, but that would be a >>> >> "last resort” option. >>> > >>> > >>> > This is the role of API notes, which you can see here: >>> > >>> > https://github.com/apple/swift/tree/master/apinotes >>> > <https://github.com/apple/swift/tree/master/apinotes> >>> > >>> > with some rough documentation-in-source here: >>> > >>> > >>> > https://github.com/apple/swift-clang/blob/stable/lib/APINotes/APINotesYAMLCompiler.cpp >>> > >>> > <https://github.com/apple/swift-clang/blob/stable/lib/APINotes/APINotesYAMLCompiler.cpp> >>> > >>> > - Doug >>> > >>> > _______________________________________________ >>> > swift-users mailing list >>> > swift-users@swift.org <mailto:swift-users@swift.org> >>> > https://lists.swift.org/mailman/listinfo/swift-users >>> > <https://lists.swift.org/mailman/listinfo/swift-users> >>> >>> >>> -- >>> Rick Mann >>> rm...@latencyzero.com <mailto:rm...@latencyzero.com> >>> >>> >> >> _______________________________________________ >> swift-users mailing list >> swift-users@swift.org <mailto:swift-users@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-users > > _______________________________________________ > swift-users mailing list > swift-users@swift.org > https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
