> now, the ad-hoc way to do this of course is to make a new shared library > (say, "cptr"), that exists both as a .ndll providing the access/alloc > functions, and as a .so to link the other libs (GL.ndll) against. then i can > DECLARE_KIND my kinds in cptr.h, and DEFINE_KIND them in libcptr.so, against > which both cptr.ndll and GL.ndll will link to have access to the kind. > > tho i am thinking that these types are so fundamental and appear in libs > again and again that it would be nice to be able to use them without the > additional burden of another shared lib. so- what do you think about defining > them as constant integers instead of using the memory address of a symbol? or > is this too ugly design-wise? if not, should they probably be defined in > neko.h? or at least be part of the standard dist?
Back to this old subject, I added the two following functions in the Neko API : EXTERN void kind_export( vkind k, const char *name ); EXTERN vkind kind_import( const char *name ); They enable you to export/import an abstract-kind by-name. This can be coupled with a library-specific header describing the content of the "data" structure in order to permit several Neko libraries to share and use each-other abstracts on the C side. Best, Nicolas -- Neko : One VM to run them all (http://nekovm.org)
