From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1 of 5 RFC] uclibc: menuconfig: take into account initial settings from config file
Date: Tue, 01 Jul 2014 08:09:45 +0200 [thread overview]
Message-ID: <53B250A9.9000707@mind.be> (raw)
In-Reply-To: <CAAXf6LVkiOswF-Hb=QGLH7rrNyX4S+bH1dU1rde+HWomn-dL8Q@mail.gmail.com>
On 30/06/14 21:31, Thomas De Schampheleire wrote:
> Hi Arnout, all,
>
> On Wed, Jun 25, 2014 at 8:16 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
[snip]
>> In order to cover all requirements, I think we should rely on real dependencies
>> here. Something like:
>>
>> uclibc-menuconfig: $(UCLIBC_DIR)/.config
>> $(MAKE1) -C $(UCLIBC_DIR) ...
>> $(UCLIBC_FIXUP_DOT_CONFIG)
>>
>> $(UCLIBC_DIR)/.config: $(UCLIBC_CONFIG_FILE) uclibc-patch
>> $(INSTALL) -m 0644 $(UCLIBC_CONFIG_FILE) $(@)
>> $(MAKE1) -C $(UCLIBC_DIR) ... oldconfig
>> $(UCLIBC_FIXUP_DOT_CONFIG)
>>
>> uclibc-configure: $(UCLIBC_DIR)/.config
>>
>>
>> (I renamed SETUP_DOT_CONFIG to FIXUP_DOT_CONFIG which I think is more accurate.)
>>
>>
>> This is obviously just a skeleton, but you can see where I'm going... The
>> important thing is:
>>
>> - all config targets depend on .config
>> - .config depends on the the CONFIG_FILE
>> - all config targets and .config itself call to FIXUP_DOT_CONFIG
>>
>
> FYI, my plan for this patch series is to first fix all issues for
> uclibc, then extract that to a kconfig-package, then convert busybox,
> barebox, linux to this kconfig-package, one by one.
>
> With respect to the skeleton above: you moved the FIXUP_DOT_CONFIG to
> the .config and menuconfig target. If a user manually edits .config
> (or copies over a new file) then these fixups will not be applied. I
> think they should be applied nevertheless, so moving the fixup to the
> configure command and letting configure depend on .config makes more
> sense to me.
>
> Would you agree?
I don't really agree that we should care about a user manually overwriting
.config (so _not_ using a 'make xxxconfig'. However, if we can support that, so
much the better of course.
Moving the fixup to the configure step has the disadvantage that there is a
difference between:
make clean; make uclibc-menuconfig; make uclibc-update-defconfig
and
make clean; make uclibc-menuconfig; make; make uclibc-update-defconfig
(the first case will not have the fixups applied, the second case does).
Also, with 'make clean; make uclibc-menuconfig' you'll won't see the result of
the fixups in your menuconfig, which is pretty strange. Especially for e.g.
linux-menuconfig, because 'make clean; make linux-menuconfig' would give you the
config options for i386 instead of your target...
That said, it doesn't hurt to just put the fixups everywhere: in the .config
target, in the -menuconfig target, and in the PRE_CONFIGURE_HOOKS.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
next prev parent reply other threads:[~2014-07-01 6:09 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-22 13:45 [Buildroot] [PATCH 0 of 5 RFC] uclibc/busybox: fix handling of configuration file Thomas De Schampheleire
2014-06-22 13:45 ` [Buildroot] [PATCH 1 of 5 RFC] uclibc: menuconfig: take into account initial settings from config file Thomas De Schampheleire
2014-06-22 14:05 ` Yann E. MORIN
2014-06-22 16:52 ` Thomas Petazzoni
2014-06-22 17:23 ` Thomas De Schampheleire
2014-06-22 17:29 ` Danomi Manchego
2014-06-22 18:52 ` Thomas De Schampheleire
2014-06-22 19:07 ` Danomi Manchego
2014-06-24 18:35 ` Thomas De Schampheleire
2014-06-25 6:16 ` Arnout Vandecappelle
2014-06-30 19:31 ` Thomas De Schampheleire
2014-07-01 6:09 ` Arnout Vandecappelle [this message]
2014-07-01 8:35 ` Thomas De Schampheleire
2014-06-22 13:45 ` [Buildroot] [PATCH 2 of 5 RFC] uclibc: update-config: preserve freshly configured settings Thomas De Schampheleire
2014-06-22 14:07 ` Yann E. MORIN
2014-06-22 13:45 ` [Buildroot] [PATCH 3 of 5 RFC] busybox: fix typo overwritting Thomas De Schampheleire
2014-06-22 13:57 ` Yann E. MORIN
2014-06-22 13:45 ` [Buildroot] [PATCH 4 of 5 RFC] busybox: menuconfig: take into account initial settings from config file Thomas De Schampheleire
2014-06-22 14:10 ` Yann E. MORIN
2014-06-22 13:45 ` [Buildroot] [PATCH 5 of 5 RFC] busybox: update-config: preserve freshly configured settings Thomas De Schampheleire
2014-06-22 14:14 ` Yann E. MORIN
2014-06-22 14:22 ` Thomas De Schampheleire
2014-06-22 14:46 ` Yann E. MORIN
2014-06-25 6:06 ` [Buildroot] [PATCH 0 of 5 RFC] uclibc/busybox: fix handling of configuration file Arnout Vandecappelle
2014-06-25 19:24 ` Thomas De Schampheleire
2014-06-29 8:13 ` Thomas De Schampheleire
2014-06-29 8:20 ` Thomas Petazzoni
2014-06-29 10:05 ` Arnout Vandecappelle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53B250A9.9000707@mind.be \
--to=arnout@mind.be \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox