From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v3 3/3] dpdk: new package
Date: Fri, 25 Mar 2016 14:17:42 +0100 [thread overview]
Message-ID: <20160325141742.2961edf4@free-electrons.com> (raw)
In-Reply-To: <20160325133240.38684e8b@jvn>
Hello Jan,
On Fri, 25 Mar 2016 13:32:40 +0100, Jan Viktorin wrote:
> > config BR2_PACKAGE_DPDK_ARCH_SUPPORTS
> > bool
> > default y if ...
>
> So, should I move here also the HAS_SYNC checks?
Yes, correct. Even though the HAS_SYNC dependencies are not
completely/only architecture related, we handle them as such, so it
makes sense to have them in the foo_ARCH_SUPPORTS variable.
> > comment "dpdk needs a toolchain w/ glibc"
> > depends on !BR2_TOOLCHAIN_USES_GLIBC
> > depends on BR2_TOOLCHAIN_HAS_SYNC_...
>
> The conditiion must be "if all dependencies but BR2_TOOLCHAIN_USES_GLIBC
> are met", is it right? So, should I put here the HAS_SYNC_*,
> ARCH_SUPPORTS, BR2_LINUX_KERNEL and BR2_LINUX_NEEDS_MODULES?
I think you could do like the on2-8170-libs package, and have a single
comment:
comment "dpdk needs a glibc toolchain and a Linux kernel to be built"
depends on BR2_PACKAGE_DPDK_ARCH_SUPPORTS
depends on !BR2_LINUX_KERNEL || !BR2_TOOLCHAIN_USES_GLIBC
The idea is that the comment should not be visible if we are on an
architecture that anyway does not support DPDK. Otherwise someone say
on MIPS will see the comment, enable glibc and Linux kernel, and then
will see the comment disappear but not the option to enable dpdk
appearing. Which would be confusing, to say the least.
> My current state is:
>
> config BR2_PACKAGE_DPDK
> depends on BR2_PACKAGE_DPDK_ARCH_SUPPORTS
> depends on BR2_TOOLCHAIN_USES_GLIBC
depends on BR2_LINUX_KERNEL
> depends on BR2_LINUX_NEEDS_MODULES
This should be a select
> depends on BR2_TOOLCHAIN_HAS_SYNC_1 &&\
> BR2_TOOLCHAIN_HAS_SYNC_2 &&\
> BR2_TOOLCHAIN_HAS_SYNC_4 &&\
> BR2_TOOLCHAIN_HAS_SYNC_8
This should go in the BR2_PACKAGE_DPDK_ARCH_SUPPORTS
> config BR2_PACKAGE_DPDK_ARCH_SUPPORTS
> bool
> default y if (BR2_i386 && !BR2_x86_i386 && !BR2_x86_i486 \
> && !BR2_x86_i586 && !BR2_x86_x1000) \
> || BR2_ARM_CPU_ARMV7A || BR2_aarch64 || BR2_aarch64_be
This can be written in a much more readable way as:
default y if BR2_i386 && !BR2_x86... && !BR2_...
default y if BR2_ARM_CPU_ARMV7A
default y if BR2_aarch64
...
> comment "dpdk needs a toolchain w/ glibc"
> depends on !BR2_TOOLCHAIN_USES_GLIBC
> depends on ??
>
> comment "dpdk needs the Linux kernel to be built"
> depends on !BR2_LINUX_KERNEL
> depends on ??
As said above, only one comment is needed. So here is a proposal:
config BR2_PACKAGE_DPDK_ARCH_SUPPORTS
bool
depends on BR2_TOOLCHAIN_HAS_SYNC_1 && \
BR2_TOOLCHAIN_HAS_SYNC_2 && \
BR2_TOOLCHAIN_HAS_SYNC_4 && \
BR2_TOOLCHAIN_HAS_SYNC_8
default y if BR2_i386 && !BR2_x86_i386 && !BR2_x86_i486 \
&& !BR2_x86_i586 && !BR2_x86_x1000
default y if BR2_ARM_CPU_ARMV7A
default y if BR2_aarch64 || BR2_aarch64_be
config BR2_PACKAGE_DPDK
bool "dpdk"
depends on BR2_PACKAGE_DPDK_ARCH_SUPPORTS
depends on BR2_TOOLCHAIN_USES_GLIBC
depends on BR2_LINUX_KERNEL
select BR2_LINUX_KERNEL_NEEDS_MODULES
help
Blabla
comment "dpdk needs a glibc toolchain and a Linux kernel to be built"
depends on BR2_PACKAGE_DPDK_ARCH_SUPPORTS
depends on !BR2_TOOLCHAIN_USES_GLIBC || !BR2_LINUX_KERNEL
Hope this helps,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2016-03-25 13:17 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-22 10:36 [Buildroot] [PATCH v3 0/3] dpdk: new package Jan Viktorin
2016-03-22 10:36 ` [Buildroot] [PATCH v3 1/3] python-ptyprocess: " Jan Viktorin
2016-03-22 11:02 ` Yegor Yefremov
2016-03-22 10:36 ` [Buildroot] [PATCH v3 2/3] python-pexpect: " Jan Viktorin
2016-03-22 11:06 ` Yegor Yefremov
2016-03-22 10:36 ` [Buildroot] [PATCH v3 3/3] dpdk: " Jan Viktorin
2016-03-22 20:12 ` Thomas Petazzoni
2016-03-23 12:50 ` Jan Viktorin
2016-03-25 12:32 ` Jan Viktorin
2016-03-25 13:17 ` Thomas Petazzoni [this message]
2016-03-27 1:31 ` [Buildroot] [PATCH v4 0/3] " Jan Viktorin
2016-03-27 1:31 ` [Buildroot] [PATCH v4 1/3] python-ptyprocess: " Jan Viktorin
2016-03-27 1:51 ` Jan Viktorin
2016-04-15 20:47 ` Thomas Petazzoni
2016-03-27 1:31 ` [Buildroot] [PATCH v4 2/3] python-pexpect: " Jan Viktorin
2016-03-27 1:50 ` Jan Viktorin
2016-03-27 20:51 ` Yegor Yefremov
2016-04-15 20:49 ` Thomas Petazzoni
2016-03-27 1:31 ` [Buildroot] [PATCH v4 3/3] dpdk: " Jan Viktorin
2016-03-27 1:48 ` Jan Viktorin
2016-04-15 21:52 ` Thomas Petazzoni
2016-04-16 0:07 ` Jan Viktorin
2016-04-16 7:31 ` Thomas Petazzoni
2016-04-16 17:08 ` [Buildroot] [PATCH v5] " Jan Viktorin
2016-04-17 14:38 ` Thomas Petazzoni
2016-04-17 15:56 ` Jan Viktorin
2016-04-17 19:35 ` Thomas Petazzoni
2016-04-17 20:56 ` Jan Viktorin
2016-04-17 21:06 ` Thomas Petazzoni
2016-04-18 8:23 ` Jan Viktorin
2016-04-18 22:50 ` Arnout Vandecappelle
2016-04-19 12:27 ` Jan Viktorin
2016-04-19 19:30 ` Arnout Vandecappelle
2016-04-19 20:47 ` Thomas Petazzoni
2016-04-19 21:41 ` Jan Viktorin
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=20160325141742.2961edf4@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