Created attachment 231661 [details] cmake-lto.patch The attached patch adds the feature USES=cmake:lto that makes build to use LTO. This feature should be used only on performance-critical ports.
The patch adds cmake option CMP0069=NEW to make it unforgiving for missing LTO features in the toolchain.
I think this approach is not consistent with other ports features. LTO support should be enabled by user and not by ports, similar to CC, MAKE_JOBS_NUMBER, etc.
(In reply to Max Brazhnikov from comment #2) LTO is different. CC and MAKE_JOBS_NUMBER for the most part only affect how software is compiled, and essentially don't affect the result of the build. LTO changes how code is optimized, and resulting binaries can be significantly more performant. Port option LTO can then be defined with LTO_USES=cmake:lto. This option would be controlled by user.
(In reply to Yuri Victorovich from comment #3) LTO is optimization in the end, it's not different to CC or CFLAGS [1] (not to mention its memory requirements). It must be optional and up to user decision. I agree that ports should support and respect LTO, but not forcing it. 1. https://docs.freebsd.org/en/books/porters-handbook/porting-dads/#dads-cflags
(In reply to Max Brazhnikov from comment #4) > I agree that ports should support and respect LTO, but not forcing it. The cmake:lto option doesn't force LTO. It's not recommended to be added to USES unconditionally. It allows port maintainer to easily add the LTO port option that is controlled by the user. This simply adds LTO support to USES=cmake which should be used from relevant port options.
Created attachment 231732 [details] patch LTO should never be an option! We don't have options for CC and DEBUG in every port, but we do have support for CC and WITH_DEBUG.
(In reply to Yuri Victorovich from comment #3) > Port option LTO can then be defined with LTO_USES=cmake:lto. Appending arguments to an existing USES=foo is broken, see bug 199603. (In reply to Max Brazhnikov from comment #6) > LTO should never be an option! See https://cgit.freebsd.org/ports/log/?qt=grep&q=LTO+by+default LTO is similar to OPTIMIZED_CFLAGS option but slightly more fragile and increases build time, so can get in the way with unusual toolchain configuration or when bisecting. Blindly enabling -flto can cause crashes at runtime e.g., https://bugs.llvm.org/show_bug.cgi?id=40635 Modern PLs like Rust enable LTO for user code as part of default optimizations, see https://doc.rust-lang.org/rustc/codegen-options/index.html#lto
I'm going to close this one with "no". - LTO can (usually? always?) be enabled by passing suitable flags to CMake at cmake-time (when generating the build system). The suggestion is that cmake:lto should add those flags. - LTO should not be an OPTION (according to Max). - if it **was** an option, then there's no effective way to add cmake:lto to USES (according to Jan). I can imagine defining some useful collections of CMake flags in cmake.mk, e.g. CMAKE_ENABLE_LTO .. are there other collections like that? Then they could be done at (ports-)make time and a port might have CMAKE_FLAGS+=${CMAKE_ENABLE_LTO} ; that's less option-fragile at least. But it would need to be carefully documented. The topic could be revisited, but then it needs a longer description, suitable documentation added to cmake.mk, and a suggestion how it would be documented in the porters handbook. There's too much pointer-chasing for CMake features as-is.