package/dhcp: bump version to 4.3.3

RFC PATCH Superseded Ricardo Martincoski 2 participants 4 messages Jan 15, 2016 – Jan 16, 2016

lore

Share & tools

lore

Ricardo Martincoski

author

2016-01-15 00:17 UTC #0 lore raw

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

Hi Doug and Arnout,

Quoted 3 lines · Doug Kehn

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]

Review

Quoted 4 lines

(quoted diff) +4 -0

+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.

Review

Quoted 3 lines

(quoted diff) +3 -0

+	GNU_HOST_NAME=$(GNU_HOST_NAME) \
+	AR="$(TARGET_AR)" \
+	BUILD_CC="$(HOSTCC)"

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

Review

Quoted 5 lines

(quoted diff) +5 -0

+
+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?

Regards,
Ricardo

rdkehn at yahoo.com

2016-01-15 15:31 UTC #1 lore raw

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

Hi Richardo, Arnout, All,

Quoted 18 lines · Ricardo Martincoski

Hi Doug and Arnout,
Quoted 3 lines · Doug Kehn
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]
Review
Quoted 4 lines
(quoted diff) +4 -0
+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.

Quoted 3 lines

Review

Quoted 3 lines

(quoted diff) +3 -0

+	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?

Quoted 14 lines

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

Quoted 7 lines

Review
Quoted 5 lines
(quoted diff) +5 -0
+
+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?

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.

Regards,
...doug

Ricardo Martincoski

author

2016-01-16 01:32 UTC #2 lore raw

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

Hi Doug,

Quoted 21 lines · rdkehn at yahoo.com

Hi Richardo, Arnout, All,
Quoted 18 lines · Ricardo Martincoski
Hi Doug and Arnout,
Quoted 3 lines · Doug Kehn
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]
Review
Quoted 4 lines
(quoted diff) +4 -0
+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.

Quoted 8 lines

Quoted 3 lines
Review
Quoted 3 lines
(quoted diff) +3 -0
+	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.

Quoted 22 lines

Quoted 14 lines
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
Quoted 7 lines
Review
Quoted 5 lines
(quoted diff) +5 -0
+
+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?

Quoted 2 lines

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.

Quoted 8 lines

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

rdkehn at yahoo.com

2016-01-16 22:08 UTC #3 lore raw

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

Hi Ricardo, All,

Quoted 32 lines · Ricardo Martincoski

Hi Doug,
Quoted 21 lines · rdkehn at yahoo.com
Hi Richardo, Arnout, All,
Quoted 18 lines · Ricardo Martincoski
Hi Doug and Arnout,
Quoted 3 lines · Doug Kehn
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]
Review
Quoted 4 lines
(quoted diff) +4 -0
+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.
Quoted 8 lines
Quoted 3 lines
Review
Quoted 3 lines
(quoted diff) +3 -0
+	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?

Quoted 5 lines

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.

Thanks for the feedback.

Quoted 23 lines

Quoted 23 lines
Quoted 22 lines
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
Review
Quoted 5 lines
(quoted diff) +5 -0
+
+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?

Quoted 6 lines

Quoted 2 lines
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.

I also tested the configure hook scenario. It worked for my use case as well.

Quoted 11 lines

Quoted 8 lines
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.

Peter, Thomas, there are two solutions to this problem. I would appreciate your input on your preference before I submit a patch.

Thanks and Regards,
...doug