All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: menuconfig task for kernels
Date: Mon, 9 Nov 2009 17:10:20 +0100	[thread overview]
Message-ID: <20091109161020.GE17505@jama> (raw)
In-Reply-To: <4AF837F4.1050501@cbnco.com>

On Mon, Nov 09, 2009 at 10:40:36AM -0500, Michael Smith wrote:
> Przemyslaw Wesolek wrote:
> >>Is this the "right" way to do? If so, maybe menuconfig should be added
> >>as 'after do_configure', instead of 'after do_patch'?
> >
> >Anyone?
> 
> Hi Przemek,
> 
> I find if I'm configuring for a new machine, I need to do_patch,
> copy a "close" defconfig into place, run make menuconfig, and copy
> the .config back to the filesdir where it belongs. The menuconfig
> task doesn't save much, as you still have to copy the defconfigs
> around. I don't use the task for that reason, and maybe others are
> in the same boat.
> 
> I think you're right about the order, though; if you sent a patch, I
> would ack it, for what it's worth.
> 
> Mike
Hi,

From what I checked now in linux.inc, then you're right that
do_menuconfig is called just after do_patch, which seems wrong, because
in do_configure_prepend it prepares few lines to .config (like logo,
*abi, thumb) and then appends defconfig without conflicting lines.

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

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}.

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

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 :))

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?.

Regards,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         



  reply	other threads:[~2009-11-09 16:44 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 [this message]
2009-11-10 13:14       ` Przemyslaw Wesolek
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=20091109161020.GE17505@jama \
    --to=martin.jansa@gmail.com \
    --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.