structs: dependency-only: opaque should apply to ObjC interfaces

[vaind]

Say we have an API that requires an NSString as an argument.
Say you only want to call that API, not do all the fiddly bits you can do with NSStrings so you set exlcude-all-by-default and only include the interface class you want to use.

If you happen to run ffigen, it will see the API you want to use needs an NSString, then it will have a look at all its APIs and will go ahead and generate code for all of those. While this is functional, it creates a lot of code (file sizes measured in megabytes). I assume this code does get tree-shaken during compilation, but it's still something that will impact compilation speed, git repo size and all the implications that has over time, package size when pushed to pub.dev (and being downloaded by the package users), etc.

I've also tried structs: dependency-only: opaque but that doesn't seem to do anything.

While the approach to generate all the dependent code is a valid one and it does work, I wonder if we could make exclude-all-by-default apply for this as well. Instead, I'd prefer having to specify the methods I need (besides the constructor) - I am excluding everything after all. Alternatively, it could be done so that by just listing the class/interface in the include list would generate all methods (related: #251) but would not go on transitively for each argument - those would be opaque instead.

Example:

• ffi config: https://github.com/getsentry/sentry-dart/pull/1622/files#diff-6101fa2fb8fa86e958fe3a953e7e9f5390f14cf1f4366ec5d4e39a3eb6f7857d
• generated file: https://raw.githubusercontent.com/getsentry/sentry-dart/8367da2a088bb6e5ece64d09d53f074233b26ba2/flutter/lib/src/sentry_cocoa.dart

[liamappelbe]

How is this different from method filtering? Are you just asking for exclude-all-by-default to apply to methods, once we implement this filtering?

[vaind]

Maybe this could be simplified to: let's have the existing option structs: dependency-only: opaque also work for objective-c. In that case, types used in arguments wouldn't pull so much code transitively.

[liamappelbe]

Sounds reasonable. But it should probably be its own flag specific to ObjC interfaces.