Arch Linux User Repository

makepkg-optimize is a collection of libmakepkg tidy, buildenv, and executable extensions, and a supplement to pacman. These enable various optimization routines for building and packaging such as upx compression, profile guided optimization, polyhedral model optimization, etc..

Note: Over-optimization is a thing, and it is not good.

See the wiki article for details.

Note to packagers: makepkg-optmize's macros may be enabled or disabled in options() as well!

oxipng may better than optipng

Any chance for including BOLT binary optimiser, it's has some substantial improvement potential over pgo+lto. https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Lands-BOLT https://github.com/facebookincubator/BOLT/blob/main/bolt/docs/OptimizingClang.md

@j1simon

I will err on the side of letting upstream deal with it, and have updated makepkg-optimize removing my own lto routine.

This means you may use one provided by pacman, in 'OPTIONS', and report problems with it to pacman's developers.

Edit: I am still shipping mine in git, btw, if you want to make some comparisons.

@quequotion in short, if I want to compile using makepkg-optimize with lto, should I activate it in BUILDENV, OPTIONS or both?

@j1simon

I finally understand what you are asking about.

Ten months ago, Allan McRae added lto, as a build option, upstream.

This was not available in pacman when I published makepkg-optimize and has probably only recently come out in a stable release.

Looking over his script, it will probably work, but I wonder about the choices that went into this implementation.

First of all, it just sets "-flto". For GCC, that actually means flto "thin" (a strategy is used to reduce memory usage during compilation that can reduce optimization; GCC decided to change this to their default while clang has not, last I checked). My version distinguishes actual flto from flto-thin.

Another issue is that it makes no distinction between GCC or clang, which passes up an opportunity to save time with GCC by disabling fat objects..

Finally, it does nothing with the LTO plugin. To be honest, my implementation here is ancient. I can no longer find the thing it is based on (an older article about LTO in the Gentoo wiki, which no longer exists, couldn't drege up whatever scripts their build system uses now). I do not know if the plugin is relevant today; it was always hard to get anyone to notice its existence.

Edit: plus one, it shouldn't be an issue, but it was an issue: I had renamed this file "ZZ-lto.sh" because of a timing issue with setting the flags in addition to flags set by other libmakepkg routines (such as those provided here).

What's the point of lto in BUILDENV and OPTIONS?

https://bugs.archlinux.org/task/66226

According to this bug those options needed to be added for polly to work with Arch's clang.

EDIT:

Upon further reflection the better change is to add the necessary flags to the polly line and add check_buildoption "polly" "y" && to the beginning of the line.

In addition, the -freg-struct-return needs to be moved into the line check_buildoption "rice" "y" && because clang does not support it on x86_64 so should not be used I think with rice-clang.

@tjuh upx is more or less useless because most binaries are application/x-pie-executable and application/x-sharedlib, and this will fail with a NotCompressibleException or a CantPackException