***dongcarl7 is now known as dongcarl
***nckx_ is now known as nckx
***dongcarl4 is now known as dongcarl
***DonRichie2 is now known as DonRichie
<unmatched-paren>which is better to write a bootstrapping compiler with: gcc, llvm, or manually? <unmatched-paren>I was considering qbe but it only supports 2 of the 6 architectures that I consider worth supporting <unmatched-paren>i'd like to make it work for x64, x32, ARM32, ARM64, powerpc64le, and riscv64 <unmatched-paren>obviously C and GCC would be the most portable options, but llvm would work too, since it supports all 6 and i don't think any others are worth investing time into tbh <unmatched-paren>I was also considering emitting D, because it has some OOP features that need to be in the compiler for it to compile FreePascal, but that's doable with C too and because D is much higher level i might run into problems? <Noisytoot>unmatched-paren: What is ARM32? ARMv6, ARMv7, or something else? <unmatched-paren>as you can see, i am not particularly familliar with arm :) i'm not sure which 32-bit ARMs i'd want to bother with <Noisytoot>They're ARMv7, except for the Raspberry Pi 1 and zero, which are ARMv6 <unmatched-paren>i think(!) pi 0 and 1 are v6, pi 2 is v7, and pi 3/pi 4 are aarch64/ARM64, right? <unmatched-paren>both the llvm-d and gccjit-d bindings appear to be unmaintained, so i guess i'll either compile to C or D ***ChanServ sets mode: +o oriansj
<oriansj>unmatched-paren: the best bootstrapping backend for writing a bootstrapping compiler is what tool seems like the most fun to work with for *YOU* <oriansj>and remember you don't have to support all architectures either <oriansj>just the ones that you want to support <oriansj>because we have gcc bootstrapped, we can bootstrap qemu; so the what architectures you support just becomes a question of will we be running natively or just emulating that architecture. (honestly since SIMH is bootstrappable from GCC; you could target even weird architectures and it will be fine) <oriansj>and since we have bootstrapped guile (and with someone putting in a little effort) so guix isn't much of a step and then we have a boatload of options to pull from <oriansj>just make sure to have lots of fun unmatched-paren <oriansj>and remember to share your progress, so we can cheer you along the way <unmatched-paren>i have finally managed to hack together a barely functioning d makefile :) <unmatched-paren>(i'd also like the amount of control make gives you, which meson does not) <unmatched-paren>could i perhaps manually write ninja files and run them with either ninja or samurai? <unmatched-paren>"In contrast to Make, Ninja lacks features such as string manipulation, as Ninja build files are not meant to be written by hand" ah <oriansj>unmatched-paren: honestly any build tool is fine; just use the one you like the most <unmatched-paren>i'm using make, because i want the amount of control that it gives, but it's yet another instance of Bell Labs apparently being completely unable to design remotely readable syntax <oriansj>I'm partial to kaem scripts but my build needs are simple <unmatched-paren>kaem's the build system that stage0 uses, right? how suitable would it be for compiling a C project? <oriansj>unmatched-paren: it is inefficient but you can't get it wrong <nimaje>are kaem scripts more than a list of commands? <oriansj>but if you plan on creating a boatload of tests; I do suggest something better for that. <oriansj>but if your build is more complex than $preprocessor $source1 $source2 ... $sourceN -o $output.c; $compiler $generated1.c $generated2.c ... $generatedN.c -o $output.S; $assembler $generated1.S $generated2.S ... $generatedN.S -o $output.o; $linker $generated1.o $generated2.o ... $generatedN.o -o final-binary; you need to rethink what you are making <unmatched-paren>(BTW, i'm not actually doing the pascal compiler here, i'm first writing a parsing library) <unmatched-paren>so i have `all` (dynamic lib), `static` (static lib), `test` (runs all integration tests), `install` (installs, obviously), and `clean` (rm -rf out/), and i soon will probably have `docs` to run DDoc <unmatched-paren>i wish there was a generic build system implemented as a $(SOME_LISP) library, but apparently there isn't <unmatched-paren>The de-facto build system for d is dub, but it's also a package manager and i'm not keen on having any package manager other than the system one installed on my system (especially since pretty much all lang-specific package repositories are unmoderated) <fossy>well, kaem does have variables, etc, but it is by no means a full shell <fossy>there are no constructs that allow you to jump back <fossy>i would not recommend it for anything more than the most simple of C packages <fossy>i would recommend for a general C project meson/ninja <unmatched-paren>this is a D project, which is slightly more complex due to the unit testing framework and doc generator <fossy>ah, yes, i would use something suited toward d <unmatched-paren>dub is The Standard, but i don't like it because it's basically like cargo but for d and tries to completely replace system packages like every single 'modern' build system <unmatched-paren>${DMD:-ldmd2} -release -c FILE -o OBJECT; ${DMD:-ldmd2} -release FILES... -o EXECUTABLE <unmatched-paren>i couldn't figure out how to use them, so i'm just doing integration tests instead <unmatched-paren>there's also the .di files (d interfaces) which are basically just like C headers but autogenerated; you need to install them under ${DESTDIR}/include/d/${PACKAGE_NAME}-${MAJOR_VERSION} <stikonas>unmatched-paren: basically kaem has variables, conditionals and aliases