IRC channel logs
2023-04-07.log
back to list of logs
<zyd>should documentation bugs (guile manual) be sent to bug-guile@gnu.org? <daviid>zyd: together with a patch, even better .. <old>I should make a release of guile-ev this weekend <old>I also have a stable guile-configure. a pure scheme build system "compatible" with the gnu coding standard <Arsen>if I send a patch to guile-devel@gnu.org, should I ping it periodically? is that the right ML even? <flatwhatson>Arsen: yes that's the right list, but no you generally shouldn't ping/bump threads <mirai>how about having a guile-patches ML? <mirai>patches in guile-devel seem prone to be forgotten in the sea of mails and it's harder to track which of them have been merged already <mirai>rekado: I guess bug-guile could be “abused” to serve for patch-tracking but wouldn't it be better to have a similar arrangement like there is for guix? <flatwhatson>guile-devel is pretty low traffic, i'm not sure having separate MLs would make much difference <mirai>flatwhatson: just for the purpose of tracking their status? <flatwhatson>oh right, yes having a tracker makes sense. maybe it could just look for [PATCH] on guile-devel? <mirai>guile-devel isn't plugged into debbugs though <Arsen>fwiw, I don't think I saw any mail on guile-devel since posting a patch <Arsen>but I suggest setting up packwork and/or public-inbox <Arsen>this works quite well for some components of the toolchain, less so for others, but b4 never fails to be useful anyway <Arsen>patchwork* didn't spot the typo <old>flatwhatson: guile-configure is not ready for release, but it's usable. I use it in my projects <old>I manully copy the modules under a .configure directory. That way, I can tweak stuff per project ver quickly <old>Here's an example of a `configure' script. I use it in Libpatch my main project <old>It's fairly complex because I do lots of thing in C and there's many options and configuration <old>that configuration in turn can transform *.in file such as Makefile.in and pre-inst-in.in, but it also export the configuration to C, Makefile and Guile module! <old>So I end up in my case with a config.h that I include in my C compilation unit and a config.scm that I can use from the following project.scm which define what to build <old>that project script is actually called from a Makefile so it's transparent to the `configure' `make' `make install' paradigm <old>Support out-of-tree build directory also <flatwhatson>closer to cmake for guile than merely a ./configure :) <old>yes. but it does support standard variable of configure <old>No -DCMAKE_BUILD_TYPE=Debug. Good old CFLAGS='-O0 -g' <old>anyway, I'm free of autotools now ^^ <flatwhatson>me too, by completely avoiding C and lazily relying on guix's guile-build-system and pretending other OS's don't exist <old>That's another thing .. some distros have guile-3.0 <old>I've been careful to ony use 3.0.7 feature and no external depedency because apparently it's hard for distros to package guile library .. <old>So it works at least on ubuntu/debian and Arch Linux from my testing <old>But I would like to add thing for auto-packaging a subset of a project. e.g. copying importants source and a generating a Makefile into an archive <old>the state of Guile outside of Guix is hostile unfortunatelly <old>Arsen: Not trying to burry your proposal here. I think that the patch submission flow could improve <old>singpolyma: Sure! But not on a customer Box that has an enterprise distro <singpolyma>They probably run pip and cargo and npm on there. Why not guix too? <old>Some customers are very conservative, e.g. using very old version of GCC and only rely on packages available on a service pack of the distros <singpolyma>Well, sure, if they want stuff to be in the distro then they can't run your software no matter what language it's in I guess :) <old>well they can build it <old>If it's in C and use autotools <old>not if the build system is a recent release of Guile <flatwhatson>support for "make release" functionality sounds very nice, the other nice thing would be "make docs" taking care of standard texinfo stuff <old>thus the foreign packaging scheme that could be made to generate a minimal Makefile for weird cases like this <old>As you can see, I have a `make repl' so I have a Guile REPL where I simply do `(check)' <old>but yes one could add a `make docs'. In my case, documentation is written in org-mode that is then export to man-pages via emacs <Arsen>isn't make release just make dist, and make docs just, well, make {html,pdf,info} <old>yes. Right now the functionallity are hand-tailored to me need for Libpatch :-) <old>Since I don't use texinfo for that project well it lack support of it <old>But since everything is based on GOOPS, it's trivial for someone to simply augment the set of possibility <old>Just define a new class <buildable> class and implement the <build> method :-) <flatwhatson>that's where having a repo for it would come in, use-cases can be expanded communally :) <flatwhatson>also "make dist" functionality would solve the need for copying it into each project, i think? <flatwhatson>so it can be external, but remain a "dev dependency" only, like autotools <old>flatwhatson: That the goal! I'm making it more stable by the days of using it. Then I will need to move it to its own distro <old>And yes that's the point of `make dist' I would only copy the C source files in my cases and genrate a minimal Makefile that do the `pkg-config' stuffs and all the rules <old>so you end up with a `diet' version of the project that is ready to be compiled from any distro <old>maybe a `make dist' that generate a autotools project could alse be made <mwette>Arsen: maybe best to send patch to both guile-devel@gnu.org and bug-guile@gnu.org <Arsen>I already sent mine, so I'm not sure I should resend, I can if you think I should <mwette>then just send to bug-guile@gnu.org; that way it stays on a list <Arsen>but it is in the guile-devel archives already <old>ehh I just realize that my patch was never sent <old>Can't find it on the ML nor guile-bug <old>eeh not true. I did receive a ticket number but can't find it in debbugs of guile <daviid>fwiw, i do not think any distro/os is/are 'hostile' to guile, at the very contrary i would say ... but i do not want to engage a conversaton on this subject, i just feel a bit annoyed that some of us here constantly try to 'market' guix 'this way' (speaking badly about other distros/os) ... [guix (or any other 'subject' by the way) does not need that kind of 'marketing' anyway ...] - <old>I mean I don't see any guile library on fedora <old>that and it package it wrong by naming guile guile3.0. <old>same for arch linux, I don't see lots of guile-package there <mirai>guile package exists for fedora <old>I meant third party package <old>not Guile itself, but guile-cairo for example <old>Ubuntu is way better on that side, it has a few libraries <old>Arch linux is terrible, only Guile but no libraries <mwette>ubuntu has lots of guile stuff because it's based on debian, which has lots of guile stuff because rlb takes care of us on debian <mwette>redhat is bleeding-edge with guile 2.0.14 <singpolyma>Ubuntu and Debian also both have guix as apt install guix <dsmith> apt-cache rdepends guile-3.0-libs | wc -l <old>I think it was fedora whom disable Makefile Guile extension <old>I vaguely remember that a distro has disabled the GNU Makefile extension for Guile because who use that few MB called Guile? <Arsen>I mean, that'd not be that surprising. I can't even think of a use for such programming in a makefile <old>It's just to show how naive some distros are toward Guile <old>even though I agree that this particular extension in Makefile is probably never used anywhere <Arsen>guile is generally criminally underused. i'm currently working on supporting it better in gentoo <old>bless you for doing god's will