<OriansJ`>well there is no way to bootstrap 1+MB binaries without having a boatload of source too.... <stikonas>although, these binaries are probably not stripped <stikonas>yeah, goes to 5 MB after that... still not a small binary <janneke>OriansJ`: i have resurrected make, mescc and added guile support ***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado
<bauen1>and i've managed to misspell "autoconf" as "uaotconf" ._. <bauen1>or rather i misspelled auto, and didn't leave a single letter in the right place ... <fossy>perl 5.12 compiles but has some broken number support <fossy>it seems to be amissing define <fossy>i will track that down tomorrow <stikonas>gforce_de1977: ok, so it's mostly that automake 2.13 (?) ssue <bauen1>why do we need ~10-20 different versions of autohell tools, are they that incompatible ? <bauen1>currently hunting down calls to autoreconf-2.57 (and similar) to add AUTOMAKE= and ACLOCAL= so it doesn't need the unversioned symlinks <stikonas>bauen1: but it's easier to build newer autotools if you have older <stikonas>bauen1: (that's true if you are not willing to use pre-generated configure scripts) <stikonas>bauen1: I suspect in the end we really need (for other software, not counting autotools themselves) autoconf 2.12 2.13 2.52, possibly 2.61 ( I think gcc), 2.65(for xz) and 2.69 (everything new should work with this one) <stikonas>not sure about automake... but probably most reasonably new stuff will work with latest automake <Hagfish>in the future, some code historian should do a case study on autotools, based on the bootstrap path it ends up needing, and then uni students can be taught about it as part of the software engineering syllabus (assuming they don't take the full "bootstrapping" lecture series) <stikonas>it's not really needed bootstrap path... It's probably the one that I found easiest... <stikonas>well, autotools are not compiled programs, they are just perl or bash scripts <stikonas>but in source form when they are distributeed they need a bit of templating <stikonas>although in general gnu packages ship huge amount of pregenerated stuff <Hagfish>do you think that templating leads to more messy versioning/dependencies, or is it just the nature of what the programs are trying to do? <Hagfish>i guess i'm imagining that they didn't manage to provide stable interfaces, or something <stikonas>well, I found it easiest to start with autoconf 2.52 which basically needed <stikonas> sed -i -e "s# @SHELL@#/bin/sh#" -e 's/@M4@/m4/' -e 's/@AWK@/awk/' \ <stikonas> -e 's/@PACKAGE_NAME@/Autoconf/' -e 's/@VERSION@/2.52/' \ <stikonas> -e "s#@datadir@#${PREFIX}/share/autoconf-2.52#" autoconf <stikonas>these variables are normally filled in by configure script <stikonas>but live-bootstrap tries to avoid using configure until we can recreate them <Hagfish>wow, i've not seen that graph before <stikonas>although, not all packages follow this exactly <Hagfish>the key/legend doesn't explain what the configure/config.status shapes mean <stikonas>although, you don't need to manually run config.status <stikonas>in terms of bootsrapping, the biggest problem was that it uses perl which is a bit annoying to build... But we wrote manual Makefile's for perl <Hagfish>is it the most complicated thing perl is needed for? <stikonas>Hagfish: well, autotools are mostly perls scripts <stikonas>so if you want to build gcc using autotools then it is needed <stikonas>although, in principle one does not strictly need autotools to build gcc <Hagfish>you could just manually generate a set of make commands or something? <stikonas>well, you can always write a build system for anything in make <Hagfish>that doesn't sound much harder than some of the other things this project is trying :) <stikonas>well, writing manual makefiles was a bit annoying before <stikonas>but we haven't done that for some time now <Hagfish>i guess the more software that is bootstrapped, the more feasible it is to build something new on that base, but i guess the things you'd want to replace are also more complex <Hagfish>i'm imagining people 50 years from now trying to bootstrap some popular new language, that runs on a virtual machine in a virtual machine on top of webasm in a browser, and the original bootstrappers will be saying "in my day, we used to bootstrap code that ran on actual hardware" <gforce_de1977>*and silence in the room for some seconds, then everybody is laughing* <Hagfish>the kids will be like "what, you had a cloud in your home? that's not possible" <bauen1>Hagfish: once you have live-bootstrap up to e.g. debian, you can start making very big breaking changes more easily, since backwards compatibility / bootstrapping is not an issue any more <bauen1>*for your hobby systems / reasearch at least <bauen1>or simplify the autohell bootstrap, eventually leading to better implementations <Hagfish>"Card personalization is the bootstrapping problem" <Hagfish>the tl;dr at the end is even better: <Hagfish>"My impression of identity is it's not a technology problem, but there are lots of people who will take your money to let you say that it is." <bauen1>perfect proof of identity is such an unsolved problem <bauen1>i mean all i'm asking for is a way to proof to a computer that **i** authorize a certain action, and that nobody with a 5$ wrench is convincing me it's a good idea <bauen1>so many modern problems that certain tech startups try to solve fall into the "not really a technology problem" section <vagrantc>janneke: is mes-mescc still expected to only work on i386? (as opposed to gcc-mescc) <janneke>vagrantc: no, mes-0.23 runs on armhf-linux too <janneke>we've built the bootstrap until glibc-2.2.5, even <vagrantc>janneke: on the debian packages i think it still only builds gcc-mescc on everything other than i386 <janneke>vagrantc: i'm not sure about the stages below mes, wrt x86_64-mes-mescc <vagrantc>janneke: i'll just try enabling it everywhere and seeing if it works :) <janneke>but last i checked, we failed to produce a good-enough working tinycc on x86_64 <vagrantc>janneke: also wondering how we can reliably communicate the new hashes :) <janneke>an as i386 works fine for x86_64, no-one seems to have any priority on fixing x86_64, even if it would be nice if it worked... 