Cheers, Geordie
Daniel Dunbar <daniel_dun...@apple.com> schrieb am Fr. 12. Mai 2017 um 20:33: > We don't have explicit support for api notes in SwiftPM. > Does that mean there is "unexplicit" support (maybe via swift build command line arguments)? I don't mind if I have to make a build script, but it'd be a major code compatibility issue across the supported platforms if apinotes didn't work at all on Linux. > 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> 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>: > > 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> 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> wrote: >> > >> > >> >> On May 3, 2017, at 4:10 PM, Geordie J via swift-users < >> 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 >> > >> > with some rough documentation-in-source here: >> > >> > >> https://github.com/apple/swift-clang/blob/stable/lib/APINotes/APINotesYAMLCompiler.cpp >> > >> > - Doug >> > >> > _______________________________________________ >> > swift-users mailing list >> > swift-users@swift.org >> > https://lists.swift.org/mailman/listinfo/swift-users >> >> >> -- >> Rick Mann >> rm...@latencyzero.com >> >> >> > _______________________________________________ > 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 > > >
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users