<fossy><stikonas[m]> I mean he bootstrapped it once (I guess first autogen didn't have those circular deps) <fossy><@oriansj> stikonas: the reason usually for why those circular dependencies are inserted secretly is usually shame in regards to how they were implemented and the aurthor not wanting that sort of mess to be associated with them. So they destroy the transistion code needed and we end up having to pull another bison bootstrap. <fossy>I do not think thats always the case.. sometimes its the easiest option <fossy>easiest is not a good thing sometimes, however <stikonas>fossy: I suspect the easiest option is actually <stikonas>forget top level makefile and build g++ anyway <fossy>I tend to agree with you after looking into autogen <fossy>clang would be a massive pita <fossy>for linux kernel particularly <stikonas>g++ is actually very easy to build, it's just --enable-languages=c,c++. What will be harder is libstdc++ <stikonas>but maybe it's finally time to build glibc <fossy>glibc is logical next step. should we do glibc before or after g++? <stikonas>glibc gets a bit grumpy if we have g++ without libstdc++ <stikonas>and regarding autogen we can still email author... <fossy>well yeah theyre kinda codependent (g++/libstdc++) <stikonas>so I'm not sure what to do with guile then... <stikonas>it's not harmful but it's not immediately useful <stikonas>unless some other project wants to use it (e.g. guix) <fossy>asked fabrice bellard about the history of tinycc and its selfhosting nature (when did it originally become selfhosting) in the pre-mes-m2 working era <stikonas>well, I guess initially gcc was used to build it <stikonas>CI run step on public CI executors is probably too long by now <stikonas>with all these GCC versions it's already way longer than anybody would allow <stikonas>should we just disable it and leave only linters? <fossy>I am thinking of running an asychronous CI bot on my personal computer (which is not on 24/7) which posts results to github using a bot <fossy>but I am not sure if software exists to accomplish this <stikonas>but not sure if there is something that is not overkill <stikonas>I know that Jenkins can definitely update github CI status <fossy>I think Jenkins has that but Jenkins is a bit over the top <fossy>it dosent even have to have the green check mark on CI. Could just be a github comment <stikonas>well, github api for that is probably not even that complicated <fossy>no, probably not. github has sane apis <stikonas>it's the last GCC that does not need C++ <fossy>we could add guile or push it back to later, up to you, I dont really mind either way (even if it isnt strictly relevant rn) <fossy>we will probably need it in the foreseeable future though <stikonas>hmm, guile works but it is really slow to build <fossy>yeah cause of the *.go files right? <stikonas>well, maybe let's keep it in the branch... <fossy>they only took like 15 mins when I compiled locally outside of live bootstrap <stikonas>well, maybe -j$(nproc) outside live-bootstrap <stikonas>potentially we should start parallelizing build... <oriansj>well it looks like /after/gcc-4.7.4/build/gcc-4.7.4/build/libstdc++v3/include/bits/os_defines.h on line 45 was mangled by libtool ***cadmium.libera.chat sets mode: +o ChanServ
***cadmium.libera.chat sets mode: +ooo ChanServ oriansj janneke
<stikonas>fossy: would you mind if I only changed tripplet from 4.7.4 onwards? <stikonas>and keep older ones i386-unknown-linux-gnu for now