Il giorno dom 17 mag 2020 alle ore 17:35 Alex Sassmannshausen < alex.sassmannshau...@gmail.com> ha scritto:
> Hey Cato, > > Catonano <caton...@gmail.com> writes: > > > […] > > > > This is an important step in making the Guile user experience less rough > > > > Where, in the manual, should such mention be placed ? > > I guess section '4.6 Using Guile Tools' might be a good place to put it? > > 4.5 advetises paredit and geiser — but that is specific to Emacs. 4.6 > is about guile tools more generally. So I imagine something like the > blurbs about paredit and geiser, but then for hall and in 4.6? > > What do you think? > > I'm ok with that I'm somewhat puzzled by 4.7, it's about installing Guile code. It mentions system controlled locations (on traditional systems) such as usr/lib/... it seems it assumes that people install guile object files by hand ? On another side, if you have some .scm files scattered around, they will be autocompiled and the result will be put into some well hidden buried folder in your home folder Ah but that's for things that only you as a user can access System locations are for all the users on a machine I mean: the whole distribution story is not clear It's not as clear how you're supposed to package your stuff and how people who receives your stuff are supposed to deal with that As in many cases, the Guile manual is detailed about properties and features and way less concerned about use cases (in this regard, I suggest this talk https://archive.fosdem.org/2017/schedule/event/legacy_docs/ ) The assumption is that based on properties and features, you can come up with a user case that fits your needs yourself it's a bit of a heavy assumption 🙁 Overall, I'd say this: There is level 0 of Guile packaging: that's NO packaging. You keep your files scattered around and they will be autocompiled You put your files in a git repo on line, your friends will check them out and autocompile them too Then there's level 1: when things get a bit more structured, for example your package may depend on some other Guile library or on a specific version of Guile In that case, you need to setup the autotools in your project Distros such as Ubuntu and Fedora will be able to distribute your package and your friends on Gentoo will be able to deal with them by hand In the future, there could be a level 2. That is: no m4 anymore !! As fas as I undertsand the Autoconf based machinery relies on bash to execute tests (is such library available ? Is Guile version >= 2.7 ?) And Guile is perfectly able to substitute bash scripting. So we could collect a series of common tests used for configuring Guile packages and implement them in Guile ! That would introduce the assumption that Guile is as widely available as Bash is and that'd be debatable But I'd go for that anyway Wrapping up: yes, 4.6 is good for a mention of guile-hall But things like 4.7 (and maybe others) will confuse people it took me years to figure out the Guile distribution story and this email is a distillate of years of confusion I'll try to write a mention of guile-hall for the manual and send a patch. Not right now, though. In the coming days Thank you Alex for giving me a chance to extend myself on the Guile distribution story
