This instructs make to delete target files if the recipe fails midway, like
when make itself is interrupted. This is mostly for development since it
protects against corrupt builds that need a `make clean` to repair. Release
builds normally don't fail mid-recipe.
GNU make and BSD make support this.
From GNU make's manual:
> This is almost always what you want make to do, but it is not historical
> practice; so for compatibility, you must explicitly request it.
See https://innolitics.com/articles/make-delete-on-error/
Rust 1.58.0 unfortunately doesn't provide facilities to control symbol
visibility/presence, but we care about controlling the list of
symbols exported from libruby-static.a and libruby.so.
This commit uses `ld -r` to make a single object out of rustc's
staticlib output, libyjit.a. This moves libyjit.a out of MAINLIBS and adds
libyjit.o into COMMONOBJS, which obviates the code for merging libyjit.a
into libruby-static.a. The odd appearance of libyjit.a in SOLIBS is also
gone.
To filter out symbols we do not want to export on ELF platforms, we use
objcopy after the partial link. On darwin, we supply a symbol list to
the linker which takes care of hiding unprefixed symbols.
[Bug #19255]
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
When the build is running with a base ruby then generating `x64-ucrt-ruby320.rc`
could fail due to a missing dependency to `x64-mingw-ucrt-fake.rb`.
This commit adds this dependency.
A failing build looks like so:
```
generating x64-mingw-ucrt-fake.rb
generating x64-ucrt-ruby320.rc
../snapshot-master/win32/resource.rb:in `require': cannot load such file -- ./x64-mingw-ucrt-fake (LoadError)
make: *** [GNUmakefile:57: x64-ucrt-ruby320.rc] Error 1
make: *** Waiting for unfinished jobs....
linking miniruby.exe
x64-mingw-ucrt-fake.rb updated
```
In principle, we have a DTrace probe in yjit.c, so yjit.o should be
in DTRACE_DEPENDENT_OBJS for DTRACE_REBUILD=yes builds. This commit
adds to the list.
In practice DTRACE_REBUILD=yes implies the system has a Solaris-like
DTrace and YJIT doesn't support those systems. YJIT_OBJ expands to
nothing, and yjit.c isn't compiled.
I tested on OmniOS v11 r151034m with:
$ ../src/configure --with-out-ext=psych MAKE=gmake AR=ar debugflags=-g
$ gmake -j
It builds before and after this change.
[Bug #18480]
Reduce duplicate replacements so that reflect macros in command lines
consitently. So that reflect macros in command lines. Others than
`nmake` have no problems with nested expansions.
