Issue #16517 has been updated by shevegen (Robert A. Heiler).


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 :)).

----------------------------------------
Feature #16517: mkmf.rb - changes for Windows ?
https://bugs.ruby-lang.org/issues/16517#change-83982

* Author: MSP-Greg (Greg L)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
I propose two changes to mkmf.rb to make it more Windows friendly.

1) mingw - `devkit` has been the standard for 'enabling' compile tools in publicly available MinGW builds for quite a while.  Could something like the following be added?  Not sure whether to rescue on LoadError or not, or whether to output anything if it doesn't load.

```ruby
if $mingw
  begin
    require 'devkit'
  rescue
  end
end
```

2) mswin - most compile tools other than msvc will find libraries without a lib prefix.  Note the following code in extconf.rb for OpenSSL:

```ruby
ret = have_library("crypto", "CRYPTO_malloc") &&
  have_library("ssl", "SSL_new")
return ret if ret

if $mswin
  # OpenSSL >= 1.1.0: libcrypto.lib and libssl.lib.
  if have_library("libcrypto", "CRYPTO_malloc") &&
      have_library("libssl", "SSL_new")
    return true
  end
```

If something like the following was added, the above wouldn't be needed:

```ruby
if $mswin
  alias_method :orig_find_library, :find_library
  
  def find_library(lib, func, *paths, &b)
    orig_find_library(lib, func, *paths, b) || orig_find_library("lib#{lib}", func, *paths, b)
  end

  alias_method :orig_have_library, :have_library

  def have_library(lib, func = nil, headers = nil, opt = "", &b)
    orig_have_library(lib, func, headers, opt, b) || orig_have_library("lib#{lib}", func, headers, opt, b)
  end
end
```

Adding something similar to above two items would remove the need for Windows specific build code in many extension gems.




-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>