build: build the Prism objects through the rules - #7248

mruby-compiler compiles the Prism sources with a file task of its own
instead of the rules every other object of a gem is built by. A file task
has the prerequisites it is written with, here the source alone, so nothing
reads the .d a compile of a Prism object writes and nothing compares the
flags the object was compiled with against the flags of now. The 21 Prism
objects of a build (42 with the mrbc build) are the only objects outside
both, and they stay as they are through a change to a Prism header and
through a change to the compile flags.

The flags case is visible from the outside. PRISM_DEPTH_MAXIMUM is the
nesting cap Prism refuses input at, and mruby-compiler's mrbgem.rake sets it
to 256 unless the config sets it first. Setting it in the config of a build
directory that was built once leaves the cap where it was:

$ rake                                   # built once, cap 256
$ echo 'conf.cc.defines << "PRISM_DEPTH_MAXIMUM=64"' # added to the config
$ rake                                   # 165 CC, none of them Prism
$ bin/mruby -e "$(printf '[%.0s' {1..100})1$(printf ']%.0s' {1..100}); p 1"
1
$ grep -o 'PRISM_DEPTH_MAXIMUM=[0-9]*' build/host/mrbgems/mruby-compiler/lib/prism.o.flags
PRISM_DEPTH_MAXIMUM=256

Why

Dir.glob over the Prism sources registers each object with
file obj => [src] do prism_cc.run ... end. Rake takes the task as it is
written, so the object is up to date whenever it is newer than its .c;
the -MMD output beside it is written and never read, and
Compiler#get_dependencies, which reads the .d and discards an output
whose recorded flags differ (#7236), runs from the rules only. Everything
else a gem builds, its own sources and its generated gem_init.c, goes
through Compiler#define_rules.

The file task was where the compiler for the C++ ABI build was made: a
clone of the gem's cc with the C++ compile flag stripped and
MRC_ALLOC_LIBC added, cloned inside the action because Compiler#clone
is a deep copy and the mrbgem.rake body runs before the gem's version
define, the include paths of the gems it depends on and the presym include
path reach cc. A rule defined in the body would have had to name its
compiler in the body.

What this does

• Compiler#define_rules takes a block that names the compiler to run
  with. The block is called when a rule is resolved, not when the rules
  are defined, so a compiler it derives from the receiver sees everything
  the build added to the receiver since. Without a block the rules run
  with the receiver, as before. get_dependencies becomes protected so
  the rules one compiler defines can ask the compiler they run.
• mruby-compiler registers the Prism objects with define_rules and
  derives the C++ ABI compiler in the block, once. The objects mirror the
  Prism source tree (lib/util/pm_buffer.o for src/util/pm_buffer.c),
  since a rule maps an output to its source by path; the file task
  flattened them into lib/.

The compile lines do not change: every Prism object is byte-identical to
the one master builds at the same path, in the default and in the C++
ABI build, and so is bin/mrbc; bin/mruby differs only in the debug
line strings that spell the build directory.

Verified

rake -m -j16, CCACHE_DISABLE=1, gcc; the build directory built once on
master (0122b45) before each row, and the run after each row does
nothing in the "this PR" column.

The 207 is 208 objects less build/host/mrbgems/gem_init.o, whose file
task in tasks/mrbgems.rake has no action and takes the rule's at execute
time, after Rake has decided it is up to date; that one is outside this PR.

Environment

gcc -MMD -c -std=gnu99 -g -O3 -Wall -Wundef -Werror-implicit-function-declaration -Wwrite-strings -DPRISM_XALLOCATOR -DPRISM_DEPTH_MAXIMUM=256 -DMRC_TARGET_MRUBY -DPRISM_BUILD_MINIMAL -DMRBGEM_MRUBY_COMPILER_VERSION=0.0.0 -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"mrbgems/mruby-compiler/include" -I"mrbgems/mruby-compiler/lib/prism/include" -I"mrbgems/mruby-compiler/include" -I"build/host/include" -o "build/host/mrbgems/mruby-compiler/lib/prism.o" "mrbgems/mruby-compiler/lib/prism/src/prism.c"

gcc -MMD -c -g -O3 -Wall -Wundef -Wwrite-strings -DPRISM_XALLOCATOR -DPRISM_DEPTH_MAXIMUM=256 -DMRC_TARGET_MRUBY -DPRISM_BUILD_MINIMAL -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DMRBGEM_MRUBY_COMPILER_VERSION=0.0.0 -DMRC_ALLOC_LIBC -DMRB_USE_CXX_EXCEPTION -DMRB_USE_CXX_ABI ... -I"build/host-cxx/include" -o "build/host-cxx/mrbgems/mruby-compiler/lib/prism.o" "mrbgems/mruby-compiler/lib/prism/src/prism.c"
gcc -MMD -c -g -O3 -Wall -Wundef -Wwrite-strings -x c++ -std=gnu++03 -DPRISM_XALLOCATOR -DPRISM_DEPTH_MAXIMUM=256 -DMRC_TARGET_MRUBY -DPRISM_BUILD_MINIMAL -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DMRBGEM_MRUBY_COMPILER_VERSION=0.0.0 -DMRB_USE_CXX_EXCEPTION -DMRB_USE_CXX_ABI ... -I"build/host-cxx/include" -o "build/host-cxx/mrbgems/mruby-compiler/src/ccontext.o" "mrbgems/mruby-compiler/src/ccontext.c"

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

Summary by CodeRabbit

• Build Improvements
  • Improved compilation of Prism C sources with more consistent compiler settings.
  • Enhanced dependency tracking for Prism source files and headers.
  • Streamlined build rule handling to improve reliability across compiler configurations.