Improvements meta-list

[ihnorton]

• tests
• better dependency resolution (emit types after the entire pass)
• integrate new struct improvements
• support const array definitions

[kmsquire]

Was about to submit an issue, but dependency resolution is something I'm running into with libav.

1. Some dependencies are obvious and can be fixed by a simple reorder
2. There are occasional circular dependencies. Since these are between structs, I assume that the type information could be left off one?
3. As noted in Option to typealias empty structs to void #84 (should have looked here first), sometimes internal structs are declared simply so there can be pointers to them.

Perhaps a start would be by storing dependencies in an (ordered?) dictionary or graph? What are your feelings about depending on other packages (DataStructures.jl or Graph.jl)?

I'm willing to help, but no worries if you want to run with something.

[kmsquire]

BTW, thanks for the push access! I'll do issues and PRs for anything non-trivial, of course.

[ihnorton]

1. I am working on smarter handling of includes inside of explicitly-declared headers, which should help with this. We might need to also do a re-ordering step, but hopefully less necessary. The compiler already knows how to resolve everything it needs for a given translation unit, so it would be good to fully utilize this fact.

   Part of the problem is that right now we are just throwing headers at Clang in lexical (or filesystem) order and expecting it to work, whereas the build system has a lot of explicit and implicit knowledge about ordering and dependencies. The Build EAR tool may be helpful here by allowing us to capture everything a build does and then reproduce the compiler state for a given file, for other purposes. Would also be useful for ensuring consistency between compile and wrap options (mismatches can lead to calling an incompatible ABI).

2. do you have an example? I'm not sure if the struct will be sized correctly if type information is excluded.

[kmsquire]

Great! That sounds like a good approach. BEAR definitely looks like it could be useful.

1. do you have an example? I'm not sure if the struct will be sized correctly if type information is excluded.

AVFrame and AVCodecContext. I think there are a few others. But I don't think it will really be a problem (at least in libav) because the dependency is always a pointer, and (I assume) the pointer type could be set to Void. Or if we wanted to get fancy, that slot could be parametric, but I doubt it's worth it.

[Gnimuc]

I think these features have already been implemented and I've updated a new improvements list in #228, so close this.