Don't fail if there is no makefile, simply don't do anything.

[ioquatix]

On some platforms, no native extensions should be created. This is typical for JRuby. Due to limitations in the extension builder, it is typical to create a dummy makefile that does nothing:

https://github.com/search?q=File.write+Makefile+path%3A**%2Fextconf.rb&type=code

This seems like a bad pattern.

• It's not intentional: we are faking the creation of a makefile for the sake of "build" and "clean".
• It's inefficient: make is still invoked several times even when no build steps are required.
• It's difficult: gems with native extensions for JRuby have to jump through hoops in order to work.
• It clutters the output: creating unnecessary files and artifacts.
• It's confusing: it suggests a native build occurred when it didn't and makes debugging build issues harder.

I think it would be preferable to just do:

# extconf.rb

return if build_not_required?

require "mkmf"

...

create_makefile

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[headius]

I'm +1 for this of course. May also help #3520?

[ioquatix]

I don't really understand the full issue here, but in order to support #3520 we'd probably need to communicate the fact that no native extension was built back to the index that's tracking what gems are compatible with what, if any such index exists.

[eregon]

LGTM as well, seems convenient and cleaner than a dummy makefile.

[deivid-rodriguez]

Thank you!

More work will be needed for #3520, but this is a good change and everyone agreed with it over at #7372 and https://bugs.ruby-lang.org/issues/20152.

The implementation seems fine to me, too 👍.

I'll leave this opened for a couple more days in case additional reviewers show up, but I'm good with this!

[deivid-rodriguez]

Let's do this, thanks so much @ioquatix!

[eregon]

For convenience: this got in RubyGems 4.0.0 but not earlier versions.
That means this trick can only be used unconditionally in gems not supporting Ruby < 4.0.
For gems supporting Ruby 3.x they'll need to either use the dummy makefile approach unconditionally, or use a mix of both (return on RUBY_VERSION 4.0+, dummy makefile otherwise)

[fxn]

For a gem that has a portable Ruby implementation, but that may optionally optimize something in C if possible, would it make sense to ship a gemspec that defines spec.extensions depending on Gem::VERSION?

spec.extensions = ["ext/zeitwerk/extconf.rb"] if Gem::VERSION >= ...

Or could that break some assumption about gem contents in RubyGems somehow?

[eregon]

@fxn That does not work, because there is a single gemspec serialized to YAML/etc uploaded to rubygems.org and so that conditional is "lost" after publishing the gem.

[fxn]

Thanks @eregon, I have written a doc patch for it: #9321.