Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v6 02/16] package/pkg-rebar: new infrastructure
Date: Tue, 3 Feb 2015 10:28:32 +0100	[thread overview]
Message-ID: <20150203102832.51cb4f7d@free-electrons.com> (raw)
In-Reply-To: <1421055140-5092-3-git-send-email-johan.oudinet@gmail.com>

Dear Johan Oudinet,

On Mon, 12 Jan 2015 10:32:06 +0100, Johan Oudinet wrote:
> Ease the development of packages that use the erlang rebar tool as
> their build system.
> 
> Signed-off-by: Johan Oudinet <johan.oudinet@gmail.com>
> [yann.morin.1998 at free.fr: split the patch into semantically separated
> patches; large rewrites of the rest]
> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

On this patch (the most important one, obviously), we did a number of
changes:

    [Thomas, with help from Yann and Arnout:
     - Fix the comment about the symlink used to make sure rebar does not
       download dependencies. The comment was not up-to-date with where
       the symlink is actually created.
     - Make <pkg>_USE_BUNDLED_REBAR and <pkg>_USE_AUTOCONF be inherited by
       host packages from their corresponding target package.
     - Make sure host dependencies are inherited from the corresponding
       target packages dependencies. This requires copying some logic from
       inner-autotools-package and inner-generic-package, just like
       inner-autotools-package duplicates some logic from
       inner-generic-package.
     - Fix host variant of $(2)_BUILD_CMDS indentation, use double quotes
       instead of simple quotes. So that it matches the target
       $(2)_BUILD_CMDS, and what we do elsewhere in Buildroot.]

See some questions below.


> +# 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 tells rebar to NOT download dependencies during
> +# the build stage.
> +#
> +REBAR_HOST_DEPS_DIR = $(HOST_DIR)/usr/share/rebar/deps
> +REBAR_TARGET_DEPS_DIR = $(STAGING_DIR)/usr/share/rebar/deps

Rather than having those paths, why don't we point directly rebar at
$(STAGING_DIR)/usr/lib/erlang/lib/ ? This directory already contains
<erlang-app>-<version> directory for each package, and we would only
have to create a symlink <erlang-app> --> <erlang-app>-<version>.

But maybe it's cleaner to have something completely separate, I don't know.

Thanks!

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

  reply	other threads:[~2015-02-03  9:28 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-12  9:32 [Buildroot] [PATCH v6 00/16] ejabberd: XMPP server Johan Oudinet
2015-01-12  9:32 ` [Buildroot] [PATCH v6 01/16] package/erlang: export EI_VSN so other packages can use it Johan Oudinet
2015-01-12  9:32 ` [Buildroot] [PATCH v6 02/16] package/pkg-rebar: new infrastructure Johan Oudinet
2015-02-03  9:28   ` Thomas Petazzoni [this message]
2015-02-24 17:07     ` Johan Oudinet
2015-02-24 18:09       ` Frank Hunleth
2015-01-12  9:32 ` [Buildroot] [PATCH v6 03/16] docs/manual: add documentation for the pkg-rebar infrastructure Johan Oudinet
2015-01-12  9:32 ` [Buildroot] [PATCH v6 04/16] erlang-goldrush: new package Johan Oudinet
2015-01-12  9:32 ` [Buildroot] [PATCH v6 05/16] erlang-lager: " Johan Oudinet
2015-02-03  9:29   ` Thomas Petazzoni
2015-01-12  9:32 ` [Buildroot] [PATCH v6 06/16] erlang-p1-zlib: " Johan Oudinet
2015-01-12  9:32 ` [Buildroot] [PATCH v6 07/16] erlang-p1-yaml: " Johan Oudinet
2015-01-12  9:32 ` [Buildroot] [PATCH v6 08/16] erlang-p1-xml: " Johan Oudinet
2015-02-03  9:29   ` Thomas Petazzoni
2015-01-12  9:32 ` [Buildroot] [PATCH v6 09/16] erlang-p1-utils: " Johan Oudinet
2015-01-12  9:32 ` [Buildroot] [PATCH v6 10/16] erlang-p1-tls: " Johan Oudinet
2015-01-12  9:32 ` [Buildroot] [PATCH v6 11/16] erlang-p1-stun: " Johan Oudinet
2015-01-12  9:32 ` [Buildroot] [PATCH v6 12/16] erlang-p1-stringprep: " Johan Oudinet
2015-02-03  9:54   ` Thomas Petazzoni
2015-01-12  9:32 ` [Buildroot] [PATCH v6 13/16] erlang-p1-sip: " Johan Oudinet
2015-02-03  9:55   ` Thomas Petazzoni
2015-01-12  9:32 ` [Buildroot] [PATCH v6 14/16] erlang-p1-iconv: " Johan Oudinet
2015-01-12  9:32 ` [Buildroot] [PATCH v6 15/16] erlang-p1-cache-tab: " Johan Oudinet
2015-01-12  9:32 ` [Buildroot] [PATCH v6 16/16] ejabberd: " Johan Oudinet
2015-02-03  9:56   ` Thomas Petazzoni
2015-02-03 10:35     ` Johan Oudinet
2015-02-03 11:32       ` Thomas Petazzoni
2015-02-04 21:17         ` Frank Hunleth
2015-02-05  7:55           ` Thomas Petazzoni
2015-02-05 14:25             ` Frank Hunleth
2015-02-03  9:26 ` [Buildroot] [PATCH v6 00/16] ejabberd: XMPP server Thomas Petazzoni
2015-02-03  9:56   ` Johan Oudinet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150203102832.51cb4f7d@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox