support/kconfig: Add missing target to README.buildroot

This kernel commit required to rename target in Makefile:
911a91c39cab kconfig: rename silentoldconfig to syncconfig

Differences from upstrem (kernel):
* Tests are not included. IMHO we don't need them.
* kernel added new tool requirement: flex & bison, added in commit 29c833061c1d kconfig: generate lexer and parser during build instead of shipping but atm we still use generated files (zconf.lex.c_shipped and zconf.tab.c_shipped).

User visible changes (incomplete list):
* make "Selected by:" and "Implied by:" readable:
d9119b5925a0 kconfig: Print reverse dependencies in groups 9a47ceec543b kconfig: clean-up reverse dependency help implementation 1ccb27143360 kconfig: make "Selected by:" and "Implied by:" readable

Old version of help:
Symbol: BR2_ARCH_HAS_MMU_MANDATORY [=y]
Type : boolean
Defined at arch/Config.in:12
Selected by: BR2_arcle [=n] && <choice> || BR2_arceb [=n] && <choice> || BR2_aarch64 [=n] && <choice> || BR2_aarch64_be [=n] && <choice> || BR2_csky [=n] && <choice> ...

New version of help:
Symbol: BR2_ARCH_HAS_MMU_MANDATORY [=y]
Type : bool
Defined at arch/Config.in:12
Selected by [y]:
- BR2_x86_64 [=y] && <choice>
Selected by [n]:
- BR2_arcle [=n] && <choice>
- BR2_arceb [=n] && <choice>
- BR2_aarch64 [=n] && <choice>
- BR2_aarch64_be [=n] && <choice>

* 2c37e08464a8 kconfig: Warn if choice default is not in choice toolchain/toolchain-buildroot/Config.in:25:warning: choice default symbol 'BR2_TOOLCHAIN_UCLIBC' is not contained in the choice package/libmediaart/Config.in:21:warning: choice default symbol 'BR2_PACKAGE_LIBMEDIAART_BACKEND_NONE' is not contained in the choice
NOTE: fixes for these errors has already been posted to ML.

Signed-off-by Petr Vorel <[email protected]>

Changes v1->v2:
* Fix building packages (v1 didn't address change in kernel 911a91c39cab kconfig: rename silentoldconfig to syncconfig)

NOTE: I think I should stop using *shipped files (zconf.hash.c_shipped and zconf.lex.c_shipped), to have the same behavior as kernel. What do you think?

Hello Petr,

Thanks for looking at the kconfig code update.

I tested this here, but unfortunately "make menuconfig" fails, because it wants <glade/glade.h>, which it shouldn't need as I don't want the Gtk-based gconfig. Here is what happens:

thomas at windsurf:~/projets/buildroot (next)$ make menuconfig
mkdir -p /home/thomas/projets/buildroot/output/build/buildroot-config/lxdialog PKG_CONFIG_PATH="" make CC="/usr/bin/gcc" HOSTCC="/usr/bin/gcc" \
obj=/home/thomas/projets/buildroot/output/build/buildroot-config -C support/kconfig -f Makefile.br mconf

/usr/bin/gcc -D_GNU_SOURCE -D_DEFAULT_SOURCE  -DCURSES_LOC="<ncurses.h>" -DNCURSES_WIDECHAR=1 -DLOCALE  -I/home/thomas/projets/buildroot/output/build/buildroot-config -DCONFIG_=\"\"  -MM *.c > /home/thomas/projets/buildroot/output/build/buildroot-config/.depend 2>/dev/null || :
/usr/bin/gcc -D_GNU_SOURCE -D_DEFAULT_SOURCE  -DCURSES_LOC="<ncurses.h>" -DNCURSES_WIDECHAR=1 -DLOCALE  -I/home/thomas/projets/buildroot/output/build/buildroot-config -DCONFIG_=\"\"   -c conf.c -o /home/thomas/projets/buildroot/output/build/buildroot-config/conf.o
/usr/bin/gcc -D_GNU_SOURCE -D_DEFAULT_SOURCE  -DCURSES_LOC="<ncurses.h>" -DNCURSES_WIDECHAR=1 -DLOCALE  -I/home/thomas/projets/buildroot/output/build/buildroot-config -DCONFIG_=\"\"  `pkg-config --cflags gtk+-2.0 gmodule-2.0 libglade-2.0` -Wno-missing-prototypes -c gconf.c -o /home/thomas/projets/buildroot/output/build/buildroot-config/gconf.o

Package libglade-2.0 was not found in the pkg-config search path. Perhaps you should add the directory containing `libglade-2.0.pc' to the PKG_CONFIG_PATH environment variable
Package 'libglade-2.0', required by 'virtual:world', not found gconf.c:17:10: fatal error: glade/glade.h: No such file or directory

 #include <glade/glade.h>
          ^~~~~~~~~~~~~~~

compilation terminated.
make[2]: *** [Makefile.br:34: /home/thomas/projets/buildroot/output/build/buildroot-config/gconf.o] Error 1 make[1]: *** [Makefile:876: /home/thomas/projets/buildroot/output/build/buildroot-config/mconf] Error 2
make: *** [Makefile:79: _all] Error 2

I did not investigate at all, just observed that it didn't work.

Quoted 7 lines

Changes v1->v2:
* Fix building packages (v1 didn't address change in kernel 911a91c39cab kconfig: rename silentoldconfig to syncconfig)

NOTE: I think I should stop using *shipped files (zconf.hash.c_shipped and zconf.lex.c_shipped), to have the same behavior as kernel. What do you think?

If we were to drop the *shipped files, it means we would have to build host-flex and host-bison prior to running any "make *config" command. This would be really annoying. Alternatively, we could decide to make "flex" and "bison" mandatory dependencies of Buildroot, and rely on the user to install them on the system rather than building them ourselves. The drawback of this is that we would no longer control which version of flex/bison gets used.

Best regards,

Thomas

If we were to drop the *shipped files, it means we would have to build host-flex and host-bison prior to running any "make *config" command. This would be really annoying.

Alternatively, we could decide to make
"flex" and "bison" mandatory dependencies of Buildroot, and rely on the user to install them on the system rather than building them ourselves. The drawback of this is that we would no longer control which version of flex/bison gets used.

Best regards,

Thomas

Signature · 3 lines

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

Thomas, All,

On 2018-05-19 23:03 +0200, Thomas Petazzoni spake thusly:

Quoted 3 lines

If we were to drop the *shipped files, it means we would have to build host-flex and host-bison prior to running any "make *config" command. This would be really annoying.

And would requier quite a rework of the main Makefile, since we do not include that pcakge .mk files until we do have a .coinfig file. So currently, we can't have host-{flex,bison} before we have a .config.

Quoted 5 lines

Alternatively, we could decide to make
"flex" and "bison" mandatory dependencies of Buildroot, and rely on the user to install them on the system rather than building them ourselves. The drawback of this is that we would no longer control which version of flex/bison gets used.

Regards,
Yann E. MORIN.

Quoted 8 lines

On 2018-05-19 23:03 +0200, Thomas Petazzoni spake thusly:

Quoted 3 lines

If we were to drop the *shipped files, it means we would have to build host-flex and host-bison prior to running any "make *config" command. This would be really annoying.

And would requier quite a rework of the main Makefile, since we do not include that pcakge .mk files until we do have a .coinfig file. So currently, we can't have host-{flex,bison} before we have a .config.

Thank you for investigation. IMHO keeping *shipped files is the best option, I'd keep it for a start.

Later we can switch to require flex and bison, as Thomas suggested (works quite well in linux kernel, I suppose it'd be working for Buildroot as well):

Quoted 5 lines

Quoted 5 lines

Alternatively, we could decide to make
"flex" and "bison" mandatory dependencies of Buildroot, and rely on the user to install them on the system rather than building them ourselves. The drawback of this is that we would no longer control which version of flex/bison gets used.

I initially did not reply further to this part, becuase I seem to remember that there was a change in behavious with certain versions of flex/bison, that made the output change drastically, and I was afraid we could be bitten by this...

But in the end, this is not a problem, because we would not care to mix-n-match files built with different versions of said tools, as they would be those from the distro, always, and never those we ship, since we would no longer ship them.

And eventually, I now remember that the issue was with gperf changing its API (a function prototype changed), and that was causing pain. But now, kconfig no longer uses gperf to start with, so no incompatibility anymore anyway.

Which would allow us to drop the dependency of linux on host-{flex,bison} that we had to add recently.

Hello,

Quoted 15 lines · Yann E. MORIN

I initially did not reply further to this part, becuase I seem to remember that there was a change in behavious with certain versions of flex/bison, that made the output change drastically, and I was afraid we could be bitten by this...

But in the end, this is not a problem, because we would not care to mix-n-match files built with different versions of said tools, as they would be those from the distro, always, and never those we ship, since we would no longer ship them.

And eventually, I now remember that the issue was with gperf changing its API (a function prototype changed), and that was causing pain. But now, kconfig no longer uses gperf to start with, so no incompatibility anymore anyway.

Quoted 2 lines

Which would allow us to drop the dependency of linux on host-{flex,bison} that we had to add recently.

If we start relying on the system-installed flex and bison, then we should remove host-flex and host-bison entirely, not only for the linux package. The question is whether bison and flex both behave in a reasonably similar way regardless of which version is used.

When I see that even "tar" does not have a sufficiently stable behavior (which forces us to build host-tar), I'm a bit worried about more complex tools such as flex and bison.

Best regards,

Thomas

Quoted 19 lines

Hello,

Quoted 15 lines · Yann E. MORIN

I initially did not reply further to this part, becuase I seem to remember that there was a change in behavious with certain versions of flex/bison, that made the output change drastically, and I was afraid we could be bitten by this...

But in the end, this is not a problem, because we would not care to mix-n-match files built with different versions of said tools, as they would be those from the distro, always, and never those we ship, since we would no longer ship them.

And eventually, I now remember that the issue was with gperf changing its API (a function prototype changed), and that was causing pain. But now, kconfig no longer uses gperf to start with, so no incompatibility anymore anyway.

Quoted 7 lines

Quoted 2 lines

Which would allow us to drop the dependency of linux on host-{flex,bison} that we had to add recently.

If we start relying on the system-installed flex and bison, then we should remove host-flex and host-bison entirely, not only for the linux package. The question is whether bison and flex both behave in a reasonably similar way regardless of which version is used.

I briefly looked at this in Paris, and it became clear very quickly that even a
minor change in the bison version would give a completely different .c file. If this is a source file that will be built for the target, it's going to be a major reproducibility-killer. So I don't think we can remove host-bison and host-flex.

Arnout, Thomas, All,

On 2018-05-22 23:22 +0200, Arnout Vandecappelle spake thusly:

Quoted 1 line · Thomas Petazzoni

Quoted 10 lines

Quoted 4 lines

If we start relying on the system-installed flex and bison, then we should remove host-flex and host-bison entirely, not only for the linux package. The question is whether bison and flex both behave in a reasonably similar way regardless of which version is used.

I briefly looked at this in Paris, and it became clear very quickly that even a
minor change in the bison version would give a completely different .c file. If this is a source file that will be built for the target, it's going to be a major reproducibility-killer. So I don't think we can remove host-bison and host-flex.

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

Quoted 4 lines

Arnout, Thomas, All,

On 2018-05-22 23:22 +0200, Arnout Vandecappelle spake thusly:

Quoted 1 line · Thomas Petazzoni

[snip]

Quoted 11 lines

Quoted 10 lines

Quoted 4 lines

If we start relying on the system-installed flex and bison, then we should remove host-flex and host-bison entirely, not only for the linux package. The question is whether bison and flex both behave in a reasonably similar way regardless of which version is used.

I briefly looked at this in Paris, and it became clear very quickly that even a
minor change in the bison version would give a completely different .c file. If this is a source file that will be built for the target, it's going to be a major reproducibility-killer. So I don't think we can remove host-bison and host-flex.

Quoted 3 lines

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.

Quoted 3 lines

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.

Hello,

Quoted 4 lines · Arnout Vandecappelle

Quoted 3 lines

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

Quoted 3 lines

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 ?

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

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.

Quoted 1 line

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.

Hello,

Quoted 10 lines · Arnout Vandecappelle

Quoted 9 lines

Quoted 7 lines

Quoted 3 lines

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 ?

Quoted 5 lines

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

Quoted 11 lines · Arnout Vandecappelle

Quoted 10 lines

Quoted 9 lines

Quoted 7 lines

Quoted 3 lines

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 ?

Quoted 8 lines

Quoted 5 lines

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 ?

kconfig is a host package, (target) dtc is a target package.

The point of reproducibility is that when someone gives me a core dump four
years from now, I can still rebuild the same source and see what that core dump really means, and I can make a patch that just changes one little thing in there without upgrading the world. Since host packages are not deployed, it's not needed to have the same level of reproducibility for them.

Quoted 7 lines

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 ?

It's not just for fully binary identical (i.e. BR2_REPRODUCIBLE).

It's basically for the same reason that we have versioned docker images, to
make sure that we really know what we're building for the target.

I realize now that this rule is not something we've written down anywhere. I
just always assumed that Buildroot tries to make sure that for a given config, whatever your build machine, you generate binaries that will behave the same and will expose the same bugs. If you use a different flex, a bug in the parsing code will manifest differently.

The more I think about it, the more I come to the conclusion that maybe this
rule (which I thought was something that I learned from the Buildroot community, not something I invented myself) is not so useful. Because in practice, the kind of bugs where this is relevant are so sensitive to even tiny changes that changing the generated code is not going to make all that much of a difference.

Regards,
Arnout

Quoted 5 lines

Best regards,

Thomas

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

On 2018-07-31 10:20 +0200, Arnout Vandecappelle spake thusly:

Quoted 4 lines · Thomas Petazzoni

Quoted 3 lines · Arnout Vandecappelle

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

We're only talking about dropping the need for host-flex and host-bison for the kconfig stuff.

Arnout, Thomas, All,

On 2018-07-31 10:20 +0200, Arnout Vandecappelle spake thusly:

Quoted 21 lines · Thomas Petazzoni

Quoted 11 lines · Arnout Vandecappelle

Quoted 10 lines

Quoted 9 lines

Quoted 7 lines

Quoted 3 lines

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 ?

Quoted 8 lines

Quoted 5 lines

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 ?

Quoted 7 lines

kconfig is a host package, (target) dtc is a target package.

The point of reproducibility is that when someone gives me a core dump four
years from now, I can still rebuild the same source and see what that core dump really means, and I can make a patch that just changes one little thing in there without upgrading the world. Since host packages are not deployed, it's not needed to have the same level of reproducibility for them.

Agreed.

I.e. we don't care about the reproducibility of the host tools that contaon generated code, like flex / bison.

Even if the generated code changes with different versions of flex and/or bison, the _behaviour_ of that generated code is predictable. It night be less or more optimised in size amd/or speed, but the behaviour is predictable. Which is all we care about for host tools, imho.

See how the kconfig code dropped use of gperf, yet still behaves as previously, with different (less) generated code.

But...

Now that we have the 'sdk' feature, people are going to distribute that, and they will have to come in compliance for this sdk. So they will want the build of the host tools to also be as reproducible as possible.

Amd since we now will have to have the toolchain before we can parse the linux kconfig stuff, building host-flex and host-bison is the least of our speed problems...

So, I'd say we should keep the dependency on host-flex and host-bison for the linux kernel...

Regards,
Yann E. MORIN.

Quoted 42 lines

Quoted 7 lines

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 ?

It's not just for fully binary identical (i.e. BR2_REPRODUCIBLE).

It's basically for the same reason that we have versioned docker images, to
make sure that we really know what we're building for the target.

I realize now that this rule is not something we've written down anywhere. I
just always assumed that Buildroot tries to make sure that for a given config, whatever your build machine, you generate binaries that will behave the same and will expose the same bugs. If you use a different flex, a bug in the parsing code will manifest differently.

The more I think about it, the more I come to the conclusion that maybe this
rule (which I thought was something that I learned from the Buildroot community, not something I invented myself) is not so useful. Because in practice, the kind of bugs where this is relevant are so sensitive to even tiny changes that changing the generated code is not going to make all that much of a difference.

Regards,
Arnout

Quoted 5 lines

Best regards,

Thomas

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Quoted 3 lines

Now that we have the 'sdk' feature, people are going to distribute that, and they will have to come in compliance for this sdk. So they will want the build of the host tools to also be as reproducible as possible.

I don't see the reasoning behind this statement. For GPL compliance,
reproducibility is definitely not an issue, otherwise every GPL binary distributed in the last 30 years would be in violation...

Quoted 3 lines

Amd since we now will have to have the toolchain before we can parse the linux kconfig stuff, building host-flex and host-bison is the least of our speed problems...

It is a big speed problem if you're using an external toolchain and you could
use the system flex and bison. This thread (long ago, in a galaxy far away) was about requiring flex and bison to be installed on the system, because Buildroot's own kconfig would also no longer ship the generated files. The general agreement was that that would be OK, and we could remove host-flex and host-bison entirely (speeding up the build for a bunch of other packages).

My statement was (and still is): drop host-flex and host-bison for building
host tools, but keep them for building target binaries (in casu, dtc).

Thomas (if I understand correctly) is questioning the need for keeping
host-flex and host-bison even for building the target binaries. And I have to agree that the need for host-flex and host-bison for target binaries is not that strong.

Quoted 2 lines

So, I'd say we should keep the dependency on host-flex and host-bison for the linux kernel...

I would really prefer to not double the build time of a simple kernel...

Regards,
Arnout

Quoted 47 lines

Regards,
Yann E. MORIN.

Quoted 42 lines

Quoted 7 lines

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 ?

It's not just for fully binary identical (i.e. BR2_REPRODUCIBLE).

It's basically for the same reason that we have versioned docker images, to
make sure that we really know what we're building for the target.

I realize now that this rule is not something we've written down anywhere. I
just always assumed that Buildroot tries to make sure that for a given config, whatever your build machine, you generate binaries that will behave the same and will expose the same bugs. If you use a different flex, a bug in the parsing code will manifest differently.

The more I think about it, the more I come to the conclusion that maybe this
rule (which I thought was something that I learned from the Buildroot community, not something I invented myself) is not so useful. Because in practice, the kind of bugs where this is relevant are so sensitive to even tiny changes that changing the generated code is not going to make all that much of a difference.

Regards,
Arnout

Quoted 5 lines

Best regards,

Thomas

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

On 2018-08-02 13:02 +0200, Arnout Vandecappelle spake thusly:

Quoted 1 line · Yann E. MORIN

Quoted 2 lines

My statement was (and still is): drop host-flex and host-bison for building
host tools, but keep them for building target binaries (in casu, dtc).

I agree that we do have a chicken-n-egg problem for our own kconfig. Which we can easily solve by bundling the generated kconfig lexer and parser sources [*], as we do today, even if the kernel does not.

[*] as long as we identify the versions of flex+bison that were used to generate said code.

Quoted 4 lines

Thomas (if I understand correctly) is questioning the need for keeping
host-flex and host-bison even for building the target binaries. And I have to agree that the need for host-flex and host-bison for target binaries is not that strong.

See my reply, below...

Quoted 4 lines

Quoted 2 lines

So, I'd say we should keep the dependency on host-flex and host-bison for the linux kernel...

I would really prefer to not double the build time of a simple kernel...

But that ship has long sailed...

And I do prefer reproducibility and correctness over speed or convenience.

But since we do have an option for reproducibility, those dependencies an be conditional for those speed- or reproducibility-afficionados.

Regards,
Yann E. MORIN.

Quoted 58 lines

Regards,
Arnout

Quoted 47 lines

Regards,
Yann E. MORIN.

Quoted 42 lines

Quoted 7 lines

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 ?

It's not just for fully binary identical (i.e. BR2_REPRODUCIBLE).

It's basically for the same reason that we have versioned docker images, to
make sure that we really know what we're building for the target.

I realize now that this rule is not something we've written down anywhere. I
just always assumed that Buildroot tries to make sure that for a given config, whatever your build machine, you generate binaries that will behave the same and will expose the same bugs. If you use a different flex, a bug in the parsing code will manifest differently.

The more I think about it, the more I come to the conclusion that maybe this
rule (which I thought was something that I learned from the Buildroot community, not something I invented myself) is not so useful. Because in practice, the kind of bugs where this is relevant are so sensitive to even tiny changes that changing the generated code is not going to make all that much of a difference.

Regards,
Arnout

Quoted 5 lines

Best regards,

Thomas

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Signature · 10 lines

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Signed-off-by Petr Vorel <[email protected]>

---
 support/kconfig/README.buildroot | 1 +
 1 file changed, 1 insertion(+)