From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] ipsec-tools: needs host-bison
Date: Thu, 20 Sep 2018 08:45:22 +0200 [thread overview]
Message-ID: <20180920084522.1dea57e8@windsurf> (raw)
In-Reply-To: <87o9ctp5if.fsf@dell.be.48ers.dk>
Hello Peter,
On Wed, 19 Sep 2018 23:00:08 +0200, Peter Korsgaard wrote:
> > diff --git a/package/ipsec-tools/ipsec-tools.mk b/package/ipsec-tools/ipsec-tools.mk
> > index ddae9a75f3..8672272538 100644
> > --- a/package/ipsec-tools/ipsec-tools.mk
> > +++ b/package/ipsec-tools/ipsec-tools.mk
> > @@ -9,7 +9,7 @@ IPSEC_TOOLS_SOURCE = ipsec-tools-$(IPSEC_TOOLS_VERSION).tar.bz2
> > IPSEC_TOOLS_SITE = http://sourceforge.net/projects/ipsec-tools/files/ipsec-tools/$(IPSEC_TOOLS_VERSION)
> > IPSEC_TOOLS_INSTALL_STAGING = YES
> > IPSEC_TOOLS_MAKE = $(MAKE1)
> > -IPSEC_TOOLS_DEPENDENCIES = openssl flex host-flex
> > +IPSEC_TOOLS_DEPENDENCIES = openssl flex host-flex host-bison
>
> Hmm, shouldn't this use BR2_BISON_HOST_DEPENDENCY /
> BR2_FLEX_HOST_DEPENDENCY instead?
No, that's not what we have agreed so far. Our idea was that
BR2_BISON_HOST_DEPENDENCY and BR2_FLEX_HOST_DEPENDENCY would be used
only for the kconfig stuff in the kernel/u-boot and al, but that we
would keep using our own host-flex/host-bison for the rest, and
especially for target packages.
There are two reasons to that:
(1) We can be pretty confident that the flex/bison stuff in kconfig
will have been tested/exercised against a wide variety of
flex/bison versions, so using whatever flex/bison version
available on the host system is good enough. However, for the rest
of the packages that use flex/bison, we can't be so sure, so
having our own flex/bison version allows us to be sure that things
"will work".
(2) For target packages, using the system-provided flex/bison version
means that the generated code can be subtly different between
flex/bison versions, which makes the build non-reproducible. Hence,
it is important to have our own fixed version of flex/bison. For
host packages, that is probably less of a concern, but point (1)
remains valid.
Do we still agree on this position, or do you have
counter-arguments ? :-)
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2018-09-20 6:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-15 9:59 [Buildroot] [PATCH 1/1] ipsec-tools: needs host-bison Fabrice Fontaine
2018-09-16 13:44 ` Thomas Petazzoni
2018-09-19 21:00 ` Peter Korsgaard
2018-09-20 6:45 ` Thomas Petazzoni [this message]
2018-09-20 6:57 ` Peter Korsgaard
2018-09-20 14:56 ` Yann E. MORIN
2018-10-01 21:44 ` 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=20180920084522.1dea57e8@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