***sneek_ is now known as sneek
<civodul>wingo: i guess they maintain it themselves? <wingo>probably they don't update often from upstream. not sure how gnulib would work without autotools <civodul>BTW, Guix does not remove .la files (yet) <wingo>i guess guile transitively depends on python already for its build :P <civodul>.la files are mostly useful for static linking since they tell the extra -l flags *wingo not actively investigating this fwiw, just thinking about it <civodul>are you saying you'd like to switch to Meson? <wingo>i was just thinking, we could do autotools without libtool, but autoconf + libtool + automake kinda hang all together <wingo>so if you want to take libtool away, replacing the whole thing starts to become maybe interesting <civodul>we could do without libtool, but that means doing the LD_LIBRARY_PATH dance, -rpath, relinking, and all that by ourselves <wingo>yeah honestly i would think that probably you and guix folks have the most informed opinions about what would be a good idea <wingo>& maybe staying with autotools is the least bad idea, dunno <wingo>but, we already have to do a lot of workarounds via meta/uninstalled-env.in etc <civodul>the rpath + relinking thing is striking: i think all build systems other than autotools get it wrong <civodul>in Guix we have workarounds/tweaks for CMake and Meson, for sure <civodul>for Meson, we explicitly pass -Wl,-rpath because apparently it won't do it otherwise <civodul>that trick works because we're building in a chroot, but if you did that with -Wl,-rpath=/usr/local/lib, you'd end up running the previously-installed code instead of the one you're building ***7GHAAB4K7 is now known as heroux
<leoprikler>As someone who uses Guile+meson, I can't say I recommend it. With Guile+Autotools, I can put everything into one Makefile.am. Meson currently doesn't have such capabilities. <lampilelo>for snarfing you have to use external command because there's no other way to obtain cflags directly in meson <wingo>my ardour for action is cooling, fwiw :) <terpri_>i can't even *build* bazel on guix. cmake's documentation seems very minimal and i end up spending far too much time finding a magic incantation to change some simple option. autotools have their problems, no doubt, but i've never found an alternative i prefer <terpri_>redo & co. sound interesting on paper, but they're only 'make' alternatives <terpri_>(i wonder how much of autotools's flexibility/longevity comes from being designed to build things automagically on random *nix systems...cf. systems like imake which iirc relied on a central database of system information) <lampilelo>i guess there is a workaround for snarfing in meson because you can write modules, so you could probably access cflags from dependency objects or something, they're not exposed by default though <lampilelo>my take on autotools, as a new user, is that they're hard to learn, the documentation is all over the place <lampilelo>i use them for my new project because i thought it would be fun to learn, but no, it's not particularly fun <lampilelo>but i have to agree, enabling and disabling features when you want to compile is super easy when everything is set up right <leoprikler>I personally feel, that Guile's autotools integration could be better. <leoprikler>People currently have to write their own .scm.go suffix rules and the way SOURCES are sometimes declared as merely "SOURCES" is also discouraging <terpri_>meson looks fairly reasonable, just skimming their site, though i'd prefer not to have python etc. be fundamental dependencies for building things (which is probably a fringe preference) <leoprikler>OTOH a guile module for meson would probably work better to get more users on board <terpri_>and tbf some of autotools's advantage is probably from "tradition" (refined over decades) and doing something complicated might require knowledge of m4 and shell and make <leoprikler>Yeah, autotools very much assumes you're at least familiar with shell and make. <civodul>terpri_: the actual cmake documentation is non-free (a book) <morganw>It is likely a biased source, but the Autotools book from 2019 states that adding new language support to Autotools is actually not too hard. And I imagine the existing support for Elisp probably has a similar compilation model to .go files. <morganw>(I bought the book because I agree that knowing where to start with Autotools is difficult) <terpri_>civodul, ah, that would explain why the official online docs seem so sparse :) <epony>like the emacs manual page.. a bit lacking <leoprikler>adding language support to autotools is really not hard, it's mostly just adding one suffix rule and you're done <leoprikler>well, it depends on how hard the language makes it, I don't think the complicated entity, that is rust, can fully be described within a suffix rule, but you get my point :P <civodul>terpri_: i know that because at work they regularly buy copies of that thing *sigh* ***d4ryus1 is now known as d4ryus
***rekado_ is now known as rekado
<lloda>wingo, civodul: ok to merge wip-gnulib-update? <civodul>rekado: yes, because the copies unavoidably get lost in some drawer ***sneek_ is now known as sneek
<roptat>hi! how do I use guile-cairo? I tried to create a surface with (cairo-image-surface-create 'CAIRO_FORMAT_ARGB32 100 100), but I get `(#f "Unknown enumerated value: ~S" (CAIRO_FORMAT_ARGB32) ())'. The manual doesn't seem to explain how to get a cairo-format-t <rekado>guile-cairo/guile-cairo-enum-types.c gives you the mapping <leoprikler>is it intended, that define* exists even without (ice-9 optargs)? <rlb>I've gotten the impression that a lot of things may not handle cross compilation (and bootstrapping) nearly as well as autotools, if at all. Though that's more important for "closer to root" dependencies like gcc. Python, and guile to a lesser extent atm, also already present a common interface to some of the things autotools detects, and could provide more, i.e. endianness, type sizes, etc. <civodul>"guild compile" has a --target switch <dsmith-work>I had to cross-compile Python by hand for some embedded stuff. Was tedious. Thankfully, buildroot eventually added Python. <ArneBab>are we actually trying to get rid of autotools? From all the runs through build systems I did since 2000, autotools was the only one that sufficed. Everthing else was worse — including cmake, scons, waf, the numpy-setup-hacks, and pip. <ArneBab>(though those actually do a bit more that is useless to guix users) <ArneBab>Nowadays I think that the right way to provide a build system is to auto-generate a working autotools-setup with a <something> init tool. <janneke>pure-funcq on an inner function does not work with guile-3, is that expected? <ArneBab>Sadly I’m too slow at pushing conf forward, which does that, but currently only for bash, python (though opinionated), latex, org-mode, and naturally wisp: https://hg.sr.ht/~arnebab/conf <janneke>civodul: u sure we don't suffer from this in guix? *janneke hasn't looked, but knows guix does some fancy memoizations