[Buildroot] [PATCH v4 03/17] package/pkg-rebar: new infrastructure
Yann E. MORIN
yann.morin.1998 at free.fr
Sun Jan 4 22:20:38 UTC 2015
Thomas, Johan, All,
[comments ellided are being dealt with]
On 2015-01-04 22:23 +0100, Thomas Petazzoni spake thusly:
> On Tue, 9 Dec 2014 15:34:08 +0100, Johan Oudinet wrote:
> > diff --git a/package/pkg-rebar.mk b/package/pkg-rebar.mk
> > new file mode 100644
> > index 0000000..c9b15c0
> > --- /dev/null
> > +++ b/package/pkg-rebar.mk
[--SNIP--]
> > +################################################################################
> > +# inner-rebar-package -- defines how the configuration, compilation
> > +# and installation of a rebar package should be done, implements a few
> > +# hooks to tune the build process according to rebar specifities, and
> > +# calls the generic package infrastructure to generate the necessary
> > +# make targets.
> > +#
> > +# argument 1 is the lowercase package name
> > +# argument 2 is the uppercase package name, including a HOST_ prefix
> > +# for host packages
> > +# argument 3 is the uppercase package name, without the HOST_ prefix
> > +# for host packages
> > +# argument 4 is the type (target or host)
> > +#
> > +################################################################################
> > +
> > +define inner-rebar-package
> > +
> > +# 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.
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.
> > +# 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.
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.
> > +# 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--]
> > +# 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?
> 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.
--
.-----------------.--------------------.------------------.--------------------.
| 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. |
'------------------------------^-------^------------------^--------------------'
More information about the buildroot
mailing list