IRC channel logs

<sneek>wb chrislck!

<chrislck>sneek: botsnack

<RhodiumToad>ACTION wonders whether to write a fixed version of srfi-171

<sneek>wb chrislck

<sneek>Welcome back dsmith

<dsmith>sneek, botsnack

<dthompson>does anyone know how, with autotools, you can create a wrapper script that sets up guile load paths properly?

<dthompson>there's a bunch of guile programs in guix that have a special build phase that wraps executables to deal with this and I'm wondering if the projects themselves could deal with it.

<dthompson>this includes some of my own stuff :)

<dthompson>even the guix package in guix does it so maybe there is no good answer

<mwette>dthompson: not really sure what you are asking, but typically you can generate template scripts (ending in .in) that get substitutes via configure. Look at guile's meta/guile.in file.

<mwette>and generate your wrapper

<dthompson>yeah this is going beyond the basic template script stuff

<dthompson>I'm just going to not worry about it since no other guile project seems to

<rekado>dthompson: not sure if that’s what you had in mind, but the GWL’s entry script sets the load path to whatever it had captured at configure time: https://git.savannah.gnu.org/cgit/gwl.git/tree/guix/extensions/workflow.scm.in

<rekado>don’t know if this makes sense on any system other than Guix

<dthompson>rekado: I get emails every so often from people not understanding why Haunt isn't working when they installed it /usr/local but guile's local path is /usr.

<dthompson>I'll take a look at gwl is doing.

<dthompson>s/local path/load path/

<rekado>the GWL is a bit weird in that it is launched by a running Guile process, and so it must re-execute itself with a known good load path.

<dthompson>hmm interesting

<rekado>so I’m capturing the load path as detected at configure time and embed it in this .in template, so that at runtime I can reset it from whatever the default is.

<dthompson>ah okay looks like you're using the same configure.ac magic as guix https://git.savannah.gnu.org/cgit/gwl.git/tree/configure.ac#n34

<dthompson>I tried this and the darn shell variables were still in the compiled template... will need to debug.

<sneek>Yey! dsmith is back :D

<dsmith>sneek, botsnack!

<sneek>:)

<dsmith>There's a good bot

<sneek>ACTION wags

<rekado>dthompson: the magic happens in Makefile.am

<rekado>dthompson: this bit right here: https://git.savannah.gnu.org/cgit/gwl.git/tree/Makefile.am#n122

<dthompson>rekado: ha I just noticed this

<dthompson>ugh

<dthompson>what a mess

<rekado>frankly, 80% of the time I feel like I’m working against the assumptions that are ingrained in autoconf and automake

<dthompson>yeah it's all trash

<rekado>the other 20% I’m too busy looking for existing snippets to feel anything

<dthompson>lol

<dthompson>every guile project just snarfs some autotools magic from guix and moves on

<singpolyma>Better just skip the autotools entirely. Save yourself the hassle

<dthompson>that's an even worse idea than not using them at all

<dthompson>than using them*

<dthompson>you'd go from something that actually builds easily for users to something that doesn't

<singpolyma>Except that autotools are hell for users

<singpolyma>Half the time I have to write my own makefile to build other people's projects because autotools is so broken

<dthompson>well we'll have to agree to disagree there

<dsmith>Makefiles can be fairly simple if you have pkg-configs for any dependencies

<RhodiumToad>when doing packaging work, I've had more issues with guile-related projects that used cmake or meson than ones that use autotools

IRC channel logs

2023-09-22.log