build: build the gem loader object through the rules - #7250

build/<name>/mrbgems/gem_init.o, the object that boots every gem of a
build, is the one object tasks/mrbgems.rake declares by hand: a file
task without an action, with the generated gem_init.c and LEGAL as its
prerequisites. Rake finds the rule for it, but only when the task runs,
after it has already answered needed? from those two files alone. The
.d its compile writes and the flags record beside it are read by the
prerequisite procs of the rule, and for this object those never ran. A
header it includes changing, or a define reaching the build by a way that
leaves MRUBY_CONFIG untouched, left the old object in libmruby.a.

The header case is visible from the outside. gem_init.c reads mrb->c
and mrb->exc; add a field at the top of struct mrb_state and run
rake:

$ rake                        # built once
$ sed -i 's/^  struct mrb_jmpbuf \*jmp;$/&\n  void *probe_pad;/' include/mruby.h
$ rake                        # 152 CC, gem_init.o not among them
$ bin/mruby -e 'p 1'
Segmentation fault (core dumped)
$ rake                        # nothing to do
$ bin/mruby -e 'p 1'
Segmentation fault (core dumped)

Every other object of the build is compiled again; gem_init.o keeps the
old offset of mrb->c, and mrb_init_mrbgems dies at mrb->c->cibase
under mrb_open.

Why

file objfile(gem_init) => [gem_init.c, LEGAL] (2013, 15871eb) exists to
have a build write LEGAL without archiving it: LEGAL used to sit in
the object list of libmruby.a and was moved to a prerequisite of this
object. Rake's Task#execute runs enhance_with_matching_rule for a task
without an action, so the rule's action does compile the object, and its
prerequisite procs do run then; but that is after invoke decided from
the written prerequisites whether to execute at all. mrblib.o, the other
generated object of core, declares no task and is built by the rule from
Compiler#define_rules alone, which reads the .d and discards an output
whose recorded flags differ (#7236).

What this does

• tasks/mrbgems.rake no longer declares the object. The rule pairs
  mrbgems/gem_init.o with mrbgems/gem_init.c in the build directory as
  it does for mrblib.o, and its .d and flags record take effect.
• LEGAL becomes a product of the build in tasks/libmruby.rake, beside
  the libmruby.a whose contents it describes. It stays out of the
  archive as before, and it is still written by a plain rake. A build
  without a gem writes it too now, with the mruby license alone; the
  mrbc build (disable_libmruby) still does not.

Verified

rake -m -j16, CCACHE_DISABLE=1, gcc; default gembox with
enable_bintest and enable_test; the build directory built once on
master (0122b45) before each row, and the run after each row does
nothing in both columns.

The 165 in the master column is 208 objects less the 42 Prism objects
(#7248) and this one.

Environment

gcc -MMD -c -std=gnu99 -g -O3 -Wall -Wundef -Werror-implicit-function-declaration -Wwrite-strings -DHAVE_MRUBY_REGEXP_GEM -DMRB_USE_SET -DHAVE_MRUBY_IO_GEM -DMRB_USE_RATIONAL -DMRB_USE_COMPLEX -DMRB_USE_BIGINT -DMRB_USE_DEBUG_HOOK -I"include" -I"build/host/include" -o "build/host/mrbgems/gem_init.o" "build/host/mrbgems/gem_init.c"

No C source changes and the compile line is the same, so .text is
unaffected in every build.

Summary by CodeRabbit

• Bug Fixes
  • Improved build packaging so the generated legal notices are included with static MRuby build products.
  • Prevented license text from being bundled inside the archive itself.
  • Simplified dependency handling for generated gem initialization files.