15 Mar 2024
xiaomiao cmake adds ... uh, lots of pain? :) 08:48
the ninja format is not designed for 'manual' use, I wouldn't recommend trying to use it directly 08:49
Voldenet theoretically build systems separate deps detection from deps usage in the project, I have no idea how it practically is, because I usually hardcode paths 08:56
simply using /lib/somelib.so worked for me in so many cases that it never occured to me to complicate this 08:58
xiaomiao you shouldn't try to do that by path directly 08:59
it usually works by accident, some of the time
Voldenet It usually works a lot of times, but when it doesn't, I can fill correct paths myself 09:00
ymmv though, maybe I should use weirder unix distros
Woodi xiaomiao: but ninja is described as simpler then make and Makefiles are supoused to be write manually :) also it is designed to be "human-readable" which is also human-writable :) 09:01
xiaomiao Woodi: so is maven ;) 09:02
just because someone writes a sequence of words doesn't make them correct or useful
Voldenet: well ... you assume dynamic linking 09:03
Voldenet I'm fully aware that it's wrong
but I do adore the simplicity ;> 09:04
xiaomiao Woodi: ninja mostly solves the problem that "make is slow" and that starts becoming human-scale measurable on something the size of the linux kernel, maybe
Voldenet theoretically cmake isn't horrible either and it's described as "simplifies stuff" 09:05
xiaomiao yeah but it's fractally wrong
most checks are pattern matching, so they fail randomly when a new compiler outputs a line extra and such unexpected things 09:06
Woodi but ninja recomended usage looks unnecessary self-conflicting and looks like cargo culting
xiaomiao and debugging it is something I'd prefer not to do so often, it's exhausting
Voldenet tbh. I've had bad experience simply building cmake projects
otoh perl script is a breeze to debug 09:07
xiaomiao yeah perl is opinionated in just the right ways
cmake syntax alone is enough to frustrate me 09:08
Woodi Configure.pl was before automake/autoconf ? 09:10
Voldenet …have you ever tried building c projects with ant? Now this is a painful syntax 09:11
Woodi both are all-in-one tools for software distribution ?
xiaomiao Woodi: configure.pl avoids pulling in a whole "foreign" system like automake 09:12
because that means bootstrapping is now also the problem of somehow bootstrapping automake, which then requires random stuff ...
Voldenet I never thought configure.pl was supposed to replace autoconf, it was written for codegen iirc 09:13
Woodi but you need to "bootstrap" plain make/Makefile too and that is solved by C compiler presence. so it's not like toolchain bootstrapping 09:15
Voldenet nevermind, I checked again and it does exactly what autoconf 09:16
xiaomiao Woodi: for make files you need some flavour of make - and that roughly depends on a C compiler 09:18
Woodi Voldenet: I think auto* were mimicking Configure.pl becouse it was earlier. and they was meant for distribution and today we need better tools for rebuilding during development. but can be mistaken on this
> also how much of "build problems" are influenced by parallel builds, kubernets like infra, TI/CI and other new toys ? what is a must have now ? what you are missing in curent Raku/Perl development process ? 09:23
coleman nine: regarding "why not cmake"... I am literally incapable of understanding cmake. :-/ 21:31
Meson generates out-of-tree ninja files, in another directory, conventionally called "builddir". I will continue to try to get things building as an experiment that lives side-by-side with the perl 21:32
The perl has never failed me, fwiw 21:33
I think having a more widely-used option will help us keep the perl up to date, too 21:46
when one of them breaks we have a reference to another
Geth MoarVM: AntonOks++ created pull request #1796:
build_release.yml: Add initial build workflow
22:02
16 Mar 2024
nine coleman: ah I know that problem :) 06:31
Geth MoarVM/main: 2a60bd07bd | (Anton Oks)++ (committed using GitHub Web editor) | .github/workflows/build_release.yml
build_release.yml: Add initial build workflow (#1796)

Add a GitHub release build workflow to assure MoarVM is successfully building:
  - on all GitHub runners (ubuntu, macos, windows)
  - based on the actual pushed "git tag"
Co-authored-by: AntonOks <anton.oks@gmx.de>
09:39
18 Mar 2024
lizmat ¢and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/03/18/2024-...pen-comma/ 18:41