(Just for the record; I haven't checked if these are already known issues or if
they are actually issues or my misuse)
I am playing again with c2nim. I am not sure if this could be a problem:
typedef enum VSColorFamily {
cmGray = 1000000,
cmRGB = 2000000
} VSColorFamily;
typedef enum VSPresetFormat {
pfNone = 0,
pfGray8 = cmGray + 10,
....
Run
gets converted into:
type
VSColorFamily* {.size: sizeof(cint).} = enum
cmGray = 1000000, cmRGB = 2000000
VSPresetFormat* {.size: sizeof(cint).} = enum
pfNone = 0, pfGray8 = cmGray + 10, ...
Run
Shouldn't it be?
pfGray8 = cmGray.int + 10
Run
given that cmGray's type is VSColorFamily.
Additionally, it looks like the ordering of the items is not correct. For
example, if you have:
pfGray8 = cmGray + 10,
pfGray16,
pfGrayH,
pfGrayS,
pfYUV420P8 = cmYUV + 10,
Run
it seems like c2nim is not taking into account if pfYUV420P8`is smaller than
`pfGray8, because of their values.
The same occurs with the ordering of chars. Nim complains due to the following
ordering:
type
enum
ptFunction = 'm',
ptInt = 'i'
Run
Additionally, it looks like:
typedef struct VSMap VSMap;
Run
does not get converted into:
type
VSMap* {.bycopy.} = object
Run
Finally, just to check, from:
(const VSAPI *) getVapourSynthAPI(int version);
Run
I had:
proc getVapourSynthAPI*(version:cint):ptr VSAPI {.importc,dynlib:
libName.}
Run
while c2nim produces:
cast[ptr VSAPI](getVapourSynthAPI(int, version))
Run
