All of 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 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.