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 |