The current Makefile scheme only allows one dylib to be specified in each make
invocation, so TestLoadUnload had a custom Makefile that's unrelated to the
base Makefile.rules. This change uses recursive make invocations to bypass the
single dylib restriction. See D11202 for more context.
Details
Diff Detail
Event Timeline
Yikes... Now I have no idea what this make file does.
Can't we just add new "DYLIB%u_XXX" variables to our make rules so we can just do something like:
DYLIB_C_SOURCES := a.c
DYLIB_NAME := loadunload_a
DYLIB2_C_SOURCES := b.c
DYLIB2_NAME := loadunload_b
DYLIB3_C_SOURCES := c.c
DYLIB3_NAME := loadunload_c
DYLIB4_C_SOURCES := d.c
And then have our makefile rules just do the right thing? Not that we didn't specify DYLIB4_NAME, but we should be able to deduce it from the name of the file (and make liba.dylib on Mac, liba.so on linux (just like we already derive DYLIB_NAME if needed)???
We're going to need to hard code each of those in the base Makefile (and a copy for every rule involving each of those variables). AFAIK, Makefiles don't have pattern matching on variable names. Maybe it'll be more readable if instead of relying on $(MAKECMDGOALS) we can explicitly call different Makefiles?
E.g.,
Have Makefile.a, Makefile.b, ..., etc each containing the rules for lib_a, lib_b, ..., etc. Then the main Makefile call each of these with $(MAKE) -f Makefile.X.
Hi Greg,
Two test cases were failing before this change. The original Makefile had a different EXEC_PATH variable for lib_d. I have no clue what -install_name does, but it seems to be hard-coded in the base Makefile to be @executable_path/$(DYLIB_FILENAME), could you please take a look if this change is alright?