CMake: warn if the user did not set a build type

[LebedevRI]

I did not get a warning for -GNinja,
and the resulting failure is bizarre:

$ ninja Halide_Python
[10/1842] Generating .__init__.py.stamp
FAILED: python_bindings/src/halide/.__init__.py.stamp /repositories/halide/build-halide/python_bindings/src/halide/.__init__.py.stamp
cd /repositories/halide/build-halide/python_bindings/src/halide && /usr/bin/cmake -E copy /repositories/halide/python_bindings/src/halide/__init__.py /halide/__init__.py1111 && /usr/bin/cmake -E touch /repositories/halide/build-halide/python_bindings/src/halide/.__init__.py.stamp
Error copying file "/repositories/halide/python_bindings/src/halide/__init__.py" to "/halide/__init__.py".
[43/1842] Building CXX object _deps/flatbuffers-build/CMakeFiles/flatbuffers.dir/src/idl_parser.cpp.o
ninja: build stopped: subcommand failed.

(TARGET_FILE_DIR is somehow missing CMAKE_CURRENT_BINARY_DIR prefix)

[alexreinking]

This is not a valid patch since CMAKE_BUILD_TYPE has no effect on multi-config generators (Ninja is single-config) unless we have mistakenly introduced such a behavior. A valid patch fixes that behavior.

If you weren't getting a warning you might have set CMAKE_BUILD_TYPE to the empty string?

Most likely we need to fix a different build rule that unintentionally depends on it.

[LebedevRI]

Huh, this is quite weird, but somehow CMAKE_BUILD_TYPE is indeed an empty string by default,
without me doing anything.

[LebedevRI]

Ok, right, the issue is DEFINED part...

[LebedevRI]

unless we have mistakenly introduced such a behavior. A valid patch fixes that behavior.

FWIW, halide$ grep -r CMAKE_BUILD_TYPE does not really show it being used anywhere,
so i'm not really sure that it is the case.