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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.