[Buildroot] [RFC PATCH v2 1/4] package/dhcp: bump version to 4.3.3

[Ricardo Martincoski]

Hi Doug,

On Fri, Jan 15, 2016 at 01:31 PM, rdkehn at yahoo.com wrote:
> Hi Richardo, Arnout, All,
> 
> On Thu, Jan 14, 2016 at 10:17:28PM -0200, Ricardo Martincoski wrote:
>> Hi Doug and Arnout,
>> 
>> On Sun, 10 Jan 2016 15:25:06 -0600, Doug Kehn wrote:
>> > The embedded bind configure is called as part of dhcp make instead of
>> > dhcp configure. dhcp make environment is expanded to ensure bind
>> > configure has the proper information.
>> Maybe the bind configure could be called in a post configure hook.
>> This way, bind would be configured in the configure step too.
>> 
>> [snip]
>> > +DHCP_MAKE=$(MAKE1)
>> > +
>> > +DHCP_MAKE_ENV = \
>> > +	GNU_TARGET_NAME=$(GNU_TARGET_NAME) \
>> For at least one external toolchain, the bind configure can't find the
>> target compiler because it is expecting arm-buildroot-linux-gnueabi-gcc
>> while the binary name is arm-none-linux-gnueabi-gcc.
>> Maybe setting CC here would fix this.
>> > +	GNU_HOST_NAME=$(GNU_HOST_NAME) \
>> > +	AR="$(TARGET_AR)" \
>> > +	BUILD_CC="$(HOSTCC)"
> 
> Did you try adding CC to see if it fixed the external toolchain
> issue? I also wonder if adding $(TARGET_CONFIGURE_OPTS) to MAKE_ENV
> is warranted?
> 
I just tested adding only CC="$(TARGET_CC)" copied from TARGET_CONFIGURE_OPTS
and it solves the external toolchain issue.
Only a few autotools-packages (smcroute, fcgiwrap, libpam-radius-auth) add
$(TARGET_CONFIGURE_OPTS) to MAKE_ENV. All three have comments to justify the
use, so I suppose it is not the best practice.

>> 
>> If a hook is used, TARGET_CONFIGURE_OPTS can provide most of variables needed,
>> fixing the issue with some external toolchains.
>> Something like this:
>> DHCP_BIND_CONF_ENV = \
>> 	$(TARGET_CONFIGURE_OPTS) \
>> 	GNU_TARGET_NAME=$(GNU_TARGET_NAME) \
>> 	GNU_HOST_NAME=$(GNU_HOST_NAME) \
>> 	BUILD_CC="$(HOSTCC)"
>> 
>> define DHCP_CONFIGURE_BIND
>> 	$(DHCP_BIND_CONF_ENV) $(DHCP_MAKE) -C $(@D)/bind bind1
>> endef
>> DHCP_POST_CONFIGURE_HOOKS += DHCP_CONFIGURE_BIND
>> > +
>> > +define DHCP_EXTRACT_BIND
>> > +	cd $(@D)/bind; tar -xvf bind.tar.gz
>> > +endef
>> > +DHCP_POST_EXTRACT_HOOKS += DHCP_EXTRACT_BIND
>> 
>> What do you think about this?
> 
> Did the configure hook work for you?
> 
Yes.
Also, in a rapid test, the hook seems to work fine after removing
TARGET_CONFIGURE_OPTS and adding back AR and CC.

> At the end of the day, configure hook vs make env is a matter
> preference for the Buildroot maintainers; as long as it works... I
> have not yet tried the configure hook; but, I will. My only
> reservation with the configure hook is that it must know the exact
> target to make to configure bind as apposed to just ensuring the
> environment has the proper values for cross compiling and letting
> the Buildroot infra take care of the rest. 
> 
Taking your reservation into account, I agree make env seems a better choice.
Thank you for your explanation.

Regards,
Ricardo