ejabberd: XMPP server

Define common macros only once (instead of as many times as there are inner-autotools-package calls).
Factorize LIBTOOL_PATCH_HOOK and AUTORECONF_HOOK to avoid duplicated code.

Signed-off-by Johan Oudinet <[email protected]>

---
 package/pkg-autotools.mk | 119 ++++++++++++++++++++++-------------------------
 1 file changed, 56 insertions(+), 63 deletions(-)

package/pkg-autotools.mk +23 -0

index 09f9412..65af6f0 100644
@@ -46,6 +46,57 @@ endef
 #	$(call AUTOCONF_AC_CHECK_FILE_VAL,/dev/random)=yes
 AUTOCONF_AC_CHECK_FILE_VAL = ac_cv_file_$(subst -,_,$(subst /,_,$(subst .,_,$(1))))
 
+# Recipe that patches libtool so it works properly with
+# cross-compilation.
+define PATCH_LIBTOOL
+	$(Q)if test "$($(PKG)_LIBTOOL_PATCH)" = "YES"; then \
+		for i in `find $($(PKG)_SRCDIR) -name ltmain.sh`; do \
+			ltmain_version=`sed -n '/^[ 	]*VERSION=/{s/^[ 	]*VERSION=//;p;q;}' $$$$i | \
+			sed -e 's/\([0-9].[0-9]*\).*/\1/' -e 's/\"//'`; \
+			if test $${ltmain_version} = 1.5; then \
+				$(APPLY_PATCHES) $${i%/*} support/libtool buildroot-libtool-v1.5.patch; \
+			elif test $${ltmain_version} = 2.2; then\
+				$(APPLY_PATCHES) $${i%/*} support/libtool buildroot-libtool-v2.2.patch; \
+			elif test $${ltmain_version} = 2.4; then\
+				$(APPLY_PATCHES) $${i%/*} support/libtool buildroot-libtool-v2.4.patch; \
+			fi \
+		done \
+	fi
+endef
+
+#
+# Hook to update config.sub and config.guess if needed
+#
+define UPDATE_CONFIG_HOOK
+	@$(call MESSAGE,"Updating config.sub and config.guess")

On 2014-11-07 14:28 +0100, Johan Oudinet spake thusly:

Quoted 4 lines

Define common macros only once (instead of as many times as there are inner-autotools-package calls).
Factorize LIBTOOL_PATCH_HOOK and AUTORECONF_HOOK to avoid duplicated code.

I'll do some more in-depth review later, presumably after you split the patch. If you don;t have time for that, I can see to get it done tomorrow.

Johan, All,

On 2014-11-07 14:28 +0100, Johan Oudinet spake thusly:

Quoted 4 lines

Define common macros only once (instead of as many times as there are inner-autotools-package calls).
Factorize LIBTOOL_PATCH_HOOK and AUTORECONF_HOOK to avoid duplicated code.

Sorry it takes so long to review this series. Touching the infra is not for the faint of heart, and reviews are really complex and time-consuming.

Quoted 37 lines

Signed-off-by Johan Oudinet <[email protected]>

---
 package/pkg-autotools.mk | 119 ++++++++++++++++++++++-------------------------
 1 file changed, 56 insertions(+), 63 deletions(-)

package/pkg-autotools.mk +23 -0

index 09f9412..65af6f0 100644
@@ -46,6 +46,57 @@ endef
 #	$(call AUTOCONF_AC_CHECK_FILE_VAL,/dev/random)=yes
 AUTOCONF_AC_CHECK_FILE_VAL = ac_cv_file_$(subst -,_,$(subst /,_,$(subst .,_,$(1))))
 
+# Recipe that patches libtool so it works properly with
+# cross-compilation.
+define PATCH_LIBTOOL
+	$(Q)if test "$($(PKG)_LIBTOOL_PATCH)" = "YES"; then \
+		for i in `find $($(PKG)_SRCDIR) -name ltmain.sh`; do \
+			ltmain_version=`sed -n '/^[ 	]*VERSION=/{s/^[ 	]*VERSION=//;p;q;}' $$$$i | \
+			sed -e 's/\([0-9].[0-9]*\).*/\1/' -e 's/\"//'`; \
+			if test $${ltmain_version} = 1.5; then \
+				$(APPLY_PATCHES) $${i%/*} support/libtool buildroot-libtool-v1.5.patch; \
+			elif test $${ltmain_version} = 2.2; then\
+				$(APPLY_PATCHES) $${i%/*} support/libtool buildroot-libtool-v2.2.patch; \
+			elif test $${ltmain_version} = 2.4; then\
+				$(APPLY_PATCHES) $${i%/*} support/libtool buildroot-libtool-v2.4.patch; \
+			fi \
+		done \
+	fi
+endef
+
+#
+# Hook to update config.sub and config.guess if needed
+#
+define UPDATE_CONFIG_HOOK
+	@$(call MESSAGE,"Updating config.sub and config.guess")

package/pkg-autotools.mk endef · line 79

Quoted 8 lines

package/pkg-autotools.mk +8 -0

+	$(call CONFIG_UPDATE,$(@D))
+endef
+
+#
+# Hook to patch libtool to make it work properly for cross-compilation
+#
+define LIBTOOL_PATCH_HOOK
+	@$(call MESSAGE,"Patching libtool")

package/pkg-autotools.mk endef · line 81

Quoted 2 lines

package/pkg-autotools.mk +2 -0

+	$(call PATCH_LIBTOOL)
+endef

Hmm... This patch does nore than extract the definitions out of inner-autotools-package; it also reworks the way they are called.

I'd rather we get this split in at least two patches:
- one that does the move proper
- one that reworks the calls

It will be easier to review.

[--SNIP--]

package/pkg-autotools.mk $(2)_DEPENDENCIES += host-gettext · line 254

Quoted 3 lines

package/pkg-autotools.mk +0 -0

@@ -265,6 +253,11 @@ $(2)_DEPENDENCIES += host-gettext
 endif
 $(2)_PRE_CONFIGURE_HOOKS += AUTORECONF_HOOK

package/pkg-autotools.mk $(2)_DEPENDENCIES += host-gettext · line 261

Quoted 7 lines

package/pkg-autotools.mk +5 -0

 $(2)_DEPENDENCIES += host-automake host-autoconf host-libtool
+else
+# default values are not evaluated yet, so don't rely on this defaulting to YES
+ifneq ($$($(2)_LIBTOOL_PATCH),NO)
+$(2)_POST_PATCH_HOOKS += LIBTOOL_PATCH_HOOK
+endif
 endif

I think you got the order wrong here: we want the libtool patch to be applied _before_ we autoreconf.

So, this last if-block should be the very first thing to do right after:

    ifeq ($$($(2)_AUTORECONF),YES)

I'll do some more in-depth review later, presumably after you split the patch. If you don;t have time for that, I can see to get it done tomorrow.

Again, sorry for the delay, reviewing infra changes is really tricky...

Regards,
Yann E. MORIN.

I'm mostly going to negate Yann's comments :-)

Quoted 10 lines

package/pkg-autotools.mk $(2)_DEPENDENCIES += host-gettext · line 261

Quoted 7 lines

$(2)_DEPENDENCIES += host-automake host-autoconf host-libtool

package/pkg-autotools.mk +5 -0

+else
+# default values are not evaluated yet, so don't rely on this defaulting to YES
+ifneq ($$($(2)_LIBTOOL_PATCH),NO)
+$(2)_POST_PATCH_HOOKS += LIBTOOL_PATCH_HOOK
+endif
 endif

I think you got the order wrong here: we want the libtool patch to be applied _before_ we autoreconf.

No, we don't. We want it to be done after the autoreconf, because autoreconf
generates the libtool scripts.

In the original, there was a shell condition that evaluates that AUTORECONF is
not YES in the LIBTOOL_PATCH_HOOK. So you would get the message that libtool is patched before the autoreconf, but the actual patching only happens after the reconf.

Arnout, All,

On 2014-11-11 14:03 +0100, Arnout Vandecappelle spake thusly:

Quoted 1 line

I'm mostly going to negate Yann's comments :-)

Meh... :-)

Quoted 11 lines

Quoted 10 lines

package/pkg-autotools.mk $(2)_DEPENDENCIES += host-gettext · line 261

Quoted 7 lines

$(2)_DEPENDENCIES += host-automake host-autoconf host-libtool

package/pkg-autotools.mk +5 -0

+else
+# default values are not evaluated yet, so don't rely on this defaulting to YES
+ifneq ($$($(2)_LIBTOOL_PATCH),NO)
+$(2)_POST_PATCH_HOOKS += LIBTOOL_PATCH_HOOK
+endif
 endif

I think you got the order wrong here: we want the libtool patch to be applied _before_ we autoreconf.

Quoted 7 lines

No, we don't. We want it to be done after the autoreconf, because autoreconf
generates the libtool scripts.

In the original, there was a shell condition that evaluates that AUTORECONF is
not YES in the LIBTOOL_PATCH_HOOK. So you would get the message that libtool is patched before the autoreconf, but the actual patching only happens after the reconf.

Well, both of us are partialy wrong, I think. LIBTOOL_PATCH_HOOK is a post-patch hook, while GETTEXTIZE_HOOK and AUTORECONF_HOOK are pre-configure hooks. So, the order at which they are defined is irrelevant, as it is done right now.

But I agree with Arnout, we need to rework this.

The issue I can see is that, in case we're not autoreconfiguring, we can only apply the libtool patch once, and that has to be as a post-patch. But if we do autoreconf, it only makes sense to apply it after the autoreconf.

One obvious thing to do would be to always apply it at post-patch, whether we autoreconf or not, and if we do autoreconf, also apply it after the autoreconf. After all, patching is not something that takes a lot of time, is it?

That way, the code path is a bit more obvious.

And move the 13-or-so lines that do the conditional patching out to a single function, so we can share it more easily.

Sigh, I need some more coffee...

Regards,
Yann E. MORIN.

Quoted 6 lines

Well, both of us are partialy wrong, I think. LIBTOOL_PATCH_HOOK is a post-patch hook, while GETTEXTIZE_HOOK and AUTORECONF_HOOK are pre-configure hooks. So, the order at which they are defined is irrelevant, as it is done right now.

But I agree with Arnout, we need to rework this.

All this makes it pretty clear that reworking the call should be done in a
separate patch :-)

Ease the development of packages that use the erlang rebar tool as their build system.

Signed-off-by Johan Oudinet <[email protected]>

---
 docs/manual/adding-packages-rebar.txt | 157 +++++++++++++++++++++++
 docs/manual/adding-packages.txt       |   2 +
 package/Makefile.in                   |   1 +
 package/erlang-rebar/erlang-rebar.mk  |  20 +++
 package/pkg-rebar.mk                  | 229 ++++++++++++++++++++++++++++++++++
 support/scripts/erlang-ei-vsn         |  19 +++
 6 files changed, 428 insertions(+)
 create mode 100644 docs/manual/adding-packages-rebar.txt
 create mode 100644 package/erlang-rebar/erlang-rebar.mk
 create mode 100644 package/pkg-rebar.mk
 create mode 100755 support/scripts/erlang-ei-vsn

package/erlang-rebar/erlang-rebar.mk new file +9 -0

+define HOST_ERLANG_REBAR_BUILD_CMDS
+	cd $(@D) && $(HOST_MAKE_ENV) $(MAKE)
+endef
+
+define HOST_ERLANG_REBAR_INSTALL_CMDS
+	$(INSTALL) -D $(@D)/rebar $(HOST_DIR)/usr/bin/rebar
+endef
+
+$(eval $(host-generic-package))

package/pkg-rebar.mk new file +13 -0

new file mode 100644
index 0000000..9dbd42d
@@ -0,0 +1,229 @@
+################################################################################
+# rebar package infrastructure
+#
+# This file implements an infrastructure that eases development of
+# package .mk files for rebar packages.  It should be used for all
+# packages that use rebar as their build system.
+#
+# In terms of implementation, this rebar infrastructure requires the
+# .mk file to only specify metadata information about the package:
+# name, version, download URL, etc.
+#
+# We still allow the package .mk file to override what the different
+# steps are doing, if needed. For example, if <PKG>_BUILD_CMDS is

package/pkg-rebar.mk new file +135 -0

+################################################################################
+# Helper functions
+################################################################################
+
+# Install an Erlang application from $(@D).
+#
+# i.e., define a recipe that installs the "ebin priv $(2)" directories
+# from $(@D) to $(1)$($(PKG)_ERLANG_LIBDIR).
+#
+#  argument 1 should typically be $(HOST_DIR), $(TARGET_DIR),
+#	      or $(STAGING_DIR).
+#  argument 2 is typically empty when installing in $(TARGET_DIR) and
+#             "include" when installing in $(HOST_DIR) or
+#             $(STAGING_DIR).
+#
+define install-erlang-directories
+	$$(INSTALL) --directory '$(1)$$($$(PKG)_ERLANG_LIBDIR)'
+	for dir in ebin priv $(2); do					\
+		if test -d "$$(@D)/$$$$dir"; then			\
+			cp -r	"$$(@D)/$$$$dir"			\
+				'$(1)$$($$(PKG)_ERLANG_LIBDIR)';	\
+		fi;							\
+	done
+endef
+
+# Setup a symbolic link in rebar's deps_dir to the actual location
+# where an Erlang application is installed.
+#
+# i.e., define a recipe that creates a symbolic link
+# from $($(PKG)_REBAR_DEPS_DIR)/$($(PKG)_ERLANG_APP)
+# to $(1)$($(PKG)_ERLANG_LIBDIR).
+#
+# One typically uses this to setup symbolic links from
+# $(BUILD_DIR)/rebar-deps/<HOST_OR_TARGET>/<ERLANG_APP> to the
+# appropriate application directory in $(HOST_DIR) or $(STAGING_DIR).
+# This avoids rebar complaining about missing dependencies, as this
+# infrastructure does NOT tell rebar to download dependencies during
+# the build stage.
+#
+# Therefore,
+#  argument 1 is $$(HOST_DIR) (for host packages) or
+#	      $$(STAGING_DIR) (for target packages).
+#
+define install-rebar-deps
+	$$(INSTALL) --directory '$$($$(PKG)_REBAR_DEPS_DIR)'
+	ln -f -s							\
+		'$(1)$$($$(PKG)_ERLANG_LIBDIR)'				\
+		'$$($$(PKG)_REBAR_DEPS_DIR)/$$($$(PKG)_ERLANG_APP)'
+endef
+
+################################################################################
+# inner-rebar-package -- defines how the configuration, compilation
+# and installation of a rebar package should be done, implements a few
+# hooks to tune the build process according to rebar specifities, and
+# calls the generic package infrastructure to generate the necessary
+# make targets.
+#
+#  argument 1 is the lowercase package name
+#  argument 2 is the uppercase package name, including a HOST_ prefix
+#             for host packages
+#  argument 3 is the uppercase package name, without the HOST_ prefix
+#             for host packages
+#  argument 4 is the type (target or host)
+#
+################################################################################
+
+define inner-rebar-package
+
+$(2)_ERLANG_APP ?= $(subst -,_,$(call LOWERCASE,$(patsubst ERLANG_%,%,$(3))))
+$(2)_ERLANG_LIBDIR ?= \
+	/usr/lib/erlang/lib/$$($$(PKG)_ERLANG_APP)-$$($$(PKG)_VERSION)
+$(2)_ENV ?=								\
+	CC='$$($(call UPPERCASE,$(4))_CC)'				\
+	CFLAGS='$$($(call UPPERCASE,$(4))_CFLAGS)'			\
+	LDFLAGS='$$($(call UPPERCASE,$(4))_LDFLAGS)'			\
+	ERL_COMPILER_OPTIONS='{i, "$$($$(PKG)_REBAR_DEPS_DIR)"}'	\
+	ERL_EI_LIBDIR='$$($(call UPPERCASE,$(4))_DIR)/usr/lib/erlang/lib/erl_interface-$$(ERLANG_EI_VSN)/lib'
+
+$(2)_REBAR_DEPS_DIR ?= $$(REBAR_$(call UPPERCASE,$(4))_DEPS_DIR)
+$(2)_REBAR_FLAGS ?= deps_dir='$$($$(PKG)_REBAR_DEPS_DIR)'
+$(2)_REBAR_ENV ?= PATH='$$(BR_PATH)'
+
+ifndef $(2)_AUTORECONF
+ ifdef $(3)_AUTORECONF
+  $(2)_AUTORECONF = $$($(3)_AUTORECONF)
+ else
+  $(2)_AUTORECONF ?= NO
+ endif
+endif
+
+$(2)_INTERNAL_CONF_ENV =			\
+	CONFIG_SITE=/dev/null			\
+	PATH='$$(BR_PATH)'			\
+	$$($$(PKG)_ENV)				\
+	$$($$(PKG)_CONF_ENV)
+
+ifeq ($(4),target)
+$(2)_INTERNAL_CONF_FLAGS =			\
+	--target=$$(GNU_TARGET_NAME)		\
+	--host=$$(GNU_TARGET_NAME)		\
+	--build=$$(GNU_HOST_NAME)		\
+	--prefix=/usr				\
+	--exec-prefix=/usr			\
+	--sysconfdir=/etc			\
+	--localstatedir=/var			\
+	--program-prefix=			\
+	$$(DISABLE_NLS)				\
+	$$(DISABLE_LARGEFILE)			\
+	$$(DISABLE_IPV6)			\
+	$$(ENABLE_DEBUG)			\
+	$$(SHARED_STATIC_LIBS_OPTS)		\
+	$$($$(PKG)_CONF_OPTS)
+else
+$(2)_INTERNAL_CONF_FLAGS =			\
+	--prefix='$$(HOST_DIR)/usr'		\
+	--sysconfdir='$$(HOST_DIR)/etc'		\
+	--localstatedir='$$(HOST_DIR)/var'	\
+	--enable-shared --disable-static	\
+	--disable-debug				\
+	$$($$(PKG)_CONF_OPTS)
+endif
+
+ifeq ($$($(2)_AUTORECONF),YES)
+$(2)_PRE_CONFIGURE_HOOKS += AUTORECONF_HOOK
+$(2)_DEPENDENCIES += host-automake host-autoconf host-libtool
+endif
+
+ifndef $(2)_CONFIGURE_CMDS
+define $(2)_CONFIGURE_CMDS
+	if [ -f '$$(@D)/configure' ]; then				\
+		cd '$$(@D)' &&						\
+		rm -rf config.cache &&					\
+		$$($$(PKG)_INTERNAL_CONF_ENV)				\
+		./configure						\
+			--disable-gtk-doc				\

package/pkg-rebar.mk new file +4 -0

+ifndef $(2)_BUILD_CMDS
+define $(2)_BUILD_CMDS
+	cd '$$(@D)' &&							\
+	if [ -f ./rebar ]; then						\

package/pkg-rebar.mk new file +24 -0

+
+ifeq ($(4),host) # Install host files.
+
+ifndef $(2)_INSTALL_CMDS
+define $(2)_INSTALL_CMDS
+	$(call install-erlang-directories,$$(HOST_DIR),include)
+	$(call install-rebar-deps,$$(HOST_DIR))
+endef
+endif
+
+else # Install staging/target files.
+
+ifndef $(2)_INSTALL_STAGING_CMDS
+define $(2)_INSTALL_STAGING_CMDS
+	$(call install-erlang-directories,$$(STAGING_DIR),include)
+	$(call install-rebar-deps,$$(STAGING_DIR))
+endef
+endif
+
+ifndef $(2)_INSTALL_TARGET_CMDS
+define $(2)_INSTALL_TARGET_CMDS
+	$(call install-erlang-directories,$$(TARGET_DIR))
+endef
+endif

support/scripts/erlang-ei-vsn new file +7 -0

new file mode 100755
index 0000000..cdab8e9
@@ -0,0 +1,19 @@
+#! /bin/sh
+# Extract and print the version of Erlang's erl_interface module.
+#
+# Exit non-zero and print nothing if Erlang has not been extracted in
+# output/build.
+
+S=[:space:]

Johan, Thomas, All,

Thomas, there is a question for you later in the mail, just search for your first name. ;-)

On 2014-11-07 14:28 +0100, Johan Oudinet spake thusly:

Quoted 2 lines

Ease the development of packages that use the erlang rebar tool as their build system.

This patch is huge. You should split it into three different patches:
- add the host-rebar package
- add the new pkg-rebar infra
- add the manual part

I won't review the manual part for now, and will concentrate on the package infra.

Quoted 13 lines

Signed-off-by Johan Oudinet <[email protected]>

---
 docs/manual/adding-packages-rebar.txt | 157 +++++++++++++++++++++++
 docs/manual/adding-packages.txt       |   2 +
 package/Makefile.in                   |   1 +
 package/erlang-rebar/erlang-rebar.mk  |  20 +++
 package/pkg-rebar.mk                  | 229 ++++++++++++++++++++++++++++++++++
 support/scripts/erlang-ei-vsn         |  19 +++
 6 files changed, 428 insertions(+)
 create mode 100644 docs/manual/adding-packages-rebar.txt
 create mode 100644 package/erlang-rebar/erlang-rebar.mk
 create mode 100644 package/pkg-rebar.mk
 create mode 100755 support/scripts/erlang-ei-vsn

[--SNIP--]

package/erlang-rebar/erlang-rebar.mk line 3

Quoted 9 lines

package/erlang-rebar/erlang-rebar.mk new file +3 -0

new file mode 100644
index 0000000..917114b
@@ -0,0 +1,20 @@
+################################################################################
+#
+# erlang-rebar

For other pkg infras, we prefix the language type for packages that actually use that infra (e.g. PYTHON_FOO_SOURCE for a Python package, but we do not prefix the Python package itself, like: PYTHON_PYTHON_SOURCE)

So, I think 'rebar' should just be 'rebar'.

package/erlang-rebar/erlang-rebar.mk line 9

Quoted 6 lines

package/erlang-rebar/erlang-rebar.mk new file +6 -0

+#
+################################################################################
+
+ERLANG_REBAR_VERSION = 2.5.1
+ERLANG_REBAR_SOURCE = $(ERLANG_REBAR_VERSION).tar.gz
+ERLANG_REBAR_SITE = https://github.com/rebar/rebar/archive

Hmm... The Erlang folks really can't do anything like the others...

There are two ways to get packages from github:
- the github helper in Buildroot
- the direct 'released' tarballs

So, rebar does do releases on GitHub. Except what they release is not the source code, but the actual generated rebar executable. Sigh...

So, in your case, you have no choice, but to use the github helper, as described in the manual:

    http://nightly.buildroot.org/#_tips_and_tricks

    REBAR_SITE = $(call github,rebar,rebar,$(REBAR_VERSION))

Quoted 1 line

package/erlang-rebar/erlang-rebar.mk new file +1 -0

+ERLANG_REBAR_DEPENDENCIES = host-erlang

Also, missing REBAR_LICENSE and REBAR_LICENSE_FILES.

(Hint: you also need to document ERLANG_FOOBAR_LICENSE and ERLANG_FOOBAR_LICENSE_FILES in the manual.)

Quoted 33 lines

package/erlang-rebar/erlang-rebar.mk new file +9 -0

+define HOST_ERLANG_REBAR_BUILD_CMDS
+	cd $(@D) && $(HOST_MAKE_ENV) $(MAKE)
+endef
+
+define HOST_ERLANG_REBAR_INSTALL_CMDS
+	$(INSTALL) -D $(@D)/rebar $(HOST_DIR)/usr/bin/rebar
+endef
+
+$(eval $(host-generic-package))

package/pkg-rebar.mk new file +18 -0

new file mode 100644
index 0000000..9dbd42d
@@ -0,0 +1,229 @@
+################################################################################
+# rebar package infrastructure
+#
+# This file implements an infrastructure that eases development of
+# package .mk files for rebar packages.  It should be used for all
+# packages that use rebar as their build system.
+#
+# In terms of implementation, this rebar infrastructure requires the
+# .mk file to only specify metadata information about the package:
+# name, version, download URL, etc.
+#
+# We still allow the package .mk file to override what the different
+# steps are doing, if needed. For example, if <PKG>_BUILD_CMDS is
+# already defined, it is used as the list of commands to perform to
+# build the package, instead of the default rebar behaviour. The
+# package can also define some post operation hooks.
+#
+################################################################################

package/pkg-rebar.mk line 23

Quoted 5 lines

package/pkg-rebar.mk new file +5 -0

+
+# Version of Erlang's erl_interface module.  One needs this to setup
+# proper linker flags when building Erlang modules written in C.
+#
+ERLANG_EI_VSN = $(shell support/scripts/erlang-ei-vsn)

See at the end my comments about that variable: it should be set from the erlang.mk (or so I think).

package/pkg-rebar.mk line 30

Quoted 7 lines

package/pkg-rebar.mk new file +6 -0

+# Directories to store rebar dependencies in.
+#
+# These directories actually only contain symbolic links to Erlang
+# applications in either $(HOST_DIR) or $(STAGING_DIR).  One needs
+# them to avoid rebar complaining about missing dependencies, as this
+# infrastructure does NOT tell rebar to download dependencies during

package/pkg-rebar.mk line 34

Quoted 4 lines

package/pkg-rebar.mk new file +4 -0

+# the build stage.
+#
+REBAR_HOST_DEPS_DIR = $(BUILD_DIR)/erlang-rebar-deps/host
+REBAR_TARGET_DEPS_DIR = $(BUILD_DIR)/erlang-rebar-deps/target

Well, I would prefer those directories not be stored in the build dir, but somewhere like:

    $(HOST_DIR)/usr/share/rebar/deps-host
    $(HOST_DIR)/usr/share/rebar/deps-target

We do not have a location for that kind of information for now in Buildroot. I believe it belongs somewhere into $(HOST_DIR), but I would accept to be contradicted on that one.

Quoted 10 lines

package/pkg-rebar.mk new file +9 -0

+################################################################################
+# Helper functions
+################################################################################
+
+# Install an Erlang application from $(@D).
+#
+# i.e., define a recipe that installs the "ebin priv $(2)" directories
+# from $(@D) to $(1)$($(PKG)_ERLANG_LIBDIR).
+#

package/pkg-rebar.mk line 52

Quoted 8 lines

package/pkg-rebar.mk new file +8 -0

+#  argument 1 should typically be $(HOST_DIR), $(TARGET_DIR),
+#	      or $(STAGING_DIR).
+#  argument 2 is typically empty when installing in $(TARGET_DIR) and
+#             "include" when installing in $(HOST_DIR) or
+#             $(STAGING_DIR).
+#
+define install-erlang-directories
+	$$(INSTALL) --directory '$(1)$$($$(PKG)_ERLANG_LIBDIR)'

package/pkg-rebar.mk line 59

Quoted 7 lines

package/pkg-rebar.mk new file +7 -0

+	for dir in ebin priv $(2); do					\
+		if test -d "$$(@D)/$$$$dir"; then			\
+			cp -r	"$$(@D)/$$$$dir"			\
+				'$(1)$$($$(PKG)_ERLANG_LIBDIR)';	\
+		fi;							\
+	done
+endef

Quoted 22 lines

package/pkg-rebar.mk new file +22 -0

+
+# Setup a symbolic link in rebar's deps_dir to the actual location
+# where an Erlang application is installed.
+#
+# i.e., define a recipe that creates a symbolic link
+# from $($(PKG)_REBAR_DEPS_DIR)/$($(PKG)_ERLANG_APP)
+# to $(1)$($(PKG)_ERLANG_LIBDIR).
+#
+# One typically uses this to setup symbolic links from
+# $(BUILD_DIR)/rebar-deps/<HOST_OR_TARGET>/<ERLANG_APP> to the
+# appropriate application directory in $(HOST_DIR) or $(STAGING_DIR).
+# This avoids rebar complaining about missing dependencies, as this
+# infrastructure does NOT tell rebar to download dependencies during
+# the build stage.
+#
+# Therefore,
+#  argument 1 is $$(HOST_DIR) (for host packages) or
+#	      $$(STAGING_DIR) (for target packages).
+#
+define install-rebar-deps
+	$$(INSTALL) --directory '$$($$(PKG)_REBAR_DEPS_DIR)'
+	ln -f -s							\

package/pkg-rebar.mk line 89

Quoted 8 lines

package/pkg-rebar.mk new file +8 -0

+		'$(1)$$($$(PKG)_ERLANG_LIBDIR)'				\
+		'$$($$(PKG)_REBAR_DEPS_DIR)/$$($$(PKG)_ERLANG_APP)'
+endef
+
+################################################################################
+# inner-rebar-package -- defines how the configuration, compilation
+# and installation of a rebar package should be done, implements a few
+# hooks to tune the build process according to rebar specifities, and

Quoted 7 lines

package/pkg-rebar.mk new file +7 -0

+# calls the generic package infrastructure to generate the necessary
+# make targets.
+#
+#  argument 1 is the lowercase package name
+#  argument 2 is the uppercase package name, including a HOST_ prefix
+#             for host packages
+#  argument 3 is the uppercase package name, without the HOST_ prefix

package/pkg-rebar.mk line 104

Quoted 8 lines

package/pkg-rebar.mk new file +8 -0

+#             for host packages
+#  argument 4 is the type (target or host)
+#
+################################################################################
+
+define inner-rebar-package
+
+$(2)_ERLANG_APP ?= $(subst -,_,$(call LOWERCASE,$(patsubst ERLANG_%,%,$(3))))

package/pkg-rebar.mk line 106

Quoted 2 lines

package/pkg-rebar.mk new file +2 -0

+$(2)_ERLANG_LIBDIR ?= \
+	/usr/lib/erlang/lib/$$($$(PKG)_ERLANG_APP)-$$($$(PKG)_VERSION)

package/pkg-rebar.mk line 110

Quoted 4 lines

package/pkg-rebar.mk new file +4 -0

+$(2)_ENV ?=								\
+	CC='$$($(call UPPERCASE,$(4))_CC)'				\
+	CFLAGS='$$($(call UPPERCASE,$(4))_CFLAGS)'			\
+	LDFLAGS='$$($(call UPPERCASE,$(4))_LDFLAGS)'			\

Quoted 6 lines

package/pkg-rebar.mk new file +6 -0

+	ERL_COMPILER_OPTIONS='{i, "$$($$(PKG)_REBAR_DEPS_DIR)"}'	\
+	ERL_EI_LIBDIR='$$($(call UPPERCASE,$(4))_DIR)/usr/lib/erlang/lib/erl_interface-$$(ERLANG_EI_VSN)/lib'
+
+$(2)_REBAR_DEPS_DIR ?= $$(REBAR_$(call UPPERCASE,$(4))_DEPS_DIR)
+$(2)_REBAR_FLAGS ?= deps_dir='$$($$(PKG)_REBAR_DEPS_DIR)'
+$(2)_REBAR_ENV ?= PATH='$$(BR_PATH)'

package/pkg-rebar.mk line 124

Quoted 8 lines

package/pkg-rebar.mk new file +8 -0

+
+ifndef $(2)_AUTORECONF
+ ifdef $(3)_AUTORECONF
+  $(2)_AUTORECONF = $$($(3)_AUTORECONF)
+ else
+  $(2)_AUTORECONF ?= NO
+ endif
+endif

Quoted 46 lines

package/pkg-rebar.mk new file +46 -0

+
+$(2)_INTERNAL_CONF_ENV =			\
+	CONFIG_SITE=/dev/null			\
+	PATH='$$(BR_PATH)'			\
+	$$($$(PKG)_ENV)				\
+	$$($$(PKG)_CONF_ENV)
+
+ifeq ($(4),target)
+$(2)_INTERNAL_CONF_FLAGS =			\
+	--target=$$(GNU_TARGET_NAME)		\
+	--host=$$(GNU_TARGET_NAME)		\
+	--build=$$(GNU_HOST_NAME)		\
+	--prefix=/usr				\
+	--exec-prefix=/usr			\
+	--sysconfdir=/etc			\
+	--localstatedir=/var			\
+	--program-prefix=			\
+	$$(DISABLE_NLS)				\
+	$$(DISABLE_LARGEFILE)			\
+	$$(DISABLE_IPV6)			\
+	$$(ENABLE_DEBUG)			\
+	$$(SHARED_STATIC_LIBS_OPTS)		\
+	$$($$(PKG)_CONF_OPTS)
+else
+$(2)_INTERNAL_CONF_FLAGS =			\
+	--prefix='$$(HOST_DIR)/usr'		\
+	--sysconfdir='$$(HOST_DIR)/etc'		\
+	--localstatedir='$$(HOST_DIR)/var'	\
+	--enable-shared --disable-static	\
+	--disable-debug				\
+	$$($$(PKG)_CONF_OPTS)
+endif
+
+ifeq ($$($(2)_AUTORECONF),YES)
+$(2)_PRE_CONFIGURE_HOOKS += AUTORECONF_HOOK
+$(2)_DEPENDENCIES += host-automake host-autoconf host-libtool
+endif
+
+ifndef $(2)_CONFIGURE_CMDS
+define $(2)_CONFIGURE_CMDS
+	if [ -f '$$(@D)/configure' ]; then				\
+		cd '$$(@D)' &&						\
+		rm -rf config.cache &&					\
+		$$($$(PKG)_INTERNAL_CONF_ENV)				\
+		./configure						\
+			--disable-gtk-doc				\

package/pkg-rebar.mk line 180

Quoted 10 lines

package/pkg-rebar.mk new file +10 -0

+			--disable-doc					\
+			--disable-docs					\
+			--disable-documentation				\
+			--with-xmlto=no					\
+			--with-fop=no					\
+			--disable-dependency-tracking			\
+			$$(QUIET) $$($$(PKG)_INTERNAL_CONF_FLAGS);	\
+	fi
+endef
+endif

Hmm... It looks like you're borrowing a lot from pkg-autotools. I do not like this duplication, especially in the pkg infras, since fixing something would imply hunting down all over the place...

What if you would call to inner-autotools-package instead of calling to inner-generic-package ?

The only problem is that pkg-autotools always calls ./configure, while in the rebar case, you only want to call it conditionally.

Except the only Erlang package that has a ./configure is ejabberd itself, and you're introducing complexity for just one package.

And ejabberd is not even a complete autotools package: it only uses autoconf (via configure.ac) but not automake (no Makefile.am).

And you need to autoreconf ejabberd because:
- you get it from the git tree. There is a release tarball, though:

      http://www.process-one.net/downloads/ejabberd/14.07/ejabberd-14.07.tgz

- you do not want to run the version check in patch 0004-disable-version-check.patch, but you could well use the configure switch --disable-erlang-version-check

The only problem I could foresee is that it tries to run the target Erlang compiler, right? If so, just patch the configure script directly (ugly, but that's better than trying to get complexity in the rebar infra just for this sucker^Wsingle package. ;-)

So, in the end, just make it a generic package (like you did here), do not provide any _CONFIGURE_CMDS, and delegate to ejabberd the responsibility to provide its own EJABBERD_CONFIGURE_CMDS

Hmmm... Looking further, it seems a few others (all from ProcessOne?) also uses ./configure . What about adding a new variable, like:

ERLANG_FOO_CONFIGURE = YES

which would tell whether running configure is needed?

I'd like input from Thomas P. on all the above, because we get into really tricky-icky stuff... Thomas?

And by the way, since ejabberd is using the rebar infra, then maybe it makes sense to call that package erlang-ejabberd? I know it sounds strange, but that what's you did for all other rebar-using packages, so I don't see why this would be different for that one.

Quoted 5 lines

package/pkg-rebar.mk new file +4 -0

+ifndef $(2)_BUILD_CMDS
+define $(2)_BUILD_CMDS
+	cd '$$(@D)' &&							\
+	if [ -f ./rebar ]; then						\

package/pkg-rebar.mk line 195

Quoted 10 lines

package/pkg-rebar.mk new file +10 -0

+		$$($$(PKG)_ENV)						\
+		$$($$(PKG)_REBAR_ENV)					\
+			./rebar $$($$(PKG)_REBAR_FLAGS) compile;	\
+	else								\
+		$$($$(PKG)_ENV)						\
+		$$($$(PKG)_REBAR_ENV)					\
+			rebar $$($$(PKG)_REBAR_FLAGS) compile;		\
+	fi
+endef
+endif

Hmm... Do we want to trust the package's own rebar? Shouldn't we always use our own version of rebar instead?

What would be the reason to 'trust' the package's rebar more than our?

package/pkg-rebar.mk line 201

Quoted 7 lines

package/pkg-rebar.mk new file +6 -0

+
+ifeq ($(4),host) # Install host files.
+
+ifndef $(2)_INSTALL_CMDS
+define $(2)_INSTALL_CMDS
+	$(call install-erlang-directories,$$(HOST_DIR),include)

Quoted 18 lines

package/pkg-rebar.mk new file +18 -0

+	$(call install-rebar-deps,$$(HOST_DIR))
+endef
+endif
+
+else # Install staging/target files.
+
+ifndef $(2)_INSTALL_STAGING_CMDS
+define $(2)_INSTALL_STAGING_CMDS
+	$(call install-erlang-directories,$$(STAGING_DIR),include)
+	$(call install-rebar-deps,$$(STAGING_DIR))
+endef
+endif
+
+ifndef $(2)_INSTALL_TARGET_CMDS
+define $(2)_INSTALL_TARGET_CMDS
+	$(call install-erlang-directories,$$(TARGET_DIR))
+endef
+endif

package/pkg-rebar.mk line 229

Quoted 10 lines

package/pkg-rebar.mk new file +10 -0

+
+endif
+
+$(call inner-generic-package,$(1),$(2),$(3),$(4))
+
+endef # inner-rebar-package
+
+rebar-package = $(call inner-rebar-package,$(pkgname),$(call UPPERCASE,$(pkgname)),$(call UPPERCASE,$(pkgname)),target)
+
+host-rebar-package = $(call inner-rebar-package,host-$(pkgname),$(call UPPERCASE,host-$(pkgname)),$(call UPPERCASE,$(pkgname)),host)

No empty lines between the target and host variants.

Quoted 13 lines

support/scripts/erlang-ei-vsn new file +7 -0

new file mode 100755
index 0000000..cdab8e9
@@ -0,0 +1,19 @@
+#! /bin/sh
+# Extract and print the version of Erlang's erl_interface module.
+#
+# Exit non-zero and print nothing if Erlang has not been extracted in
+# output/build.
+
+S=[:space:]

support/scripts/erlang-ei-vsn line 17

Quoted 10 lines

support/scripts/erlang-ei-vsn new file +10 -0

+
+# Extract the BAR part from all lines matching "$2 = BAR" in file $1.
+get_make_variable() {
+    local file="$1" name="$2"
+
+    sed "s/^[$S]*$name[$S]*=[$S]*\\([^$S]*\\)[$S]*\$/\\1/; t; d" "$file"
+}
+
+ERLANG_VSN=$(get_make_variable package/erlang/erlang.mk ERLANG_VERSION)
+EI_VSN_FILE=output/build/erlang-$ERLANG_VSN/lib/erl_interface/vsn.mk

That does not work for out-of-tree builds. You should use something like:

    EI_VSN_FILE="${O}/build/erlang-$ERLANG_VSN/lib/erl_interface/vsn.mk"

However, rather than poke in the erlang sources, could you modify our erlang.mk and add a post-install hook that just extract this value and installs it in (for example) $(HOST_DIR)/usr/share/erlang/EI_VSN .

But if you have ERLANG_EI_VSN set from the erlang.mk package itself, you do not need to have that script.

support/scripts/erlang-ei-vsn line 19

Quoted 1 line

support/scripts/erlang-ei-vsn new file +1 -0

+[ -f "$EI_VSN_FILE" ] && get_make_variable "$EI_VSN_FILE" EI_VSN

OK, I'm definitely not done reviewing that series. ;-)

But it looks very, *very* promising! :-)

Regards,
Yann E. MORIN.

Quoted 8 lines

Johan, Thomas, All,

Thomas, there is a question for you later in the mail, just search for your first name. ;-)

On 2014-11-07 14:28 +0100, Johan Oudinet spake thusly:

Quoted 2 lines

Ease the development of packages that use the erlang rebar tool as their build system.

Quoted 3 lines

For other pkg infras, we prefix the language type for packages that actually use that infra (e.g. PYTHON_FOO_SOURCE for a Python package, but we do not prefix the Python package itself, like: PYTHON_PYTHON_SOURCE)

Err, we do exactly the same for python-setuptools, so how is this different?

You could say that the package infrastructure should be named pkg-erlang
instead of pkg-rebar, but I don't think so. The situation is a bit similar to qmake - qmake is the canonical build tool for Qt packages, but if we would have qmake infrastructure, it would be called pkg-qmake and not pkg-qt.

So I vote for erlang-rebar and pkg-rebar, exactly as it is now.

Quoted 15 lines

So, I think 'rebar' should just be 'rebar'.

package/erlang-rebar/erlang-rebar.mk line 9

Quoted 6 lines

package/erlang-rebar/erlang-rebar.mk new file +6 -0

+#
+################################################################################
+
+ERLANG_REBAR_VERSION = 2.5.1
+ERLANG_REBAR_SOURCE = $(ERLANG_REBAR_VERSION).tar.gz
+ERLANG_REBAR_SITE = https://github.com/rebar/rebar/archive

Hmm... The Erlang folks really can't do anything like the others...

There are two ways to get packages from github:
- the github helper in Buildroot
- the direct 'released' tarballs

Quoted 2 lines

So, rebar does do releases on GitHub. Except what they release is not the source code, but the actual generated rebar executable. Sigh...

Err, when I download https://github.com/rebar/rebar/archive/2.5.1.tar.gz I get
exactly the same files as what is in the 2.5.1 tag, I don't get any executable...

Quoted 8 lines

package/pkg-rebar.mk line 34

Quoted 3 lines

package/pkg-rebar.mk new file +3 -0

+#
+REBAR_HOST_DEPS_DIR = $(BUILD_DIR)/erlang-rebar-deps/host
+REBAR_TARGET_DEPS_DIR = $(BUILD_DIR)/erlang-rebar-deps/target

Well, I would prefer those directories not be stored in the build dir, but somewhere like:

    $(HOST_DIR)/usr/share/rebar/deps-host
    $(HOST_DIR)/usr/share/rebar/deps-target

+1, but I'd say

$(HOST_DIR)/usr/share/rebar/deps
$(STAGING_DIR)/usr/share/rebar/deps

Note on the naming: even though the package is called erlang-rebar for
buildroot, anything it installs will just be rebar (without erlang-) because that's how upstream identifies itself.

Quoted 7 lines

package/pkg-rebar.mk line 59

Quoted 7 lines

package/pkg-rebar.mk new file +7 -0

+	for dir in ebin priv $(2); do					\
+		if test -d "$$(@D)/$$$$dir"; then			\
+			cp -r	"$$(@D)/$$$$dir"			\
+				'$(1)$$($$(PKG)_ERLANG_LIBDIR)';	\
+		fi;							\
+	done
+endef

Ah, double-$ mess :-)

The double-$ is needed only because it is called from inner-rebar-package,
which means that this function cannot be called from custom package commands. That's not very nice.

Fortunately, the solution is very simple: use single $ here, and put a double $
at the $$(call install-erlang-directories,...) site.

(Of course I haven't tested this, so YMMV.)

Same for all other functions defined below

Quoted 3 lines

package/pkg-rebar.mk line 104

Quoted 3 lines

package/pkg-rebar.mk new file +3 -0

+define inner-rebar-package
+
+$(2)_ERLANG_APP ?= $(subst -,_,$(call LOWERCASE,$(patsubst ERLANG_%,%,$(3))))

It would make more sense to me to do

$(subst -,_,$(patsubst erlang-%,%,$(patsubst host-%,%,$(1))))

Quoted 2 lines

package/pkg-rebar.mk line 106

Quoted 2 lines

+$(2)_ERLANG_LIBDIR ?= \

package/pkg-rebar.mk new file +1 -0

+	/usr/lib/erlang/lib/$$($$(PKG)_ERLANG_APP)-$$($$(PKG)_VERSION)

Does it make sense to make this configurable? I.e., wouldn't it be better to
just expand this in the two places where it's used? It would certainly be clearer that way.

Quoted 4 lines

package/pkg-rebar.mk line 110

Quoted 4 lines

+$(2)_ENV ?= \

package/pkg-rebar.mk new file +3 -0

+	CC='$$($(call UPPERCASE,$(4))_CC)'				\
+	CFLAGS='$$($(call UPPERCASE,$(4))_CFLAGS)'			\
+	LDFLAGS='$$($(call UPPERCASE,$(4))_LDFLAGS)'			\

I don't like this way of distinguishing host and target very much. It avoids
code duplication, but it's a lot harder to read. So I'd prefer

ifeq ($(4),host)

$(2)_ENV ?= \
	CC='$$(TARGET_CC)' \
	CFLAGS='$$(TARGET_CFLAGS)' \
	...

Also, it would be nice to cater for custom CFLAGS, i.e.

	CFLAGS='$$(TARGET_CFLAGS) $$($$(PKG)_CFLAGS)'

Quoted 3 lines

And you need to autoreconf ejabberd because:
- you get it from the git tree. There is a release tarball, though:

      http://www.process-one.net/downloads/ejabberd/14.07/ejabberd-14.07.tgz

That's of course definitely a good idea, but it should still be _possible_ to
use a git version.

Quoted 6 lines

Hmmm... Looking further, it seems a few others (all from ProcessOne?) also uses ./configure . What about adding a new variable, like:

ERLANG_FOO_CONFIGURE = YES

which would tell whether running configure is needed?

I have the feeling we'll need a rebar-package and rebar-autotools-package.

But starting with FOO_CONFIGURE isn't a bad idea either.

Quoted 7 lines

I'd like input from Thomas P. on all the above, because we get into really tricky-icky stuff... Thomas?

And by the way, since ejabberd is using the rebar infra, then maybe it makes sense to call that package erlang-ejabberd? I know it sounds strange, but that what's you did for all other rebar-using packages, so I don't see why this would be different for that one.

No, the convention is that library-type packages should be called
<language>-<package>, while program-type packages should be called just <package> (and should select the programming language rather than depending on it).

Quoted 18 lines

Quoted 4 lines

package/pkg-rebar.mk new file +4 -0

+ifndef $(2)_BUILD_CMDS
+define $(2)_BUILD_CMDS
+	cd '$$(@D)' &&							\
+	if [ -f ./rebar ]; then						\

package/pkg-rebar.mk line 195

Quoted 10 lines

package/pkg-rebar.mk new file +10 -0

+		$$($$(PKG)_ENV)						\
+		$$($$(PKG)_REBAR_ENV)					\
+			./rebar $$($$(PKG)_REBAR_FLAGS) compile;	\
+	else								\
+		$$($$(PKG)_ENV)						\
+		$$($$(PKG)_REBAR_ENV)					\
+			rebar $$($$(PKG)_REBAR_FLAGS) compile;		\
+	fi
+endef
+endif

Hmm... Do we want to trust the package's own rebar? Shouldn't we always use our own version of rebar instead?

Quoted 1 line

What would be the reason to 'trust' the package's rebar more than our?

Because the package's rebar may be more up-to-date or may be modified. As long
as we don't apply cross-compilation patches to our rebar, there is no reason to prefer that one.

Ideally, however, the package should only depend on host-rebar if it will
actually use it. It's not a showstopper for me, just a preference.

Also, I have a slight preference for the buildroot package to specify which one
should be used rather than autodiscovering it. But again, not a showstopper for me.

Quoted 5 lines

package/pkg-rebar.mk line 201

Quoted 5 lines

package/pkg-rebar.mk new file +5 -0

+ifeq ($(4),host) # Install host files.
+
+ifndef $(2)_INSTALL_CMDS
+define $(2)_INSTALL_CMDS
+	$(call install-erlang-directories,$$(HOST_DIR),include)

Personally, I'd find it slightly more readable to put all the directories here
(ebin priv include) rather than automagically installing ebin and priv.

Quoted 24 lines

Quoted 18 lines

Quoted 4 lines

package/pkg-rebar.mk new file +4 -0

+ifndef $(2)_BUILD_CMDS
+define $(2)_BUILD_CMDS
+  cd '$$(@D)' &&                                                  \
+  if [ -f ./rebar ]; then                                         \

package/pkg-rebar.mk line 195

Quoted 10 lines

package/pkg-rebar.mk new file +10 -0

+          $$($$(PKG)_ENV)                                         \
+          $$($$(PKG)_REBAR_ENV)                                   \
+                  ./rebar $$($$(PKG)_REBAR_FLAGS) compile;        \
+  else                                                            \
+          $$($$(PKG)_ENV)                                         \
+          $$($$(PKG)_REBAR_ENV)                                   \
+                  rebar $$($$(PKG)_REBAR_FLAGS) compile;          \
+  fi
+endef
+endif

Hmm... Do we want to trust the package's own rebar? Shouldn't we always use our own version of rebar instead?

Quoted 1 line

What would be the reason to 'trust' the package's rebar more than our?

Because the package's rebar may be more up-to-date or may be modified. As long
as we don't apply cross-compilation patches to our rebar, there is no reason to prefer that one.

Quoted 2 lines

Ideally, however, the package should only depend on host-rebar if it will
actually use it. It's not a showstopper for me, just a preference.

But as Johan said, some packages' rebar may break the compilation, like I could observe in my testing.

Johan, care to investigate why would we use the package's rebar instead of our own?

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

package/pkg-rebar.mk new file +6 -0

+ifndef $(2)_BUILD_CMDS
+define $(2)_BUILD_CMDS
+  cd '$$(@D)' &&                                                  \
+  if [ -f ./rebar ]; then                                         \
+          $$($$(PKG)_ENV)                                         \
+          $$($$(PKG)_REBAR_ENV)                                   \

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

package/pkg-rebar.mk line 195

Quoted 8 lines

package/pkg-rebar.mk new file +8 -0

+                  ./rebar $$($$(PKG)_REBAR_FLAGS) compile;        \
+  else                                                            \
+          $$($$(PKG)_ENV)                                         \
+          $$($$(PKG)_REBAR_ENV)                                   \
+                  rebar $$($$(PKG)_REBAR_FLAGS) compile;          \
+  fi
+endef
+endif

Quoted 2 lines

Johan, care to investigate why would we use the package's rebar instead of our own?

That's because packages distribute a rebar.config{,.script} file and its syntax may differ from the rebar version packaged in buildroot. Anyway, if I find out some packages' rebar break the compilation, the solution is probably to use our own rebar and patch the rebar configuration file of packages that distribute an old version.

Signed-off-by Johan Oudinet <[email protected]>

---
 package/Config.in                          |  1 +
 package/erlang-p1-iconv/Config.in          |  6 ++++++
 package/erlang-p1-iconv/erlang-p1-iconv.mk | 17 +++++++++++++++++
 3 files changed, 24 insertions(+)
 create mode 100644 package/erlang-p1-iconv/Config.in
 create mode 100644 package/erlang-p1-iconv/erlang-p1-iconv.mk

On 2014-11-07 14:28 +0100, Johan Oudinet spake thusly:

Quoted 8 lines

Signed-off-by Johan Oudinet <[email protected]>

---
 package/Config.in                          |  1 +
 package/erlang-p1-iconv/Config.in          |  6 ++++++
 package/erlang-p1-iconv/erlang-p1-iconv.mk | 17 +++++++++++++++++
 3 files changed, 24 insertions(+)
 create mode 100644 package/erlang-p1-iconv/Config.in
 create mode 100644 package/erlang-p1-iconv/erlang-p1-iconv.mk

[--SNIP--]

While I was reviewing the other patches, I got a build failure with this package (long lines may have got split in the copy-paste):

Compiling c_src/iconv.c /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lerl_interface /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lei /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lerl_interface /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lei
collect2: error: ld returned 1 exit status
ERROR: sh(/home/ymorin/dev/buildroot/O/host/usr/bin/armv6-rpi-linux-gnueabihf-gcc
c_src/iconv.o

(quoted diff) +0 -4

-L/home/ymorin/dev/buildroot/O/target/usr/lib/erlang/lib/erl_interface-/lib
-lerl_interface -lei  -shared
-L/home/ymorin/dev/buildroot/O/target/usr/lib/erlang/lib/erl_interface-/lib
-lerl_interface -lei -o priv/lib/iconv.so)

failed with return code 1 and the following output:
/home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lerl_interface /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lei /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lerl_interface /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lei
collect2: error: ld returned 1 exit status

ERROR: compile failed while processing /home/ymorin/dev/buildroot/O/build/erlang-p1-iconv-dff5ee5: rebar_abort

Here is my defconfig file:

BR2_armeb=y
BR2_arm1176jzf_s=y
BR2_ARM_EABIHF=y
BR2_TOOLCHAIN_EXTERNAL=y BR2_TOOLCHAIN_EXTERNAL_PATH="/home/ymorin/x-tools/armv6-rpi-linux-gnueabihf" BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX="armv6-rpi-linux-gnueabihf" BR2_TOOLCHAIN_EXTERNAL_HEADERS_3_12=y BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y
# BR2_TOOLCHAIN_EXTERNAL_INET_RPC is not set BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_PACKAGE_ERLANG=y
BR2_PACKAGE_EJABBERD=y

Quoted 18 lines

Compiling c_src/iconv.c /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lerl_interface /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lei /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lerl_interface /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lei
collect2: error: ld returned 1 exit status
ERROR: sh(/home/ymorin/dev/buildroot/O/host/usr/bin/armv6-rpi-linux-gnueabihf-gcc
c_src/iconv.o

(quoted diff) +0 -4

-L/home/ymorin/dev/buildroot/O/target/usr/lib/erlang/lib/erl_interface-/lib
-lerl_interface -lei  -shared
-L/home/ymorin/dev/buildroot/O/target/usr/lib/erlang/lib/erl_interface-/lib
-lerl_interface -lei -o priv/lib/iconv.so)

failed with return code 1 and the following output:
/home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:

Quoted 8 lines

cannot find -lerl_interface /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lei /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lerl_interface /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lei
collect2: error: ld returned 1 exit status

Yann, All,

Quoted 24 lines · Yann E. MORIN

Quoted 24 lines

Compiling c_src/iconv.c /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lerl_interface /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lei /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lerl_interface /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lei
collect2: error: ld returned 1 exit status
ERROR: sh(/home/ymorin/dev/buildroot/O/host/usr/bin/armv6-rpi-linux-gnueabihf-gcc
c_src/iconv.o

(quoted diff) +0 -4

-L/home/ymorin/dev/buildroot/O/target/usr/lib/erlang/lib/erl_interface-/lib
-lerl_interface -lei  -shared
-L/home/ymorin/dev/buildroot/O/target/usr/lib/erlang/lib/erl_interface-/lib
-lerl_interface -lei -o priv/lib/iconv.so)

failed with return code 1 and the following output:
/home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lerl_interface /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lei /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:
cannot find -lerl_interface /home/ymorin/x-tools/armv6-rpi-linux-gnueabihf/lib/gcc/armv6-rpi-linux-gnueabihf/4.9.1/../../../../armv6-rpi-linux-gnueabihf/bin/ld.bfd:

Quoted 2 lines

Quoted 2 lines

cannot find -lei
collect2: error: ld returned 1 exit status

I've seen this error few times when compiling several rebar packages. As a workaround, I run `make erlang-dirclean'.
I'm not 100% sure of the reason for this error but I suspect that old versions of rebar remove such libraries after compiling, which leads to an error on the next compilation.

Since ejabberd build system relies on rebar to download its dependencies, we've packaged all of them separately and modified ejabberd makefile to not download any dependency.

Actually, every erlang package that is introduced here rely on the rebar software. Thus, we also introduce a new infrastructure to simplify the development of such packages in buildroot.

Changes v1 -> v2:
- use BR_PATH instead of an hard-coded path in pkg-rebar.mk.
- update erlang-p1-iconv version to fix a link error with libiconv.

Johan Oudinet (15):
package/pkg-autotools.mk: Factorize hooks.
package/pkg-rebar.mk: new infrastructure.
erlang-goldrush: new package.
erlang-lager: new package.
erlang-p1-zlib: new package.
erlang-p1-yaml: new package.
erlang-p1-xml: new package.
erlang-p1-utils: new package.
erlang-p1-tls: new package.
erlang-p1-stun: new package.
erlang-p1-stringprep: new package.
erlang-p1-sip: new package.
erlang-p1-iconv: new package.
erlang-p1-cache-tab: new package.
ejabberd: new package.

 docs/manual/adding-packages-rebar.txt              | 157 ++++++++++++++
 docs/manual/adding-packages.txt                    |   2 +
 package/Config.in                                  |  17 ++
 package/Makefile.in                                |   1 +
 package/ejabberd/0001-remove-deps.patch            |  20 ++
 package/ejabberd/0002-disable-rebar-deps.patch     |  70 +++++++
 package/ejabberd/0003-disable-test.patch           |  21 ++
 package/ejabberd/0004-disable-version-check.patch  |  20 ++
 package/ejabberd/0005-fix-includes.patch           |  45 ++++
 package/ejabberd/0006-remove-doc.patch             |  26 +++
 package/ejabberd/0007-fix-init.patch               |  99 +++++++++
 .../ejabberd/0008-fix-install-permissions.patch    |  76 +++++++
 package/ejabberd/Config.in                         |  21 ++
 package/ejabberd/S50ejabberd                       |  35 ++++
 package/ejabberd/check-erlang-lib                  |  55 +++++
 package/ejabberd/ejabberd.mk                       |  51 +++++
 package/erlang-goldrush/Config.in                  |   6 +
 package/erlang-goldrush/erlang-goldrush.mk         |  14 ++
 package/erlang-lager/Config.in                     |  12 ++
 package/erlang-lager/erlang-lager.mk               |  14 ++
 package/erlang-p1-cache-tab/Config.in              |   6 +
 package/erlang-p1-cache-tab/erlang-p1-cache-tab.mk |  13 ++
 package/erlang-p1-iconv/Config.in                  |   6 +
 package/erlang-p1-iconv/erlang-p1-iconv.mk         |  17 ++
 package/erlang-p1-sip/Config.in                    |   8 +
 .../erlang-p1-sip-01-fix-includes.patch            |  19 ++
 package/erlang-p1-sip/erlang-p1-sip.mk             |  14 ++
 package/erlang-p1-stringprep/Config.in             |   5 +
 .../erlang-p1-stringprep/erlang-p1-stringprep.mk   |  13 ++
 package/erlang-p1-stun/Config.in                   |   7 +
 package/erlang-p1-stun/erlang-p1-stun.mk           |  14 ++
 package/erlang-p1-tls/Config.in                    |   5 +
 package/erlang-p1-tls/erlang-p1-tls.mk             |  14 ++
 package/erlang-p1-utils/Config.in                  |   5 +
 package/erlang-p1-utils/erlang-p1-utils.mk         |  14 ++
 package/erlang-p1-xml/Config.in                    |   6 +
 package/erlang-p1-xml/erlang-p1-xml.mk             |  14 ++
 package/erlang-p1-yaml/Config.in                   |   6 +
 package/erlang-p1-yaml/erlang-p1-yaml.mk           |  13 ++
 package/erlang-p1-zlib/Config.in                   |   5 +
 package/erlang-p1-zlib/erlang-p1-zlib.mk           |  13 ++
 package/erlang-rebar/erlang-rebar.mk               |  20 ++
 package/pkg-autotools.mk                           | 119 +++++------
 package/pkg-rebar.mk                               | 229 +++++++++++++++++++++
 support/scripts/erlang-ei-vsn                      |  19 ++
 45 files changed, 1303 insertions(+), 63 deletions(-)
 create mode 100644 docs/manual/adding-packages-rebar.txt
 create mode 100644 package/ejabberd/0001-remove-deps.patch
 create mode 100644 package/ejabberd/0002-disable-rebar-deps.patch
 create mode 100644 package/ejabberd/0003-disable-test.patch
 create mode 100644 package/ejabberd/0004-disable-version-check.patch
 create mode 100644 package/ejabberd/0005-fix-includes.patch
 create mode 100644 package/ejabberd/0006-remove-doc.patch
 create mode 100644 package/ejabberd/0007-fix-init.patch
 create mode 100644 package/ejabberd/0008-fix-install-permissions.patch
 create mode 100644 package/ejabberd/Config.in
 create mode 100644 package/ejabberd/S50ejabberd
 create mode 100755 package/ejabberd/check-erlang-lib
 create mode 100644 package/ejabberd/ejabberd.mk
 create mode 100644 package/erlang-goldrush/Config.in
 create mode 100644 package/erlang-goldrush/erlang-goldrush.mk
 create mode 100644 package/erlang-lager/Config.in
 create mode 100644 package/erlang-lager/erlang-lager.mk
 create mode 100644 package/erlang-p1-cache-tab/Config.in
 create mode 100644 package/erlang-p1-cache-tab/erlang-p1-cache-tab.mk
 create mode 100644 package/erlang-p1-iconv/Config.in
 create mode 100644 package/erlang-p1-iconv/erlang-p1-iconv.mk
 create mode 100644 package/erlang-p1-sip/Config.in
 create mode 100644 package/erlang-p1-sip/erlang-p1-sip-01-fix-includes.patch
 create mode 100644 package/erlang-p1-sip/erlang-p1-sip.mk
 create mode 100644 package/erlang-p1-stringprep/Config.in
 create mode 100644 package/erlang-p1-stringprep/erlang-p1-stringprep.mk
 create mode 100644 package/erlang-p1-stun/Config.in
 create mode 100644 package/erlang-p1-stun/erlang-p1-stun.mk
 create mode 100644 package/erlang-p1-tls/Config.in
 create mode 100644 package/erlang-p1-tls/erlang-p1-tls.mk
 create mode 100644 package/erlang-p1-utils/Config.in
 create mode 100644 package/erlang-p1-utils/erlang-p1-utils.mk
 create mode 100644 package/erlang-p1-xml/Config.in
 create mode 100644 package/erlang-p1-xml/erlang-p1-xml.mk
 create mode 100644 package/erlang-p1-yaml/Config.in
 create mode 100644 package/erlang-p1-yaml/erlang-p1-yaml.mk
 create mode 100644 package/erlang-p1-zlib/Config.in
 create mode 100644 package/erlang-p1-zlib/erlang-p1-zlib.mk
 create mode 100644 package/erlang-rebar/erlang-rebar.mk
 create mode 100644 package/pkg-rebar.mk
 create mode 100755 support/scripts/erlang-ei-vsn

Signature · 6 lines

2.1.0

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Since ejabberd build system relies on rebar to download its dependencies, we've packaged all of them separately and modified ejabberd makefile to not download any dependency.