@@ -76,12 +76,11 @@ Just like the generic infrastructure, the autotools infrastructure
works by defining a number of variables before calling the
+autotools-package+ macro.
-First, all the package metadata information variables that exist in the
-generic infrastructure also exist in the autotools infrastructure:
-+LIBFOO_VERSION+, +LIBFOO_SOURCE+,
-+LIBFOO_PATCH+, +LIBFOO_SITE+,
-+LIBFOO_SUBDIR+, +LIBFOO_DEPENDENCIES+,
-+LIBFOO_INSTALL_STAGING+, +LIBFOO_INSTALL_TARGET+.
+All the package metadata information variables that exist in the
+xref:generic-package-reference[generic package infrastructure] also
+exist in the autotools infrastructure: +LIBFOO_VERSION+,
++LIBFOO_SOURCE+, +LIBFOO_PATCH+, +LIBFOO_SITE+, +LIBFOO_DEPENDENCIES+,
++LIBFOO_LICENSE+, +LIBFOO_LICENSE_FILES+, etc.
A few additional variables, specific to the autotools infrastructure,
can also be defined. Many of them are only useful in very specific
@@ -64,10 +64,11 @@ Just like the generic infrastructure, the Cargo infrastructure works
by defining a number of variables before calling the +cargo-package+
or +host-cargo-package+ macros.
-First, all the package metadata information variables that exist in
-the generic infrastructure also exist in the Cargo infrastructure:
-+FOO_VERSION+, +FOO_SOURCE+, +FOO_PATCH+, +FOO_SITE+,
-+FOO_DEPENDENCIES+, +FOO_LICENSE+, +FOO_LICENSE_FILES+, etc.
+All the package metadata information variables that exist in the
+xref:generic-package-reference[generic package infrastructure] also
+exist in the Cargo infrastructure: +FOO_VERSION+, +FOO_SOURCE+,
++FOO_PATCH+, +FOO_SITE+, +FOO_DEPENDENCIES+, +FOO_LICENSE+,
++FOO_LICENSE_FILES+, etc.
A few additional variables, specific to the Cargo infrastructure, can
also be defined. Many of them are only useful in very specific cases,
@@ -75,11 +75,11 @@ Just like the generic infrastructure, the CMake infrastructure works
by defining a number of variables before calling the +cmake-package+
macro.
-First, all the package metadata information variables that exist in
-the generic infrastructure also exist in the CMake infrastructure:
-+LIBFOO_VERSION+, +LIBFOO_SOURCE+, +LIBFOO_PATCH+, +LIBFOO_SITE+,
-+LIBFOO_SUBDIR+, +LIBFOO_DEPENDENCIES+, +LIBFOO_INSTALL_STAGING+,
-+LIBFOO_INSTALL_TARGET+.
+All the package metadata information variables that exist in the
+xref:generic-package-reference[generic package infrastructure] also
+exist in the Cmake infrastructure: +LIBFOO_VERSION+, +LIBFOO_SOURCE+,
++LIBFOO_PATCH+, +LIBFOO_SITE+, +LIBFOO_DEPENDENCIES+, +LIBFOO_LICENSE+,
++LIBFOO_LICENSE_FILES+, etc.
A few additional variables, specific to the CMake infrastructure, can
also be defined. Many of them are only useful in very specific cases,
@@ -56,16 +56,17 @@ The main macro of the Go package infrastructure is
ability to build host packages is also available, with the
+host-golang-package+ macro.
Host packages built by +host-golang-package+ macro should depend on
-BR2_PACKAGE_HOST_GO_HOST_ARCH_SUPPORTS.
++BR2_PACKAGE_HOST_GO_HOST_ARCH_SUPPORTS+.
Just like the generic infrastructure, the Go infrastructure works
-by defining a number of variables before calling the +golang-package+.
+by defining a number of variables before calling the +golang-package+
+macro.
All the package metadata information variables that exist in the
xref:generic-package-reference[generic package infrastructure] also
exist in the Go infrastructure: +FOO_VERSION+, +FOO_SOURCE+,
-+FOO_PATCH+, +FOO_SITE+, +FOO_SUBDIR+, +FOO_DEPENDENCIES+,
-+FOO_LICENSE+, +FOO_LICENSE_FILES+, +FOO_INSTALL_STAGING+, etc.
++FOO_PATCH+, +FOO_SITE+, +FOO_DEPENDENCIES+, +FOO_LICENSE+,
++FOO_LICENSE_FILES+, etc.
Note that it is not necessary to add +host-go+ in the
+FOO_DEPENDENCIES+ variable of a package, since this basic dependency
@@ -15,10 +15,20 @@ expose the package's +menuconfig+ target as +foo-menuconfig+ in
Buildroot, and to handle the copying back and forth of the configuration
file in a correct way.
-The +kconfig-package+ infrastructure is based on the +generic-package+
-infrastructure. All variables supported by +generic-package+ are
-available in +kconfig-package+ as well. See
-xref:generic-package-reference[] for more details.
+The main macro of the kconfig package infrastructure is
++kconfig-package+: like +generic-package+ it works by defining a number
+of variables providing metadata information about the package, and then
+calling +kconfig-package+ macro.
+
+Just like the generic infrastructure, the kconfig infrastructure works
+by defining a number of variables before calling the +kconfig-package+
+macro.
+
+All the package metadata information variables that exist in the
+xref:generic-package-reference[generic package infrastructure] also
+exist in the kconfig infrastructure: +FOO_VERSION+, +FOO_SOURCE+,
++FOO_PATCH+, +FOO_SITE+, +FOO_DEPENDENCIES+, +FOO_LICENSE+,
++FOO_LICENSE_FILES+, etc.
In order to use the +kconfig-package+ infrastructure for a Buildroot
package, the minimally required lines in the +.mk+ file, in addition to
@@ -73,16 +73,18 @@ infrastructures in Buildroot, respectively.
The main macro of the LuaRocks package infrastructure is +luarocks-package+:
like +generic-package+ it works by defining a number of variables providing
-metadata information about the package, and then calling +luarocks-package+.
+metadata information about the package, and then calling +luarocks-package+
+macro.
Just like the generic infrastructure, the LuaRocks infrastructure works
by defining a number of variables before calling the +luarocks-package+
macro.
-First, all the package metadata information variables that exist in
-the generic infrastructure also exist in the LuaRocks infrastructure:
-+LUA_FOO_VERSION+, +LUA_FOO_SOURCE+, +LUA_FOO_SITE+,
-+LUA_FOO_DEPENDENCIES+, +LUA_FOO_LICENSE+, +LUA_FOO_LICENSE_FILES+.
+All the package metadata information variables that exist in the
+xref:generic-package-reference[generic package infrastructure] also
+exist in the LuaRocks infrastructure: +LUA_FOO_VERSION+,
++LUA_FOO_SOURCE+, +LUA_FOO_PATCH+, +LUA_FOO_SITE+,
++LUA_FOO_DEPENDENCIES+, +LUA_FOO_LICENSE+, +LUA_FOO_LICENSE_FILES+, etc.
Two of them are populated by the LuaRocks infrastructure (for the
+download+ step). If your package is not hosted on the LuaRocks mirror
@@ -76,10 +76,11 @@ packages is also available, with the +host-meson-package+ macro.
Just like the generic infrastructure, the Meson infrastructure works by defining
a number of variables before calling the +meson-package+ macro.
-First, all the package metadata information variables that exist in the generic
-infrastructure also exist in the Meson infrastructure: +FOO_VERSION+,
-+FOO_SOURCE+, +FOO_PATCH+, +FOO_SITE+, +FOO_SUBDIR+, +FOO_DEPENDENCIES+,
-+FOO_INSTALL_STAGING+, +FOO_INSTALL_TARGET+.
+All the package metadata information variables that exist in the
+xref:generic-package-reference[generic package infrastructure] also
+exist in the Meson infrastructure: +FOO_VERSION+, +FOO_SOURCE+,
++FOO_PATCH+, +FOO_SITE+, +FOO_DEPENDENCIES+, +FOO_LICENSE+,
++FOO_LICENSE_FILES+, etc.
A few additional variables, specific to the Meson infrastructure, can also be
defined. Many of them are only useful in very specific cases, typical packages
@@ -85,12 +85,12 @@ Just like the generic infrastructure, the Perl/CPAN infrastructure
works by defining a number of variables before calling the
+perl-package+ macro.
-First, all the package metadata information variables that exist in the
-generic infrastructure also exist in the Perl/CPAN infrastructure:
-+PERL_FOO_VERSION+, +PERL_FOO_SOURCE+,
-+PERL_FOO_PATCH+, +PERL_FOO_SITE+,
-+PERL_FOO_SUBDIR+, +PERL_FOO_DEPENDENCIES+,
-+PERL_FOO_INSTALL_TARGET+.
+All the package metadata information variables that exist in the
+xref:generic-package-reference[generic package infrastructure] also
+exist in the Perl/CPAN infrastructure: +PERL_FOO_VERSION+,
++PERL_FOO_SOURCE+, +PERL_FOO_PATCH+, +PERL_FOO_SITE+,
++PERL_FOO_DEPENDENCIES+, +PERL_FOO_LICENSE+, +PERL_FOO_LICENSE_FILES+,
+etc.
Note that setting +PERL_FOO_INSTALL_STAGING+ to +YES+ has no effect
unless a +PERL_FOO_INSTALL_STAGING_CMDS+ variable is defined. The perl
@@ -81,8 +81,8 @@ All the package metadata information variables that exist in the
xref:generic-package-reference[generic package infrastructure] also
exist in the Python infrastructure: +PYTHON_FOO_VERSION+,
+PYTHON_FOO_SOURCE+, +PYTHON_FOO_PATCH+, +PYTHON_FOO_SITE+,
-+PYTHON_FOO_SUBDIR+, +PYTHON_FOO_DEPENDENCIES+, +PYTHON_FOO_LICENSE+,
-+PYTHON_FOO_LICENSE_FILES+, +PYTHON_FOO_INSTALL_STAGING+, etc.
++PYTHON_FOO_DEPENDENCIES+, +PYTHON_FOO_LICENSE+,
++PYTHON_FOO_LICENSE_FILES+, etc.
Note that:
@@ -51,13 +51,13 @@ Just like the generic infrastructure, the QMake infrastructure works
by defining a number of variables before calling the +qmake-package+
macro.
-First, all the package metadata information variables that exist in
-the generic infrastructure also exist in the QMake infrastructure:
-+LIBFOO_VERSION+, +LIBFOO_SOURCE+, +LIBFOO_PATCH+, +LIBFOO_SITE+,
-+LIBFOO_SUBDIR+, +LIBFOO_DEPENDENCIES+, +LIBFOO_INSTALL_STAGING+,
-+LIBFOO_INSTALL_TARGET+.
+All the package metadata information variables that exist in the
+xref:generic-package-reference[generic package infrastructure] also
+exist in the QMake infrastructure: +LIBFOO_VERSION+, +LIBFOO_SOURCE+,
++LIBFOO_PATCH+, +LIBFOO_SITE+, +LIBFOO_DEPENDENCIES+, +LIBFOO_LICENSE+,
++LIBFOO_LICENSE_FILES+, etc.
-An additional variable, specific to the QMake infrastructure, can
+A few additional variables, specific to the QMake infrastructure, can
also be defined.
* +LIBFOO_CONF_ENV+, to specify additional environment variables to
@@ -51,13 +51,12 @@ Just like the generic infrastructure, the +rebar+ infrastructure works
by defining a number of variables before calling the +rebar-package+
macro.
-First, all the package metadata information variables that exist in
-the generic infrastructure also exist in the +rebar+ infrastructure:
-+ERLANG_FOOBAR_VERSION+, +ERLANG_FOOBAR_SOURCE+,
-+ERLANG_FOOBAR_PATCH+, +ERLANG_FOOBAR_SITE+,
-+ERLANG_FOOBAR_SUBDIR+, +ERLANG_FOOBAR_DEPENDENCIES+,
-+ERLANG_FOOBAR_INSTALL_STAGING+, +ERLANG_FOOBAR_INSTALL_TARGET+,
-+ERLANG_FOOBAR_LICENSE+ and +ERLANG_FOOBAR_LICENSE_FILES+.
+All the package metadata information variables that exist in the
+xref:generic-package-reference[generic package infrastructure] also
+exist in the +rebar+ infrastructure: +ERLANG_FOOBAR_VERSION+,
++ERLANG_FOOBAR_SOURCE+, +ERLANG_FOOBAR_PATCH+, +ERLANG_FOOBAR_SITE+,
++ERLANG_FOOBAR_DEPENDENCIES+, +ERLANG_FOOBAR_LICENSE+,
++ERLANG_FOOBAR_LICENSE_FILES+, etc.
A few additional variables, specific to the +rebar+ infrastructure,
can also be defined. Many of them are only useful in very specific
@@ -51,13 +51,13 @@ Just like the generic infrastructure, the Waf infrastructure works
by defining a number of variables before calling the +waf-package+
macro.
-First, all the package metadata information variables that exist in
-the generic infrastructure also exist in the Waf infrastructure:
-+LIBFOO_VERSION+, +LIBFOO_SOURCE+, +LIBFOO_PATCH+, +LIBFOO_SITE+,
-+LIBFOO_SUBDIR+, +LIBFOO_DEPENDENCIES+, +LIBFOO_INSTALL_STAGING+,
-+LIBFOO_INSTALL_TARGET+.
+All the package metadata information variables that exist in the
+xref:generic-package-reference[generic package infrastructure] also
+exist in the Waf infrastructure: +LIBFOO_VERSION+, +LIBFOO_SOURCE+,
++LIBFOO_PATCH+, +LIBFOO_SITE+, +LIBFOO_DEPENDENCIES+, +LIBFOO_LICENSE+,
++LIBFOO_LICENSE_FILES+, etc.
-An additional variable, specific to the Waf infrastructure, can
+A few additional variables, specific to the Waf infrastructure, can
also be defined.
* +LIBFOO_SUBDIR+ may contain the name of a subdirectory inside the
Currently the text for each package infra that mentions the usage of variables already provided by the generic infra diverge from each other: - some (golang, kconfig, python) add a cross-referece to the generic infra chapter; - kconfig does not list any example; - some mention _LICENSE as an example, others don't; - some (cargo, golang, python) add an 'etc.' at the end of the examples, giving the idea that can be more symbols provided by the generic infra than the ones listed; - most have the text 'works by defining a number of variables before calling the +<macro-name>+ macro', except golang and kconfig; - some actually list 'A few additional variables' but keep using some old reference as 'An additional variable'; - some say 'First, all the package metadata' and other only 'All the package metadata'; - most mention _SUBDIR as an example of variable supported by the generic infra, even the generic infra manual not mentioning it. The _SUBDIR variable is a tricky one. It *is* declared for the generic infra package (and all package infras that inherit from the generic one), but it is really used in certain conditions. package/pkg-generic.mk uses <pkg>_SUBDIR only to define: (2)_SRCDIR = $$($(2)_DIR)/$$($(2)_SUBDIR) and it also uses <pkg>_SRCDIR only to define: $(2)_BUILDDIR ?= $$($(2)_SRCDIR) so the generic package infra does not really uses _SUBDIR by itself in the common scenario. So the manual entry for the generic infra seems correct in not mentioning _SUBDIR. Also any package infra that inherits from the generic one (by calling inner-generic-package) needs to use one of the three variables in order to support _SUBDIR: _BUILDDIR, _SRCDIR or _SUBDIR. That is the case for: autotools (_SRCDIR), cargo (_SRCDIR, _SUBDIR), cmake (_BUILDDIR, _SRCDIR), luarocks (_SRCDIR, _SUBDIR), meson (_SRCDIR), perl (_SRCDIR), python (_BUILDDIR), qmake (_BUILDDIR) and waf (_SRCDIR). Of course the .mk file for a package using the generic infra can define this symbol and use it, directly or indirectly, for example, in its _INSTALL_TARGET_CMDS. Also any package infra, even the ones that do not use directly any of the three variables above, can use _SUBDIR when the package uses the macros KCONFIG_ENABLE_OPT, KCONFIG_SET_OPT or KCONFIG_DISABLE_OPT declared in package/pkg-utils.mk. Improve the correctness for the manual by standardizing the text among the package infras: - use the same text "All the package metadata information variables that exist in the generic package infrastructure also exist in the <name> infrastructure:" for all of them; - add the cross-reference for all of them; - do not mention _SUBDIR as a variable that exist on generic infra; - use the same set of examples for all infras: "_VERSION, _SOURCE, _PATCH, _SITE, _DEPENDENCIES, _LICENSE, _LICENSE_FILES, etc."; - wrap the modified text at 72 columns; - add "macro" to golang and luarocks infra; - use "A few additional variables" for qmake and waf. At same time, add a missing format on golang manual for BR2_PACKAGE_HOST_GO_HOST_ARCH_SUPPORTS. Cc: Eric Le Bihan <eric.le.bihan.dev@free.fr> Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> --- docs/manual/adding-packages-autotools.txt | 11 +++++------ docs/manual/adding-packages-cargo.txt | 9 +++++---- docs/manual/adding-packages-cmake.txt | 10 +++++----- docs/manual/adding-packages-golang.txt | 9 +++++---- docs/manual/adding-packages-kconfig.txt | 18 ++++++++++++++---- docs/manual/adding-packages-luarocks.txt | 12 +++++++----- docs/manual/adding-packages-meson.txt | 9 +++++---- docs/manual/adding-packages-perl.txt | 12 ++++++------ docs/manual/adding-packages-python.txt | 4 ++-- docs/manual/adding-packages-qmake.txt | 12 ++++++------ docs/manual/adding-packages-rebar.txt | 13 ++++++------- docs/manual/adding-packages-waf.txt | 12 ++++++------ 12 files changed, 72 insertions(+), 59 deletions(-)