Just a comment or two - please don't get distracted from the main issue greg referred
to, it is just my opinion:
Taking it further, *.gemspec metadata could include the names of packages required
for Ubuntu, macOS, mingw, and maybe mswin. T
I think it would be better to not include specific distributions per se, as people
may want to add their own distributions to that list ("why is distribution A a
first-class citizen but not distribution B?"). IMO it would be best if rubygems
- mkmf are just as agnostic as possible, and as flexible/adaptable as possible.
That way distributions can adjust the ruby ecosystem to their needs, without
needing special per-distribution hooks as such.
As for where to include the code as such, I would actually recommend to have mkmf
support the functionality if that functionality is currently missing, rather than
put it into the one-click installer or elsewhere, IF this is in general
windows-platform specific (been some time since I last used windows + msys/mingw).
So from that point of view, if there are no significant trade-offs otherwise, I
would agree with lars in regards to his statement "[...]mkmf.rb is a good place
to add require 'devkit' [...]", with which I would like to agree with.
On a not-so-related note, the meson/ninja team once wondered whether, perhaps
two years ago, to include code for general enhancement of functionality that
only one or two distributions did want or added (fedora was one), or whether to
let the distributions handle such add-on case(s) on their own.
Back then I reasoned that it would be better to include general-purpose functionality
that could benefit distributions right into meson directly, and bundle it there, since
that would benefit more people than special per-distribution modifications only. It
would also help against dilution of enhancements to meson, which I think is better
in the long run to avoid - sort of like having a "standard", "generic" specification
for meson in one place primarily.
Following the same reasoning here for ruby and the ruby-ecosystem, IMO it would make
sense to have mkmf support it too (perhaps structure that code as a gem-plugin for
mkmf or so; that way you can always decide to not include it lateron, but I would also
recommend to add support for it into mkmf; after all one reason for gemifying
the ruby stdlib was to make it easier to add/remove gems/code by default too,
like what Hiroshi Shibata has been doing a lot in the last years :)).