Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 2/3 v3] linux: kconfig needs host-{flex, bison} to build the configurators
Date: Wed, 15 Aug 2018 14:18:38 +0200	[thread overview]
Message-ID: <20180815141838.0a83993c@windsurf> (raw)
In-Reply-To: <ea46788a-f814-7fc8-b9dd-1ce97a59546c@mind.be>

Hello,

On Wed, 15 Aug 2018 00:50:42 +0200, Arnout Vandecappelle wrote:

>  My position is that we do indeed need our host flex and bison for everything
> installed in target/ (which implies everything installed in staging/), but not
> for things installed in host/. We definitely need it for BR2_REPRODUCIBLE.
> 
>  It would also be nice if dependencies.sh could do a version check and accept
> the system flex/bison if it is the right version, like we do for cmake and tar.
> 
>  But both of these wishes make things more complicated, so I'm OK with just
> keeping all current host-flex/bison dependencies.

In fact, I think adding flex and bison as mandatory dependencies of the
system is going to cause too much disruption. All the autobuilders
would start complaining, all the Travis/Gitlab CI setups would have to
be adjusted, and everyone building in containers/minimal environments
will be affected.

So instead, I'd like to detect if flex/bison are available on the
system. If they are available, then we use them for the Linux kernel
configuration process. If they are not available, we build them.

Instead of:

  LINUX_KCONFIG_DEPENDENCIES = host-bison host-flex

I'd prefer to see:

  LINUX_KCONFIG_DEPENDENCIES = $(BR2_FLEX_HOST_DEPENDENCY) $(BR2_BISON_HOST_DEPENDENCY)

And the usual logic in support/dependencies/ to check for bison/flex.
This will avoid disrupting all existing setups, and still provide the
speed-up that we don't need to build flex/bison when doing "make
linux-menuconfig".

> > For the linux kernel and other kconfig-based packages, we don't care
> > which flex/bison are used, because the resulting binaries are not
> > installed, unless those packages also generate code eventually installed
> > in host/, staging/ or target/  
> 
>  Note that this means you'll still need host-flex/bison for the kernel, because
> the kernel may build dtc and that gets installed in host...

Are you sure flex/bison are used when building the DTC copy in the
Linux kernel ? Indeed we only added host-bison/host-flex as
dependencies of linux in commit
1b9faedf32be26d9c983c573ccd98f57fc6f6569, when kconfig stopped shipping
its pre-generated files. How could DTC be built before
1b9faedf32be26d9c983c573ccd98f57fc6f6569 if it required bison/flex ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2018-08-15 12:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-03 20:16 [Buildroot] [PATCH 0/3 v3] core/pkg-kconfig: ensure we have necessary tools to run configurators Yann E. MORIN
2018-08-03 20:16 ` [Buildroot] [PATCH 1/3 v3] core/pkg-kconfig: allow dependencies before configurators Yann E. MORIN
2018-08-07 10:22   ` Jan Kundrát
2018-08-03 20:16 ` [Buildroot] [PATCH 2/3 v3] linux: kconfig needs host-{flex, bison} to build the configurators Yann E. MORIN
2018-08-07 10:21   ` Jan Kundrát
2018-08-14 14:21   ` Thomas Petazzoni
2018-08-14 15:27     ` Yann E. MORIN
2018-08-14 19:53       ` Thomas Petazzoni
2018-08-14 21:03         ` Yann E. MORIN
2018-08-14 21:12           ` Thomas Petazzoni
2018-08-14 22:50       ` Arnout Vandecappelle
2018-08-15 12:18         ` Thomas Petazzoni [this message]
2018-08-15 16:00           ` Yann E. MORIN
2018-08-16 15:50           ` Arnout Vandecappelle
2018-08-03 20:16 ` [Buildroot] [PATCH 3/3 v3] linux: kconfig needs the toolchain Yann E. MORIN
2018-08-07 10:21   ` Jan Kundrát

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=20180815141838.0a83993c@windsurf \
    --to=thomas.petazzoni@bootlin.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