Am 16.05.2016 um 16:17 schröbte Hisham: > On 13 May 2016 at 11:57, Philipp Janda <siffie...@gmx.net> wrote: >> >> Having `build.modules` is actually rather nice, because you can infer >> which modules are part of a rock without downloading the source code. I >> think someone somewhere suggested a semi-automated check to ensure that >> there are no module naming conflicts. That option would be off the table ... >> Also, I think that listing the modules to be installed is one of the >> least complicated things when writing a rockspec. > > But is one of the most tedious. At the very least, people asked for > globs numerous times. > > As for inferring module names, having bulid.modules is not sufficient > because of the other build.types.
Most of the rockspecs are builtin-type rockspecs. But sure, you don't get everything (and it's not even clear that flagging module name conflicts is something we want to do). > What I have in mind is changing > `luarocks upload` so that it uploads the corresponding rock_manifest > to luarocks.org from the locally installed rock (and attempts to build > it locally prior to uploading if it's not already built). This way we > could get module name information for all rocks (eventually), and > greatly improve `luarocks search`, etc. (That takes quite some work in > the luarocks.org side of things too, and I haven't talked to Leaf > about it yet, it's just an idea). I've not yet used `luarocks upload`, I use the web-interface. Also, building locally may fail if you need to specify `XY_DIR` variables for a successful build ... > >>> Try one of these: >>> 1) if there's a src/ dir, assume everything inside it is to be >>> installed according to default rules for .lua and .c files >>> 2) if there's a lua/ dir, assume everything inside it is to be >>> installed according to default rules for .lua files >>> 3) if there are *.lua or *.c files in the root, assume they are to >>> be installed according to default rules for .lua and .c files >> >> Hopefully most repositories contain at least a test script. Those would >> be installed as modules by the default rules. > > Yes, but I assume those would be in places like test/, tests/. If you have a `src` directory I'd say chances are high that the test script is in a `tests` directory (or similar), but for small modules I put module source and test script in the main directory. >>> Add a `depends` to specify which libraries to pull definitions >>> from, when building multiple modules that depend on different >>> libraries in the same rock. >> >> I do not understand this one ... > > This is to avoid repetition. > > Say you have five C modules, three of them depend on LibA, two depend on LibB. Hmmm, how many rocks with at least five C modules are there? Also, I believe it doesn't hurt if you just link all five C modules to both libraries (unnecessary libraries are ignored, at least here on Linux). > > Currently, you'll have to add `LIBA_LIBDIR`, `LIBA_INCDIR`, > `libraries` to all three, and then `LIBB_LIBDIR`, `LIBB_INCDIR`, > `libraries` to the other two. (Which is also error-prone because > rockspec authors forget to add stuff such as *_INCDIR because it's in > /usr/include in their system). > > What's proposed here is that, instead, one would write `depends = > "LIBA"` in the first three and `depends = "LIBB"` in the other two. > >>> When specifying dependencies: >>> Add a `build_dependencies` table, checked only during `luarocks build`. >>> Add a `provides` table for allowing virtual dependencies. Depending >>> on a virtual dependency may specify a default suggestion ( "json >>> (default to dkjson)" ). >> >> May or must? If you don't have a default, a `luarocks install` might >> have to fail and prompt the user to manually install other rocks first. > > The alternative is just to let the LuaRocks server pick one (highest > downloaded, e.g.). I'm not a fan of the download counts. At the moment, a large number of downloads only means that another active project with continuous integration installs the rock during automated testing. Downloads by humans are just noise compared to that. Also we'd create a feedback loop, and it would be difficult to get rid of an unmaintained module. I'm still eagerly waiting for the Lua Toolbox to be merged with the LuaRocks.org website. >> >> I'd also like an option to specify that I need (or don't want) LuaJIT. I >> maintain two rocks that won't work on LuaJIT, and there are lots of >> rocks that depend on LuaJIT's FFI. Together with virtual packages you >> can install an FFI-based version on LuaJIT, and a C-based one on PUC-Rio >> Lua. > > For needing LuaJIT, there's the "luajit" entry in rocks_provided; is > saying "not luajit" really needed, given in passes as Lua 5.1? > Well, I maintain two rocks that don't work on LuaJIT (getsize and lbci), because they depend on Lua internals. But those are probably the only ones of their kind in the repository. But if you want to select an FFI-based rock for LuaJIT and a C-based one for non-LuaJIT, you'd have to make sure that the C-based one won't get picked by LuaJIT when resolving virtual dependencies or alternative dependencies. > > Thank you for the feedback! Let's keep this conversation going! > > -- Hisham > Philipp ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j _______________________________________________ Luarocks-developers mailing list Luarocks-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/luarocks-developers
