build: write a generated source again when the list of its inputs changes - #7255

mrblib.c, the gem_init.c of every gem and the sources of mrbtest
are written from a list of files, and the list itself is not among the
things Rake compares. A file that is gone is not a prerequisite any more,
so the ones that remain are all older than the last generation, and
nothing runs:

$ rake                                  # built once
$ printf 'class Integer; def zip; 42; end; end\n' > mrblib/zz_probe.rb
$ rake                                  # 1 GEN, 1 CC
$ bin/mruby -e 'p 1.zip'
42
$ rm mrblib/zz_probe.rb
$ rake                                  # nothing
$ bin/mruby -e 'p 1.zip'
42                                      # and after every rake from here on

The same for a test file removed from a gem: rake test keeps running
it. The gem_init.c of a gem also depends on two values that are not
files at all: whether the gem has native objects, which decides whether
the generated mrb_<gem>_gem_init call is written, and whether cdump
is on. Adding a src/probe.c to a gem that had only Ruby files compiles
and archives it, and its mrb_..._gem_init is never called; removing the
last one leaves the call in place, and the link fails at the next archive
and stays failed. spec.disable_cdump in an mrbgem.rake is not seen
either. Each of these takes a clean build, or a deleted stamp, to get
out of.

Why

Rake compares times of files that are there. The set of inputs, and a
value read from a spec, leave no time behind. active_gems.txt in
tasks/mrbgems.rake is the in-tree answer to the same question for the
list of gems: a task that always runs writes the list only when it
differs, and the loader depends on the file. The flags record beside
every object (#7236) does the same for the compile line. The stamp of
generated_file (#7254) is the place for the list of a generated source.

What this does

generated_file in lib/mruby/core_ext.rb writes the list of the
prerequisites and of inputs, the values the caller names, into the
stamp, one per line, and the stamp task is needed when the list on disk
differs from the list of this run. gem_init.c names cdump? and
objs; the other four generators pass no inputs, the prerequisite list
covers them. Nothing else changes: the same prerequisites, the same
write only when the text differs, the same compile lines.

Verified

rake -m -j16, CCACHE_DISABLE=1, gcc; default gembox with
enable_bintest and enable_test; the build directory built once
before each row, and the run after each row does nothing in both columns
unless the row says otherwise. mruby-compar-ext is the gem with only
Ruby files used for the rows about native objects.

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/mrblib/mrblib.o" "build/host/mrblib/mrblib.c"

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

Summary by CodeRabbit

• Bug Fixes
  • Generated files are now refreshed when their prerequisites or input values change.
  • Missing generated files are correctly detected and rebuilt.
  • Gem initialization output now updates when relevant source files or build settings change.