Getting apitrace to work on Android

[José Fonseca]

On Fri, Mar 9, 2012 at 2:59 AM, George Wright <george at mozilla.com> wrote:
> On 8 Mar 2012, at 20:50, Zack Rusin wrote:
>
>
> Cool. FWIW, ApiTrace has already been made to work on Android by the LunarG
> folks. I'm ccing Chia-I Wu to see if he wants to say anything about it.
>
>
> Great!
>
> From my side, I really dislike the #if android's and the cmake patches are
> very ugly. Also importing GL headers to compile a GL application used to
> debug
> GL applications seems at best crazy.
> But I have very little time for fun projects nowadays and I'm sure Jose will
> do a proper review when he'll be back from his vacations.
>
>
> I also dislike ifdefs, but for such small changes I'm not sure which is
> worse - ifdefing the small changes, or putting said functions in
> Android-specific files.
>
> I tried to make the cmake changes as uninvasive as possible. Can you suggest
> how to clean it up - I'm not sure what your specific concerns are.
>
> When I spoke to Jose about the GL headers being imported he suggested that
> this way was the best way to deal with the issue of apitrace supporting
> several different GL APIs for tracing at runtime, but no way at choose at
> compile time which ones to compile in. I originally looked into getting
> apitrace to only build certain APIs like GLES2 at compile time but it proved
> to be a huge undertaking and I was on a time budget… Do you have any other
> possibilities for how to deal with this problem?
>
> Thanks,
>
> George


Concerning the GL headers, I think that the GL & GL ES APIs are so
intertwined, that trying to get apitrace to build only  GL ES to build
without full GL headers would be a hair pulling exercise.


The only thing I'm not sure is whether we should only include our own
GL headers when there are no system headers, or always include our own
GL header regardless (as we do with gl*ext.h headers).

On one hand, there is no standard GL headers from Khronos, and headers
do vary slightly with platform.

On another hand, system's GL headers already gives us several griefs:
- Apple swaps GLenum with GLint on some entrypoints every now and
then, and C++ type checking rules don't like that.
- Linux/MacOSX ship their own and outdated glext.h, glxext.h etc.


The rest of the changes will need tweaking/cleanups to avoid breaking
other platforms. But instead of iterative reviews I rather do this
myself as I build/test on every platform.


BTW, before I start merging I'm going to tag version 3.0, to avoid
breaking what's there now.


Jose