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
- Repository
- rL LLVM
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?