IRC channel logs
2025-09-05.log
back to list of logs
<identity>jklowden: gnu is dealing with scrapers, stuff periodically goes down <jklowden>Thanks. Seems worse than usual. I was unable to subscribe to the mailing list or retrieve the archives. I'm diving in the deep end with syntax-rules. <jklowden>(Heh. Subscribe-by-mail still works, just takes a while.) <rlb>iirc, guile also doesn't switch the reader back at the end of a module for some things, i.e. if you enable postfix/prefix keywords (:foo or foo:) in your module, (and don't manually reset somewhere) it can break modules that are loaded later. I'd originally thought I wanted it to be "module scoped" by default, a while back, but now I don't know. <rlb>(I can't recall if there might be some similar language-related entanglement.) <sneek>Welcome back euouae, you have 2 messages! <sneek>euouae, ArneBab says: the .go files are distributed, because that avoids long startup times on first run after update. With long, I mean minutes for a somewhat large program. After that, if you don’t have precompiled *.go files, guile will auto-compile them. <sneek>euouae, ArneBab says: another reason is that *.go files are language-independent. Whether you wrote your logic in elisp, in ecmascript, in wisp, in brainfuck, or in pure scheme: once it’s compiled to *.go files, you can use it from any other language. <euouae>Here's my Guile sample project that works with `make install` and `make uninstall` and `make dist`. <euouae>I have not made `make distcheck` work yet. <euouae>I suspect the reason is that GUILE_SITE is not configurable to be a local directory outside of /usr. Any insights are welcome -- I have not bothered yet with installing .go files. This only installs the .scm files. <euouae>oh shoot! I made `make distcheck` work by setting DESTDIR=/tmp <euouae>ArneBab: the main issue is that Guile provides guile.m4 with GUILE_SITE ignoring --prefix etc <euouae>it's just a hardcoded path that pkg-config returns <euouae>so distcheck tries to install stuff there and fails <euouae>Does anyone know why guile has GUILE_SITE instead of respecting --prefix? Ping: civodul wingo <ArneBab>euouae: I think you found a bug. I also had to meddle with site to get distcheck working. <euouae>Yes it's a bug, but how should it be fixed? I'm trying to determine what the constraints are <euouae>I.e. should Autoconf/automake be patched? is it a mistake of Guile? <ArneBab>I think that prefix should win, because it’s actual user input. <euouae>I think Guile may have decided that 1) it's inferior and therefore should not respect --prefix and 2) what it cares about is working on Guix <euouae>It's a possible explanation, I don't know if it is the correct explanation <ArneBab>I’m not sure whether guile.m4 sees much maintenance. <euouae>yeah but I don't think it can be fixed from within guile.m4, that's the problem <euouae>if we must go that route, we need to patch autoconf <euouae>two options: 1) patch autoconf to provide mechanism for --guile-site=... (and somehow fix distcheck) or 2) reorganize the entire Guile modules, source codes, etc, to be under --prefix not tucked away by itself in /usr/share/guile <euouae>the second option would make a guile library (say foolib) be installed under /usr/lib next to all the "normal" libraries written in C, C++, etc <ArneBab>Where the modules are searched for is defined by GUILE_LOAD_PATH, so using prefix should be no problem. <ArneBab>and /usr is the default prefix, so /usr/share/lib/… is under prefix <ArneBab>(and I think (2) isn’t correct -- guix is really nice to use with Guile, but Guile is bigger than Guix) <euouae>okay so it really comes down to autoconf support then <euouae>we need something more than foo_DATA = and foodir = <euouae>because those require the path to be installed and they break distcheck <ArneBab>We can change the site dir from Makefile.am <euouae>what is needed is that the correct rules are generated for distcheck <ArneBab>Are you sure that you found all possible paths? <euouae>in C you don't have to specify foodir because foo_PROGRAMS = ... and foo_SOURCES = ... and so on are correctly creating all the rules (make install, make distcheck, etc) <euouae>but autoconf recognizes the .c and .cpp files <ArneBab>In C you also have resources that need to be put in prefix. <ArneBab>but if improvements in autoconf are needed, that’s the way to go, I think. <euouae>I know, the point I'm trying to make is that autoconf has first-class support of C and C++ <euouae>it recognizes the file extension <euouae>You can't do that with Guile because .scm is not "guile" but scheme, whatever that means <ArneBab>I found autoconf + automake to be very flexible, that’s why I’m not sure whether there’s no way to make that clean. <euouae>Youd' have to make up an extension to begin with? like foo.guile. Another possibility is that with some AC macro you turn on support for .scm files to be treated as guile files <euouae>An example is this: you can't add custom options in configure scripts <euouae>you can only add --with-* and --enable-* options <ArneBab>I used more than half a dozen other build systems, all of them were less flexible than autoconf. <ArneBab>That’s just an API convention, not missing flexibility. Simply use --enable-* -- reusing recognizable patterns means that it’s an API, not that it lacks flexibility. <euouae>--with- is for packages and --enable- is for features <ArneBab>And ./configure FOO=bar sets variables. <euouae>well if autoconf and automake are so great ;-) why is Guile's distcheck broken <euouae>the proof is in the pudding as they say. something is amiss. <Arsen> 09:25:07 <euouae> well if autoconf and automake are so great ;-) why is Guile's distcheck broken <Arsen>presumably because nobody fixed it? <euouae>Yes, and nobody has fixed it because it's hard to fix <euouae>I've been trying for a long time <Arsen>there's programs of similar qualities that do have a working distcheck <euouae>Well I'm not complaining about distcheck for C programs <Arsen>the poke VM is C, but poke is implemented in poke <euouae>Wait a second, you're saying there's one project that implements its DSL that has a working distcheck for itself? <Arsen>I'm saying there's at least one <Arsen>poke is written in poke and has a working distcheck <Arsen>lemme try distchecking emacs, written in elisp; that probably works <euouae>I think you're a bit confused here <Arsen>oh boo, emacs lacks a distcheck target <euouae>That there's projects that have working distchecks does not mean a programming language implementation that ships with m4 macros etc has a working distcheck <Arsen>I don't see how that meaningfully distinguishes poke and guile <euouae>Can you show me other people writing poke programs in poke with working distchecks for their autotools projects? <euouae>hes using picklesdir = $(datadir)/poke/pickles <euouae>the issue with Guile is that the guile binary will not pick up $(datadir) in its load path <Arsen>that's unrelated to distcheck <euouae>no its not, how are you supposed to set foodir? <euouae>If you use $(GUILE_SITE)/foo, then you break distcheck <euouae>feel free to try, you can't run make distcheck as a normal user because you can't write under /usr <Arsen>I literally ran distcheck as a normal user <euouae>Try to run make distcheck and send me the log <Arsen>~/gnu/poke-elf/_build$ make -j distcheck <Arsen>poke-elf-1.0 archives ready for distribution: <Arsen>~/gnu/poke-elf/_build$ grep picklesdir Makefile <Arsen>picklesdir = $(datadir)/poke/pickles <euouae>Yes poke-elf is fine, but Guile has issues <euouae>Guile did not make the executive decision to have stuff under the usual directories. They came up with their own GUILE_SITE etc. <euouae>When you set foodir=$(GUILE_SITE)/foo and run distcheck, it will attempt (as a normal user) to write to $(foodir), which is under /usr. Thus distcheck fails. <Arsen>that happened because GUILE_SITE doesn't respect prefix <euouae>I agree, but why was this decision made? <Arsen>I don't see any way you can reconcile "pick value from system" with this, no matter the language or directory <euouae>The problem is that distcheck doesn't work for Guile <Arsen>no, your packages distcheck doesn't work <euouae>You're saying that this is a distro problem? <euouae>The debian maintaienrs should had installed guile under prefix? <euouae>What is the purpose of GUILE_SITE from meta/guile.m4? <Arsen>you're using it correctly, that's not the issue <Arsen>hell, you could argue that distcheck should use DESTDIR besides just --prefix to relocate its install test <Arsen>I'm inclined to agree with that <Arsen>that'd fix this issue and still keep GUILE_SITE being the correct, detected value <euouae>Yes maybe autoconf can be patched to do that, or at least allow for a macro that does that. <euouae>If one could AC_I_WANT_TMP_DESTDIR_BY_DEFAULT <Arsen>now, wrt the custom directories thing <Arsen>IMO it's still useful to allow adding new ones <Arsen>but, the existing directory variables are *not* for C, or whatever <Arsen>oh, it intentionally checks without DESTDIR <Arsen>to see if you forget to relocate the install <Arsen>interesting topic for discussion on the automake ML at any rate :) <euouae>Will you chip in? I feel like you know a bit more <Arsen>I'm subscribed so if I feel like I can contribute, I will <Arsen>at least I think I'm subscribed <euouae>I don't understand your very last comment "intentionally checks without DESTDIR" <euouae>I sent the ML a message, not sure if it posted, though gmail didn't complain. gnu.org is getting DDoS'd hard <Arsen> 09:52:05 <euouae> (i.e. it runs install?) <euouae>I don't encounter that issue; if I set DESTDIR=/tmp it works fine <euouae>If I don't set DESTDIR, it tries to write under GUILE_SITE <ArneBab>sneek: later tell euouae: wisp distcheck works, and it’s built on guile distcheck. So while autoconf or automake improvements could make this more convenient (it was a hassle) they are not required to make it work. <dsmith>rlb, I noticed the other day with "make check" on fbsd that an error in a test would stop and not run remaining tests. <dsmith>rlb, I don't remember it behaving that way before. <dsmith>rlb, ISTR something about making the checks parallel? (make -j) <rlb>And I can't remember exactly where that ended up offhand -- but if you get intereseted, we now use the (not deprecated) automake "parallel test harness" (see automake info). <dsmith>(info "(automake-1) Parallel Test Harness")