* [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
@ 2014-02-11 20:58 Thomas De Schampheleire
2014-02-12 8:21 ` Thomas Petazzoni
0 siblings, 1 reply; 6+ messages in thread
From: Thomas De Schampheleire @ 2014-02-11 20:58 UTC (permalink / raw)
To: buildroot
Hi,
Bug #5030 "busybox built fails if we use an override src dir
BUSYBOX_OVERRIDE_SRCDIR and that dir does not contain .config"
https://bugs.busybox.net/show_bug.cgi?id=5030
The bug is about the fact that the config file for busybox is copied
from the extract step, which is not used when you have an
OVERRIDE_SRCDIR. The submitter proposes to use a pre-configure hook
instead.
Triggered by this, I compared the situation of the other components
using .config files: uclibc and the kernel. My analysis (and questions
to buildroot developers) are in the bug report, copy pasted below for
your convenience. If we can reach a conclusion then this bug can be
fixed too.
-----
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...
-----
Thanks for your input,
Thomas
^ permalink raw reply [flat|nested] 6+ messages in thread
* [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
2014-02-11 20:58 [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 De Schampheleire
@ 2014-02-12 8:21 ` Thomas Petazzoni
2014-02-12 10:41 ` Thomas De Schampheleire
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Petazzoni @ 2014-02-12 8:21 UTC (permalink / raw)
To: buildroot
Dear Thomas De Schampheleire,
On Tue, 11 Feb 2014 21:58:54 +0100, Thomas De Schampheleire wrote:
> Bug #5030 "busybox built fails if we use an override src dir
> BUSYBOX_OVERRIDE_SRCDIR and that dir does not contain .config"
> https://bugs.busybox.net/show_bug.cgi?id=5030
>
> The bug is about the fact that the config file for busybox is copied
> from the extract step, which is not used when you have an
> OVERRIDE_SRCDIR. The submitter proposes to use a pre-configure hook
> instead.
>
> Triggered by this, I compared the situation of the other components
> using .config files: uclibc and the kernel. My analysis (and questions
> to buildroot developers) are in the bug report, copy pasted below for
> your convenience. If we can reach a conclusion then this bug can be
> fixed too.
>
> -----
> 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.
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.
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.
> 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)
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [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
2014-02-12 8:21 ` Thomas Petazzoni
@ 2014-02-12 10:41 ` Thomas De Schampheleire
2014-02-12 10:51 ` Thomas Petazzoni
0 siblings, 1 reply; 6+ messages in thread
From: Thomas De Schampheleire @ 2014-02-12 10:41 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Wed, Feb 12, 2014 at 9:21 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Tue, 11 Feb 2014 21:58:54 +0100, Thomas De Schampheleire wrote:
>
>> Bug #5030 "busybox built fails if we use an override src dir
>> BUSYBOX_OVERRIDE_SRCDIR and that dir does not contain .config"
>> https://bugs.busybox.net/show_bug.cgi?id=5030
>>
>> The bug is about the fact that the config file for busybox is copied
>> from the extract step, which is not used when you have an
>> OVERRIDE_SRCDIR. The submitter proposes to use a pre-configure hook
>> instead.
>>
>> Triggered by this, I compared the situation of the other components
>> using .config files: uclibc and the kernel. My analysis (and questions
>> to buildroot developers) are in the bug report, copy pasted below for
>> your convenience. If we can reach a conclusion then this bug can be
>> fixed too.
>>
>> -----
>> 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.
>
> 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.
But as I said, I don't think we need to support this case.
>
> 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.
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.
>
>> 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?
Thanks,
Thomas
^ permalink raw reply [flat|nested] 6+ messages in thread
* [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
2014-02-12 10:41 ` Thomas De Schampheleire
@ 2014-02-12 10:51 ` Thomas Petazzoni
2014-02-12 10:55 ` Thomas De Schampheleire
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Petazzoni @ 2014-02-12 10:51 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [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
2014-02-12 10:51 ` Thomas Petazzoni
@ 2014-02-12 10:55 ` Thomas De Schampheleire
2014-02-12 19:26 ` Peter Korsgaard
0 siblings, 1 reply; 6+ messages in thread
From: Thomas De Schampheleire @ 2014-02-12 10:55 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On Wed, Feb 12, 2014 at 11:51 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> 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.
Yes, agreed, and this is what the patch is proposing.
So I think we're on the same page :)
>
>> >> 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.
Peter, what do you think?
Thanks,
Thomas
^ permalink raw reply [flat|nested] 6+ messages in thread
* [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
2014-02-12 10:55 ` Thomas De Schampheleire
@ 2014-02-12 19:26 ` Peter Korsgaard
0 siblings, 0 replies; 6+ messages in thread
From: Peter Korsgaard @ 2014-02-12 19:26 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:
Hi,
>>> > 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.
> Peter, what do you think?
I don't feel strongly about it, but if changing it to "the linux way"
solves problems, then lets do it.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-02-12 19:26 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-02-11 20:58 [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 De Schampheleire
2014-02-12 8:21 ` Thomas Petazzoni
2014-02-12 10:41 ` Thomas De Schampheleire
2014-02-12 10:51 ` Thomas Petazzoni
2014-02-12 10:55 ` Thomas De Schampheleire
2014-02-12 19:26 ` Peter Korsgaard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox