On Wed, Jul 7, 2021 at 8:14 AM Florian Weimer <fweimer(a)redhat.com> wrote:
* Hans de Goede:
> 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:
> 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
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!