<stikonas>so far I checked mihi's bootstrap up to the point where autogen binary is built (there is a bit more after that, in particular "Bootstrapping tpl-config.tlib") and so far it all seems good <stikonas>rickmasters: out of curiousity, any reason why you had to write simple-patch.c rather than use replace from stage0-posix? *oriansj wonders if adding diff and patch to mescc-tools-extra might have been a superior choice to replace. <oriansj>I can actually use M2-Planet's -D VERSION=1.2.3 functionally and no longer have to update the version string <oriansj>I can just pull it from the build environment and it'll always be correct <oriansj>(although the bootstrap script might need to manually update the -D value <fossy>stikonas[m]: oh yes, that was fine to merge which <stikonas>fossy: regarding autogen, we need to build it in two stages (right now mihi's script does both) but I think we can split it, exit earlier and just do normal build of 2nd stage. <stikonas>so once tricky parts are over, so once columns, getdefs and autogen binaries are built <stikonas>that config-tpl.tlib step is just using sed command to patch some placeholder values and running configure <fossy>stikonas: i would say probably at L95, that seems the most "normal" part of it all <fossy>(as in, where it's most like anormal build) <stikonas>indeed, that's where a normal build starts <stikonas>that previous step is still bootstrapping though at that point it's an easy bootstrapping ***Noisytoot_ is now known as Noisytoot
<fossy>yeah, makes more sense to my brain at least, if we're going to separate it, separate it where the bootstrapping portion ends <stikonas>possibly the nicer way to refactor that bootstrap.sh is to have main() function in bash that just calls individual stages (each in its own function) <stikonas>anyway, I first need to fix static vs dynamic linking stuff in live-bootstrap <stikonas>so I'll add CFLAGS="-static" (or CXXFLAGS="-static") for binaries but for libraries I'll build both static and dynamic libraries if possible <stikonas>hmm, now I've got some build error in automake-1.15 <stikonas>autom4te-2.69: cannot create autom4te.cache: No such file or directory <doras>stikonas: this looks like the same build failure seen in automake-1.11.2 <doras>The one where it was suggested that it may be related to timestamp.s <doras>You can see that it tries to re-run autom4te/autoconf during the `src_compile()` stage. <stikonas>doras: strangely I only see it in automake-1.15... <stikonas>doras: so do you think we need to add those variables? AUTOCONF=autoconf-.. etc? <doras>stikonas: well, I think it would work around the issue. Perhaps it's not too bad to rely on a workaround for now. <doras>I saw it in both packages, by the way. <doras>More often in automake-1.11.2, however. <stikonas>doras: I have a change to make gperf build static binary and libffi, gc, libatomic_ops and libunistring to build both shared and static libraries, although I have not yet figured out guile... <stikonas>though my changes might conflict a bit with your PR... <stikonas>anyway, it will probably take a few more rebuilds till I iron out all issues <doras>It may take me a few days to handle the review comments, so don't worry about the hashes.