Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes. Set by lizmat on 24 May 2021. |
|||
nine | coleman: why Meson btw? Why not e.g. cmake? | 06:07 | |
Nicholas | I think he mentioned i in the PR, but my experience of cmake is that it's impossible to bootstrap it on less common OSes. It's an albatross | 06:46 | |
whereas Python is actually portable | 06:47 | ||
if cmake isn't already installed or packaged, 50/50 you're stuffed | |||
Woodi | dropping Perl family for build system will be huge loss for the future... looks cmake with ninja is very fast but cmake part is a mess | 06:55 | |
and builds are not so complicated overall, even Makefile dependency graph is overkill, why not have something working hierarchical/declarative with caches ? partial rebuilds part is what need to be fast ? | 06:58 | ||
also tool discovering what to rebuild can be augmented by telling it what to rebuild | 07:00 | ||
nine | I'm not a big fan of cmake either. Have never tried Meson though. Just curious really. | 07:02 | |
Woodi | they say cmake is standard :) | ||
and Bazel is Java - everyone have his own build system :) | |||
maybe it is fast total rebuild what devs would like ? ccache is there for C/C++. also git have all info what files changed | 07:11 | ||
Nicholas | I think it was ccache that I couldn't build the current version of. Because it needed cmake. And cmake wouldn't bootstrap on whatever-it-was. So I used the previous version of ccache | 07:12 | |
Woodi | ccache is older then cmake by decades... | ||
Nicholas | whatever-it-is, I'd be happy if Configure.pl and all our special snowflake could be replaced by something someone else maintains, that's no less portable than what we have | ||
IIRC version 4 changed its build system | 07:13 | ||
it was something like that. The previous version of ccache was perfectly good | |||
Woodi | "CMake 3.15 or newer."... | 07:14 | |
Nicholas | "perfectly good for what I needed" is what I meant. I have no knowledge of how much of a rats nest the ccache build is | ||
Woodi | I have impression that ccache is very standard Unix tool that just blends into background and is invisible... and it is so old that corner cases are well documented: ccache.dev/manual/4.9.1.html#_caveats | 07:29 | |
alternative is github.com/mozilla/sccache | 07:33 | ||
but actually would be nice to have list of wishes for build system first and then brainstorm solutions :) | 07:35 | ||
0. remove system detection from build script... why not have script that detects is that CC working on HalloWorlds, etc and _do not run_ this script on every rebuild ? :) | 07:38 | ||
Nicholas | good news: I have improved my Wifi | 07:40 | |
bad news: It's still a long work video call meeting | 07:41 | ||
Woodi | 1. git submodules are meh and security violation sometimes but conceptually clean, complete and usefull... do separate repos would be nicer ? submodules are usually forks with patches... | 08:17 | |
2. do big projects have "expectations" ? eg. do they automatically know how to plug-in dependency using cmake/meson ? maybe that can be added on top of existing/improved build ? | 08:23 | ||
xiaomiao | cmake only exists because people insist on building stuff on windows | 08:24 | |
it's best treated as a leftover from the old times and not encouraged | |||
Woodi | xiaomiao: /me feels old now :) | 08:25 | |
xiaomiao | Woodi: I am often surprised about the unironic use of such legacy systems | ||
Woodi | xiaomiao: it's what old people know :) I still didn't finished reading "UNIX administration" by AEleen Fresh ;) | 08:27 | |
but if somethink brings value it should be promoted, few times even... | 08:28 | ||
xiaomiao | Woodi: nah "old" people would use proper tools like ... autotools | ||
or just a plain Makefile, because most of the time you don't care what cc is set to | 08:29 | ||
Woodi | yep, plain Makefiles pls ;) but how much ninja could replace it ? | 08:30 | |
xiaomiao | no ;) | 08:31 | |
ninja is just half of the problem space, handwriting ninja files is unpleasant | |||
so you need something like meson or a makefile to generate that | |||
Woodi | 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 ? | ||
xiaomiao | and what problem does it solve? | ||
the modern thing is having a makefile that curlbashes into docker | 08:32 | ||
Woodi | but we have grammars ;) | ||
xiaomiao | that way everything is ubuntu 22 ;)\ | ||
Woodi | xiaomiao: let's just filter some sudocurl|bash and have better future :) | 08:33 | |
xiaomiao | you mean curl | sudo tee bash | ||
Woodi | can ninja files be templated for usual case ? how often that files change ? they describe whole project, right ? and are human-readable, simpler then Makefile's, "always parallel". I do not understand what else valuable outer builder like cmake adds... | 08:42 | |
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 | ||
08:51
nine left,
nine joined
|
|||
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 ... | |||
09:13
sena_kun joined
|
|||
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 | ||
09:56
sena_kun left
16:18
vrurg_ joined
16:21
vrurg left
18:20
sena_kun joined,
vrurg_ is now known as vrurg
|
|||
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 | |
23:24
sena_kun left
|