when one tries to make busybox this fails because the BUSYBOX_POST_EXTRACT_HOOKS are not run (we rsync from another directory). The solution to that I've came up with is to either change the BUSYBOX_POST_EXTRACT_HOOKS to BUSYBOX_PRE_CONFIGURE_HOOKS or add another hook BUSYBOX_PRE_CONFIGURE_HOOKS += BUSYBOX_COPY_CONFIG (the worst case scenario with the two hooks will be to copy the same file twice) the proposed solution is the following: diff --git a/package/busybox/busybox.mk b/package/busybox/busybox.mk index d18b6d0..17e8b7e 100644 --- a/package/busybox/busybox.mk +++ b/package/busybox/busybox.mk @@ -138,7 +138,7 @@ define BUSYBOX_INSTALL_LOGGING_SCRIPT endef # We do this here to avoid busting a modified .config in configure -BUSYBOX_POST_EXTRACT_HOOKS += BUSYBOX_COPY_CONFIG +BUSYBOX_PRE_CONFIGURE_HOOKS += BUSYBOX_COPY_CONFIG define BUSYBOX_CONFIGURE_CMDS $(BUSYBOX_SET_LARGEFILE)
A question to buildroot developers: what do we do with this patch? The different components using .config files all handle it differently: busybox copies its .config from the post-extract hook. linux copies its .config in the configure_cmds. uclibc copies its .config from the post-patch hook. The busybox behavior allows a user to change .config, then re-run the configure step and keep the user's changes. For linux this is not true: if you change your config and re-run the configure step, your changes are lost. If you change your .config and expect to keep the changes, you can only rebuild, not reconfigure. This patch proposes to line-up busybox more with how the linux kernel handles it. This raises the question: what do we want, what should the behavior be? Personally, I haven't had a big problem with the linux way, and thus would accept the principle of this patch. But I don't have a very strong opinion on this...
This bug has been fixed with commit http://git.buildroot.org/buildroot/commit/?id=eedfc7121cf5b9a8dee8546c85b3bd36e9a743a4 Thanks for reporting!