Mk/Features/lto.mk: Use Cargo and Meson toggles

[diizzy]

Summary

Use corresponding toggles for each build framework to enable LTO

[diizzy]

There's also a similar feature for CMake but as far as I can tell it requires patching of files.
https://cmake.org/cmake/help/latest/policy/CMP0069.html

[pkubaj]

It's a great idea, I was looking for a way to detect using Meson or CMake, but didn't think about checking the define.
Could you also do the same for CMake? Just need to add -DCMAKE_INTERPROCEDURAL_OPTIMIZATION=TRUE to CMAKE_ARGS.

[pkubaj]

The CMake change can go in the separate commit.

[diizzy]

The reason I looped in Tobias ;-)

From what I can tell cmake_minimum_required kinda limits how (if) it works and it's not possible to override it without modifying CMakeLists.txt.
We basically need a clever way (which might be deemed as hack-ish to begin with) to determine what its current value is and bump it to (at least) 3.9 if it's below but I don't know how much we'll break by doing so.
https://cmake.org/cmake/help/latest/command/cmake_minimum_required.html

I tested my theory on audio/exhale (mainly because it's tiny so its easy to tell what's going on) and it works as expected.

I'll commit it soon

Best regards,
Daniel

[pkubaj]

CMake 3.9 is from 2017: https://cmake.org/files/v3.9/
I think we can safely assume everyone has at least 3.9.

To enforce LTO with CMake, you probably also need CMAKE_POLICY_DEFAULT_CMP0069:STRING=NEW. Look at https://cgit.freebsd.org/ports/tree/multimedia/svt-av1/Makefile#n33

[diizzy]

The issue are lines that define cmake_minimum_required, see https://gitlab.com/ecodis/exhale/-/blob/master/CMakeLists.txt#L11 for example.

Anything lower than 3.9 and it wont apply which we need to solve before adding any CMake support. I would imagine that bumping it if needed may break some ports but I would rather see that fallout than it being "randomly" applied.

[tobik]

Mk/Features/lto.mk

12

Why fat LTO ("true") and not "thin"?

Should lto=off be enforced when LTO_UNSAFE is defined?

https://doc.rust-lang.org/cargo/reference/profiles.html#lto

[diizzy]

Mk/Features/lto.mk

12

Thin unforuntately performs worse at producing small binaries and at least for in my tests it doesn't (yet) seem to be worth switching to.

Examples:

fat (true) vs thin
        45.29s real             2m15.60s user           3.79s sys
-rwxr-xr-x  1 root  wheel  1774704 Sep 27 13:57 work/stage/usr/local/bin/ztop
        39.41s real             2m40.61s user           3.41s sys
-rwxr-xr-x  1 root  wheel  1884976 Sep 27 13:59 work/stage/usr/local/bin/ztop

        2m31.12s real           7m56.87s user           16.93s sys
-rwxr-xr-x  1 root  wheel  4148512 Sep 27 14:08 work/stage/usr/local/bin/librespot
        2m15.24s real           9m15.35s user           14.81s sys
-rwxr-xr-x  1 root  wheel  5279912 Sep 27 14:04 work/stage/usr/local/bin/librespot

I left lto=off out as some ports already define release flags and I'm unsure of the benefit since it's not something rust/cargo enforces on its own
sysutils/bupstash --> https://github.com/andrewchambers/bupstash/blob/master/Cargo.toml#L11