***lukedashjr is now known as luke-jr
***ChanServ sets mode: +o rekado
<melg8>hi, anybody know how kaem (and witch version of it) handles env variables? if i want to use it inside kaem script? ***lukedashjr is now known as luke-jr
<gforce_d11977>this already uses variables: are you speaking really of ENV vars or just $VARS ? <melg8>env vars, like if there out=/some/path - and i need my outuput file go to that path. Btw, how is progress about splitting build process to parts? <gforce_d11977>printf '%s\n%s\n%s\n' "FOO=bar" 'echo $FOO' 'echo $PATH' >foo.kaem <gforce_d11977>./kaem.bin foo.kaem ---> +> FOO=bar ---> Subprocess error -> ABORTING HARD <stikonas>gforce_d11977: the first kaem does not have vars <stikonas>then later we build C version of kaem which also has more features <melg8>first kaem can't reach out to env variables. that was my question about. final kaem - can <gforce_d11977>i always overlooked it, but this line during stage0 seems to be the beginning of kaem-full: <gforce_d11977>+> ./M2 --architecture x86 -f ../M2-Planet/test/common_x86/functions/exit.c -f ../M2-Planet/test/common_x86/functions/file.c -f ../M2-Planet/functions/file_print.c -f ../M2-Planet/test/common_x86/functions/malloc.c -f ../M2-Planet/functions/calloc.c -f ../M2-Planet/functions/match.c -f ../M2-Planet/functions/in_set.c -f ../M2-Planet/functions/require.c -f ../mescc-tools/functions/string.c -f <gforce_d11977>../M2-Planet/functions/numerate_number.c -f ../M2-Planet/test/common_x86/functions/fork.c -f ../M2-Planet/test/common_x86/functions/execve.c -f ../M2-Planet/test/common_x86/functions/chdir.c -f ../M2-Planet/test/common_x86/functions/getcwd.c -f ../mescc-tools/Kaem/kaem.h -f ../mescc-tools/Kaem/variable.c -f ../mescc-tools/Kaem/kaem_globals.c -f ../mescc-tools/Kaem/kaem.c --debug -o kaem.M1 <stikonas>(double kaem-optional-seed is just to reuse more files from stage0-posix... <stikonas>although it might be possible to just ship our own .kaem script to avoid that <stikonas>i.e. move stuff from mescc-tools-seed.kaem.run to base.kaem.run and adjust it as necessary <melg8>btw do we want sometime in future create this scripts not by hand but generate them in sysa? or it will be against spirit of project? <melg8>live-bootstrap kaems and run.sh run2.sh run123.sh <stikonas>it's not really clear how easily you can generate them... <stikonas>well, you can probably create them from smaller template file <stikonas>but they are not that complicated anyway <stikonas>and we don't really have good way to deal with templates yet <stikonas>run.sh is already mostly just a list of things to build <stikonas>so I don't really see how you can minimize much further even if you allow generating stuff <melg8>i'm looking forward live-bootstrap not to be just single bootstrap with fixed number of outputs, but more like bootstrapping factory, so if somebody just needs gcc 4 - it stops there, if somebody need python - go all way to it <stikonas>it doesn't take that much time go go to python though <bauen1>oh nice, i just noticed that my last test run with add-gnu-stow ran fine until the very end <stikonas>(at leats on normal system, on cirrus CI something is slowing things down) <bauen1>melg8: upkg will make your idea easy (easier) to achieve <melg8>and now it's not clear why in kaem/run/run2.sh - some packet D is after A B C is now dependencies graph is embedded in linear form <bauen1>should also speed up ci massively once there's not as many changes ... <melg8>@bauen1 when it arrives? what it's idea? how it works?) <stikonas>there is some explanation in text, sometimes order does not matter too much though <stikonas>melg8: we also have live-bootstrap.dot graph <stikonas>although that is less accurate in later stages <bauen1>melg8: i've written a bit about it in here, but basically you give it dependencies and a build script and it gives you the result (taking care of hashing, building in a chroot, skipping build if necessary, ...) <bauen1>melg8: what it doesn't do is dependency resolution or anything like that, so you'd still have to write a script to call it, but then it becomes a lot more obvious what depends on what <stikonas>and it will take some time, I guess it won't be ready in the next few weeks yet <melg8>so it's working as command center from sysa into chrooted environment? <stikonas>well, it's working more like building environment of any other distro <bauen1>melg8: kind of, think of it like dpkg-buildpackage <bauen1>btw if someone needs something to do, it'd be nice if you can somehow get the early stages of live-bootstrap to "skip" if the ouput is already present and has a corret hash <stikonas>and hence also suffers from magic dependencies <melg8>what it will load as first executable if i want to build packet number 34 (for example) <stikonas>although, now his commit is broken after we changed some early stuff <bauen1>stikonas: well, that was more of a dump every binary into git and skip the steps by editing the script, i had a more elegant solution in mind :D <bauen1>but we're probably reaching the point where the early bootstraps time will become less relative to everything else <stikonas>longer term something better would be nicer <melg8>can we dynamically replace init executable? <stikonas>well, there is a way to massively speed later bootstrap <bauen1>stikonas: "changes every hash" please explain <stikonas>basically remove all optimization passes <stikonas>of course binaries compiled with -O0 are a bit slower than standard -O2...