[Bug]: mismatched make and gmake versions can cause strange build failures

[jabraham17]

A user found that when doing a Chapel install on linux64 with make, the build was subtly failing due to an internal error by gmake. gmake was being used because thats what CHPL_MAKE defaults to on linux64.

From the users log

Making third-party-packages...
make[3]: Nothing to be done for 'jemalloc'.
rm -rf /......../chapel/third-party/qthread/install/linux64-aarch64-native-llvm-none-flat-jemalloc-bundled && rm -rf /....../chapel/third-party/qthread/build/linux64-aarch64-native-llvm-none-flat-jemalloc-bundled
make[3]: Nothing to be done for 're2'.
make[3]: Nothing to be done for 'gmp'.
make[3]: Nothing to be done for 'hwloc'.
cd qthread && make

Error: command failed: ['gmake', '--no-print-directory', '-f', '/....../chapel/runtime/etc/Makefile.include', 'printincludesanddefines']
output was:
gmake[5]: *** internal error: invalid --jobserver-auth string 'fifo:/tmp/GMfifo3942521'.  Stop.

compileline failed!
make[4]: *** [Makefile:194: qthread-config] Error 1
make[3]: *** [Makefile:188: /..../chapel/third-party/qthread/install/linux64-aarch64-native-llvm-none-flat-jemalloc-bundled] Error 2
make[2]: *** [Makefile:80: third-party-pkgs] Error 2
make[1]: *** [Makefile:107: runtime] Error 2
make: *** [Makefile:70: comprt] Error 2

This comes from compileline, which uses CHPL_MAKE instead of $(MAKE). This also only seems to be an issue when gmake and make are distinct (only many systems 1 is a symlink of the other). In this users case, they were entirely different versions

This can be worked around by explicitly setting export CHPL_MAKE=make