Porting Question wrt. Conflicting TypeDefs

Has anyone come across this before, where a large program written for a different platform has done something like:



And, you have needed to indirectly include "exec/types.h" to implement some functionality in a source file. And, boom, now you have "int32" typedef with a conflict.
It is pretty nastly, and the only way I can think of at the moment is to hack the exec/types.h file to my own "ifndef DEFINED_int32" before the typedef inside exec/types.h. Hacking it the other way other way does not work, because the code base is relying on it.


I do not particularly like it

@rjd324

Cant you do

?

@rjd324

I have used two approaches in the past to deal with such issues.

1. A Raziel suggested use conditionals arround the type definitions to avoid redefining the types. That should work as long as int32 is a signed 32 intetger in both systems. (Most likely it is).

2. Isolate the amiga specific code in sperate compilation units (src files)

In a number of ports I've done, most notably perl and blender, some of the amigaos specific code is seperated out completely to avoid these kind of type clashes.

Editing systems headers should be an absolute last resort, if you must, make local copy so that the SDK version remains unaltered

Hi, yes. Separating the functionality into a separate and clean and new translation unit is the first thing I tried. But this project brings uses opengl, and opengl from minigl indirectly includes these type files. In that case it is not possible.

Of course, afterwards, I tried to do as suggested and make the code base modifications versus the sdk modifications, but they use c++ explicit keywords which causes further issues. I could remove all the explicits.

In any case, got there in the end.

Thanks.