On Wed, Jul 7, 2021 at 8:14 AM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > * Hans de Goede: > > > Hi, > > > > On 7/7/21 1:08 PM, Florian Weimer wrote: > >> * Neal Gompa: > >> > >>> Wait, why don't we have guile 3.0? > >> > >> We have a mandate from Fesco that the core toolchain must depend on > >> Guile. Naturally that makes updates rather difficult. > > > > So I've gone and checked the Fesco issue where dropping guile > > support from make + gdb was discussed: > > > > https://pagure.io/fesco/issue/2558 > > > > And I must say that I find the argumentation for rejecting the > > change very very weak. I would really expect Fesco to make better > > motivated decisions then this one. > > > > I'm especially shocked about how Fesco is in essence mandating > > a group of maintainers to spend time maintaining a feature > > where they clearly have indicated they don't want to maintain > > that feature. > > I guess this is partly on us (on the toolchain side). We missed the > meeting, and no one pointed out that the make change in particular meant > that instead of writing $(guile …), the user arguing for this feature > would have to write $(shell guile …). The make/Guile integration is > simply not very deep. It's not that you can rewrite recipes, have > access to the dependency engine, or anything like that. > If I had known that, I would have voted differently. If using Guile in Make is trivial even without the native support, then documenting how to do it would have been fine. I assumed it was like how GDB's integration works, where you can instrument the tool itself. > (There is deeper integration for GDB, but no one seemed to be concerned > about that for some reason.) > I have not seen any Guile usage for instrumenting GDB. Everyone uses Python. So, this didn't really bother me. For Make, there was no other option, and I didn't know the Guile integration wasn't much of one that could be replaced with a shell exec. If you were dropping *both* Guile and Python, we would have words. :) -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
