I'm a bit of a noob in Make and wrote a makefile which essentially parses my src folder looking for .c files and creates a .so file out of them. I then parse my user folder, searching for .c files, and make a .so file per .c file.
These .so files in /user are dynamically linked using dlopen in a .c file from /src. The libmain.so is also dynamically linked by a Python script.
MAKEFLAGS += -j$(shell nproc)
USR_DIR = ./user
USRS = $(USR_DIR)/*.c
SRCS = ./src/*.c
.PHONY: all clean
all: libmain.so $(USRS:.c=.so)
libmain.so:
gcc -I./include -fPIC -shared -o libmain.so $(SRCS)
@touch $@
$(USR_DIR)/%.so: $(USR_DIR)/%.c libmain.so
gcc -I./include -shared -o $@ -fPIC $< -L. -lmain -Wl,-rpath,.
clean:
rm -f main $(USR_DIR)/*.o $(USR_DIR)/*.so libmain.so
The problem is that even with the parallelism optimisation I tried to make at the beginning, this takes quite a while to run, especially if there's a lot of files this needs to be done with. Is there any way I can optimise the compilation process?
You don't specify which version of GNU Make you're using. This line:
MAKEFLAGS += -j$(shell nproc)
doesn't enable parallel builds in the current instance of make, in all versions; it only works in the newer versions.
If you want to see if it works consider this simple makefile:
a: one two
one two: ; @echo start $@; sleep 1; echo stop $@
MAKEFLAGS += -j2
If parallelism is enabled you'll see:
start one
start two
end one
end two
If it is not enabled you'll see:
start one
end one
start two
end two
In any event, creating so many shared libraries, out of single source files, is certainly unusual. Normally a project will have only a few shared libraries containing lots of object files. If you're seeing build performance issues maybe the solution is to reconsider how you organize your code. Do you really need all those tiny shared libraries?