From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Kernel build process
Date: Wed, 30 Jun 2010 18:58:24 +0200 [thread overview]
Message-ID: <20100630185824.095c6ad0@surf> (raw)
In-Reply-To: <002401cb1843$dc1e2670$945a7350$@pauljones.id.au>
Hello,
On Wed, 30 Jun 2010 21:03:22 +1000
"Paul Jones" <paul@pauljones.id.au> wrote:
> Just some comments about the new kernel cleanup code. If a kernel
> config is not supplied, the default action is to stop with a rather
> cryptic error.
Hum true.
> This doesn't seem like a good idea to me, especially when the
> previous behaviour was to just create a default .config and continue.
> I can see a lot of beginners getting caught out with that one.
>
> What I would like to suggest is this:
>
> 1) Change the default Kernel Configuration to "Using a custom
> config file" (is currently set to use a defconfig)
Ok, why not.
> 2) Leave "Configuration file path" blank as default
Yes.
>
> 3) Add code to ignore copying config file if "Configuration file
> path" is still blank and just continue compiling the kernel with the
> default options.
>
> That way it should be obvious to any beginners what the options do,
> and if they are not set (ie left as default) the build will still be
> able to continue.
I'm not sure about this last part, though. What kind of "default
options" will the kernel select ? Just a random set of options for the
architecture selected ? Yes for x86 this will do something more or less
sensible, but for other embedded architectures such as ARM, there's no
such thing as a "default set of options that makes sense".
So I'd prefer to detect the fact that the configuration file path
option has been left empty, and abort the build by showing an explicit
and clear error message about this.
Same could be done for the defconfig option.
What do you think ?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2010-06-30 16:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-30 11:03 [Buildroot] Kernel build process Paul Jones
2010-06-30 16:58 ` Thomas Petazzoni [this message]
2010-06-30 22:22 ` Paul Jones
2010-07-01 6:45 ` Thomas Petazzoni
2010-07-01 7:01 ` Paul Jones
2010-06-30 17:04 ` Thiago A. Corrêa
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=20100630185824.095c6ad0@surf \
--to=thomas.petazzoni@free-electrons.com \
--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