On 03/11/2018 05:00 AM, Antonio Rojas via arch-dev-public wrote:
This is very poorly documented, so you have to dig into the cmake code to figure it out. The default build type is None, which means CMAKE_C(XX)_FLAGS is used (see /usr/share/cmake-3.10/Modules/CMakeCInformation.cmake:117), whose value is taken from the environment C(XX)FLAGS (see /usr/share/cmake-3.10/Modules/CMakeCXXInformation.cmake:198). So yes, not setting CMAKE_BUILD_TYPE will simply use the build flags from C(XX)FLAGS. If you want to test yourself, run cmake with the -LAH flag and check the output for CMAKE_C(XX)_FLAGS.
Oh, huh, nice. This seems to work. I wonder why whenever I googled for information about this it seemed to imply the default buildtype was a debug build... oh wait, this is CMake we are talking about, google may be the *only* source of information but it still isn't a *good* source. :p
For example, I am currently the maintainer of a package that has, apparently, historically used:
-DCMAKE_C_FLAGS:STRING="${CFLAGS}" \ -DCMAKE_CXX_FLAGS:STRING="${CXXFLAGS}" \ -DCMAKE_BUILD_TYPE=Release \
The first two lines should not be necessary (see above)
But I still think this is "necessary". That CMake module mentions
# use _INIT variables so that this only happens the first time
I've double-checked, and if you don't explicitly set the CFLAGS and CXXFLAGS then CMake unconditionally reuses the cache, which is ironic because CMake also contains a touted feature where changing the CFLAGS causes any object files that depend on those flags, to be properly rebuilt. Except they don't get rebuilt because they don't even get changed... I know repository PKGBUILDs are typically built in a clean chroot, so cached builds make no difference there, but then neither do unquoted srcdir/pkgdir. It is still not helpful to people who e.g. check out a PKGBUILD from svntogit and rebuild it locally for any of a number of reasons to have unpredictable behavior due to assumptions about always building in a clean chroot. So I think maybe we should still (or start?) specifying this. -- Eli Schwartz Bug Wrangler and Trusted User