On Wed, Apr 25, 2012 at 2:34 AM, Alexander Gladysh <[email protected]> wrote: > Hi, list! > > I've raised this issue some time ago, but would like to do that again. > > Many rocks come bundled C libraries because they are too rare to hope > to be found on users machine. I can name lua-hiredis, lua-uv, lua-inih > from the top of my head — that's only three that I recently worked > with. > > Some other rocks would benefit from exposing their C header files. For > example, lua-nucleo contains some useful C code that is now copied > around, luabins also exports C API to work with serialized data which > is now impossible to use because of the issue being discussed. > > It would be nice if rocks could reuse C libraries from the rocks that > they depend on. > > Thoughts?
I have mixed feelings about features that lead LuaRocks in the direction of becoming a general-purpose package manager. I understand the usefulness of the feature, but (as I said many times before) the dangers of clashing with files provided by the host system can bring many problems (even though that would never happen in your particular use-case). Perhaps the solution would be an extensible design where features such as this one can be brought via plugins or something, only to users who need it and are able to configure their systems accordingly... but that's not easy to design properly. I'll keep this in mind. -- Hisham http://hisham.hm/ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Luarocks-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/luarocks-developers
