All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.