Move core ObjC classes into their own library

[liamappelbe]

For example NSObject and NSString. This makes sense from a modularisation perspective, and also solves the problem where 2 different code genned ObjC libraries are incompatible.

[dcharkes]

We'll likely need to convert this repo to a monorepo (similar to JNIgen), that's a better approach than a new repo.

JNIgen also has a helper library package:jni with common types.

We should try to do that conversion at a point where not a ton of PRs are outstanding.

[vaind]

This would also solve the pain point I've had when creating this issue: #432 - although the issues are not the same, anything to get rid of those MiB of generated code would be nice.

[vaind]

We should try to do that conversion at a point where not a ton of PRs are outstanding.

Now seems to be the right time then :D

[dcharkes]

cc @devoncarew any concerns about converting this repo to a monorepo?

The helper package with code that the FFIgen generated could would import should be called:

• package:objective_c (most obvious name, but does not indicate it belongs to FFIgen generated code)
• package:objc (because it's shorter than the first)
• package:ffigen_objc (so it's clear it belongs to FFIgen)
• package:ffigen_objective_c (so it's clear it belongs to FFIgen)

cc @mit-mit for package name inspiration.

[devoncarew]

cc @devoncarew any concerns about converting this repo to a monorepo?

None, but consider also moving this into dart-lang/native.

And, +1 to the package names qualifed w/ ffi prefixes (package:ffigen_objc, package:ffigen_objective_c, ...).

[dcharkes]

My reservation with moving FFIgen (and then probably also package:ffi, JNIgen and package:jni) all to dart-lang/native is that all issues will be in one big issue tracker. cc @HosseinYousefi @mannprerak2 @liamappelbe @brianquinlan as most impacted workflow-wise.

[HosseinYousefi]

I like the idea of having all the native stuff in dart-lang/native.

all issues will be in one big issue tracker

This can be solved using a tag for each package.

[devoncarew]

My reservation with moving FFIgen (and then probably also package:ffi, JNIgen and package:jni) all to dart-lang/native is that all issues will be in one big issue tracker.

That's a drawback for sure, but I think the cost of doing business; we do get real economies of scale from monorepos.

Here's an example of issues for a mono-repo; we just make sure that each package has an issue template, so all filed issues up up w/ a label to help categorize them: https://github.com/dart-lang/tools/issues.

[liamappelbe]

I'm also in favour of a dart-lang/native monorepo. We need to start deduping logic between ffigen and jnigen.

[dcharkes]

Okay!

The process of merging a (non-mono) repo into dart-lang/native can be found here: dart-lang/tools#100. @liamappelbe could you follow these steps for the FFIgen repo and make a PR in the same style?