From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Petazzoni Date: Tue, 31 Jul 2018 10:06:46 +0200 Subject: [Buildroot] [RFC] [PATCH v2 2/2] support/kconfig: Bump to kconfig from Linux 4.17-rc2 In-Reply-To: <9ec69586-1154-f4e3-2fff-4f831263eef0@mind.be> References: <20180509164412.31596-1-petr.vorel@gmail.com> <20180509164412.31596-2-petr.vorel@gmail.com> <20180519230311.6a3652fd@windsurf> <20180520142311.GA3453@scaer> <20180520143139.GA14607@x230> <20180520144141.GB3453@scaer> <20180520165009.56b44d9b@windsurf> <20180528203743.GK2965@scaer> <67a166b0-1466-8bd9-86be-3a8f3d7a4079@mind.be> <20180730150433.704e57ef@windsurf> <9ec69586-1154-f4e3-2fff-4f831263eef0@mind.be> Message-ID: <20180731100646.3221056f@windsurf> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net Hello, On Tue, 31 Jul 2018 09:55:42 +0200, Arnout Vandecappelle wrote: > >>> We're only talking about dropping the need for host-flex and host-bison > >>> for the kconfig stuff. In this case, we don;t care that the user > >>> generates C code one way or another: it's only a host tool... > >> > >> I was replying to Thomas's "we should remove host-flex and host-bison > >> entirely". Yes we can rely on system-installed flex and bison for kconfig, but > >> we can't rely on that for target packages, e.g. target dtc. > > > > Why so ? > > Reproducibility. I tested this for something (I think it was flex, but as usual > I don't remember exactly), and the code generated by my system's flex was wildly > different from what was generated by Buildroot's host-flex, even though the > versions were pretty close. Unfortunately, I don't remember exactly, but that > was my concern. True, but then if we have this reproducibility issue, it also applies to building the kconfig code, no ? Or do you assume that because kconfig is so widely used, it is tested against lots of bison/flex version, so we don't need to build bison/flex for kconfig, but we should still build it for other packages that need bison/flex, as those ones may be less tested against random versions of flex/bison ? Or because the generated flex/bison code goes into the target, and we ideally want binary-identical results for a given Buildroot configuration ? Best regards, Thomas -- Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com