Improvements to generating code, support for typedef.

[mannprerak2]

Closes dart-lang/native#359, Closes dart-lang/native#363

• All declarations that are not included by the user are now only included if being used somewhere.
  Context. - earlier, declarations that were used by another declaration were included even if the declaration that included it was removed due to it not being supported by dart:ffi
• Improved struct/union include/exclude
  Contest - earlier, it was a bit complicated to target structs, since they could have multiple names (from typedefs). With typedef support users can target structs by their true name (or incase they are anonymous, by the first typedef that refers to them.
• Use inline types for function types
  Context - earlier, we generated typedefs like _c_func and _dart_func for specifying function type. This has now been replaced with an inline function type declaration. Note that if the user exposes a function pointer using function->symbol-address we still create a typedef for that, but not otherwise. Since these types are only referred to once, using inline types reduces the number of lines generated.
• Support for typedefs
  Context - Typedefs in C are now directly mapped as it is when possible. Only typedefs that were referred somewhere are generated. Users can rename these and exclude generating them (referred typedefs only). If a typedef is excluded we simply use the underlying type.
• Added /usr/lib64 to the default dynamic library search paths on Linux.
• Updated/Added tests, Updated changelog, version.
• Fixed cJSON example.

[mannprerak2]

Hey @dcharkes, this is probably the biggest PR since #2, please take your time to review this. I've tried to clarify the reasons for the changes in the above #224 (comment).

[dcharkes]

First round of comments. (This is mostly the public API/docs. I'll go through the implementation code later.)

[dcharkes]

Please also add tests that generate intptr_t -> IntPtr() now that we can recognize the typedefs. In the past we just saw the int32 or int64 of the underlying size correct? We should be able to now support this properly.

[dcharkes]

Please also add tests that generate intptr_t -> IntPtr() now that we can recognize the typedefs. In the past we just saw the int32 or int64 of the underlying size correct? We should be able to now support this properly.

Did you see this @mannprerak2 ?

[mannprerak2]

Please also add tests that generate intptr_t -> IntPtr() now that we can recognize the typedefs. In the past we just saw the int32 or int64 of the underlying size correct? We should be able to now support this properly.
Did you see this @mannprerak2 ?

Ah, my bad, didn't see this before.

We already have support for IntPtr. Using the use-supported-typedefs config (true by default) We map intptr_t to IntPtr. Test - Map intptr_t to IntPtr, Output => C code & Dart Code.

[dcharkes]

I must have misremembered that then. 😄

[mannprerak2]

I must have misremembered that then.

Well, you weren't than far. We are still using platform dependant types (Uint32 or Uint64) for types such as size_t. But the user can map them to whatever they like using typedef-map in config.

Do we have a cross platform solution for this in the working for dart:ffi?

[dcharkes]

Do we have a cross platform solution for this in the working for dart:ffi?

It's on the list, but I've been busy with other stuff.