On Fri, Feb 1, 2019 at 4:03 PM Bruce Dubbs via lfs-dev <[email protected]> wrote: > > On 02/01/2019 03:49 PM, Gavin Howard via lfs-dev wrote: > > Hello, > > > > I am the author of a bc with GNU extensions > > (https://github.com/gavinhoward/bc) that enables it to help build the > > Linux kernel. I think that my bc would be useful in Linux from > > Scratch. > > > > I have run through the entire LFS book with nothing changed except to > > replace GNU bc with the current release of my bc > > (https://github.com/gavinhoward/bc/releases/tag/1.1.3). > > > > The required instructions are: > > > > <<Begin instructions>> > > Prepare Bc for compilation: > > > > PREFIX=/usr CC=gcc CFLAGS="-std=c99" ./configure.sh -G -O3 > > > > The meaning of the configure options: > > > > * PREFIX=/usr > > Like --prefix in other packages. > > * CC=gcc > > Set the C compiler. This package defaults to c99, which doesn't exist. > > * CFLAGS="-std=c99" > > Sets the C standard that gcc uses to be C99. > > * -G > > Disables tests in the test suite that requires another bc to > > generate results for. > > * -O3 > > Enables optimization. This bc gets an order of magnitude more > > performance from optimizations, and these optimizations have been > > tested. > > > > Compile the package: > > > > make > > > > If desired, test bc: > > > > make test > > > > Install the package: > > > > make install > > <<End instructions>> > > > > Would there be interest in switching to this new bc? > > I would be open to this. The instructions seem to be a lot simpler than > what we have now. I'm interested in other opinions. In any case I > think we would postpone this until after our next release. (March 1st) > > I do have one concern. There appear to be four releases in three days > (1.1.0, 1.1.1, 1.1.2, and 1.1.3) in three days. We really need > something a bit more stable than that.
tldr; there are that many releases in such a short time because I fix bugs fast. My bc *is* stable. Each of those releases (besides 1.1.0) fixes only one deficiency. For 1.1.1, it was a bug in the build system. For 1.1.2, it was a small bug in the custom history (readline) implementation. And for 1.1.3, it wasn't even to fix a bug; it was to enable `make test` to run its targets in parallel. Basically, as soon as I found out about the those things, I fixed them and updated. That's why there are that many releases that fast. Not every update has to be taken, but even if they are, point releases like this are completely safe because they are fully backwards compatible. Also, when I release, I run my bc through ASan, MSan, UBSan, valgrind, and a script that tests every build configuration in debug, release, reldebug, and minsize modes for both gcc and clang. And then I eliminate crashes by running a fuzzer. GNU bc can't even pass my release process. Not by half. So, if by "stability" you mean "as bug-free as possible," my bc is just that. If you mean "few releases," then my bc doesn't have that. Yet. After March 1st, it will most likely be very stable as the few bugs that are left should be ironed out. And then it will be stable in both senses of the word. Gavin Howard -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
