<stikonas>rickmasters: so pdpmake might be buildable but would really need quite a bit of patching and even building some libraries from gnu make tarball <stikonas>so I don't think I'll be looking at it in the near future <stikonas>but it's definitely more painful to build than GNU make <stikonas>so it's only worth if builder-hex0 can run it <stikonas>which we probably can test by manually building a static version of it and injecting into builder-hex0 <rickmasters>stikonas: i've already spent a bit of time figuring out GNU make so I'm pretty confident I can make it work on builder-hex0 <rickmasters>stikonas: probably. the biggest issue with make is that it is several different implementations mixed together with ifdefs. <rickmasters>I mean, it supports linux, windows, DOS, VMS, and amiga <rickmasters>but I don't think DOS or amiga supports pipes or fork so it can be dumbed down, its just a bit painful to detangle <stikonas>maybe then we'll have to move patch before make? <oriansj>or leverage the mini-patch rickmasters made and enhance it to the level required and just add it to mescc-tools-extras <rickmasters>perhaps. It seems you guys value starting with an official package and then patching whereas I'm find with just going with a modified fork <stikonas>it depends, we started live-bootstrap with submodules <stikonas>and then oriansj wrote untar and ungz, so we switch to packages for everything after mes <stikonas>but if you make a fork, create a tag and tarball, I guess we can take it too <stikonas>I guess official packages are easier in terms of reviews, people probaby can trust them a bit more than random stuff <stikonas>but if we have a clear diff from official package, then it should be fine too <rickmasters>It doesn't matter much to me. I'm fine with patching but I think building patch earlier would make sense because we do kinda need it already <rickmasters>Then again, I have no idea how much code and build cruft patch uses. If its GNU, its probably a million lines of code with autocrap, I mean autoconf and all that fun stuff <rickmasters>sorry, I probably shouldn't be so negative. there is a lot of value in those tools <stikonas[m]>rickmasters: we used to have a kaem script to build patch <rickmasters>on second thought, i'm patching mes and tcc but I can't use patch for those because we'd need tcc (at least) to build patch. <rickmasters>and I don't know how much make will need to change, so we can wait to see how much patch will help and whether it makes sense down the road <stikonas[m]>Sure, let me know later if patch helps and I'll do the change <fossy>hmm, i think we will build python shared rather than statically. it makes things quite a lot easier, what with pythons shared modules, particuarly in intermediete versions where other options are sketchy <fossy>rickmasters: glad to here the progress. i did explore this for a little while (early linux under live-bootstrap). <fossy>i'm *personally* not a particular fan of linux 2.4 due to its complexity and (ab)use of gcc/binutils isms <fossy>tilck's codebase does look simpler, but, it still uses a lot of gcc/gas-isms <fossy>at any rate tcc is a bit of a strange (even approaching cursed in some cases) compiler, so kernels in that stage are never going to be trivial <fossy>oh, it was fiwix, https://github.com/mikaku/Fiwix that I thought looked rather promising. it didn't appear to have as many gcc/gas-isms, it has ext2, vfs, linux abi compatibility to a strong extent, pipes, multitasking <fossy>and the incredibly helpful idea/ata device driver. which makes bootstraps so much easier to manage <fossy>(no need to fit everything into 4G) <fossy>i am absolutely NOT a kernel dev tho, so i would appreciate your thoughts on fiwix, rickmasters :) <Hagfish>yeah, i'd be interested to hear some expert opinions on it too <Hagfish>"You can contact me at jordi@fibranet.cat." <Hagfish>perhaps that's one way to get an expert opinion :) <stikonas[m]>fossy: I guess then we build newer GCC, shared musl and the python <stikonas[m]>And then we drop lots of shared linking patches to GCC 4.7.4 <fossy>stikonas[m]: yeah, i was just chucking python on the end now anyways, its not particualrly useful yet <fossy>pretty sure it's needed for newest gcc pregened too? <rickmasters>fossy: the linker script might be a challenge for tcc but other than that it looks great. It's small enough to understand and has the syscalls we need. <Hagfish>it definitely seems like the developer of that project shares the same sense of aesthetics as we do <rickmasters>all of the C files compile with tcc-0.9.27 without error... <rickmasters>yeah, without any changes to the command line options <rickmasters>well, the commands ran without error but I need to check that it actually did something... <rickmasters>so tcc 0.9.27 is producing object files but a few C files in the kernel directory were skipped because the assembly files in that directory failed to compile. <rickmasters>its looks like a minor problem with some assembly. i'm trying to skip those files for now... <rickmasters>fossy: anyway, it looks really promising and the new leading candidate to move forward. thanks a lot for pointing it out. <fossy>rickmasters: that's exciting to hear. let me know if there's anything i might be able to help with. i know tcc's specialties reasonably well but not so much kernel architecture :D <janneke>with m2-planet 1.10.0 (haven't checked later version yet) on foo.h: <janneke>#define got something it can't handle <janneke>[1]15:52:29 janneke@drakenpad:~/src/mes/fix [env] ***ChanServ sets mode: -o janneke
<janneke>it's not the underscores, this also works "fine": <rickmasters>janneke: it just seems related to the #if because the define works by itself <janneke>[1]17:24:44 janneke@drakenpad:~/src/m2-planet [env] *janneke tried 0 - 1, and (0 - 1); neither works :-( <muurkha>I guess ~1 + 1 probably doesn't work either, does it? <rickmasters>janneke: actually it does support negative literals, just not inside and #if that does not succeed. probably a bug <rickmasters>janneke: it a little weirder: you can define a negative literal outside an #if but, separately, you can't set a global variable with a negative literal <rickmasters>more precise: you cannot define a negative literal in an failing #if/#endif and you you can't set a global variable with a negative literal <clemens3>I get a build error for mes using guile 3.0.7 <clemens3>make: *** [GNUmakefile:95: build] Error 1