IRC channel logs
2023-09-23.log
back to list of logs
<lilyp>I wish guile was easier to use from meson tbh <lilyp>I wouldn't touch cmake anyway – it's somehow more verbose than autotools and less useful in generating Makefiles at the same time. <RhodiumToad>the issues I generally had was projects insisting on using the latest available guile version rather than a specified version <lilyp>oof, yeah, guile 3.0 hasn't been that stable in terms of api <lilyp>I feel like each release adds a new section to our manual <daviid>rekado: in your workflow configure.ac file, couldn't replace lines 34 - 38 by a call to GUILE_SITE_DIR, which defines GUILE_SITE, GUILE_SITE_CCACHE and GUILE_EXTENSION, which you can then use in your other files, instead of guilemoduledir, guileobjectdir ? [ not a big deal, but i don't see you are giving them other values then the guile.m4 GUILE_SITE_DIR macro ] <mwette>I had no luck with the auto-conf guile.m4 stuff so I use the user's preferred guile to extract the load directories from guile's %guile-build-info etc using `$GUILE -c '(display (%global-site-dir))'` etc. <Arsen>please stick to pkg-config (which is what guile.m4 uses internally, so that works too) <rlb>(I wish I had something other than m4/bare-bones-posix, etc. for "most" non-root (in the bootstrapping tree) projects. e.g. I'd love to just use guile (or some minimal guile "core") to build other things, using some hypothetical nice infrastructure around it, and let guile paper over (or gather and provide) all the relevant platform specific information.) <mwette>If you have multiple guile's installed (e.g., guile, guile-2.2) autoconf will get mixed up. If you don't have your PKG_CONFIG_PATH sync'd perfectly with your PATH autoconf will get mixed up, etc, etc. <daviid>rekado: just curious, this Makefile.am do_subst function, it seems you'll change occurrences of @var@ -> $(var) in for exanmple, guix/extensions/workflow.scm.in, so, why don't you write the guix/extensions/workflow.scm 'directly' using these $(var) expressions? i probably am mssing something, sorry to bother you ... <daviid>mwette: fwiw, guile.m4 macros do exactly that, calling `$GUILE -c "(display ...)' , where ... is (%site-ccache-dir), (major-version) ... they just do not define GUILE_GLOBAL_SITE, nor GUILE_SITE_CCACHE [ which is why i add a guile-ext.m4 to my projects, which defines those and also GUILE3_PROGS, because i need, if the user uses guile-3.0, i need it to be >= 3.0.7, as it fixes a module-use! bug ... ] <daviid>mwette: and they have been fixed in 2-17, 2020 for 'not finding the right guile verson' related bug ... imr there are pretty robust now <daviid>the 'secret', ime, is to (always) define AC_CONFIG_MACRO_DIR([m4]) and distribute the latest guile.m4 version with your project(s), because users might not have guile installed, or not the latest , and therefore an old guile.m4 version, and/or an inadequate $ACLOCAL definition ... but if you distribute the latest with your project(s), it should be fine (robustly fine) even with multiple guile version installed <Arsen>the users' guile.m4 is irrelevant, though, if you distribute your sources correctly <daviid>Arsen: right, but 'relevant' for users who install using an upstream repo clone ... and 'packagers' ... <Arsen>no, not relevant to packagers, and those users are developers, not users <daviid>Arsen: guix uses the upstream (sometimes patched) configure.ac ... but anyway, users/developers is not 'relevant' :) - and i stand by my recommendations, always define AC_CONFIG_MACRO_DIR([m4]) and distribute the latest guile.m4 version with your project(s) <daviid>this conversation reminds me we should patch GUILE_PROGS, so its optional version arg is not a 'fixed' version requirement, but the minimal version the s/w requires ... <daviid>actually 5 screeshots, i just added the (missing) Labels classes example screenshot [ which, if following the demo 'order', should/would be the second screenshot ] <mirai>did this fall through the cracks? the message body looks important <sneek>Not as far as I can remember.