[Buildroot] [PATCH v2 02/15] package/pkg-rebar.mk: new infrastructure.

[Johan Oudinet]

Yann, All,

On Tue, Nov 11, 2014 at 4:35 PM, Yann E. MORIN <yann.morin.1998 at free.fr> wrote:
>> >> +ifndef $(2)_BUILD_CMDS
>> >> +define $(2)_BUILD_CMDS
>> >> +  cd '$$(@D)' &&                                                  \
>> >> +  if [ -f ./rebar ]; then                                         \
>> >> +          $$($$(PKG)_ENV)                                         \
>> >> +          $$($$(PKG)_REBAR_ENV)                                   \
>> >> +                  ./rebar $$($$(PKG)_REBAR_FLAGS) compile;        \
>> >> +  else                                                            \
>> >> +          $$($$(PKG)_ENV)                                         \
>> >> +          $$($$(PKG)_REBAR_ENV)                                   \
>> >> +                  rebar $$($$(PKG)_REBAR_FLAGS) compile;          \
>> >> +  fi
>> >> +endef
>> >> +endif
>> >
>> > Hmm... Do we want to trust the package's own rebar? Shouldn't we always
>> > use our own version of rebar instead?
>> >
>> > What would be the reason to 'trust' the package's rebar more than our?
>>
>>  Because the package's rebar may be more up-to-date or may be modified. As long
>> as we don't apply cross-compilation patches to our rebar, there is no reason to
>> prefer that one.
>>
>>  Ideally, however, the package should only depend on host-rebar if it will
>> actually use it. It's not a showstopper for me, just a preference.
>
> But as Johan said, some packages' rebar may break the compilation, like
> I could observe in my testing.
>
> Johan, care to investigate why would we use the package's rebar instead
> of our own?

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

-- 
Johan