From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [pkg-luarocks infra V4 10/10] manual: adding packages luarocks
Date: Sun, 22 Dec 2013 18:40:24 +0100 [thread overview]
Message-ID: <20131222184024.012d3bdf@skate> (raw)
In-Reply-To: <1384520859-3189-10-git-send-email-francois.perrad@gadz.org>
Dear Francois Perrad,
On Fri, 15 Nov 2013 14:07:39 +0100, Francois Perrad wrote:
> +Infrastructure for LuaRocks-based packages
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +[[luarocks-package-tutorial]]
> +
> ++luarocks-package+ tutorial
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +First, let's see how to write a +.mk+ file for a LuaRocks-based package,
> +with an example :
> +
> +------------------------
> +01: ################################################################################
> +02: #
> +03: # luafoo
> +04: #
> +05: ################################################################################
> +06:
> +07: LUAFOO_VERSION = 1.0.2-1
> +08: LUAFOO_DEPENDENCIES = foo
Maybe add LUAFOO_LICENSE and LUAFOO_LICENSE_FILES here.
> +10: LUAFOO_BUILD_OPT += FOO_INCDIR=$(STAGING_DIR)/usr/include
> +11: LUAFOO_BUILD_OPT += FOO_LIBDIR=$(STAGING_DIR)/usr/lib
> +12:
> +13: $(eval $(luarocks-package))
> +------------------------
> +
> +On line 7, we declare the version of the package (the same as in the rockspec,
> +which is the concatenation of the upstream version and the rockspec revision).
Maybe indicate that the upstream version and the rockspec version are
separated by a '-' sign ?
> +On line 8, we declare our dependencies, so that they are built
> +before the build process of our package starts.
Maybe mention that dependencies are only needed for packages that link
against native libraries?
> +On line 10-11, we tell Buildroot to pass custom options to LuaRocks when it is
> +building the package.
Ditto here?
> +
> +Finally, on line 13, we invoke the +luarocks-package+
> +macro that generates all the Makefile rules that actually allows the
> +package to be built.
> +
> +[[luarocks-package-reference]]
> +
> ++luarocks-package+ reference
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +LuaRocks is a deployment and management system for Lua modules.
> +
> +LuaRocks supports various +build.type+ : +builtin+, +make+, +cmake+.
> +This infrastructure supports only the +builtin+ mode,
> +the +make+ & +cmake+ modes could be directly handled by generic & cmake infrastructure.
LuaRocks is a deployment and management system for Lua modules, and
supports various +build.type+: +builtin+, +make+ and +cmake+. In the
contetx of Buildroot, the +luarocks-package+ infrastructure only
supports the +builtin+ mode. LuaRocks packages that use the +make+ or
+cmake+ build mechanisms should instead be packaged using the
+generic-package+ and +cmake-package+ infrastructures in Buildroot,
respectively.
> +The main macro of the LuaRocks package infrastructure is
> ++luarocks-package+. It is similar to the +generic-package+ macro.
> +The +host-luarocks-package+ macro is not available,
> +only the +luarocks-package+ macro is available.
> +
> +Just like the generic infrastructure, the LuaRocks infrastructure works
> +by defining a number of variables before calling the +luarocks-package+
> +macro.
The main macro of the LuaRocks package infrastructure is
+luarocks-package+: like +generic-package+ it works by defining a
number of variables providing meta informations about the package, and
then calling +luarocks-package+. It is worth mentioning that building
LuaRocks packages for the host is not supported, so the macro
+host-luarocks-package+ is not implemented.
> +First, all the package metadata information variables that exist in
> +the generic infrastructure also exist in the LuaRocks infrastructure:
> ++LUAFOO_VERSION+, +LUAFOO_SOURCE+, +LUAFOO_SITE+,
> ++LUAFOO_DEPENDENCIES+.
LUAFOO_LICENSE, LUAFOO_LICENSE_FILES
> +Two of them are populate by the LuaRocks infrastructure (for the
populated
> ++download+ step) :
> +
> +* +LUAFOO_SITE+ with the +BR2_LUAROCKS_MIRROR+ value
> +
> +* +LUAFOO_SOURCE+ with +foo-$(FOO_VERSION).src.rock+
If they are populated by the LuaRocks infrastructure, then there is no
point to mention them here.
> +A few additional variables, specific to the LuaRocks infrastructure, are
> +also defined. They could be overridden in specific cases.
> +
> +* +LUAFOO_ROCKSPEC+ with +foo-$(FOO_VERSION).rockspec+
What does "with" means? I guess it means it is the default value, but
it should be explained.
> +
> +* +LUAFOO_SUBDIR+ with +foo-$(FOO_VERSION_WITHOUT_ROCKSPEC_REVISION)+
Ditto.
> +
> +* +LUAFOO_BUILD_OPT+ contains the build options for the +luarocks build+ call.
> + The default is empty.
What is it useful for.
> +With the LuaRocks infrastructure, only 2 steps use +luarocks+ :
> +extract and install-target. +luarocks+ handles building and install
> +in the same step.
> +
> +The step +patch+ is handled by the generic infrastructure.
> +The step +configure+ and +build+ stay empty.
These last two paragraphs are not needed I believe: they give internal
details of how the infrastructure works, which are transparent to the
user of the infrastructure.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2013-12-22 17:40 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-15 13:07 [Buildroot] [pkg-luarocks infra V4 01/10] luainterpreter: create virtual package Francois Perrad
2013-11-15 13:07 ` [Buildroot] [pkg-luarocks infra V4 02/10] luajit: allow to build Lua extensions without lua Francois Perrad
2013-12-22 17:23 ` Thomas Petazzoni
2014-01-07 14:11 ` François Perrad
2014-01-10 2:34 ` Thomas Petazzoni
2013-11-15 13:07 ` [Buildroot] [pkg-luarocks infra V4 03/10] lua: remove a too invasive patch Francois Perrad
2013-12-22 17:24 ` Thomas Petazzoni
2013-12-22 17:30 ` Yann E. MORIN
2013-11-15 13:07 ` [Buildroot] [pkg-luarocks infra V4 04/10] lua*: restore version in module paths Francois Perrad
2013-12-22 17:26 ` Thomas Petazzoni
2013-11-15 13:07 ` [Buildroot] [pkg-luarocks infra V4 05/10] luarocks: new package Francois Perrad
2013-12-22 17:28 ` Thomas Petazzoni
2013-12-22 20:45 ` Yann E. MORIN
2013-12-23 7:56 ` François Perrad
2013-12-23 8:21 ` Thomas Petazzoni
2013-11-15 13:07 ` [Buildroot] [pkg-luarocks infra V4 06/10] luarocks: new infrastructure Francois Perrad
2013-12-22 17:31 ` Thomas Petazzoni
2013-12-22 20:47 ` Yann E. MORIN
2013-12-23 8:20 ` François Perrad
2013-11-15 13:07 ` [Buildroot] [pkg-luarocks infra V4 07/10] lua-cjson: restore official name Francois Perrad
2013-12-22 17:32 ` Thomas Petazzoni
2013-11-15 13:07 ` [Buildroot] [pkg-luarocks infra V4 08/10] luasql-sqlite3: renamed like with LuaRocks Francois Perrad
2013-11-15 13:07 ` [Buildroot] [pkg-luarocks infra V4 09/10] lua*: refactor with luarocks infrastructure Francois Perrad
2013-12-22 17:34 ` Thomas Petazzoni
2013-11-15 13:07 ` [Buildroot] [pkg-luarocks infra V4 10/10] manual: adding packages luarocks Francois Perrad
2013-12-22 17:40 ` Thomas Petazzoni [this message]
2013-12-22 20:51 ` Yann E. MORIN
2013-12-22 20:02 ` Yann E. MORIN
2013-12-22 20:52 ` Yann E. MORIN
2013-12-22 17:22 ` [Buildroot] [pkg-luarocks infra V4 01/10] luainterpreter: create virtual package Thomas Petazzoni
2013-12-22 20:44 ` Yann E. MORIN
2013-12-22 17:37 ` Yann E. MORIN
2013-12-22 20:56 ` Yann E. MORIN
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131222184024.012d3bdf@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox