Yes, lots of thought has gone into this, but its a tricky problem. For the prebuilt luvi binaries I use uname -s and uname -m as the platform key..
I think if we embedded libc into luvi and published headers for all of luvi's exports as part of the release, then addons could link against luvi's headers and not be dependent on anything else, not even the system libc. I'll have to see if this is actually feasable, libuv and luajit use lots of system libraries. Once we have a sane way to know the platform key for a given machine, lit integration can be as simple a magic variable in the name path. So creationix/leveldb/$arch could map to "creationix/leveldb/Linux_x86_64" and be installed as "leveldb.so" so that require can find it. Also we could add a `lit build` command that builds an addon using the proper headers. This will probably be based on cmake like luvi itself. On Mar 2, 2015 7:16 AM, "Martin Croome" <[email protected]> wrote: > Has any thought been given to how one might distribute a native (C) module > with lit? From my own perspective I would like to distribute compiled > binaries rather than building on the destination platform since I will not > have a compiler/toolchain available on it. What seems to be needed is a way > of indicating the appropriate file for the target architecture. I guess I > will look at adding this to lit unless someone already has something > underway or objects to this plan! > > Thanks > > -- > You received this message because you are subscribed to the Google Groups > "luvit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "luvit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
