Consuming uWebSockets via Makefile

[j-m]

I saw in other issues & discussions that you strongly discourage use of CMake, so I thought I'd give Make a go.
This is my first time using Make and I'm predominantly a Windows dev so, if you have time, would greatly appreciate any insights or comments you may have.

From what I've seen, the common practice in using any library is to just run its makefile and move the generated .a files to usr/lib and header files in usr/header or similar. However, I wanted to keep a particular version of uWebSockets tied to my project so added uWebSockets as a git submodule.

So, is this a sensible thing to do? Have I missed anything important (i.e. missed/changed a flag that would affect performance)?

PROJECT := <redacted>

SRC_DIR := ./src
BIN_DIR := ./bin
OUT_DIR := ./build

CXX := g++
CXX_FLAGS := -std=c++17 -Wfatal-errors -Wall -Wextra -Wpedantic -Wconversion -Wshadow
INC := -I uWebSockets/src -I uWebSockets/uSockets/src
LDFLAGS := uWebSockets/uSockets/uSockets.a uWebSockets/libdeflate/libdeflate.a -lz

########################################

EXE := $(OUT_DIR)/${PROJECT}
SRC := $(wildcard $(SRC_DIR)/*.cpp)
OBJ := $(SRC:%.cpp=$(BIN_DIR)/%.o) 
DEP := $(OBJ:%.o=%.d)

-include $(DEP)

$(EXE) : $(OBJ)
	mkdir -p $(@D)
	$(CXX) $(CXX_FLAGS) $^ $(INC) -o $(EXE) $(LDFLAGS) 

$(BIN_DIR)/%.o : %.cpp
	mkdir -p $(@D)
	$(CXX) $(CXX_FLAGS) $(INC) -MMD -MP -c $< -o $@  $(LDFLAGS) 

########################################

.PHONY : default

default: build

all : clean install build 

install :
	$(MAKE) -C uWebSockets/libdeflate install
	$(MAKE) -C uWebSockets/uSockets
	$(MAKE) -C uWebSockets install

build : $(EXE)

clean :
	@$(RM) -rv $(OBJ) $(DEP)

[ghost]

strongly discourage use of CMake

No, I don't discourage the use of CMake - I only oppose the totalitarianism CMake users stand for. In other words - use what you want, but don't force me to use what you want. I don't want to use CMake, so I don't.

move the generated .a files to usr/lib and header files in usr/header or similar.

Yep. And that means that whatever "build system" was used to produce those .a files doesn't matter. The interface, and where compatibility between modules matters, is at the link stage.

uWS doesn't even have anything that needs to be built - it is only a header-only library so this whole discussion is entirely pointless on not just 1 level, but on 2 levels.

[j-m]

uWS doesn't even have anything that needs to be built

Right, but it has dependencies which do, and I meant for this question to be about consuming uWS as a whole, apologies if this was the wrong place for that.