Sven Panne <[EMAIL PROTECTED]> writes:
>
> "Manuel M. T. Chakravarty" wrote:
> > Isn't there still a difference? When the C-library changes
> > (ie, you get a new version) and the definition of `Status'
> > changes to [...]
> > The IDL binding would produce wrong code, but the Green Card
> > binding would still be correct. Right? Or do I miss something?
>
> The Green Card binding will definitely be correct, but AFAIK the IDL
> binding will be not. This was one of my main motivations for
> preferring Green Card to H/Direct. To the IDL wizards: Is there a
> *simple* way to ensure consistency between header files and IDL
> sources, i.e. without perl/m4/awk/...? This is very important when
> you can't rely on a portable mapping of enumeration types to int.
> My usual example: AFAIK, in OpenGL there's no guarantee that your
> GL_xyz identifier is mapped to a certain int (via enum or cpp).
>
Manuel does highlight a problem, but it's an example of Bad Practice
on the part of the library provider - rejigging the ordering and mapping
of enumeration tags is a no-no if you care about backward compatibility.
[Do GL enums vary between implementations? I'm surprised]
Extending them 'at the end' is acceptable, and what most sane people
seem to be doing. However, since both GC and HDirect doesn't work on
the .h file directly, they're, as you say, unlikely to pick up such a
change :)
HDirect could generate output which delayed the binding of enum tags
to values until the Haskell/C stubs are compiled, if this is a
real problem.
Having a .h -> .idl route would be helpful (at least until .idl has
supplanted the use .h as a means to specify libs ;-), but I'm probably
not going to invest any more time developing HDirect (or GreenCard),
so if anyone feels the itch, go for it!
--sigbjorn
