[swift-users] Annotating C APIs without changing the original header files

[Geordie Jay]

Cheers,
Geordie


Daniel Dunbar <daniel_dunbar at 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 at swift.org> wrote:
>
> +Ankit
>
> Michael
>
> On May 12, 2017, at 10:10 AM, Geordie J via swift-users <
> swift-users at 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 <geojay at 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 <rmann at 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 at swift.org> wrote:
>> >
>> >
>> >> On May 3, 2017, at 4:10 PM, Geordie J via swift-users <
>> swift-users at 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 at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-users
>>
>>
>> --
>> Rick Mann
>> rmann at latencyzero.com
>>
>>
>>
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170514/a32c4880/attachment.html>