ejabberd: XMPP server

---
 package/erlang/erlang.mk | 5 +++++
 1 file changed, 5 insertions(+)

package/erlang/erlang.mk +5 -0

index ef0e0a2..54e5a56 100644
@@ -4,6 +4,7 @@
 #
 ################################################################################
 
+# See note below when updating Erlang
 ERLANG_VERSION = 17.3
 ERLANG_SITE = http://www.erlang.org/download
 ERLANG_SOURCE = otp_src_$(ERLANG_VERSION).tar.gz

@@ -13,6 +14,10 @@ ERLANG_LICENSE = EPL
 ERLANG_LICENSE_FILES = EPLICENCE
 ERLANG_INSTALL_STAGING = YES
 
+# Whenever updating Erlang, this value should be updated as well, to the
+# value of EI_VSN in the file lib/erl_interface/vsn.mk
+ERLANG_EI_VSN = 3.7.18
+
 # The configure checks for these functions fail incorrectly
 ERLANG_CONF_ENV = ac_cv_func_isnan=yes ac_cv_func_isinf=yes

Signature · 1 line

2.1.0

Johan Oudinet

author

2014-12-09 14:34 UTC #2 lore raw

PATCH v4 2/17 package/erlang-rebar: new host package

From: "Yann E. MORIN" <[email protected]>

rebar is used to compile Erlang packages.

We need host variant so as to be able to provide it to Erlang packages that do not bundle their own version, or bundle a broken version.

Since this is a host-only package, used only internally, we do not provide a Kconfig option for it. Packages that need it will depend on it.

[yann.morin.1998 at free.fr: extract host-rebar to its own patch]

Signed-off-by "Yann E. MORIN" <[email protected]>

Cc Arnout Vandecappelle <[email protected]>

---
Changes v2 -> v3:
- fix dependencies (Arnout)
- fix download location
- add licencing info
- add comments

---
 package/erlang-rebar/erlang-rebar.mk | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 package/erlang-rebar/erlang-rebar.mk

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

new file mode 100644
index 0000000..f29eb75
@@ -0,0 +1,31 @@
+################################################################################
+#
+# erlang-rebar
+#
+################################################################################
+
+ERLANG_REBAR_VERSION = 2.5.1
+
+# Upstream publishes a release, but we can not use it as it is a release of
+# a generated rebar script, when we want the sources. So we have to use the
+# gihub helper in this case.
+ERLANG_REBAR_SITE = $(call github,rebar,rebar,$(ERLANG_REBAR_VERSION))
+
+# Although the file LICENSE state Apache-2.0, a lot (if not all) the files
+# in src/ bear the MIT licence.
+ERLANG_LICENSE = Apache-2.0, MIT
+ERLANG_LICENSE_FILES = LICENSE
+
+# We do not have a target variant, so just define the dependencies,
+# configure and build commands for the host variant.
+HOST_ERLANG_REBAR_DEPENDENCIES = host-erlang
+
+define HOST_ERLANG_REBAR_BUILD_CMDS
+	cd $(@D) && $(HOST_MAKE_ENV) $(MAKE)
+endef
+
+define HOST_ERLANG_REBAR_INSTALL_CMDS
+	$(INSTALL) -m 0755 -D $(@D)/rebar $(HOST_DIR)/usr/bin/rebar
+endef
+
+$(eval $(host-generic-package))

Signature · 1 line

2.1.0

Thomas Petazzoni

2014-12-22 14:16 UTC #3 lore raw

PATCH v4 2/17 package/erlang-rebar: new host package

Dear Johan Oudinet,

Quoted 7 lines · Johan Oudinet

From: "Yann E. MORIN" <[email protected]>
rebar is used to compile Erlang packages.
We need host variant so as to be able to provide it to Erlang packages that do not bundle their own version, or bundle a broken version.

Quoted 8 lines

Since this is a host-only package, used only internally, we do not provide a Kconfig option for it. Packages that need it will depend on it.
Signed-off-by Johan Oudinet <[email protected]>
[yann.morin.1998 at free.fr: extract host-rebar to its own patch]
Signed-off-by "Yann E. MORIN" <[email protected]>
Cc Arnout Vandecappelle <[email protected]>

Thanks, patch applied.

There's one thing I've noticed though: trying to run the 'rebar' binary doesn't work:

$ LANG=C ./output/host/usr/bin/rebar 
/usr/bin/env: escript: No such file or directory

This is obviously due to:

#!/usr/bin/env escript

at the beginning of the rebar binary, and the fact that output/host/usr/bin is not in my PATH.
Executing ./output/host/usr/bin/escript ./output/host/usr/bin/rebar works fine. This is not a problem for Buildroot packages, as $(HOST_DIR)/usr/bin will be in the PATH. Not sure if it's worth fixing for other use cases.

Best regards,

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Johan Oudinet

author

2014-12-09 14:34 UTC #4 lore raw

PATCH v4 3/17 package/pkg-rebar: new infrastructure

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

[yann.morin.1998 at free.fr: split the patch into semantically separated patches; large rewrites of the rest]

---
Changes v2 -> v3:
- introduce two new options: ERLANG_FOO_CONFIGURE to use the autotools infra (YES) or the generic infra (NO/empty) and ERLANG_FOO_HAS_REBAR to use the package's rebar (YES) or our own (NO/empty)
- remove the duplicated code from the autotools infra
- largely re-organise the code and variables definitions
- move the EI_VSN setting into the elrnag package
- remove the script used to compute EI_VSN, as it is no longer needed
- split host-rebar to its own patch
- add some comments

In reply to Thomas Petazzoni

---
 package/Makefile.in  |   1 +
 package/pkg-rebar.mk | 210 +++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 211 insertions(+)
 create mode 100644 package/pkg-rebar.mk

package/Makefile.in +1 -0

index 36ecf0b..6ef4231 100644
@@ -407,3 +407,4 @@ include package/pkg-python.mk
 include package/pkg-virtual.mk
 include package/pkg-generic.mk
 include package/pkg-kconfig.mk
+include package/pkg-rebar.mk

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

210 lines not on this page · raw message

Signature · 1 line

2.1.0

Thomas Petazzoni

2015-01-04 21:23 UTC #5 lore raw

PATCH v4 3/17 package/pkg-rebar: new infrastructure

Dear Johan Oudinet,

Quoted 12 lines · Johan Oudinet

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

new file mode 100644
index 0000000..c9b15c0
@@ -0,0 +1,210 @@
+################################################################################
+# 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.

package/pkg-rebar.mk line 16

Quoted 10 lines

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

+#
+# 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.

Maybe we should mention "Erlang" somewhere in this description.

package/pkg-rebar.mk line 26

Quoted 10 lines

package/pkg-rebar.mk new file +10 -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
+# the build stage.

I would rephrase that:

"this infrastructure tells rebar to NOT download dependencies during the build stage".

package/pkg-rebar.mk line 70

Quoted 13 lines

package/pkg-rebar.mk new file +13 -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.

Ditto. "this infrastructure tells rebar to NOT download dependencies during the build stage".

Quoted 13 lines

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

+################################################################################
+# 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)

package/pkg-rebar.mk line 110

Quoted 10 lines

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

+#
+################################################################################
+
+define inner-rebar-package
+
+# Extract just the raw package name, lowercase without the leading
+# erlang- or host- prefix, as this is used by rebar to find the
+# dependencies a package specifies.
+#
+$(2)_ERLANG_APP = $(subst -,_,$(call LOWERCASE,$(patsubst ERLANG_%,%,$(3))))

I think the comment doesn't line up any more with what is done exactly:
we're working on the uppercase version, which never has HOST_, and doesn't have erlang- but ERLANG_. Too bad that LOWERCASE replaces _ by -, and that then you have replace again - by _.

Would it be clearer to actually use $(1) ?

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

Not sure that's really better.

package/pkg-rebar.mk line 124

Quoted 13 lines

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

+# Path where to store the package's libs, relative to either $(HOST_DIR)
+# for host packages, or $(STAGING_DIR) for target packages.
+#
+$(2)_ERLANG_LIBDIR = \
+	/usr/lib/erlang/lib/$$($$(PKG)_ERLANG_APP)-$$($$(PKG)_VERSION)
+
+# Whether to use the generic rebar or the package's rebar
+#
+ifeq ($$($(2)_HAS_REBAR),YES)
+$(2)_REBAR = ./rebar
+else
+$(2)_REBAR = rebar
+endif

It's not clear what $(2)_HAS_REBAR is useful for, and this variable is not documented in PATCH 04/17.

package/pkg-rebar.mk line 131

Quoted 5 lines

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

+# Define the build and install commands
+#
+ifeq ($(4),target)
+
+ifeq ($$($(2)_CONFIGURE),YES)

What is $(2)_CONFIGURE exactly? It is not documented in PATCH 04/17.

package/pkg-rebar.mk line 139

Quoted 8 lines

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

+$(2)_CONF_ENV += \
+	ERL_COMPILER_OPTIONS='{i, "$$(REBAR_TARGET_DEPS_DIR)"}' \
+	ERL_EI_LIBDIR=$$(STAGING_DIR)/usr/lib/erlang/lib/erl_interface-$$(ERLANG_EI_VSN)/lib
+endif
+
+ifndef $(2)_BUILD_CMDS
+define $(2)_BUILD_CMDS
+	cd '$$(@D)'; \

Any reason for the simple quotes here? Also, other package infrastructures do:

	(cd $$($$(PKG)_SRCDIR) && \
	  ....)

Which allows to use the <foo>_SUBDIR mechanism when needed.

package/pkg-rebar.mk line 142

Quoted 3 lines

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

+	CC='$$(TARGET_CC)' \
+	CFLAGS='$$(TARGET_CFLAGS)' \
+	LDFLAGS='$$(TARGET_LDFLAGS)' \

Why simple quotes? We use double quotes everywhere in Buildroot. I guess you look at using $$(TARGET_CONFIGURE_OPTS) instead?

package/pkg-rebar.mk line 93

Quoted 2 lines

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

+	ERL_COMPILER_OPTIONS='{i, "$$(REBAR_TARGET_DEPS_DIR)"}' \
+	ERL_EI_LIBDIR=$$(STAGING_DIR)/usr/lib/erlang/lib/erl_interface-$$(ERLANG_EI_VSN)/lib \

This is duplicated from the CONFIGURE == YES case above, which defines $(2)_CONF_ENV. Maybe this can be factorized somehow?

package/pkg-rebar.mk line 146

Quoted 2 lines

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

+	$$(TARGET_MAKE_ENV) \
+	$$($$(PKG)_ENV) $$($$(PKG)_REBAR) deps_dir=$$(REBAR_TARGET_DEPS_DIR) compile

Maybe $$(PKG)_ENV should be named $$(PKG)_REBAR_ENV, to be more explicit, and in line with $$(PKG)_CONF_ENV that you use above, and that we use in the autotools infra?

Quoted 6 lines

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

+ifeq ($$($(2)_CONFIGURE),YES)
+$(2)_CONF_ENV += \
+	ERL_COMPILER_OPTIONS='{i, "$$(REBAR_HOST_DEPS_DIR)"}' \
+	ERL_EI_LIBDIR=$$(HOST_DIR)/usr/lib/erlang/lib/erl_interface-$$(ERLANG_EI_VSN)/lib
+endif
+

package/pkg-rebar.mk line 184

Quoted 10 lines

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

+ifndef $(2)_BUILD_CMDS
+define $(2)_BUILD_CMDS
+	cd '$$(@D)'; \
+	CC='$$(HOST_CC)' \
+	CFLAGS='$$(HOST_CFLAGS)' \
+	LDFLAGS='$$(HOST_LDFLAGS)' \
+	ERL_COMPILER_OPTIONS='{i, "$$(REBAR_HOST_DEPS_DIR)"}' \
+	ERL_EI_LIBDIR=$$(HOST_DIR)/usr/lib/erlang/lib/erl_interface-$$(ERLANG_EI_VSN)/lib \
+	$$(HOST_MAKE_ENV) \
+	$$($$(PKG)_ENV) $$($$(PKG)_REBAR) deps_dir=$$(REBAR_HOST_DEPS_DIR) compile

Same comments as for the target variant.

Quoted 11 lines

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

+endef
+endif
+
+# We need to double-$ the 'call' because it wants to expand
+# package-related variables
+ifndef $(2)_INSTALL_CMDS
+define $(2)_INSTALL_CMDS
+	$$(call install-erlang-directories,$$(HOST_DIR),include)
+	$$(call install-rebar-deps,$$(HOST_DIR),HOST)
+endef
+endif

package/pkg-rebar.mk line 205

Quoted 10 lines

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

+
+endif # !target
+
+# The package sub-infra to use
+#
+ifeq ($$($(2)_CONFIGURE),YES)
+$(call inner-autotools-package,$(1),$(2),$(3),$(4))
+else
+$(call inner-generic-package,$(1),$(2),$(3),$(4))
+endif

Wow, this is funky :-) A package infra that inherits from either one infra or the other! And two-level inheritance in the case of generic-package -> autotools-package -> rebar-package.

All in all, despite the minor questions/comments above, it looks pretty good. Care to work to resolve those issues and post an updated version?

Thanks!

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Yann E. MORIN

2015-01-04 22:20 UTC #6 lore raw

PATCH v4 3/17 package/pkg-rebar: new infrastructure

Thomas, Johan, All,

[comments ellided are being dealt with]

On 2015-01-04 22:23 +0100, Thomas Petazzoni spake thusly:

Quoted 6 lines · Johan Oudinet

package/pkg-rebar.mk
Quoted 5 lines
package/pkg-rebar.mk new file +0 -0
new file mode 100644
index 0000000..c9b15c0

[--SNIP--]

Quoted 29 lines

Quoted 13 lines

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

+################################################################################
+# 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)

package/pkg-rebar.mk line 110

Quoted 10 lines

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

+#
+################################################################################
+
+define inner-rebar-package
+
+# Extract just the raw package name, lowercase without the leading
+# erlang- or host- prefix, as this is used by rebar to find the
+# dependencies a package specifies.
+#
+$(2)_ERLANG_APP = $(subst -,_,$(call LOWERCASE,$(patsubst ERLANG_%,%,$(3))))

Quoted 5 lines

Would it be clearer to actually use $(1) ?
$(2)_ERLANG_APP = $(subst -,_,$(patsubst erlang-%,%,$(patsubst host-%,%,$(1))
Not sure that's really better.

Yet, it is better to deal with the original values, rather than to try to retro-engineer them. I'll check your proposal, and use it.

Quoted 8 lines

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

+# Path where to store the package's libs, relative to either $(HOST_DIR)
+# for host packages, or $(STAGING_DIR) for target packages.
+#
+$(2)_ERLANG_LIBDIR = \
+	/usr/lib/erlang/lib/$$($$(PKG)_ERLANG_APP)-$$($$(PKG)_VERSION)
+
+# Whether to use the generic rebar or the package's rebar
+#

Quoted 8 lines

package/pkg-rebar.mk line 124
Quoted 5 lines
package/pkg-rebar.mk new file +5 -0
+ifeq ($$($(2)_HAS_REBAR),YES)
+$(2)_REBAR = ./rebar
+else
+$(2)_REBAR = rebar
+endif
It's not clear what $(2)_HAS_REBAR is useful for, and this variable is not documented in PATCH 04/17.

Some packages bundle their own rebar, other do not.

Of the former, some may really require we use their bundled rebar instead f the one we provide. _HAS_REBAR is for those packages.

But maybe it is not really properly named. It's meaning is: this package has a bundled rebar, and does not work with the system rebar, so must use its own bnundled version.

But the appreciated meaning of the variable name is just: this package has a rebar utility. It does not state that the rebar infra shall use it. I'll try to come up with a better name.

Quoted 7 lines

package/pkg-rebar.mk line 131
Quoted 5 lines
package/pkg-rebar.mk new file +5 -0
+# Define the build and install commands
+#
+ifeq ($(4),target)
+
+ifeq ($$($(2)_CONFIGURE),YES)
What is $(2)_CONFIGURE exactly? It is not documented in PATCH 04/17.

Some rebar packages use autotools for the configure step, and use rebar for the build step. Worse, some of them even require being autoreconf-ed.

This variable, if set to YES, means that this package will use the autotools-package infrastrucutre; otherwise, it will be trated as a generic-package.

Fortunately, I could not see an Erlang package that uses CMake or setuptoolsi or distutils... :-)

[--SNIP--]

Quoted 11 lines

package/pkg-rebar.mk line 205
Quoted 7 lines
package/pkg-rebar.mk new file +7 -0
+# The package sub-infra to use
+#
+ifeq ($$($(2)_CONFIGURE),YES)
+$(call inner-autotools-package,$(1),$(2),$(3),$(4))
+else
+$(call inner-generic-package,$(1),$(2),$(3),$(4))
+endif
Wow, this is funky :-) A package infra that inherits from either one infra or the other! And two-level inheritance in the case of generic-package -> autotools-package -> rebar-package.

So, are you not too horrified by this? Shall we keep it, or do you want we copme up with an alternate solution?

Quoted 2 lines

All in all, despite the minor questions/comments above, it looks pretty good. Care to work to resolve those issues and post an updated version?

I'm doing a sanitising pass with your comments, now. I'll push that to my branch so Johan can grab it (I'll poke here when I did the push).

Thanks for the reviews! :-)

/me can't wait to have a Jabber daemin in Buildroot... :-]

Regards,
Yann E. MORIN.

Signature · 6 lines

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Thomas Petazzoni

2015-01-05 09:31 UTC #7 lore raw

PATCH v4 3/17 package/pkg-rebar: new infrastructure

Hello!

Quoted 8 lines · Yann E. MORIN

Quoted 5 lines
Would it be clearer to actually use $(1) ?
$(2)_ERLANG_APP = $(subst -,_,$(patsubst erlang-%,%,$(patsubst host-%,%,$(1))
Not sure that's really better.
Yet, it is better to deal with the original values, rather than to try to retro-engineer them. I'll check your proposal, and use it.

Well, it's a matter of taste really because both expressions are equally "complicated". So using $(1) as I propose, or $(3) as was in the patch doesn't make much difference. Maybe only the switch back and forth between - and _ is a bit weird when using $(3).

Quoted 8 lines

Quoted 2 lines
It's not clear what $(2)_HAS_REBAR is useful for, and this variable is not documented in PATCH 04/17.
Some packages bundle their own rebar, other do not.
Of the former, some may really require we use their bundled rebar instead f the one we provide. _HAS_REBAR is for those packages.

Quoted 7 lines

But maybe it is not really properly named. It's meaning is: this package has a bundled rebar, and does not work with the system rebar, so must use its own bnundled version.
But the appreciated meaning of the variable name is just: this package has a rebar utility. It does not state that the rebar infra shall use it. I'll try to come up with a better name.

$(2)_USE_BUNDLED_REBAR, default to NO, and overridden by YES for those packages that should really use their rebar rather than the system one.

or:

$(2)_USE_SYSTEM_REBAR, default to YES, and overridden to NO for those packages that should really use their rebar rather than the system one.

Quoted 8 lines

Quoted 7 lines
package/pkg-rebar.mk line 131
Quoted 5 lines
package/pkg-rebar.mk new file +5 -0
+# Define the build and install commands
+#
+ifeq ($(4),target)
+
+ifeq ($$($(2)_CONFIGURE),YES)
What is $(2)_CONFIGURE exactly? It is not documented in PATCH 04/17.

Quoted 6 lines

Some rebar packages use autotools for the configure step, and use rebar for the build step. Worse, some of them even require being autoreconf-ed.
This variable, if set to YES, means that this package will use the autotools-package infrastrucutre; otherwise, it will be trated as a generic-package.

Not sure of a better name for this one. Maybe $(2)_USE_AUTOTOOLS, defaults to no, can be overridden to YES by the packages having a configure script? Do they both autoconf and automake, or just autoconf? I guess the latter, so maybe $(2)_USE_AUTOCONF.

Quoted 6 lines

Quoted 3 lines
Wow, this is funky :-) A package infra that inherits from either one infra or the other! And two-level inheritance in the case of generic-package -> autotools-package -> rebar-package.
So, are you not too horrified by this? Shall we keep it, or do you want we copme up with an alternate solution?

No, I'm not horrified by this at all. It's smart, and elegantly re-uses the existing infrastructures. It's perfectly fine for me.

Quoted 2 lines

I'm doing a sanitising pass with your comments, now. I'll push that to my branch so Johan can grab it (I'll poke here when I did the push).

Great, thanks!

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Johan Oudinet

author

2015-01-05 11:13 UTC #8 lore raw

PATCH v4 3/17 package/pkg-rebar: new infrastructure

Thomas, All,

Quoted 12 lines · Thomas Petazzoni

Quoted 11 lines · Yann E. MORIN
Quoted 7 lines
package/pkg-rebar.mk line 131
Quoted 5 lines
package/pkg-rebar.mk new file +5 -0
+# Define the build and install commands
+#
+ifeq ($(4),target)
+
+ifeq ($$($(2)_CONFIGURE),YES)
What is $(2)_CONFIGURE exactly? It is not documented in PATCH 04/17.
Some rebar packages use autotools for the configure step, and use rebar for the build step. Worse, some of them even require being autoreconf-ed.

Quoted 8 lines

Quoted 3 lines
This variable, if set to YES, means that this package will use the autotools-package infrastrucutre; otherwise, it will be trated as a generic-package.
Not sure of a better name for this one. Maybe $(2)_USE_AUTOTOOLS, defaults to no, can be overridden to YES by the packages having a configure script? Do they both autoconf and automake, or just autoconf? I guess the latter, so maybe $(2)_USE_AUTOCONF.

They use autoconf only (mostly for the rebar.config.in file). So, I vote for $(2)_USE_AUTOCONF.

Signature · 3 lines

Johan
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Yann E. MORIN

2015-01-05 22:01 UTC #9 lore raw

PATCH v4 3/17 package/pkg-rebar: new infrastructure

Johan, All,

On 2015-01-05 12:13 +0100, Johan Oudinet spake thusly:

Quoted 18 lines

Quoted 16 lines · Thomas Petazzoni
Quoted 14 lines · Yann E. MORIN
Quoted 7 lines
package/pkg-rebar.mk line 131
Quoted 5 lines
package/pkg-rebar.mk new file +5 -0
+# Define the build and install commands
+#
+ifeq ($(4),target)
+
+ifeq ($$($(2)_CONFIGURE),YES)
What is $(2)_CONFIGURE exactly? It is not documented in PATCH 04/17.
Some rebar packages use autotools for the configure step, and use rebar for the build step. Worse, some of them even require being autoreconf-ed.
This variable, if set to YES, means that this package will use the autotools-package infrastrucutre; otherwise, it will be trated as a generic-package.

Quoted 7 lines

Quoted 4 lines
Not sure of a better name for this one. Maybe $(2)_USE_AUTOTOOLS, defaults to no, can be overridden to YES by the packages having a configure script? Do they both autoconf and automake, or just autoconf? I guess the latter, so maybe $(2)_USE_AUTOCONF.
They use autoconf only (mostly for the rebar.config.in file). So, I vote for $(2)_USE_AUTOCONF.

As I said in my reply to Thomas, I believe _CONFIGURE is really fit, because that's what people expect: the package needs to be configured.

But, also as I said, if Thomas prefers we use an alternative, I'd say we go for _AUTOTOOLS, as it matches the underlying infra we call to, "autotools".

Regards,
Yann E. MORIN.

Signature · 6 lines

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Yann E. MORIN

2015-01-05 21:59 UTC #10 lore raw

PATCH v4 3/17 package/pkg-rebar: new infrastructure

Thomas, All,

On 2015-01-05 10:31 +0100, Thomas Petazzoni spake thusly:

Quoted 1 line · Yann E. MORIN

[--SNIP--]

Quoted 13 lines

Quoted 5 lines
Some packages bundle their own rebar, other do not.
Of the former, some may really require we use their bundled rebar instead f the one we provide. _HAS_REBAR is for those packages.
Quoted 7 lines
But maybe it is not really properly named. It's meaning is: this package has a bundled rebar, and does not work with the system rebar, so must use its own bnundled version.
But the appreciated meaning of the variable name is just: this package has a rebar utility. It does not state that the rebar infra shall use it. I'll try to come up with a better name.

Quoted 7 lines

$(2)_USE_BUNDLED_REBAR, default to NO, and overridden by YES for those packages that should really use their rebar rather than the system one.
or:
$(2)_USE_SYSTEM_REBAR, default to YES, and overridden to NO for those packages that should really use their rebar rather than the system one.

I have already gone for _USE_BUNDLED_REBAR in the series I pushed to Johan, although I had pondered the alternative you also suggested.

Great minds think alike! Hehe! :-)

Quoted 11 lines

Quoted 11 lines
Quoted 7 lines
package/pkg-rebar.mk line 131
Quoted 5 lines
package/pkg-rebar.mk new file +5 -0
+# Define the build and install commands
+#
+ifeq ($(4),target)
+
+ifeq ($$($(2)_CONFIGURE),YES)
What is $(2)_CONFIGURE exactly? It is not documented in PATCH 04/17.
Some rebar packages use autotools for the configure step, and use rebar for the build step. Worse, some of them even require being autoreconf-ed.

Quoted 8 lines

Quoted 3 lines
This variable, if set to YES, means that this package will use the autotools-package infrastrucutre; otherwise, it will be trated as a generic-package.
Not sure of a better name for this one. Maybe $(2)_USE_AUTOTOOLS, defaults to no, can be overridden to YES by the packages having a configure script? Do they both autoconf and automake, or just autoconf? I guess the latter, so maybe $(2)_USE_AUTOCONF.

Alternatively, I was even thinking of an even more generic solution, $(2)_PACKAGE_TYPE , which would be set to the underlying type of packages.

In the end, I did not implement that because it is too much overkill. Also, I kept _CONFIGURE because it is what people do expect: the package needs to be configured before being built. But I am not completely opposed to changing the variable name. _USE_AUTOTOOLS or _USE_AUTOCONF is equally fit, I guess (although I'd still prefer _AUTOTOOLS, because it matches the fact that we call back to the autotools infrastructure underneath.

Johan, are there Erlang packages that use something other than autotools?

Regards,
Yann E. MORIN.

Signature · 6 lines

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Thomas Petazzoni

2015-01-06 08:24 UTC #11 lore raw

PATCH v4 3/17 package/pkg-rebar: new infrastructure

Dear Yann E. MORIN,

Quoted 7 lines · Yann E. MORIN

In the end, I did not implement that because it is too much overkill. Also, I kept _CONFIGURE because it is what people do expect: the package needs to be configured before being built. But I am not completely opposed to changing the variable name. _USE_AUTOTOOLS or _USE_AUTOCONF is equally fit, I guess (although I'd still prefer _AUTOTOOLS, because it matches the fact that we call back to the autotools infrastructure underneath.

Unfortunately, I disagree on this. "Configure" is a very vague term, which does not necessarily mean "run an autoconf generated ./configure script". We do have certain generic-package packages that do provide an implementation for the <pkg>_CONFIGURE_CMDS that aren't calling an autoconf generated ./configure script.

Moreover, a non-autoconf using rebar package may want to implement its <pkg>_CONFIGURE_CMDS to do some stuff. But it would have to keep <pkg>_CONFIGURE set to NO. This is really confusing.

Please, use <pkg>_USE_AUTOTOOLS, <pkg>_AUTOTOOLS or <pkg>_USE_AUTOCONF. I tend to prefer the latter, because this is really what the user is
seeing: the package is using autoconf. You say you prefer _AUTOTOOLS because it matches the fact that we're using the autotools infrastructure underneath, but that's an implementation detail. It's much better to expose things that make sense for the package developer that things that relate to implementation details, IMO.

Best regards,

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Johan Oudinet

author

2015-01-06 10:05 UTC #12 lore raw

PATCH v4 3/17 package/pkg-rebar: new infrastructure

Thomas, Yann, All,

Quoted 20 lines · Thomas Petazzoni

Quoted 7 lines · Yann E. MORIN
In the end, I did not implement that because it is too much overkill. Also, I kept _CONFIGURE because it is what people do expect: the package needs to be configured before being built. But I am not completely opposed to changing the variable name. _USE_AUTOTOOLS or _USE_AUTOCONF is equally fit, I guess (although I'd still prefer _AUTOTOOLS, because it matches the fact that we call back to the autotools infrastructure underneath.
Unfortunately, I disagree on this. "Configure" is a very vague term, which does not necessarily mean "run an autoconf generated ./configure script". We do have certain generic-package packages that do provide an implementation for the <pkg>_CONFIGURE_CMDS that aren't calling an autoconf generated ./configure script.
Moreover, a non-autoconf using rebar package may want to implement its <pkg>_CONFIGURE_CMDS to do some stuff. But it would have to keep <pkg>_CONFIGURE set to NO. This is really confusing.

Quoted 7 lines

Please, use <pkg>_USE_AUTOTOOLS, <pkg>_AUTOTOOLS or <pkg>_USE_AUTOCONF. I tend to prefer the latter, because this is really what the user is
seeing: the package is using autoconf. You say you prefer _AUTOTOOLS because it matches the fact that we're using the autotools infrastructure underneath, but that's an implementation detail. It's much better to expose things that make sense for the package developer that things that relate to implementation details, IMO.

I tend to agree with Thomas on this point and not only because I've already modified all erlang packages to the USE_AUTOCONF syntax ;-) Actually, even though pkg-rebar uses the autotools infrastructure, it does redefine the BUILD_CMDS. So automake is never called. Using the term AUTOTOOLS might be confusing to the package developer as he would expect its Makefile.am to be read.
I'm going to push a new version soon, so you can modify it if you want.

Signature · 1 line

Johan

Johan Oudinet

author

2014-12-09 14:34 UTC #13 lore raw

PATCH v4 4/17 docs/manual: add documentation for the pkg-rebar infrastructure

From: "Yann E. MORIN" <[email protected]>

[yann.morin.1998 at free.fr: split the doc into its own patch]

Signed-off-by "Yann E. MORIN" <[email protected]>

---
 docs/manual/adding-packages-rebar.txt | 157 ++++++++++++++++++++++++++++++++++
 docs/manual/adding-packages.txt       |   2 +
 2 files changed, 159 insertions(+)
 create mode 100644 docs/manual/adding-packages-rebar.txt

docs/manual/adding-packages-rebar.txt new file +157 -0

new file mode 100644
index 0000000..c132a4a
@@ -0,0 +1,157 @@
+// -*- mode:doc; -*-
+// vim: set syntax=asciidoc:
+
+=== Infrastructure for rebar-based packages
+
+[[rebar-package-tutorial]]
+
+==== +rebar-package+ tutorial
+
+First, let's see how to write a +.mk+ file for a rebar-based package,
+with an example :
+
+------------------------------
+01: ################################################################################
+02: #
+03: # erlang-foobar
+04: #
+05: ################################################################################
+06:
+07: ERLANG_FOOBAR_VERSION = 1.0
+08: ERLANG_FOOBAR_SOURCE = erlang-foobar-$(ERLANG_FOOBAR_VERSION).tar.gz
+09: ERLANG_FOOBAR_SITE = http://www.foosoftware.org/download
+10: ERLANG_FOOBAR_INSTALL_STAGING = YES
+11: ERLANG_FOOBAR_CONF_OPTS = --enable-bar
+12: ERLANG_FOOBAR_DEPENDENCIES = host-libaaa libbbb
+13:
+14: $(eval $(rebar-package))
+--------------------------------
+
+On line 7, we declare the version of the package.
+
+On line 8 and 9, we declare the name of the tarball (xz-ed tarball recommended)
+and the location of the tarball on the Web. Buildroot will automatically
+download the tarball from this location.
+
+On line 10, we tell Buildroot to install the package to the staging
+directory. The staging directory, located in +output/staging/+
+is the directory where all the packages are installed, including their
+development files, etc. By default, packages are not installed to the
+staging directory, since usually, only libraries need to be installed in
+the staging directory: their development files are needed to compile
+other libraries or applications depending on them.
+
+On line 11, we tell Buildroot to pass a custom configure option, that
+will be passed to the +./configure+ script before configuring
+and building the package.
+
+On line 12, we declare our dependencies, so that they are built
+before the build process of our package starts.
+
+Finally, on line line 14, we invoke the +rebar-package+
+macro that generates all the Makefile rules that actually allows the
+package to be built.
+
+[[rebar-package-reference]]
+
+==== +rebar-package+ reference
+
+The main macro of the rebar package infrastructure is
++rebar-package+. It is similar to the +generic-package+ macro. The
+ability to have target and host packages is also available, with the
++host-rebar-package+ macro.
+
+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+.
+
+Note that the rebar infrastructure does not expect a configure script,
+but does call such a script when it exists.  When a package uses both
+the Autotools and rebar, it should use the rebar infrastructure.  In
+this case however, the build commands do not call make, but only
++rebar compile+; this avoids triggering the download of dependencies
+(as most Makefile's do when combined with rebar).  Also, note that the
+install commands never call +make install+.  Instead, they install
+Erlang's application directories (ebin, priv, etc.)  into a proper
+location.  If this is not what you want, add custom hooks or override
+rebar commands (see below).
+
+A few additional variables, specific to the rebar infrastructure,
+can also be defined. Many of them are only useful in very specific
+cases, typical packages will therefore only use a few of them.
+
+* +ERLANG_FOOBAR_CONF_ENV+, to specify additional environment
+  variables to pass to the configure script. By default, empty.
+
+* +ERLANG_FOOBAR_CONF_OPTS+, to specify additional configure options
+  to pass to the configure script. By default, empty.
+
+* +ERLANG_FOOBAR_AUTORECONF+, tells whether the package should be
+  autoreconfigured or not (i.e. if the configure script and
+  Makefile.in files should be re-generated by re-running autoconf,
+  automake, libtool, etc.). Valid values are +YES+ and +NO+. By
+  default, the value is +NO+
+
+* +ERLANG_FOOBAR_AUTORECONF_ENV+, to specify additional environment
+  variables to pass to the 'autoreconf' program if
+  +ERLANG_FOOBAR_AUTORECONF=YES+. These are passed in the environment
+  of the 'autoreconf' command. By default, empty.
+
+* +ERLANG_FOOBAR_AUTORECONF_OPTS+ to specify additional options passed
+  to the 'autoreconf' program if +ERLANG_FOOBAR_AUTORECONF=YES+. By
+  default, empty.
+
+* +ERLANG_FOOBAR_REBAR_ENV+, to specify additional environment
+  variables to pass to rebar.  By default, the value sets a minimal
+  PATH that only includes +HOST_DIR/bin+, +HOST_DIR/usr/bin+, and
+  +/bin+.
+
+* +ERLANG_FOOBAR_REBAR_FLAGS+, to specify rebar flags. By default, the
+  value is +deps_dir=ERLANG_FOOBAR_REBAR_DEPS_DIR+.
+
+* +ERLANG_FOOBAR_REBAR_DEPS_DIR+, to specify where to look for the
+  package's dependencies.  By default, the value is
+  +output/build/erlang-rebar-deps/target+, or
+  +output/build/erlang-rebar-deps/host+ for host packages.  Note that
+  if the package installs to staging as well, the rebar infrastructure
+  then creates a symbolic link in this directory to
+  +ERLANG_FOOBAR_ERLANG_LIBDIR+ so other packages may use it as
+  a dependency.
+
+* +ERLANG_FOOBAR_ERLANG_LIBDIR+, to specify where to install the
+  Erlang application.  By default, the value is
+  +/usr/lib/erlang/lib/ERLANG_FOOBAR_ERLANG_APP-ERLANG_FOOBAR_VERSION+.
+
+* +ERLANG_FOOBAR_ERLANG_APP+, to specify the name of the Erlang
+  application to be installed.  This modifies where the application is
+  installed (e.g., +/usr/lib/erlang/lib/ERLANG_FOOBAR_ERLANG_APP-ERLANG_FOOBAR_VERSION+)
+  and the name of the symbolic link in +ERLANG_FOOBAR_REBAR_DEPS_DIR+,
+  if any (e.g., +output/build/erlang-rebar-deps/target/ERLANG_FOOBAR_ERLANG_APP+.
+  By default, the value is the lowercase package name stripped from
+  any +erlang-+ prefix, and with dashes converted to underscores.
+
+* +ERLANG_FOOBAR_ENV+, to specify additional environment variables to
+  pass both to the configure script and rebar.  By default, sets CC,
+  CFLAGS, LDFLAGS, ERL_COMPILER_OPTIONS, and ERL_EI_LIBDIR.
+
+With the rebar infrastructure, all the steps required to build
+and install the packages are already defined, and they generally work
+well for most rebar-based packages. However, when required, it is
+still possible to customize what is done in any particular step:
+
+* By adding a post-operation hook (after extract, patch, configure,
+  build or install). See xref:hooks[] for details.
+
+* By overriding one of the steps. For example, even if the rebar
+  infrastructure is used, if the package +.mk+ file defines its
+  own +ERLANG_FOOBAR_CONFIGURE_CMDS+ variable, it will be used
+  instead of the default rebar one. However, using this method
+  should be restricted to very specific cases. Do not use it in the
+  general case.

docs/manual/adding-packages.txt +2 -0

index feb0d13..b8674f8 100644
@@ -27,6 +27,8 @@ include::adding-packages-virtual.txt[]
 
 include::adding-packages-kconfig.txt[]
 
+include::adding-packages-rebar.txt[]
+
 include::adding-packages-asciidoc.txt[]
 
 include::adding-packages-hooks.txt[]

Signature · 1 line

2.1.0

Thomas Petazzoni

2015-01-04 21:33 UTC #14 lore raw

PATCH v4 4/17 docs/manual: add documentation for the pkg-rebar infrastructure

Dear Johan Oudinet,

Quoted 9 lines · Johan Oudinet

+------------------------------
+01: ################################################################################ +02: #
+03: # erlang-foobar
+04: #
+05: ################################################################################ +06:
+07: ERLANG_FOOBAR_VERSION = 1.0
+08: ERLANG_FOOBAR_SOURCE = erlang-foobar-$(ERLANG_FOOBAR_VERSION).tar.gz

It might be good to use .tar.xz as the example, because otherwise this example is bogus: erlang-foobar-$(ERLANG_FOOBAR_VERSION).tar.gz is the default _SOURCE value, and should not be specified.

Quoted 3 lines

+09: ERLANG_FOOBAR_SITE = http://www.foosoftware.org/download
+10: ERLANG_FOOBAR_INSTALL_STAGING = YES
+11: ERLANG_FOOBAR_CONF_OPTS = --enable-bar

Does this make sense for a rebar package that doesn't have ERLANG_FOOBAR_CONFIGURE = YES ?

Quoted 8 lines

+12: ERLANG_FOOBAR_DEPENDENCIES = host-libaaa libbbb +13:
+14: $(eval $(rebar-package))
+--------------------------------
docs/manual/adding-packages-rebar.txt new file +4 -0
+
+On line 7, we declare the version of the package.
+
+On line 8 and 9, we declare the name of the tarball (xz-ed tarball recommended)

docs/manual/adding-packages-rebar.txt line 42

Quoted 10 lines

docs/manual/adding-packages-rebar.txt new file +10 -0

+and the location of the tarball on the Web. Buildroot will automatically
+download the tarball from this location.
+
+On line 10, we tell Buildroot to install the package to the staging
+directory. The staging directory, located in +output/staging/+
+is the directory where all the packages are installed, including their
+development files, etc. By default, packages are not installed to the
+staging directory, since usually, only libraries need to be installed in
+the staging directory: their development files are needed to compile
+other libraries or applications depending on them.

Does this applies to rebar packages?

docs/manual/adding-packages-rebar.txt line 46

Quoted 3 lines

docs/manual/adding-packages-rebar.txt new file +3 -0

+On line 11, we tell Buildroot to pass a custom configure option, that
+will be passed to the +./configure+ script before configuring
+and building the package.

Same question as above: does it make sense for a package that doesn't pass <pkg>_CONFIGURE = YES ?

Quoted 4 lines

docs/manual/adding-packages-rebar.txt new file +4 -0

+On line 12, we declare our dependencies, so that they are built
+before the build process of our package starts.
+
+Finally, on line line 14, we invoke the +rebar-package+

docs/manual/adding-packages-rebar.txt line 61

Quoted 10 lines

docs/manual/adding-packages-rebar.txt new file +10 -0

+macro that generates all the Makefile rules that actually allows the
+package to be built.
+
+[[rebar-package-reference]]
+
+==== +rebar-package+ reference
+
+The main macro of the rebar package infrastructure is
++rebar-package+. It is similar to the +generic-package+ macro. The
+ability to have target and host packages is also available, with the

"The ability to have host packages is also available, with the +host-rebar-package+ macro", otherwise one could think that host-rebar-package is also used for target packages.

docs/manual/adding-packages-rebar.txt line 73

Quoted 12 lines

++host-rebar-package+ macro.

docs/manual/adding-packages-rebar.txt new file +11 -0

+
+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, ERLANG_FOOBAR_LICENSE_FILES.

Maybe we should refactor the documentation a bit to avoid mentioning those variables over and over again.

Review

Quoted 2 lines

(quoted diff) +2 -0

+Note that the rebar infrastructure does not expect a configure script,
+but does call such a script when it exists.

What about <pkg>_CONFIGURE = YES ?

docs/manual/adding-packages-rebar.txt line 84

Quoted 9 lines

When a package uses both

docs/manual/adding-packages-rebar.txt new file +8 -0

+the Autotools and rebar, it should use the rebar infrastructure.  In
+this case however, the build commands do not call make, but only
++rebar compile+; this avoids triggering the download of dependencies
+(as most Makefile's do when combined with rebar).  Also, note that the
+install commands never call +make install+.  Instead, they install
+Erlang's application directories (ebin, priv, etc.)  into a proper
+location.  If this is not what you want, add custom hooks or override
+rebar commands (see below).

What is "a proper location" ? As opposed to what ?

docs/manual/adding-packages-rebar.txt line 91

Quoted 6 lines

docs/manual/adding-packages-rebar.txt new file +6 -0

+A few additional variables, specific to the rebar infrastructure,
+can also be defined. Many of them are only useful in very specific
+cases, typical packages will therefore only use a few of them.
+
+* +ERLANG_FOOBAR_CONF_ENV+, to specify additional environment
+  variables to pass to the configure script. By default, empty.

And only useful when <pkg>_CONFIGURE = YES, no?

docs/manual/adding-packages-rebar.txt line 94

Quoted 2 lines

docs/manual/adding-packages-rebar.txt new file +2 -0

+* +ERLANG_FOOBAR_CONF_OPTS+, to specify additional configure options
+  to pass to the configure script. By default, empty.

Ditto.

docs/manual/adding-packages-rebar.txt line 100

Quoted 5 lines

docs/manual/adding-packages-rebar.txt new file +5 -0

+* +ERLANG_FOOBAR_AUTORECONF+, tells whether the package should be
+  autoreconfigured or not (i.e. if the configure script and
+  Makefile.in files should be re-generated by re-running autoconf,
+  automake, libtool, etc.). Valid values are +YES+ and +NO+. By
+  default, the value is +NO+

Ditto.

docs/manual/adding-packages-rebar.txt line 105

Quoted 5 lines

docs/manual/adding-packages-rebar.txt new file +5 -0

+
+* +ERLANG_FOOBAR_AUTORECONF_ENV+, to specify additional environment
+  variables to pass to the 'autoreconf' program if
+  +ERLANG_FOOBAR_AUTORECONF=YES+. These are passed in the environment
+  of the 'autoreconf' command. By default, empty.

Ditto.

docs/manual/adding-packages-rebar.txt line 109

Quoted 4 lines

docs/manual/adding-packages-rebar.txt new file +4 -0

+
+* +ERLANG_FOOBAR_AUTORECONF_OPTS+ to specify additional options passed
+  to the 'autoreconf' program if +ERLANG_FOOBAR_AUTORECONF=YES+. By
+  default, empty.

Ditto.

Maybe we should simply specify that when <pkg>_CONFIGURE = YES is specified, the normal autotools-package infra is used and that therefore for the configure step, a given set of variables have the same meaning as the ones of the autotools-package infra?

docs/manual/adding-packages-rebar.txt line 114

Quoted 4 lines

docs/manual/adding-packages-rebar.txt new file +4 -0

+* +ERLANG_FOOBAR_REBAR_ENV+, to specify additional environment
+  variables to pass to rebar.  By default, the value sets a minimal
+  PATH that only includes +HOST_DIR/bin+, +HOST_DIR/usr/bin+, and
+  +/bin+.

<pkg>_ENV, no? At least that's what patch 03/17 does, but I indeed suggested to use <pkg>_REBAR_ENV instead.

docs/manual/adding-packages-rebar.txt line 117

Quoted 2 lines

docs/manual/adding-packages-rebar.txt new file +2 -0

+* +ERLANG_FOOBAR_REBAR_FLAGS+, to specify rebar flags. By default, the
+  value is +deps_dir=ERLANG_FOOBAR_REBAR_DEPS_DIR+.

I don't see this variable used anywhere in PATCH 03/17.

docs/manual/adding-packages-rebar.txt line 126

Quoted 8 lines

docs/manual/adding-packages-rebar.txt new file +8 -0

+* +ERLANG_FOOBAR_REBAR_DEPS_DIR+, to specify where to look for the
+  package's dependencies.  By default, the value is
+  +output/build/erlang-rebar-deps/target+, or
+  +output/build/erlang-rebar-deps/host+ for host packages.  Note that
+  if the package installs to staging as well, the rebar infrastructure
+  then creates a symbolic link in this directory to
+  +ERLANG_FOOBAR_ERLANG_LIBDIR+ so other packages may use it as
+  a dependency.

Why would one want to override this? Isn't the value always set to:

+REBAR_HOST_DEPS_DIR = $(HOST_DIR)/usr/share/rebar/deps +REBAR_TARGET_DEPS_DIR = $(STAGING_DIR)/usr/share/rebar/deps

docs/manual/adding-packages-rebar.txt line 130

Quoted 3 lines

docs/manual/adding-packages-rebar.txt new file +3 -0

+* +ERLANG_FOOBAR_ERLANG_LIBDIR+, to specify where to install the
+  Erlang application.  By default, the value is
+  +/usr/lib/erlang/lib/ERLANG_FOOBAR_ERLANG_APP-ERLANG_FOOBAR_VERSION+.

Hum, the code does:

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

So it doesn't really seem to leave the freedom for the package to provide its own value, no?

docs/manual/adding-packages-rebar.txt line 138

Quoted 8 lines

docs/manual/adding-packages-rebar.txt new file +8 -0

+
+* +ERLANG_FOOBAR_ERLANG_APP+, to specify the name of the Erlang
+  application to be installed.  This modifies where the application is
+  installed (e.g., +/usr/lib/erlang/lib/ERLANG_FOOBAR_ERLANG_APP-ERLANG_FOOBAR_VERSION+)
+  and the name of the symbolic link in +ERLANG_FOOBAR_REBAR_DEPS_DIR+,
+  if any (e.g., +output/build/erlang-rebar-deps/target/ERLANG_FOOBAR_ERLANG_APP+.
+  By default, the value is the lowercase package name stripped from
+  any +erlang-+ prefix, and with dashes converted to underscores.

Ditto:

+$(2)_ERLANG_APP = $(subst -,_,$(call LOWERCASE,$(patsubst ERLANG_%,%,$(3))))

docs/manual/adding-packages-rebar.txt line 142

Quoted 3 lines

docs/manual/adding-packages-rebar.txt new file +3 -0

+* +ERLANG_FOOBAR_ENV+, to specify additional environment variables to
+  pass both to the configure script and rebar.  By default, sets CC,
+  CFLAGS, LDFLAGS, ERL_COMPILER_OPTIONS, and ERL_EI_LIBDIR.

Ah, so here we document $$(PKG)_ENV, which actually exists in the code. How is that different from ERLANG_FOOBAR_REBAR_ENV above?

Could you rework this documentation, and send an updated version?

Thanks!

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Yann E. MORIN

2015-01-04 23:27 UTC #15 lore raw

PATCH v4 4/17 docs/manual: add documentation for the pkg-rebar infrastructure

Thomas, Johan, All,

[Elided comments are being dealt with without further ado.]

On 2015-01-04 22:33 +0100, Thomas Petazzoni spake thusly:

Quoted 1 line · Johan Oudinet

[--SNIP--]

Quoted 9 lines

docs/manual/adding-packages-rebar.txt line 42

Quoted 7 lines

docs/manual/adding-packages-rebar.txt new file +7 -0

+On line 10, we tell Buildroot to install the package to the staging
+directory. The staging directory, located in +output/staging/+
+is the directory where all the packages are installed, including their
+development files, etc. By default, packages are not installed to the
+staging directory, since usually, only libraries need to be installed in
+the staging directory: their development files are needed to compile
+other libraries or applications depending on them.

Does this applies to rebar packages?

It would seem it does not, since they are interpreted packages, the dependencies would always be in target/

Johan, care to expand/fix the exaplanations, please? ;-)

[--SNIP--]

Quoted 11 lines

docs/manual/adding-packages-rebar.txt line 73
Quoted 6 lines
docs/manual/adding-packages-rebar.txt new file +6 -0
+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, ERLANG_FOOBAR_LICENSE_FILES.
Maybe we should refactor the documentation a bit to avoid mentioning those variables over and over again.

I've just written that to my TODO list. It seems it can only grow... ;-)

Quoted 4 lines

Review
Quoted 2 lines
(quoted diff) +2 -0
+Note that the rebar infrastructure does not expect a configure script,
+but does call such a script when it exists.
What about <pkg>_CONFIGURE = YES ?

I've rewritten that section quite a bit to make this much more explicit.

Quoted 11 lines

docs/manual/adding-packages-rebar.txt line 84

Quoted 9 lines

When a package uses both

docs/manual/adding-packages-rebar.txt new file +8 -0

+the Autotools and rebar, it should use the rebar infrastructure.  In
+this case however, the build commands do not call make, but only
++rebar compile+; this avoids triggering the download of dependencies
+(as most Makefile's do when combined with rebar).  Also, note that the
+install commands never call +make install+.  Instead, they install
+Erlang's application directories (ebin, priv, etc.)  into a proper
+location.  If this is not what you want, add custom hooks or override
+rebar commands (see below).

What is "a proper location" ? As opposed to what ?

I was thinking of just gettin rid of the implementation details. The details are available in pkg-rebar.mk.

Quoted 7 lines

docs/manual/adding-packages-rebar.txt line 114
Quoted 4 lines
docs/manual/adding-packages-rebar.txt new file +4 -0
+* +ERLANG_FOOBAR_REBAR_ENV+, to specify additional environment
+  variables to pass to rebar.  By default, the value sets a minimal
+  PATH that only includes +HOST_DIR/bin+, +HOST_DIR/usr/bin+, and
+  +/bin+.
<pkg>_ENV, no? At least that's what patch 03/17 does, but I indeed suggested to use <pkg>_REBAR_ENV instead.

Switched to using <pkg>_REBAR_ENV as you suggested in your review of the infra itself.

Quoted 4 lines

docs/manual/adding-packages-rebar.txt line 117
Quoted 2 lines
docs/manual/adding-packages-rebar.txt new file +2 -0
+* +ERLANG_FOOBAR_REBAR_FLAGS+, to specify rebar flags. By default, the
+  value is +deps_dir=ERLANG_FOOBAR_REBAR_DEPS_DIR+.
I don't see this variable used anywhere in PATCH 03/17.

Inded, it is not used, and none of the following packages sets it.

I'll just drop that one, unless Johan has a use-case for it?

Review

Quoted 13 lines

docs/manual/adding-packages-rebar.txt line 126

Quoted 8 lines

docs/manual/adding-packages-rebar.txt new file +8 -0

+* +ERLANG_FOOBAR_REBAR_DEPS_DIR+, to specify where to look for the
+  package's dependencies.  By default, the value is
+  +output/build/erlang-rebar-deps/target+, or
+  +output/build/erlang-rebar-deps/host+ for host packages.  Note that
+  if the package installs to staging as well, the rebar infrastructure
+  then creates a symbolic link in this directory to
+  +ERLANG_FOOBAR_ERLANG_LIBDIR+ so other packages may use it as
+  a dependency.

Why would one want to override this? Isn't the value always set to:

(quoted diff) +2 -0

+REBAR_HOST_DEPS_DIR = $(HOST_DIR)/usr/share/rebar/deps
+REBAR_TARGET_DEPS_DIR = $(STAGING_DIR)/usr/share/rebar/deps

Moreover, nothing references $(2)_REBAR_DEPS_DIR at all.

Johan, did we miss anything?

Quoted 11 lines

docs/manual/adding-packages-rebar.txt line 130
Quoted 3 lines
docs/manual/adding-packages-rebar.txt new file +3 -0
+* +ERLANG_FOOBAR_ERLANG_LIBDIR+, to specify where to install the
+  Erlang application.  By default, the value is
+  +/usr/lib/erlang/lib/ERLANG_FOOBAR_ERLANG_APP-ERLANG_FOOBAR_VERSION+.
Hum, the code does:
+$(2)_ERLANG_LIBDIR = \
(quoted diff) +1 -0
+	/usr/lib/erlang/lib/$$($$(PKG)_ERLANG_APP)-$$($$(PKG)_VERSION)
So it doesn't really seem to leave the freedom for the package to provide its own value, no?

I gues not. We really want all packages to behave the same and install all their files in a similar fashion.

I'll drop this variable, inless Johan has a good reason to keep it.

Quoted 6 lines

docs/manual/adding-packages-rebar.txt line 142
Quoted 3 lines
docs/manual/adding-packages-rebar.txt new file +3 -0
+* +ERLANG_FOOBAR_ENV+, to specify additional environment variables to
+  pass both to the configure script and rebar.  By default, sets CC,
+  CFLAGS, LDFLAGS, ERL_COMPILER_OPTIONS, and ERL_EI_LIBDIR.
Ah, so here we document $$(PKG)_ENV, which actually exists in the code. How is that different from ERLANG_FOOBAR_REBAR_ENV above?

Ah...

OK, I'll rework whatever I can, for Johan to grab.

Thank you!

Regards,
Yann E. MORIN.

Signature · 6 lines

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Yann E. MORIN

2015-01-04 23:39 UTC #16 lore raw

PATCH v4 4/17 docs/manual: add documentation for the pkg-rebar infrastructure

Thomas, Johan, All,

On 2015-01-05 00:27 +0100, Yann E. MORIN spake thusly:
[--SNIP--]

Quoted 6 lines

Quoted 6 lines
docs/manual/adding-packages-rebar.txt line 142
Quoted 3 lines
docs/manual/adding-packages-rebar.txt new file +3 -0
+* +ERLANG_FOOBAR_ENV+, to specify additional environment variables to
+  pass both to the configure script and rebar.  By default, sets CC,
+  CFLAGS, LDFLAGS, ERL_COMPILER_OPTIONS, and ERL_EI_LIBDIR.
Ah, so here we document $$(PKG)_ENV, which actually exists in the code. How is that different from ERLANG_FOOBAR_REBAR_ENV above?

Hmm... In fact, for the configure step, we already have $(2)_CONF_ENV as it only applies to autotools-based packages.

Non-autotools-based packages do not have a configure step.

So I'll aso remove that variable.

Regards,
Yann E. MORIN.

Signature · 6 lines

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Johan Oudinet

author

2014-12-09 14:34 UTC #17 lore raw

PATCH v4 5/17 erlang-goldrush: new package.

---
 package/Config.in                          |  5 +++++
 package/erlang-goldrush/Config.in          |  6 ++++++
 package/erlang-goldrush/erlang-goldrush.mk | 14 ++++++++++++++
 3 files changed, 25 insertions(+)
 create mode 100644 package/erlang-goldrush/Config.in
 create mode 100644 package/erlang-goldrush/erlang-goldrush.mk

package/Config.in +5 -0

index 600a68d..06c8e04 100644
@@ -392,6 +392,11 @@ endmenu
 menu "Interpreter languages and scripting"
 	source "package/enscript/Config.in"
 	source "package/erlang/Config.in"
+if BR2_PACKAGE_ERLANG
+menu "Erlang libraries/modules"
+	source "package/erlang-goldrush/Config.in"
+endmenu
+endif
 	source "package/guile/Config.in"
 	source "package/haserl/Config.in"
 	source "package/jamvm/Config.in"

package/erlang-goldrush/Config.in new file +6 -0

new file mode 100644
index 0000000..685a887
@@ -0,0 +1,6 @@
+config BR2_PACKAGE_ERLANG_GOLDRUSH
+	bool "erlang-goldrush"
+	depends on BR2_PACKAGE_ERLANG
+	help
+	  Goldrush is a small Erlang app that provides fast event
+	  stream processing.

package/erlang-goldrush/erlang-goldrush.mk new file +14 -0

new file mode 100644
index 0000000..7537e76
@@ -0,0 +1,14 @@
+################################################################################
+#
+# erlang-goldrush
+#
+################################################################################
+
+ERLANG_GOLDRUSH_VERSION = 0.1.6
+ERLANG_GOLDRUSH_SITE = $(call github,DeadZen,goldrush,$(ERLANG_GOLDRUSH_VERSION))
+ERLANG_GOLDRUSH_LICENSE_FILES = LICENSE
+ERLANG_GOLDRUSH_DEPENDENCIES = erlang host-erlang-rebar
+ERLANG_GOLDRUSH_INSTALL_STAGING = YES
+
+$(eval $(rebar-package))
+$(eval $(host-rebar-package))

Signature · 1 line

2.1.0

Thomas Petazzoni

2015-01-04 21:36 UTC #18 lore raw

PATCH v4 5/17 erlang-goldrush: new package.

Dear Johan Oudinet,

Quoted 16 lines · Johan Oudinet

Signed-off-by Johan Oudinet <[email protected]>
Signed-off-by Yann E. MORIN <[email protected]>
Signed-off-by Johan Oudinet <[email protected]>
---
 package/Config.in                          |  5 +++++
 package/erlang-goldrush/Config.in          |  6 ++++++
 package/erlang-goldrush/erlang-goldrush.mk | 14 ++++++++++++++
 3 files changed, 25 insertions(+)
 create mode 100644 package/erlang-goldrush/Config.in
 create mode 100644 package/erlang-goldrush/erlang-goldrush.mk
package/Config.in +0 -0
index 600a68d..06c8e04 100644

package/Config.in endmenu · line 395

Quoted 4 lines

package/Config.in +1 -0

@@ -392,6 +392,11 @@ endmenu
 menu "Interpreter languages and scripting"
 	source "package/enscript/Config.in"
 	source "package/erlang/Config.in"
+if BR2_PACKAGE_ERLANG

So all Erlang packages are not visible unless erlang is enabled. Which sounds good.

Quoted 13 lines

package/Config.in +4 -0

+menu "Erlang libraries/modules"
+	source "package/erlang-goldrush/Config.in"
+endmenu
+endif
 	source "package/guile/Config.in"
 	source "package/haserl/Config.in"
 	source "package/jamvm/Config.in"

package/erlang-goldrush/Config.in new file +0 -0

new file mode 100644
index 0000000..685a887

package/erlang-goldrush/Config.in line 3

Quoted 3 lines

package/erlang-goldrush/Config.in new file +3 -0

@@ -0,0 +1,6 @@
+config BR2_PACKAGE_ERLANG_GOLDRUSH
+	bool "erlang-goldrush"
+	depends on BR2_PACKAGE_ERLANG

So why do we have this dependency again here?

Quoted 9 lines

package/erlang-goldrush/Config.in new file +3 -0
+	help
+	  Goldrush is a small Erlang app that provides fast event
+	  stream processing.
package/erlang-goldrush/erlang-goldrush.mk new file +0 -0
new file mode 100644
index 0000000..7537e76

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

Quoted 9 lines

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

@@ -0,0 +1,14 @@
+################################################################################
+#
+# erlang-goldrush
+#
+################################################################################
+
+ERLANG_GOLDRUSH_VERSION = 0.1.6
+ERLANG_GOLDRUSH_SITE = $(call github,DeadZen,goldrush,$(ERLANG_GOLDRUSH_VERSION))
+ERLANG_GOLDRUSH_LICENSE_FILES = LICENSE

No <pkg>_LICENSE ?

package/erlang-goldrush/erlang-goldrush.mk line 10

Quoted 1 line

package/erlang-goldrush/erlang-goldrush.mk new file +1 -0
+ERLANG_GOLDRUSH_DEPENDENCIES = erlang host-erlang-rebar

Why are those dependencies necessary? Aren't they handled by the rebar infra?

package/erlang-goldrush/erlang-goldrush.mk line 14

Quoted 4 lines

package/erlang-goldrush/erlang-goldrush.mk new file +4 -0
+ERLANG_GOLDRUSH_INSTALL_STAGING = YES
+
+$(eval $(rebar-package))
+$(eval $(host-rebar-package))

Might be good to say a word in the commit log to explain why a host variant of this library is needed.

Thanks!

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Johan Oudinet

author

2015-01-05 14:52 UTC #19 lore raw

PATCH v4 5/17 erlang-goldrush: new package.

Thomas, All,

Quoted 37 lines · Thomas Petazzoni

Dear Johan Oudinet,
Quoted 16 lines · Johan Oudinet
Signed-off-by Johan Oudinet <[email protected]>
Signed-off-by Yann E. MORIN <[email protected]>
Signed-off-by Johan Oudinet <[email protected]>
---
 package/Config.in                          |  5 +++++
 package/erlang-goldrush/Config.in          |  6 ++++++
 package/erlang-goldrush/erlang-goldrush.mk | 14 ++++++++++++++
 3 files changed, 25 insertions(+)
 create mode 100644 package/erlang-goldrush/Config.in
 create mode 100644 package/erlang-goldrush/erlang-goldrush.mk
package/Config.in +0 -0
index 600a68d..06c8e04 100644
package/Config.in endmenu · line 395
Quoted 4 lines
package/Config.in +1 -0
@@ -392,6 +392,11 @@ endmenu
 menu "Interpreter languages and scripting"
      source "package/enscript/Config.in"
      source "package/erlang/Config.in"
+if BR2_PACKAGE_ERLANG
So all Erlang packages are not visible unless erlang is enabled. Which sounds good.
Quoted 10 lines
package/Config.in +4 -0
+menu "Erlang libraries/modules"
+     source "package/erlang-goldrush/Config.in"
+endmenu
+endif
      source "package/guile/Config.in"
      source "package/haserl/Config.in"
      source "package/jamvm/Config.in"
package/erlang-goldrush/Config.in new file +0 -0
new file mode 100644
index 0000000..685a887

Quoted 8 lines

package/erlang-goldrush/Config.in line 3
Quoted 6 lines
package/erlang-goldrush/Config.in new file +3 -0
@@ -0,0 +1,6 @@
+config BR2_PACKAGE_ERLANG_GOLDRUSH
+     bool "erlang-goldrush"
+     depends on BR2_PACKAGE_ERLANG
So why do we have this dependency again here?

Good point. I've removed it. Thanks for noticing it.

Quoted 6 lines

Quoted 6 lines
package/erlang-goldrush/erlang-goldrush.mk new file +3 -0
@@ -0,0 +1,14 @@
+################################################################################
+#
+# erlang-goldrush

Quoted 8 lines

package/erlang-goldrush/erlang-goldrush.mk line 9
Quoted 6 lines
package/erlang-goldrush/erlang-goldrush.mk new file +6 -0
+#
+################################################################################
+
+ERLANG_GOLDRUSH_VERSION = 0.1.6
+ERLANG_GOLDRUSH_SITE = $(call github,DeadZen,goldrush,$(ERLANG_GOLDRUSH_VERSION))
+ERLANG_GOLDRUSH_LICENSE_FILES = LICENSE
No <pkg>_LICENSE ?

It is an ISC license, and the abbreviation is not available within Buildroot.

Quoted 5 lines

package/erlang-goldrush/erlang-goldrush.mk line 10
Quoted 2 lines
package/erlang-goldrush/erlang-goldrush.mk new file +1 -0
+ERLANG_GOLDRUSH_DEPENDENCIES = erlang host-erlang-rebar
Why are those dependencies necessary? Aren't they handled by the rebar infra?

Excellent idea. I've just modified pkg-rebar to do that and I'll remove erlang and host-erlang-rebar from the dependencies of all erlang packages.

Quoted 8 lines

package/erlang-goldrush/erlang-goldrush.mk line 14
Quoted 5 lines
package/erlang-goldrush/erlang-goldrush.mk new file +4 -0
+ERLANG_GOLDRUSH_INSTALL_STAGING = YES
+
+$(eval $(rebar-package))
+$(eval $(host-rebar-package))
Might be good to say a word in the commit log to explain why a host variant of this library is needed.

Ok. So I should not provide an host variant unless some other packages need it?

Thanks for the review.

Signature · 1 line

Johan

Thomas Petazzoni

2015-01-05 16:37 UTC #20 lore raw

PATCH v4 5/17 erlang-goldrush: new package.

Dear Johan Oudinet,

Quoted 3 lines · Johan Oudinet

Quoted 1 line
No <pkg>_LICENSE ?
It is an ISC license, and the abbreviation is not available within Buildroot.

This doesn't make sense: the <pkg>_LICENSE field is a free-form text field. You can put whatever you want in this field. Whenever possible, we prefer to use the SDPX license identifiers
(http://spdx.org/licenses/).

Also:

$ git grep "LICENSE.*ISC"
package/at/at.mk:AT_LICENSE = GPLv2+, GPLv3+, ISC
package/bind/bind.mk:BIND_LICENSE = ISC
package/crda/crda.mk:CRDA_LICENSE = ISC
package/dhcp/dhcp.mk:DHCP_LICENSE = ISC
package/harfbuzz/harfbuzz.mk:HARFBUZZ_LICENSE = MIT, ISC (ucdn library)
package/libass/libass.mk:LIBASS_LICENSE = ISC
package/libconfuse/libconfuse.mk:LIBCONFUSE_LICENSE = ISC
package/libuv/libuv.mk:LIBUV_LICENSE = BSD-2c, BSD-3c, ISC, MIT
package/odhcploc/odhcploc.mk:ODHCPLOC_LICENSE = ISC
package/pure-ftpd/pure-ftpd.mk:PURE_FTPD_LICENSE = ISC
package/python-certifi/python-certifi.mk:PYTHON_CERTIFI_LICENSE = ISC (Python code), MPL-2.0 (cacert.pem)
package/sudo/sudo.mk:SUDO_LICENSE = ISC BSD-3c
package/tmux/tmux.mk:TMUX_LICENSE = ISC
package/wireless-regdb/wireless-regdb.mk:WIRELESS_REGDB_LICENSE = ISC
package/yajl/yajl.mk:YAJL_LICENSE = ISC

Quoted 3 lines

Excellent idea. I've just modified pkg-rebar to do that and I'll remove erlang and host-erlang-rebar from the dependencies of all erlang packages.

Great.

Quoted 4 lines

Quoted 2 lines
Might be good to say a word in the commit log to explain why a host variant of this library is needed.
Ok. So I should not provide an host variant unless some other packages need it?

Indeed. Why would we want to have dead/unused code?

Best regards,

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Johan Oudinet

author

2014-12-09 14:34 UTC #21 lore raw

PATCH v4 6/17 erlang-lager: new package.

---
 package/Config.in                    |  1 +
 package/erlang-lager/Config.in       | 12 ++++++++++++
 package/erlang-lager/erlang-lager.mk | 14 ++++++++++++++
 3 files changed, 27 insertions(+)
 create mode 100644 package/erlang-lager/Config.in
 create mode 100644 package/erlang-lager/erlang-lager.mk

package/Config.in +1 -0

index 06c8e04..7703828 100644
@@ -395,6 +395,7 @@ menu "Interpreter languages and scripting"
 if BR2_PACKAGE_ERLANG
 menu "Erlang libraries/modules"
 	source "package/erlang-goldrush/Config.in"
+	source "package/erlang-lager/Config.in"
 endmenu
 endif
 	source "package/guile/Config.in"

package/erlang-lager/Config.in new file +12 -0

new file mode 100644
index 0000000..f83239e
@@ -0,0 +1,12 @@
+config BR2_PACKAGE_ERLANG_LAGER
+	bool "erlang-lager"
+	depends on BR2_PACKAGE_ERLANG
+	select BR2_PACKAGE_ERLANG_GOLDRUSH
+	help
+	  Logging framework for Erlang.
+	  
+	  Lager (as in the beer) is a logging framework for
+	  Erlang. Its purpose is to provide a more traditional way to
+	  perform logging in an erlang application that plays nicely
+	  with traditional UNIX logging tools like logrotate and
+	  syslog.

package/erlang-lager/erlang-lager.mk new file +14 -0

new file mode 100644
index 0000000..b530c8e
@@ -0,0 +1,14 @@
+################################################################################
+#
+# erlang-lager
+#
+################################################################################
+
+ERLANG_LAGER_VERSION = 2.0.3
+ERLANG_LAGER_SITE = $(call github,basho,lager,$(ERLANG_LAGER_VERSION))
+ERLANG_LAGER_LICENSE = Apache-2.0
+ERLANG_LAGER_LICENSE_FILES = LICENSE
+ERLANG_LAGER_DEPENDENCIES = erlang erlang-goldrush
+
+$(eval $(rebar-package))
+$(eval $(host-rebar-package))

Signature · 1 line

2.1.0

Thomas Petazzoni

2015-01-04 21:37 UTC #22 lore raw

PATCH v4 6/17 erlang-lager: new package.

Dear Johan Oudinet,

package/erlang-lager/Config.in line 3

Quoted 9 lines · Johan Oudinet

package/erlang-lager/Config.in new file +3 -0

new file mode 100644
index 0000000..f83239e
@@ -0,0 +1,12 @@
+config BR2_PACKAGE_ERLANG_LAGER
+	bool "erlang-lager"
+	depends on BR2_PACKAGE_ERLANG

Same as erlang-goldrush.

package/erlang-lager/Config.in line 12

Quoted 9 lines

package/erlang-lager/Config.in new file +9 -0

+	select BR2_PACKAGE_ERLANG_GOLDRUSH
+	help
+	  Logging framework for Erlang.
+	  
+	  Lager (as in the beer) is a logging framework for
+	  Erlang. Its purpose is to provide a more traditional way to
+	  perform logging in an erlang application that plays nicely
+	  with traditional UNIX logging tools like logrotate and
+	  syslog.

We generally want an upstream web site location at the end of the Config.in help text.

Quoted 7 lines

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

new file mode 100644
index 0000000..b530c8e
@@ -0,0 +1,14 @@
+################################################################################

package/erlang-lager/erlang-lager.mk line 11

Quoted 10 lines

package/erlang-lager/erlang-lager.mk new file +10 -0

+#
+# erlang-lager
+#
+################################################################################
+
+ERLANG_LAGER_VERSION = 2.0.3
+ERLANG_LAGER_SITE = $(call github,basho,lager,$(ERLANG_LAGER_VERSION))
+ERLANG_LAGER_LICENSE = Apache-2.0
+ERLANG_LAGER_LICENSE_FILES = LICENSE
+ERLANG_LAGER_DEPENDENCIES = erlang erlang-goldrush

The dependency on erlang-goldrush looks OK, but why isn't the dependency on erlang added automatically by the rebar-package macro?

package/erlang-lager/erlang-lager.mk line 14

Quoted 2 lines

package/erlang-lager/erlang-lager.mk new file +2 -0
+$(eval $(rebar-package))
+$(eval $(host-rebar-package))

Same as previous package: why a host variant is needed?

Thanks!

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Johan Oudinet

author

2015-01-05 16:10 UTC #23 lore raw

PATCH v4 6/17 erlang-lager: new package.

Thomas, All,

Quoted 12 lines · Thomas Petazzoni

package/erlang-lager/erlang-lager.mk line 2
Quoted 8 lines · Johan Oudinet
package/erlang-lager/erlang-lager.mk new file +2 -0
new file mode 100644
index 0000000..b530c8e
@@ -0,0 +1,14 @@
+$(eval $(rebar-package))
+$(eval $(host-rebar-package))
Same as previous package: why a host variant is needed?

host-erlang-lager is listed in ejabberd dependencies. I do not remember why, so I'm going to check if it is really needed and add an explanation on the commit message if so.

Thanks.

Signature · 1 line

Johan

Thomas Petazzoni

2015-01-05 16:38 UTC #24 lore raw

PATCH v4 6/17 erlang-lager: new package.

Dear Johan Oudinet,

Quoted 17 lines · Johan Oudinet

Thomas, All,
Quoted 12 lines · Thomas Petazzoni
package/erlang-lager/erlang-lager.mk line 2
Quoted 8 lines · Johan Oudinet
package/erlang-lager/erlang-lager.mk new file +2 -0
new file mode 100644
index 0000000..b530c8e
@@ -0,0 +1,14 @@
+$(eval $(rebar-package))
+$(eval $(host-rebar-package))
Same as previous package: why a host variant is needed?

Quoted 3 lines

host-erlang-lager is listed in ejabberd dependencies. I do not remember why, so I'm going to check if it is really needed and add an explanation on the commit message if so.

Ah, my review did not go all the way to ejabberd, sorry about missing this. Indeed, please check if host-erlang-lager is needed, and if it is, quickly indicate in the commit log which package uses it.

Thanks a lot!

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Johan Oudinet

author

2015-01-05 23:53 UTC #25 lore raw

PATCH v4 6/17 erlang-lager: new package.

Thomas, All,

Quoted 16 lines · Thomas Petazzoni

Quoted 15 lines · Johan Oudinet
Quoted 12 lines · Thomas Petazzoni
package/erlang-lager/erlang-lager.mk line 2
Quoted 8 lines · Johan Oudinet
package/erlang-lager/erlang-lager.mk new file +2 -0
new file mode 100644
index 0000000..b530c8e
@@ -0,0 +1,14 @@
+$(eval $(rebar-package))
+$(eval $(host-rebar-package))
Same as previous package: why a host variant is needed?

Quoted 8 lines

Quoted 3 lines
host-erlang-lager is listed in ejabberd dependencies. I do not remember why, so I'm going to check if it is really needed and add an explanation on the commit message if so.
Ah, my review did not go all the way to ejabberd, sorry about missing this. Indeed, please check if host-erlang-lager is needed, and if it is, quickly indicate in the commit log which package uses it.

It does need it otherwise ejabberd compilation failed at src/gen_mod.erl, which includes include/logger.hrl. At line 23 of this file there is such statement :
-compile([{parse_transform, lager_transform}]).
And lager_transform is provided by erlang-lager.

So, I'll mention that ejabberd uses host-erlang-lager in the patches for erlang-lager and erlang-goldrush, which is a dependency of erlang-lager.

Signature · 1 line

Johan

Johan Oudinet

author

2014-12-09 14:34 UTC #26 lore raw

PATCH v4 7/17 erlang-p1-zlib: new package.

---
 package/Config.in                        |  1 +
 package/erlang-p1-zlib/Config.in         |  5 +++++
 package/erlang-p1-zlib/erlang-p1-zlib.mk | 13 +++++++++++++
 3 files changed, 19 insertions(+)
 create mode 100644 package/erlang-p1-zlib/Config.in
 create mode 100644 package/erlang-p1-zlib/erlang-p1-zlib.mk

package/Config.in +1 -0

index 7703828..240a82c 100644
@@ -396,6 +396,7 @@ if BR2_PACKAGE_ERLANG
 menu "Erlang libraries/modules"
 	source "package/erlang-goldrush/Config.in"
 	source "package/erlang-lager/Config.in"
+	source "package/erlang-p1-zlib/Config.in"
 endmenu
 endif
 	source "package/guile/Config.in"

package/erlang-p1-zlib/Config.in new file +5 -0

new file mode 100644
index 0000000..3d4f455
@@ -0,0 +1,5 @@
+config BR2_PACKAGE_ERLANG_P1_ZLIB
+	bool "erlang-p1-zlib"
+	depends on BR2_PACKAGE_ERLANG
+	help
+	  Erlang interface to zlib

package/erlang-p1-zlib/erlang-p1-zlib.mk new file +13 -0

new file mode 100644
index 0000000..84ecb35
@@ -0,0 +1,13 @@
+################################################################################
+#
+# erlang-p1-zlib
+#
+################################################################################
+
+ERLANG_P1_ZLIB_VERSION = 52e82bb
+ERLANG_P1_ZLIB_SITE = $(call github,processone,zlib,$(ERLANG_P1_ZLIB_VERSION))
+ERLANG_P1_ZLIB_LICENSE = GPLv2+
+ERLANG_P1_ZLIB_LICENSE_FILES = COPYING
+ERLANG_P1_ZLIB_DEPENDENCIES = erlang
+
+$(eval $(rebar-package))

Signature · 1 line

2.1.0

Johan Oudinet

author

2014-12-09 14:34 UTC #27 lore raw

PATCH v4 8/17 erlang-p1-yaml: new package.

---
 package/Config.in                        |  1 +
 package/erlang-p1-yaml/Config.in         |  6 ++++++
 package/erlang-p1-yaml/erlang-p1-yaml.mk | 13 +++++++++++++
 3 files changed, 20 insertions(+)
 create mode 100644 package/erlang-p1-yaml/Config.in
 create mode 100644 package/erlang-p1-yaml/erlang-p1-yaml.mk

package/Config.in +1 -0

index 240a82c..9096211 100644
@@ -396,6 +396,7 @@ if BR2_PACKAGE_ERLANG
 menu "Erlang libraries/modules"
 	source "package/erlang-goldrush/Config.in"
 	source "package/erlang-lager/Config.in"
+	source "package/erlang-p1-yaml/Config.in"
 	source "package/erlang-p1-zlib/Config.in"
 endmenu
 endif

package/erlang-p1-yaml/Config.in new file +6 -0

new file mode 100644
index 0000000..423ef3f
@@ -0,0 +1,6 @@
+config BR2_PACKAGE_ERLANG_P1_YAML
+	bool "erlang-p1-yaml"
+	depends on BR2_PACKAGE_ERLANG
+	select BR2_PACKAGE_LIBYAML
+	help
+	  Erlang wrapper for libyaml C library

package/erlang-p1-yaml/erlang-p1-yaml.mk new file +13 -0

new file mode 100644
index 0000000..990c3a7
@@ -0,0 +1,13 @@
+################################################################################
+#
+# erlang-p1-yaml
+#
+################################################################################
+
+ERLANG_P1_YAML_VERSION = 236b943
+ERLANG_P1_YAML_SITE = $(call github,processone,p1_yaml,$(ERLANG_P1_YAML_VERSION))
+ERLANG_P1_YAML_LICENSE = Apache-2.0
+ERLANG_P1_YAML_LICENSE_FILES = COPYING
+ERLANG_P1_YAML_DEPENDENCIES = erlang libyaml
+
+$(eval $(rebar-package))

Signature · 1 line

2.1.0

Johan Oudinet

author

2014-12-09 14:34 UTC #28 lore raw

PATCH v4 9/17 erlang-p1-xml: new package.

---
 package/Config.in                      |  1 +
 package/erlang-p1-xml/Config.in        |  6 ++++++
 package/erlang-p1-xml/erlang-p1-xml.mk | 16 ++++++++++++++++
 3 files changed, 23 insertions(+)
 create mode 100644 package/erlang-p1-xml/Config.in
 create mode 100644 package/erlang-p1-xml/erlang-p1-xml.mk

package/Config.in +1 -0

index 9096211..f9503ad 100644
@@ -396,6 +396,7 @@ if BR2_PACKAGE_ERLANG
 menu "Erlang libraries/modules"
 	source "package/erlang-goldrush/Config.in"
 	source "package/erlang-lager/Config.in"
+	source "package/erlang-p1-xml/Config.in"
 	source "package/erlang-p1-yaml/Config.in"
 	source "package/erlang-p1-zlib/Config.in"
 endmenu

package/erlang-p1-xml/Config.in new file +6 -0

new file mode 100644
index 0000000..85fe02f
@@ -0,0 +1,6 @@
+config BR2_PACKAGE_ERLANG_P1_XML
+	bool "erlang-p1-xml"
+	depends on BR2_PACKAGE_ERLANG
+	select BR2_PACKAGE_EXPAT
+	help
+	  XML utilities for Erlang

package/erlang-p1-xml/erlang-p1-xml.mk new file +16 -0

new file mode 100644
index 0000000..ac5ff53
@@ -0,0 +1,16 @@
+################################################################################
+#
+# erlang-p1-xml
+#
+################################################################################
+
+ERLANG_P1_XML_VERSION = b530983
+ERLANG_P1_XML_SITE = $(call github,processone,xml,$(ERLANG_P1_XML_VERSION))
+ERLANG_P1_XML_LICENSE = GPLv2
+ERLANG_P1_XML_LICENSE_FILES = COPYING
+ERLANG_P1_XML_DEPENDENCIES = erlang expat
+ERLANG_P1_XML_INSTALL_STAGING = YES
+
+ERLANG_P1_XML_CONFIGURE = YES
+
+$(eval $(rebar-package))

Signature · 1 line

2.1.0

Johan Oudinet

author

2014-12-09 14:34 UTC #29 lore raw

PATCH v4 10/17 erlang-p1-utils: new package.

---
 package/Config.in                          |  1 +
 package/erlang-p1-utils/Config.in          |  5 +++++
 package/erlang-p1-utils/erlang-p1-utils.mk | 14 ++++++++++++++
 3 files changed, 20 insertions(+)
 create mode 100644 package/erlang-p1-utils/Config.in
 create mode 100644 package/erlang-p1-utils/erlang-p1-utils.mk

package/Config.in +1 -0

index f9503ad..93b7bcb 100644
@@ -396,6 +396,7 @@ if BR2_PACKAGE_ERLANG
 menu "Erlang libraries/modules"
 	source "package/erlang-goldrush/Config.in"
 	source "package/erlang-lager/Config.in"
+	source "package/erlang-p1-utils/Config.in"
 	source "package/erlang-p1-xml/Config.in"
 	source "package/erlang-p1-yaml/Config.in"
 	source "package/erlang-p1-zlib/Config.in"

package/erlang-p1-utils/Config.in new file +5 -0

new file mode 100644
index 0000000..a544eed
@@ -0,0 +1,5 @@
+config BR2_PACKAGE_ERLANG_P1_UTILS
+	bool "erlang-p1-utils"
+	depends on BR2_PACKAGE_ERLANG
+	help
+	  Set of small Erlang libraries

package/erlang-p1-utils/erlang-p1-utils.mk new file +14 -0

new file mode 100644
index 0000000..23e2c63
@@ -0,0 +1,14 @@
+################################################################################
+#
+# erlang-p1-utils
+#
+################################################################################
+
+ERLANG_P1_UTILS_VERSION = 940f42d
+ERLANG_P1_UTILS_SITE = $(call github,processone,p1_utils,$(ERLANG_P1_UTILS_VERSION))
+ERLANG_P1_UTILS_LICENSE = GPLv2+
+ERLANG_P1_UTILS_LICENSE_FILES = COPYING
+ERLANG_P1_UTILS_DEPENDENCIES = erlang
+ERLANG_P1_UTILS_INSTALL_STAGING = YES
+
+$(eval $(rebar-package))

Signature · 1 line

2.1.0

Johan Oudinet

author

2014-12-09 14:34 UTC #30 lore raw

PATCH v4 11/17 erlang-p1-tls: new package.

---
 package/Config.in                      |  1 +
 package/erlang-p1-tls/Config.in        |  5 +++++
 package/erlang-p1-tls/erlang-p1-tls.mk | 14 ++++++++++++++
 3 files changed, 20 insertions(+)
 create mode 100644 package/erlang-p1-tls/Config.in
 create mode 100644 package/erlang-p1-tls/erlang-p1-tls.mk

package/Config.in +1 -0

index 93b7bcb..2a33c09 100644
@@ -396,6 +396,7 @@ if BR2_PACKAGE_ERLANG
 menu "Erlang libraries/modules"
 	source "package/erlang-goldrush/Config.in"
 	source "package/erlang-lager/Config.in"
+	source "package/erlang-p1-tls/Config.in"
 	source "package/erlang-p1-utils/Config.in"
 	source "package/erlang-p1-xml/Config.in"
 	source "package/erlang-p1-yaml/Config.in"

package/erlang-p1-tls/Config.in new file +5 -0

new file mode 100644
index 0000000..1aa53bc
@@ -0,0 +1,5 @@
+config BR2_PACKAGE_ERLANG_P1_TLS
+	bool "erlang-p1-tls"
+	depends on BR2_PACKAGE_ERLANG
+	help
+	  Erlang interface to OpenSSL

package/erlang-p1-tls/erlang-p1-tls.mk new file +14 -0

new file mode 100644
index 0000000..a884377
@@ -0,0 +1,14 @@
+################################################################################
+#
+# erlang-p1-tls
+#
+################################################################################
+
+ERLANG_P1_TLS_VERSION = 53f0478
+ERLANG_P1_TLS_SITE = $(call github,processone,tls,$(ERLANG_P1_TLS_VERSION))
+ERLANG_P1_TLS_LICENSE = GPLv2+
+ERLANG_P1_TLS_LICENSE_FILES = COPYING
+ERLANG_P1_TLS_DEPENDENCIES = erlang
+ERLANG_P1_TLS_INSTALL_STAGING = YES
+
+$(eval $(rebar-package))

Signature · 1 line

2.1.0

Johan Oudinet

author

2014-12-09 14:34 UTC #31 lore raw

PATCH v4 12/17 erlang-p1-stun: new package.

---
 package/Config.in                        |  1 +
 package/erlang-p1-stun/Config.in         |  7 +++++++
 package/erlang-p1-stun/erlang-p1-stun.mk | 14 ++++++++++++++
 3 files changed, 22 insertions(+)
 create mode 100644 package/erlang-p1-stun/Config.in
 create mode 100644 package/erlang-p1-stun/erlang-p1-stun.mk

package/Config.in +1 -0

index 2a33c09..51536b5 100644
@@ -396,6 +396,7 @@ if BR2_PACKAGE_ERLANG
 menu "Erlang libraries/modules"
 	source "package/erlang-goldrush/Config.in"
 	source "package/erlang-lager/Config.in"
+	source "package/erlang-p1-stun/Config.in"
 	source "package/erlang-p1-tls/Config.in"
 	source "package/erlang-p1-utils/Config.in"
 	source "package/erlang-p1-xml/Config.in"

package/erlang-p1-stun/Config.in new file +7 -0

new file mode 100644
index 0000000..bbe6bae
@@ -0,0 +1,7 @@
+config BR2_PACKAGE_ERLANG_P1_STUN
+	bool "erlang-p1-stun"
+	depends on BR2_PACKAGE_ERLANG
+	select BR2_PACKAGE_ERLANG_P1_TLS
+	select BR2_PACKAGE_ERLANG_P1_UTILS
+	help
+	  STUN library for Erlang

package/erlang-p1-stun/erlang-p1-stun.mk new file +14 -0

new file mode 100644
index 0000000..d963caa
@@ -0,0 +1,14 @@
+################################################################################
+#
+# erlang-p1-stun
+#
+################################################################################
+
+ERLANG_P1_STUN_VERSION = a7c07b6
+ERLANG_P1_STUN_SITE = $(call github,processone,stun,$(ERLANG_P1_STUN_VERSION))
+ERLANG_P1_STUN_LICENSE = GPLv2+
+ERLANG_P1_STUN_LICENSE_FILES = COPYING
+ERLANG_P1_STUN_DEPENDENCIES = erlang host-erlang-rebar erlang-p1-tls erlang-p1-utils
+ERLANG_P1_STUN_INSTALL_STAGING = YES
+
+$(eval $(rebar-package))

Signature · 1 line

2.1.0

Johan Oudinet

author

2014-12-09 14:34 UTC #32 lore raw

PATCH v4 13/17 erlang-p1-stringprep: new package.

---
 package/Config.in                                    |  1 +
 package/erlang-p1-stringprep/Config.in               |  5 +++++
 package/erlang-p1-stringprep/erlang-p1-stringprep.mk | 13 +++++++++++++
 3 files changed, 19 insertions(+)
 create mode 100644 package/erlang-p1-stringprep/Config.in
 create mode 100644 package/erlang-p1-stringprep/erlang-p1-stringprep.mk

package/Config.in +1 -0

index 51536b5..ac885c4 100644
@@ -396,6 +396,7 @@ if BR2_PACKAGE_ERLANG
 menu "Erlang libraries/modules"
 	source "package/erlang-goldrush/Config.in"
 	source "package/erlang-lager/Config.in"
+	source "package/erlang-p1-stringprep/Config.in"
 	source "package/erlang-p1-stun/Config.in"
 	source "package/erlang-p1-tls/Config.in"
 	source "package/erlang-p1-utils/Config.in"

package/erlang-p1-stringprep/Config.in new file +5 -0

new file mode 100644
index 0000000..eaaa59e
@@ -0,0 +1,5 @@
+config BR2_PACKAGE_ERLANG_P1_STRINGPREP
+	bool "erlang-p1-stringprep"
+	depends on BR2_PACKAGE_ERLANG
+	help
+	  Erlang interface to stringprep

package/erlang-p1-stringprep/erlang-p1-stringprep.mk new file +13 -0

new file mode 100644
index 0000000..b83e106
@@ -0,0 +1,13 @@
+################################################################################
+#
+# erlang-p1-stringprep
+#
+################################################################################
+
+ERLANG_P1_STRINGPREP_VERSION = 9e9e0f8
+ERLANG_P1_STRINGPREP_SITE = $(call github,processone,stringprep,$(ERLANG_P1_STRINGPREP_VERSION))
+ERLANG_P1_STRINGPREP_LICENSE = GPLv2+
+ERLANG_P1_STRINGPREP_LICENSE_FILES = LICENSE.TCL
+ERLANG_P1_STRINGPREP_DEPENDENCIES = erlang
+
+$(eval $(rebar-package))

Signature · 1 line

2.1.0

Johan Oudinet

author

2014-12-09 14:34 UTC #33 lore raw

PATCH v4 14/17 erlang-p1-sip: new package.

---
 package/Config.in                                     |  1 +
 package/erlang-p1-sip/Config.in                       |  8 ++++++++
 .../erlang-p1-sip/erlang-p1-sip-01-fix-includes.patch | 19 +++++++++++++++++++
 package/erlang-p1-sip/erlang-p1-sip.mk                | 14 ++++++++++++++
 4 files changed, 42 insertions(+)
 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

package/Config.in +1 -0

index ac885c4..132c2a8 100644
@@ -396,6 +396,7 @@ if BR2_PACKAGE_ERLANG
 menu "Erlang libraries/modules"
 	source "package/erlang-goldrush/Config.in"
 	source "package/erlang-lager/Config.in"
+	source "package/erlang-p1-sip/Config.in"
 	source "package/erlang-p1-stringprep/Config.in"
 	source "package/erlang-p1-stun/Config.in"
 	source "package/erlang-p1-tls/Config.in"

package/erlang-p1-sip/Config.in new file +8 -0

new file mode 100644
index 0000000..64a12b1
@@ -0,0 +1,8 @@
+config BR2_PACKAGE_ERLANG_P1_SIP
+	bool "erlang-p1-sip"
+	depends on BR2_PACKAGE_ERLANG
+	select BR2_PACKAGE_ERLANG_P1_STUN
+	select BR2_PACKAGE_ERLANG_P1_TLS
+	select BR2_PACKAGE_ERLANG_P1_UTILS
+	help
+	  SIP library for Erlang

package/erlang-p1-sip/erlang-p1-sip-01-fix-includes.patch new file +19 -0

new file mode 100644
index 0000000..80e2ab3
@@ -0,0 +1,19 @@
+Description: correct include
+ This part of the code was moved into it's own project and was packaged
+ separately by me. To make the build process work, this small fix is
+ necessary.
+Author: Philipp Huebner <[email protected]>
+
+Index: erlang-p1-sip/src/esip_socket.erl
+===================================================================
+--- erlang-p1-sip.orig/src/esip_socket.erl
++++ erlang-p1-sip/src/esip_socket.erl
+@@ -22,7 +22,7 @@
+ 
+ -include("esip.hrl").
+ -include("esip_lib.hrl").
+--include("stun.hrl").
++-include_lib("p1_stun/include/stun.hrl").
+ 
+ -define(TCP_SEND_TIMEOUT, 15000).
+ -define(CONNECT_TIMEOUT, 20000).

package/erlang-p1-sip/erlang-p1-sip.mk new file +14 -0

new file mode 100644
index 0000000..d38ff2b
@@ -0,0 +1,14 @@
+################################################################################
+#
+# erlang-p1-sip
+#
+################################################################################
+
+ERLANG_P1_SIP_VERSION = bba4459
+ERLANG_P1_SIP_SITE = $(call github,processone,p1_sip,$(ERLANG_P1_SIP_VERSION))
+ERLANG_P1_SIP_LICENSE = GPLv2
+ERLANG_P1_SIP_LICENSE_FILES = COPYING
+ERLANG_P1_SIP_DEPENDENCIES = erlang erlang-p1-stun erlang-p1-tls erlang-p1-utils
+ERLANG_P1_SIP_INSTALL_STAGING = YES
+
+$(eval $(rebar-package))

Signature · 1 line

2.1.0

Johan Oudinet

author

2014-12-09 14:34 UTC #34 lore raw

PATCH v4 15/17 erlang-p1-iconv: new package.

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

package/Config.in +1 -0

index 132c2a8..3ddc78b 100644
@@ -396,6 +396,7 @@ if BR2_PACKAGE_ERLANG
 menu "Erlang libraries/modules"
 	source "package/erlang-goldrush/Config.in"
 	source "package/erlang-lager/Config.in"
+	source "package/erlang-p1-iconv/Config.in"
 	source "package/erlang-p1-sip/Config.in"
 	source "package/erlang-p1-stringprep/Config.in"
 	source "package/erlang-p1-stun/Config.in"

package/erlang-p1-iconv/Config.in new file +6 -0

new file mode 100644
index 0000000..53876bf
@@ -0,0 +1,6 @@
+config BR2_PACKAGE_ERLANG_P1_ICONV
+	bool "erlang-p1-iconv"
+	depends on BR2_PACKAGE_ERLANG
+	select BR2_PACKAGE_LIBICONV if !BR2_ENABLE_LOCALE
+	help
+	  Erlang interface to libiconv

package/erlang-p1-iconv/erlang-p1-iconv.mk new file +19 -0

new file mode 100644
index 0000000..d28ff39
@@ -0,0 +1,19 @@
+################################################################################
+#
+# erlang-p1-iconv
+#
+################################################################################
+
+ERLANG_P1_ICONV_VERSION = dff5ee5
+ERLANG_P1_ICONV_SITE = $(call github,processone,eiconv,$(ERLANG_P1_ICONV_VERSION))
+ERLANG_P1_ICONV_LICENSE = GPLv2+
+ERLANG_P1_ICONV_LICENSE_FILES = COPYING
+ERLANG_P1_ICONV_DEPENDENCIES = erlang
+
+ifeq ($(BR2_PACKAGE_LIBICONV),y)
+ERLANG_P1_ICONV_DEPENDENCIES += libiconv
+endif
+
+ERLANG_P1_ICONV_CONFIGURE = YES
+
+$(eval $(rebar-package))

Signature · 1 line

2.1.0

Johan Oudinet

author

2014-12-09 14:34 UTC #35 lore raw

PATCH v4 16/17 erlang-p1-cache-tab: new package.

---
 package/Config.in                                  |  1 +
 package/erlang-p1-cache-tab/Config.in              |  6 ++++++
 package/erlang-p1-cache-tab/erlang-p1-cache-tab.mk | 13 +++++++++++++
 3 files changed, 20 insertions(+)
 create mode 100644 package/erlang-p1-cache-tab/Config.in
 create mode 100644 package/erlang-p1-cache-tab/erlang-p1-cache-tab.mk

package/Config.in +1 -0

index 3ddc78b..22393ec 100644
@@ -396,6 +396,7 @@ if BR2_PACKAGE_ERLANG
 menu "Erlang libraries/modules"
 	source "package/erlang-goldrush/Config.in"
 	source "package/erlang-lager/Config.in"
+	source "package/erlang-p1-cache-tab/Config.in"
 	source "package/erlang-p1-iconv/Config.in"
 	source "package/erlang-p1-sip/Config.in"
 	source "package/erlang-p1-stringprep/Config.in"

package/erlang-p1-cache-tab/Config.in new file +6 -0

new file mode 100644
index 0000000..6d1f889
@@ -0,0 +1,6 @@
+config BR2_PACKAGE_ERLANG_P1_CACHE_TAB
+	bool "erlang-p1-cache-tab"
+	depends on BR2_PACKAGE_ERLANG
+	select BR2_PACKAGE_ERLANG_P1_UTILS
+	help
+	  Erlang library implementing cache tables

package/erlang-p1-cache-tab/erlang-p1-cache-tab.mk new file +13 -0

new file mode 100644
index 0000000..0f0b637
@@ -0,0 +1,13 @@
+################################################################################
+#
+# erlang-p1-cache-tab
+#
+################################################################################
+
+ERLANG_P1_CACHE_TAB_VERSION = 7b89d6a
+ERLANG_P1_CACHE_TAB_SITE = $(call github,processone,cache_tab,$(ERLANG_P1_CACHE_TAB_VERSION))
+ERLANG_P1_CACHE_TAB_LICENSE = GPLv2+
+ERLANG_P1_CACHE_TAB_LICENSE_FILES = COPYING
+ERLANG_P1_CACHE_TAB_DEPENDENCIES = erlang erlang-p1-utils
+
+$(eval $(rebar-package))

Signature · 1 line

2.1.0

Johan Oudinet

author

2014-12-09 14:34 UTC #36 lore raw

PATCH v4 17/17 ejabberd: new package.

---
 package/Config.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                       | 52 ++++++++++++
 13 files changed, 541 insertions(+)
 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

package/Config.in +1 -0

index 22393ec..03c25cb 100644
@@ -1036,6 +1036,7 @@ endif
 	source "package/dnsmasq/Config.in"
 	source "package/dropbear/Config.in"
 	source "package/ebtables/Config.in"
+	source "package/ejabberd/Config.in"
 	source "package/ethtool/Config.in"
 	source "package/faifa/Config.in"
 	source "package/fmc/Config.in"

package/ejabberd/0001-remove-deps.patch new file +20 -0

new file mode 100644
index 0000000..1982ca8
@@ -0,0 +1,20 @@
+Description: remove make targets for deps
+ Without this patch, dependencies would be downloaded and compiled
+ using rebar at build time.
+Author: Philipp Huebner <[email protected]>
+
+Index: ejabberd/rebar.config.script
+===================================================================
+--- ejabberd.orig/rebar.config.script
++++ ejabberd/rebar.config.script
+@@ -126,9 +126,7 @@ Config = [{erl_opts, Macros ++ HiPE ++ D
+           {sub_dirs, ["rel"]},
+           {keep_build_info, true},
+           {ct_extra_params, "-include "
+-           ++ filename:join([Cwd, "tools"])},
+-          {post_hooks, PostHooks ++ CfgPostHooks},
+-          {deps, Deps ++ CfgDeps}],
++           ++ filename:join([Cwd, "tools"])}],
+ %%io:format("ejabberd configuration:~n  ~p~n", [Config]),
+ Config.
+

package/ejabberd/0002-disable-rebar-deps.patch new file +70 -0

70 lines not on this page · raw message

package/ejabberd/0003-disable-test.patch new file +21 -0

new file mode 100644
index 0000000..4354ab6
@@ -0,0 +1,21 @@
+Description: remove testing with MySQL and PostgreSQL
+ Without this patch a test would be initiated after building ejabberd that
+ requires specially configured instances of MySQL and PostgreSQL to be up
+ and running.
+Author: Philipp Huebner <[email protected]>
+
+Index: ejabberd/Makefile.in
+===================================================================
+--- ejabberd.orig/Makefile.in
++++ ejabberd/Makefile.in
+@@ -260,10 +260,6 @@ dialyzer: erlang_plt deps_plt ejabberd_p
+ 	status=$$? ; if [ $$status -ne 2 ]; then exit $$status; else exit 0; fi
+ 
+ test:
+-	@echo "************************** NOTICE ***************************************"
+-	@cat test/README
+-	@echo "*************************************************************************"
+-	$(REBAR) skip_deps=true ct
+ 
+ .PHONY: src doc edoc dialyzer Makefile TAGS clean clean-rel distclean rel \
+ 	install uninstall uninstall-binary uninstall-all translations deps test spec \

package/ejabberd/0004-disable-version-check.patch new file +20 -0

new file mode 100644
index 0000000..f2f1e81
@@ -0,0 +1,20 @@
+Description: remove checking erlang version
+ Without this patch, the configure will try to run erlang to simply check if
+ the version is supported by ejabberd. Instead, we do this test statically.
+Author: Johan Oudinet <[email protected]>
+
+Index: ejabberd/configure.ac
+===================================================================
+--- ejabberd.orig/configure.ac	2014-10-20 11:04:14.751256865 +0200
++++ ejabberd/configure.ac	2014-10-20 11:03:47.983578623 +0200
+@@ -37,10 +37,8 @@ AC_ARG_ENABLE(erlang-version-check,
+ 	[Check Erlang/OTP version @<:@default=yes@:>@])])
+ case "$enable_erlang_version_check" in
+ 	yes|'')
+-		ERLANG_VERSION_CHECK([$REQUIRE_ERLANG_MIN],[$REQUIRE_ERLANG_MAX])
+ 		;;
+ 	no)
+-		ERLANG_VERSION_CHECK([$REQUIRE_ERLANG_MIN],[$REQUIRE_ERLANG_MAX],[warn])
+ 		;;
+ esac
+

package/ejabberd/0005-fix-includes.patch new file +45 -0

45 lines not on this page · raw message

package/ejabberd/0006-remove-doc.patch new file +26 -0

new file mode 100644
index 0000000..0c0a21b
@@ -0,0 +1,26 @@
+Description: remove installing documentation
+ Without this patch, the Makefile will try to install ejabberd
+ documentation even if it is not generated, which will fail.
+Author: Johan Oudinet <[email protected]>
+
+Index: ejabberd/Makefile.in
+===================================================================
+--- ejabberd.orig/Makefile.in	2014-10-21 16:43:42.604972005 +0200
++++ ejabberd/Makefile.in	2014-10-21 16:45:12.419989667 +0200
+@@ -156,16 +156,6 @@ install: all
+ 	$(INSTALL) -d -m 750 $(O_USER) $(LOGDIR)
+ 	$(CHOWN_COMMAND) -R @INSTALLUSER@ $(LOGDIR) >$(CHOWN_OUTPUT)
+ 	chmod -R 750 $(LOGDIR)
+-	#
+-	# Documentation
+-	$(INSTALL) -d $(DOCDIR)
+-	$(INSTALL) -m 644 doc/dev.html $(DOCDIR)
+-	$(INSTALL) -m 644 doc/guide.html $(DOCDIR)
+-	$(INSTALL) -m 644 doc/*.png $(DOCDIR)
+-	[ -f doc/guide.pdf ] \
+-		&& $(INSTALL) -m 644 doc/guide.pdf $(DOCDIR) \
+-		|| echo "No doc/guide.pdf was built"
+-	$(INSTALL) -m 644 COPYING $(DOCDIR)
+ 
+ uninstall: uninstall-binary
+

package/ejabberd/0007-fix-init.patch new file +99 -0

99 lines not on this page · raw message

package/ejabberd/0008-fix-install-permissions.patch new file +76 -0

76 lines not on this page · raw message

package/ejabberd/Config.in new file +21 -0

new file mode 100644
index 0000000..2a8d274
@@ -0,0 +1,21 @@
+config BR2_PACKAGE_EJABBERD
+	bool "ejabberd"
+	depends on BR2_PACKAGE_ERLANG
+	select BR2_PACKAGE_ERLANG_LAGER
+	select BR2_PACKAGE_ERLANG_P1_CACHE_TAB
+	select BR2_PACKAGE_ERLANG_P1_ICONV
+	select BR2_PACKAGE_ERLANG_P1_SIP
+	select BR2_PACKAGE_ERLANG_P1_STRINGPREP
+	select BR2_PACKAGE_ERLANG_P1_XML
+	select BR2_PACKAGE_ERLANG_P1_YAML
+	select BR2_PACKAGE_ERLANG_P1_ZLIB
+	select BR2_PACKAGE_OPENSSL
+	help
+	  Ejabberd is a Jabber/XMPP instant messaging server, written
+	  in Erlang/OTP. Among other features, ejabberd is
+	  cross-platform, fault-tolerant, clusterable and modular.
+
+	  http://www.ejabberd.im
+
+comment "Ejabberd needs a toolchain w/ Erlang"
+	depends on !BR2_PACKAGE_ERLANG

package/ejabberd/S50ejabberd new file +35 -0

new file mode 100644
index 0000000..2656307
@@ -0,0 +1,35 @@
+#!/bin/sh
+#
+# Start/stop ejabberd
+#
+
+USER=ejabberd
+RUNDIR=/var/run/ejabberd
+
+mkrundir() {
+    install -d -o $USER -g $USER $RUNDIR
+}
+
+case "$1" in
+    start)
+	mkrundir
+        echo "Starting ejabberd..."
+        ejabberdctl start
+        ;;
+    stop)
+        echo -n "Stopping ejabberd... "
+        ejabberdctl stop > /dev/null
+        if [ $? -eq 3 ] || ejabberdctl stopped; then
+            echo "OK"
+        else
+            echo "failed"
+        fi
+        ;;
+    restart|reload)
+        "$0" stop
+        "$0" start
+        ;;
+    *)
+        echo "Usage: $0 {start|stop|restart}"
+        exit 1
+esac

package/ejabberd/check-erlang-lib new file +55 -0

55 lines not on this page · raw message

package/ejabberd/ejabberd.mk new file +52 -0

52 lines not on this page · raw message

Signature · 1 line

2.1.0

Yann E. MORIN

2015-01-05 00:06 UTC #37 lore raw

v4 cover ejabberd: XMPP server