[arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake

[Eli Schwartz]

On 03/10/2018 05:34 AM, Antonio Rojas via arch-dev-public wrote:
> Hi, Currently most of our packages which use the cmake build system
> are built with -DCMAKE_BUILD_TYPE=Release. This provides a reasonable
> (according to upstream) set of C(XX)FLAGS defaults which are appended
> to and override our default C(XX)FLAGS. So, for instance, our cmake
> packages are being built with -O3 instead of our default -O2. Besides
> the inconsistency that this brings to our binaries, IMO it's not a
> good idea to override our default C(XX)FLAGS unless there's a good
> reason to. This will also cause issues once we start building debug
> packages by default (-DCMAKE_BUILD_TYPE=Release also adds DNDEBUG). 
> Therefore I'm proposing to drop -DCMAKE_BUILD_TYPE from all our cmake
> packages, building them with our default C(XX)FLAGS as all other
> packages. Comments?

This theoretically sounds like a fantastic idea, but I'm not really sure
what CMake's deal with build flags are in the first place. What is the
default build type, and does CMake even look at build flags from the
environment at all (at least in a sane manner)?

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 \

IIRC the first two are because there are situations where CMake simply
ignores environment *FLAGS altogether. Maybe this only impacts
incremental builds because of some stupid CMakeCache rule where the
cache shall not be overwritten under any circumstances because KitWare
in its terrible glory has so decreed, but I cannot swear this is the
only such situation...

As for the buildtype, I was under the impression this is because 1)
CMake simply has no BUILD_TYPE=plain as far as I know, and 2) failing to
specify it means CMake does something strange and magical ranging from
"assume the default build type is Debug" to "read some arbitrary build
type that upstream was allowed to set in CMakeLists.txt because clearly
this should be enforced by the build system for hysterical raisins".

I have never felt brave enough to debug where environment *FLAGS go
anyways, nor if/when/where they get overridden somehow by CMake when
they "clash" with the BUILD_TYPE flags.

...

While we are at it, someone has seen fit to create some arbitrary meson
wrapper called "arch-meson" (note we have never shipped an arch-cmake
nor an arch-configure, nor an arch-setup-py nor even an arch-make etc.),
which aside for being somewhat magical also most certainly sets
--buildtype release

I distinctly remember this being something we do not want to support in
makepkg due to us being fundamentally opposed to the end result where
e.g. Debian packaging has magic in every which direction and you have to
have a degree in Debian packaging plus go spelunking through addons
provided by six or seven packages just to figure out how the actual
build system for packages is being configured and run.

I *know* that meson's buildtype=plain does the sane thing and delegates
to the environment *FLAGS (or rather, the makepkg.conf *FLAGS and
OPTIONS=(debug) if specified).
In fact, the Meson people have called me out for Arch being hypocrites,
because we hardcode buildtype=release. Which was primarily news to me
because I did not realize we even have a wrapper in the first place.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20180310/2cdf12a9/attachment.asc>