build: let a build config declare host after a cross build - #7239

Stacked on #7238, which reads the defines a cross target and its mrbc have to
agree on from the build as well as from the compiler, and keeps them in
MRBC_DEFINES. Its commit is the first here and is not part of this change.

A build config that declares an MRuby::CrossBuild before its own
MRuby::Build.new('host') cannot be built. No defines, no toolchain settings,
nothing but the order:

MRuby::CrossBuild.new('cross') do |conf|
  conf.toolchain
  conf.gem :core => "mruby-bin-mruby"
  conf.test_runner.command = 'env'
end

MRuby::Build.new('host') do |conf|
  conf.toolchain
  conf.gem :core => 'mruby-bin-mrbc'
  conf.gem :core => 'mruby-bin-mruby'
end

$ rake
rake aborted!
Don't know how to build task 'build/host/lib/libmruby.a' (See the list of available tasks with `rake --tasks`)
Did you mean?  build/host/bin/mruby
               build/cross/lib/libmruby.a
tasks/presym.rake:5:in 'block (2 levels) in <top (required)>'

Swapping the two declarations builds fine.

Why

CrossBuild#initialize settles the build it borrows mrbc from as the target
is declared, and where the config has written no host yet it generates one
under that name, deliberately crippled:

        MRuby::Build.new('host') do |conf|
          conf.toolchain
          conf.build_mrbc_exec
          conf.disable_libmruby
        end

Build#initialize initialises a target only when the name is free, and reopens
it otherwise. Every instance variable, @enable_libmruby included, sits inside
that unless:

      unless current = MRuby.targets[@name]
        ...
        @enable_libmruby = true
        ...
        MRuby.targets[@name] = current = self
      end

      MRuby::Build.current = current
      begin
        current.instance_eval(&block)

So the config's own host block does not run on a fresh build. It runs on the
generated one, which already carries disable_libmruby and a gem list of its
own. libmruby_enabled? stays false, no libmruby.a rule is defined for
host, and tasks/presym.rake asks for one.

The failure is loud, so nothing is silently miscompiled, but the message names
a missing rake task and points at presym.rake, which says nothing about
declaration order. No in-tree config is affected:
build_config/IntelEdison.rb is the only one that declares both, and it
declares host first.

What this does

Ask the question once, from the Rakefile, where the config has been read whole.
MRuby.resolve_mrbc_hosts binds every cross build before any gem is set up, so
a host written after a cross build is as visible as one written before it,
and the defines the answer turns on are still the ones the config alone has
written.

A cross target that cannot borrow a declared host then borrows a build
generated under a name of this code's own, named for the MRBC_DEFINES it
carries rather than for the target that asked for it first:

The name is one a build config does not write, so nothing generated here takes
a name the config wants, and build/mrbc is where mrbc built for its own
sake goes, which is where build_config/mrbc.rb already puts it. build/host
is left to a host the config declares, so an ordinary host build no longer
meets a MRB_NO_GEMS object a config of cross builds alone left behind.

Two things follow for a config of cross builds alone. No host target is left
for rake install and rake install_bin to name, so they fall back to every
target the config did declare. And tasks/presym.rake reads mrbc_build to
leave the generated build's objects to it, which a cross target named mrbc
holds in its own directory and would otherwise scan as its own, 62 files
against 49.

Verified

One build directory, build_config/default.rb and then
build_config/minimal.rb and then build_config/default.rb again: 145
compiles for the cross build and its mrbc, and nothing recompiled when the
default config comes back to it, the two having no directory in common.

Environment

No C source changes, so .text is unaffected in every build.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JJf1R2cytz2gAnJ2CgpGp1

Summary by CodeRabbit

• New Features

  • Improved cross-build compiler handling, including automatic compatibility checks and reuse of compatible generated builds.
  • Added support for installations when no dedicated host build is available.

• Bug Fixes

  • Prevented conflicts between generated and declared build names.
  • Ensured cross-build compiler assignments are resolved correctly after all targets are loaded.

• Documentation

  • Clarified build-generation behavior in installation-related documentation.