In the process of upgrading our redis infra to 4.0 (still running 2.8 at the moment), I would appreciate the possibility to have both/multiple major release available in parallel on the same filesystem with a minimum of fiddling around (i. e., without installing them into separate PREFIXes), like most software using autotools supports via program_transform_name.
After reviewing redis' Makefile, I noticed that there's variables like REDIS_CHECK_RDB_NAME defined, and set to the values one would expect from a default redis build and installation. Now, monkey-patching the Makefile to make these executables pop out of the compiler with names that I'd want them to have (for instance, resulting in a binary named redis40-server instead of redis-server, etc.) already breaks a few things, since the redis-server executable also implements redis-check-aof and redis-check-rdb by comparing argv[0] with hardcoded strings that make main call the proper, corresponding function for those features.
That's pretty trivial to fix in an at least semi-correct way, by passing these variables into the build process as values for preprocessor constants via the Makefile (which contains all the information required to make this work). The problem with that is that in many other places, the resulting binary names are also hard-coded, which breaks make test pretty spectacularly.
My question, I guess, is: What is the purpose of having REDIS_CHECK_RDB_NAME et al. in the first place? And, as a follow-up: Should building redis with non-default executable names be (properly) supported? (If so, would patches that make this work properly be considered for merging? If not, what's a good/the recommended way of having multiple major releases installed and available in parallel?)