All of lore.kernel.org
 help / color / mirror / Atom feed
From: Przemyslaw Wesolek <przemyslaw.wesolek@cs.put.poznan.pl>
To: openembedded-devel@lists.openembedded.org
Subject: Re: menuconfig task for kernels
Date: Tue, 10 Nov 2009 14:14:07 +0100	[thread overview]
Message-ID: <4AF9671F.8040303@cs.put.poznan.pl> (raw)
In-Reply-To: <20091109161020.GE17505@jama>

Martin Jansa wrote:
> If I need to enable some options temporary then I use
> -c configure (for sane .config)
> -c menuconfig (for temporary modification)
> -c build 

This is exactly what I want to do, as a *user*.

> But if you want to use menuconfig for updating defconfig used in OE tree
> or default config in kernel (like arch/arm/configs/gta02_defconfig) then
> do_configure phase would change some options you didn't want to touch
> (as they can be OE specific, ie disabling deprecated sysfs paths for
> ${UDEV_GE_141}.

This is what -- I guess -- recipes *maintainers* do.

> 
> So 1st case is easily workarounded by user in current state.
> 

Agreed, with the exception that this is a path hard to find, without
looking into the recipes and classes. And this is not what all *users*
are competent to do.

> 2nd will be a bit more difficult if its moved to after do_configure
> as you need to revert all changes automagically introduced in 
> do_configure_prepend in menuconfig or replace .config with defconfig
> between do_configure and do_menuconfig or just use load ../defconfig
> option from menuconfig. (Hmm doesn't look more difficult now :))

I think of two possible solutions:

1. Add another task, which will do the same as 'menuconfig' now, and
change 'menuconfig' to run after 'configure'. This way, users can work
under assumptions of "least surprise" (in my terms, I agree, but I'm a
mere user, too).

2. Change 'configure' to operate on existing .config, if there is one;
this way 'menuconfig' and 'configure' can cooperate, although resulting
.config can have contradicting options selected and lead to errors (but
maybe 'make oldconfig' can point them out?).

I opt for 1., as 2. seems hard and risky.

> Btw: haven't checked but if you use
> -c menuconfig (create custom config)
> -c build
> 
> isn't your custom .config rewritten in do_configure phase with defconfig
> + do_configure_prepend automagic?.

Yes, it is overwritten with 'echo "" >path/to/.config' at the beginning
of do_configure.

Przemek




  reply	other threads:[~2009-11-10 13:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-05 22:38 menuconfig task for kernels Przemyslaw Wesolek
2009-11-08 22:37 ` Przemyslaw Wesolek
2009-11-09 15:40   ` Michael Smith
2009-11-09 16:10     ` Martin Jansa
2009-11-10 13:14       ` Przemyslaw Wesolek [this message]
2009-11-10 16:06 ` Leon Woestenberg
2009-11-10 17:05   ` Otavio Salvador
2009-11-12 15:15     ` Leon Woestenberg
2009-11-12 19:29       ` Przemyslaw Wesolek

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=4AF9671F.8040303@cs.put.poznan.pl \
    --to=przemyslaw.wesolek@cs.put.poznan.pl \
    --cc=openembedded-devel@lists.openembedded.org \
    /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.