[Buildroot] Analysis of bug #5030: busybox built fails if we use an override src dir BUSYBOX_OVERRIDE_SRCDIR and that dir does not contain .config
Thomas Petazzoni
thomas.petazzoni at free-electrons.com
Wed Feb 12 10:51:18 UTC 2014
Dear Thomas De Schampheleire,
On Wed, 12 Feb 2014 11:41:29 +0100, Thomas De Schampheleire wrote:
> > But what would you change the .config and then re-run the configure
> > step? The configure is all about *producing* the .config, so making a
> > change to the .config, and then re-running the configure step seems
> > weird to me.
>
> I don't necessarily feel that the 'configure' step is about producing
> the .config. To me, the configure step is about configuring busybox,
> based on the .config. So for me, the .config is input to the configure
> step, not output.
Well, in some sense the configure step is just "some step you do before
building", and generating the .config thing typically falls in this
category.
> > We have had for quite a while this comment in busybox.mk, which I never
> > really understood:
> >
> > # We do this here to avoid busting a modified .config in configure
> > BUSYBOX_POST_EXTRACT_HOOKS += BUSYBOX_COPY_CONFIG
> >
> > But we have the busybox-{menuconfig,xconfig} targets that allow to
> > adjust the configuration, and they only remove the "built" and
> > "target_installed" stamp files, which means after doing "make
> > busybox-menuconfig", if you run "make", the configure step of busybox
> > isn't re-executed, so the configuration changes you made are properly
> > taken into account and preserved.
>
> One may also edit .config manually, without running any of the *config commands.
And then you simply run "make busybox-rebuild", and that's it.
> Note by the way that the bug report is submitted from the context of
> the OVERRIDE_SRCDIR mechanism. Here there is no .config created at
> all, so it is not about editing it.
There would be a .config created is the .config creation was done in
the "configure" step and not in the extract step.
> >> 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...
> >
> > I also accept the principle of this patch.
> >
> > As a side note, this behavior of busybox.mk was also problematic when
> > trying to implement out of tree build for packages, because .config is
> > inherently part of the *build* directory, but the build directory
> > doesn't exist yet during the extract step: it is only created at the
> > beginning of the configure step. So my out-of-tree patch set contains:
> >
> > -# We do this here to avoid busting a modified .config in configure
> > -BUSYBOX_POST_EXTRACT_HOOKS += BUSYBOX_COPY_CONFIG
> > -
> > define BUSYBOX_CONFIGURE_CMDS
> > + $(BUSYBOX_COPY_CONFIG)
> >
>
> Then maybe we should apply exactly this change, and not the proposed
> one that uses a hook?
> Additionally, we should then also make this change in uclibc, right?
Yes. But I would like to hear Peter's opinion on this.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
More information about the buildroot
mailing list