mrbgems: let a build take a gem back out of a gembox - #7154

Taking up the invitation at the end of #7142.

MRuby::Gem::List has [] and << and nothing that removes, so a build config that wants a gembox minus one gem has to restate the box. full-core.gembox is a five line glob and can be re-globbed, as you showed; default.gembox cannot, and build_config/i586-pc-msdosdjgpp.rb pays for it in full:

# All provided gems that can be reasonably made to compile:
# default.gembox, minus mruby-socket and replacing mruby-cmath with mruby-cmath-alt
conf.gembox "stdlib"
conf.gembox "stdlib-ext"

conf.gem :core => 'mruby-io'              # stdlib-io.gembox <- default.gembox
# No socket support in DJGPP
# conf.gem :core => 'mruby-socket'        # stdlib-io.gembox <- default.gembox
conf.gem :core => 'mruby-errno'           # stdlib-io.gembox <- default.gembox
...

Twelve lines hand-expanding one box, each carrying a comment naming the box the line came from, so that one gem can be left out.

The reach for this is conf.gems.reject!, which raises NoMethodError. conf.gems.reject is worse: it comes from Enumerable, builds a new Array and drops it, so the removal reads as if it worked and does nothing.

What is added

List#delete, which names the gem, and List#reject!, which takes a predicate.

conf.gembox 'full-core'
conf.gems.delete 'mruby-encoding'

delete fails when the name is not in the build rather than returning nil, following Can't find gembox and Invalid gem name elsewhere in the build system. A misspelled name is a typo, and a build that silently keeps the gem is the failure this method exists to remove. reject! keeps Array semantics and returns nil when it matches nothing, since a predicate matching nothing is not a mistake.

Why removing after the fact is sound

The phase boundary this needs already exists. Specification#initialize stores the block and runs nothing (gem.rb:46); the body, including every spec.build.defines <<, runs in Specification#setup (gem.rb:94); and the Rakefile reaches gems.setup only after load MRUBY_CONFIG (Rakefile:19-31). So a gem removed while the build config is being read contributes nothing at all, not its objects and not its defines.

Measured on full-core, evaluating the config and running gems.setup with no compilation:

What stays behind after a removal is enable_cxx_exception, which LoadGems#gem decides from the gem's sources, and the @gem_checkouts entry for a gem fetched from git. No core gem has a .cpp, .cxx or .cc file under src, test or tools, so the first never fires for the gems a gembox carries; the second only shows up if a removed git gem is re-declared at another revision.

I did look at moving the mrbgem.rake load out of conf.gem so that nothing at all happens before the config is read. I am not proposing it. It buys the two residues above, neither of which a core gem can reach, so nothing in the tree could show it working. It also weakens this API rather than strengthening it: the list during config would hold requests, whose only name is the :core => key or a URL basename, and the tree already treats that name and spec.name as separable, since gem.rb:504 fails when they disagree. Removal by spec.name is exact today.

The one thing removal cannot do

A gem that another gem in the build declares as a dependency comes back. Dependencies are declared in Specification#setup, a phase after delete runs, so delete cannot check against them, and setup_dependencies loads the gem again. conf.gems.delete 'mruby-string-ext' on full-core ends with the same 58 gems it started with.

Keeping it is right, since mruby-regexp cannot be built without it. Staying quiet is not, so the second commit records what was removed and says so when it comes back:

gem 'mruby-string-ext' can't be removed; mruby-regexp depends on it

23 gems in a full-core build with tests enabled are reachable this way, 17 without, the difference being add_test_dependency, which is add_dependency under test_enabled? || bintest_enabled?. mruby-encoding is in the larger list and is still removable, because mruby-regexp and mruby-sprintf guard that dependency on the gem being present and the guard is read after the removal.

Split into its own commit in case you would rather this said nothing, or failed instead. Failing reads well until you see where it lands: the config line that removed the gem is long gone by gems.setup, so the message would arrive without it.

Not included

build_config/i586-pc-msdosdjgpp.rb could now say conf.gembox "default" and one delete, which is what its comment already claims it does. Its hand expansion is not equivalent to default.gembox though: besides mruby-socket, it is missing mruby-env, which stdlib-io.gembox carries and the comment does not mention. That looks like an expansion that was not kept up rather than a decision, but DJGPP is not built in CI and I cannot test it, so I left the file alone.

Tests

There is no test suite for the build system, so the verification is builds. MRUBY_CONFIG=ci/gcc-clang rake -m test is green at every commit, 2281 / 2281 / 2280 tests and 116 bintests, KO 0.

Beyond that: full-core minus mruby-encoding builds and answers as a byte indexed build should, "あ".length is 3 and Encoding is undefined; a misspelled name fails at the build config line that wrote it; reject! returns self when it removes and nil when it does not.

Summary by CodeRabbit

• New Features

  • Added support for removing gems from a GemBox by name or condition.
  • Gem removal now reports errors when the specified gem is missing or required by another gem.
  • Removed dependencies may be automatically restored when required during dependency resolution.

• Documentation

  • Expanded gem compilation guidance with removal examples, behavior details, ordering requirements, and dependency-related errors.