[Buildroot] [PATCH v4 03/17] package/pkg-rebar: new infrastructure

[Thomas Petazzoni <thomas.petazzoni@free-electrons.com>]

Dear Yann E. MORIN,

On Mon, 5 Jan 2015 22:59:56 +0100, Yann E. MORIN wrote:

> 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com