From: Peter Korsgaard <peter@korsgaard.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v1 0/2] Checking whether a certain CONFIG_* is set
Date: Fri, 21 Aug 2015 22:28:17 +0200 [thread overview]
Message-ID: <877foo75em.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <20150821132227.GA3753@free.fr> (Yann E. MORIN's message of "Fri, 21 Aug 2015 15:22:27 +0200")
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
Hi,
>> > I think the plan I'll be goign with is to add a hidden Kconfig knob that
>> > packages that want to build a kernel module will have to select.
>>
>> Why not just like the kernel-module infrastructure handle it like I
>> proposed? I don't think it is very nice that people have to remember to
>> add the select as well (and chances are they won't notice if they
>> forget).
> Because that would not work for packages in br2-external trees, as I
> already explained.
Are you sure? I didn't try it, but as we only *USE* the variable when
LINUX_KCONFIG_FIXUP_CMDS runs, which is after all the .mk files have
been parsed I think it should work?
> I know you are not using br2-external (and also do not really see the
> point of it), but a lot of people find this to be a really important
> feature. I also suspect some of our (corporate) users did choose
> Buildroot (partly) because of br2-external.
It's true that I don't personally use br2-external and don't find it
such a killer feature, I *DO* acknowledge that some people do (which is
why I merged the support for it in the first place) and will try to keep
it working as good as possible. With that said, we have a lot of other
requirements for Buildroot (like keeping it simple), so will not bend
over backwards to improve br2-external support if it means making big
compromises elsewhere.
br2-external stuff will always been more limited than normal packages in
the tree.
>> Like Thomas says, we are already doing the 2nd option and I think it
>> makes sense to keep on doing so - So I don't think there's a common need
>> for the first.
> Still, we are currently not allowing another package to set kernel
> options _from_ that package's .mk file. All we have is the kernel
> (de)activating options based on the presence of other packages, and that
> excludes packages from br2-external. Unless Buildroot is modified
> accordingly (but then br2-external looses its attractiveness for that
> package).
Ok, but if all of these use the kernel-module infrastructure (which
linux.mk knows about), then this should work for CONFIG_MODULES, right?
It naturally cannot work for random other config settings.
--
Venlig hilsen,
Peter Korsgaard
next prev parent reply other threads:[~2015-08-21 20:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-17 16:50 [Buildroot] xtables-addons does not build for arm kernel 4.1.4 Jan Viktorin
2015-08-17 21:52 ` Peter Korsgaard
2015-08-17 22:35 ` Jan Viktorin
2015-08-19 13:14 ` [Buildroot] [PATCH v1 0/2] Checking whether a certain CONFIG_* is set Jan Viktorin
2015-08-19 13:14 ` [Buildroot] [PATCH v1 1/2] pkg-utils: Define KCONFIG_ASSERT_OPT macro Jan Viktorin
2015-08-19 19:16 ` Yann E. MORIN
2015-08-19 13:14 ` [Buildroot] [PATCH v1 2/2] xtables-addons: test CONFIG_MODULES=y in the kernel Jan Viktorin
2015-08-19 17:46 ` [Buildroot] [PATCH v1 0/2] Checking whether a certain CONFIG_* is set Thomas Petazzoni
2015-08-19 19:05 ` Yann E. MORIN
2015-08-19 19:08 ` Thomas Petazzoni
2015-08-19 19:21 ` Yann E. MORIN
2015-08-19 20:23 ` Thomas Petazzoni
2015-08-19 21:05 ` Peter Korsgaard
2015-08-21 13:22 ` Yann E. MORIN
2015-08-21 13:41 ` Jeremy Rosen
2015-08-21 20:28 ` Peter Korsgaard [this message]
2015-08-21 21:05 ` Yann E. MORIN
2015-08-21 22:17 ` Peter Korsgaard
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=877foo75em.fsf@dell.be.48ers.dk \
--to=peter@korsgaard.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 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.