On 13 May 2016 at 11:57, Philipp Janda <siffie...@gmx.net> wrote:
> Am 12.05.2016 um 22:09 schröbte Hisham:
>>
>> Waiting for your feedback,
>> Hisham
>>
>> Streamlining the rockspec format
>> ================================
>>
>> if build.type is not given, assume builtin.
>>
>> If build.modules is not given:
>
> 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. 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).
>> 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/. Again,
it's a heuristic. If it ends up promoting some path standardization
("I'll put these here so that I don't need to add extra stuff in the
rockspec") all the better.
> The same is true for bin
> scripts.
We could look for #! lines. I'd like the defaults to be smart
heuristics so that one could have a rockspec writing as little as
possible.
> Also, more often than not you have multiple C files that implement a
> single Lua module. So, the default rule is not that useful for packages
> with multiple C files in them.
That's a good point. I think I was catering for the simplest case of a
module with a single .c file. Maybe that's all we can handle
automagically.
>> Use array part of build.modules for shorthand notation:
>> if string entry is a directory, assume everything inside it is to
>> be installed according to default rules for .lua and .c files
>> if string entry is glob of files, expand glob and assume this is
>> the list of files to install
>> use build.base_dir to extract the dirname when converting paths
>> to module names (e.g. build = { modules = { "src/lua/*.lua" },
>> base_dir = "src/lua" } )
>
> I'm not sure that's better than explicitly specifying module name and
> corresponding source file(s).
>
>>
>> When building C code:
>> If external_dependencies are given and `libdirs`, `libraries` or
>> `incdirs` is not given, propagate the data from external_dependencies
>> automatically.
>
> Linking order matters, so this could fail if you have multiple
> libraries, and one depends on the other.
In that case, `depends` (see below) could be used. But you bring a
good point: the behavior should be deterministic, so the default
propagation should always happen in the same order (e.g.,
lexicographically).
>> Add a `language` key, which may be set globally as
>> `build.language`. Support at first "C", "C99", "C++", "C++11",
>> producing appropriate compiler flags.
>
> While we are at it there's also C11 and C++14. Maybe we should use "C89"
> (or "C90") instead of just "C", because technically the only currently
> valid C standard is ISO C 2011.
Good point.
>> 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.
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.).
>> Range operator "to" -- "lua 5.1 to 5.3" ("<pkg> <ax>.<ay> to
>> <bx>.<by>" means "<pkg >= <ax>.<ay>, < <bx>.<by + 1>")
>> Optional dependencies:
>> support "or" expressions in dependencies.
>
> This one would definitely be welcome ...
>
>> support "optionally" prefix.
>> Default behavior: install optional dependencies by default but
>> keep going if they fail. --optionals={none,install,try (default)}
>
> 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?
>> When specifying external dependencies:
>> A library name without a `.` means a libname suitable for use with
>> -l<libname>. Auto-add it.
>
>> Add a `libraries` field to support an array of libraries.
>> Add other fields that are allowed in the builtin mode, such as
>> `defines`, for auto-propagation
>> Support a list of alternatives when searching paths, and support globs.
>> Add a `distro_suggestions` field, for error messages only. Check
>> `cfg.distro`, which should be configured by upstream.
>>
>> On Windows:
>> Add <external_dependency>_BINDIR to automatic libdirs. (found in
>> LuaSec - is this common practice?)
>>
>> Platform overrides:
>> Expand `platforms` at deeper levels (at any level that does not
>> allow arbitrary keys).
>> Assume that non-arbitrary-keyed entries starting with "append_"
>> mean that the corresponding table is to be appended.
>
> That feature is overdue.
>
>>
>> Support installing arbitrary resource files.
>> In `build.modules`:
>> In the array part, if name (or result of glob expansion) is of
>> an unknown extension, copy it as-is.
>> In the hash part, if key contains a slash, assume it is the
>> filename. If unknown extension, copy it as-is.
>> Add a `resources` (`assets`? simply `files`?) entry for installing
>> straight into share/ (manpages, icons, etc.)
Thank you for the feedback! Let's keep this conversation going!
-- Hisham
------------------------------------------------------------------------------
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
