On Fri, May 13, 2016 at 2:57 PM, 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.
I would like a luarocks command which would fill "modules" part of
rockspec automatically.
>
>
>> 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. The same is true for bin
> scripts.
>
> 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.
>
>>
>> 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.
>
>> 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.
>
>> 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 ...
>
>>
>> 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.
>
>> 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.
>
>>
>> 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.)
>
>
> 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
--
Best regards,
Boris Nagaev
------------------------------------------------------------------------------
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
