From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v3] package/iqvlinux: new package
Date: Mon, 12 Oct 2015 23:24:41 +0200 [thread overview]
Message-ID: <20151012232441.3322b2fa@free-electrons.com> (raw)
In-Reply-To: <20151012211618.GG3735@free.fr>
Dear Yann E. MORIN,
On Mon, 12 Oct 2015 23:16:18 +0200, Yann E. MORIN wrote:
> > I agree on the principle, but I think we should rather handle that like
> > we do for other options: enable automatically the needed option.
>
> Except for PCI it does not really makes sense, see Arnout's explanations:
> http://lists.busybox.net/pipermail/buildroot/2015-October/141178.html
Except that I disagree with Arnout :)
Arnout is not making the difference between being able to *build* and
being able to *run*.
CONFIG_PCI is needed for the build to proceed, so it is normal that we
enable it automatically. The PCI root complex drivers are only needed
for the PCI support to actually work on the target, not for iqvlinux to
build.
And the story is the same for xtable-addons: the additions in linux.mk
were made because those kernel options were needed for xtable-addons to
simply *build*.
> > Remember how someone proposed to check for CONFIG_MODULES=y and error
> > out if not available? Instead, you implemented
> > b7c32c98bc810b88e0391117f225658f82b44995.
>
> Meh... ;-)
No, your commit is good I believe.
> I'm not totally oposed to this idea.
>
> However, there are cases, like PCI, for which it does not make sense to
> just enable it (as Arnout explained).
See above :)
> Unless we don't care about runtime consistency, and just care about the
> buildability of the configuration...
>
> However, I like doing such little tiny bit of infra, so I can append that
> to my todo-list. What do you prefer: setting the option (like for
> modules), or checking the option?
Setting the option, when it is needed to build the external modules.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2015-10-12 21:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-09 13:26 [Buildroot] [PATCH v3] package/iqvlinux: new package Romain Naour
2015-10-10 15:04 ` Yann E. MORIN
2015-10-12 20:44 ` Thomas Petazzoni
2015-10-12 21:16 ` Yann E. MORIN
2015-10-12 21:24 ` Thomas Petazzoni [this message]
2015-10-13 7:03 ` Arnout Vandecappelle
2015-10-15 19:39 ` Peter Korsgaard
2015-10-12 21:16 ` Thomas Petazzoni
2015-10-12 21:24 ` Yann E. MORIN
2015-10-12 21:17 ` Thomas Petazzoni
2015-10-13 9:00 ` Romain Naour
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=20151012232441.3322b2fa@free-electrons.com \
--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