[Buildroot] [PATCH 2/3] core: waf-package infra: add missing additional variables for each build step

Arnout Vandecappelle arnout at mind.be
Sun Dec 4 23:32:24 UTC 2016



On 04-12-16 22:41, Thomas Petazzoni wrote:
> Hello,
> 
> On Sun, 4 Dec 2016 22:24:34 +0100, Yann E. MORIN wrote:
>> Romain, All,
> 
>>> -     $$(TARGET_MAKE_ENV) $$(HOST_DIR)/usr/bin/python2 $$($(2)_WAF) build -j $$(PARALLEL_JOBS)
>>> +     $$(TARGET_MAKE_ENV) $$(HOST_DIR)/usr/bin/python2 $$($(2)_WAF) \
>>> +             build -j $$(PARALLEL_JOBS) $$($(2)_MAKE_OPTS)  
>>
>> I'm not against having variables named the same across packages, but
>> here I think $(2)_BUILD_OPTS would be more appropriate.
> 
> ACK.
> 
>>> @@ -84,7 +85,8 @@ ifndef $(2)_INSTALL_STAGING_CMDS
>>>  define $(2)_INSTALL_STAGING_CMDS
>>>       cd $$(@D) && \
>>>       $$(TARGET_MAKE_ENV) $$(HOST_DIR)/usr/bin/python2 $$($(2)_WAF) \
>>> -             install --destdir=$$(STAGING_DIR)
>>> +             install --destdir=$$(STAGING_DIR) \
>>> +             $$($(2)_INSTALL_STAGING_OPTS)  
>>
>> Usually, those options entirely override the default ones. For example,
>> if you provide FOO_INSTALL_STAGING_OPTS for an autotools package, then
>> the default (just 'install') is lost:
>>
>>     package/pkg-autotools.mk:
>>     159 $(2)_INSTALL_STAGING_OPTS»  ?= DESTDIR=$$(STAGING_DIR) install>>


 That's autotools, but if you look at cmake, python, and perl, they're basically
doing it all differently. For example, cmake has a _MAKE_OPTS that is passed for
all steps; python and perl hardcode the 'install' command.

 I think we can conclude that consistency is not going to happen, so instead we
should look for the "best" option. Which means:

>> OTOH, I find this to be counter-intuitive for a user, and I would prefer
>> the options to add rather than replace.
> 
> Agreed. I also find it super annoying that we have to replicate
> DESTDIR=$$(STAGING_DIR) install. But in some cases, we *do* need to
> override it.

 In case of waf, I'm not so sure we're ever going to need to override this.
autotools has more freedom to shoot yourself in the foot, but waf (like cmake)
is pretty much fixed.

> 
> Another thing that I dislike is that we have no way to pass an option
> to all of the build and install steps.

 Yep, and for cmake this is possible. So it would be better to have such an
option. What I'm not sure of, however, is how this option should be called, and
also if it should be passed in the configure step or not. Ideally we should have
more examples.

 Regards,
 Arnout


>> But consistency trumps it all, so we should do the same for waf
>> packages:
>>
>>     $(2)_INSTALL_STAGING_OPTS ?= install --destdir=$$(STAGING_DIR)
> 
> I agree. Even if the current situation is not 100% nice, I think a
> rework of this current situation is a much broader effort. So let's
> make the waf-package infrastructure be as similar as possible to the
> other ones.
> 
> Best regards,
> 
> Thomas
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF


More information about the buildroot mailing list