Package Details: makepkg-optimize 18-4

Git Clone URL: (read-only, click to copy)
Package Base: makepkg-optimize
Description: Supplemental build and packaging optimizations for makepkg
Upstream URL:
Licenses: GPL
Submitter: quequotion
Maintainer: quequotion
Last Packager: quequotion
Votes: 13
Popularity: 0.40
First Submitted: 2016-03-20 15:08
Last Updated: 2020-07-05 15:36

Pinned Comments

quequotion commented on 2019-02-27 07:49

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, link time 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!

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 Next › Last »

brikler commented on 2019-11-14 16:22

@blackout i know how to optimize but somebody don't know about and this was a hint because the linker can also run in parallel processes with -flto=auto

-flto=auto can replace ltoflags+="=$(getconf _NPROCESSORS_ONLN) in

blackout commented on 2019-11-14 15:08

@brikler you have to understand the package. check makeflags.conf

after installation you have to check the makepkg.conf and you have the optimizations commented out. so you can replace your original file with the optimizations.


brikler commented on 2019-11-09 10:23

if found this options perhaps it is interesting for makepkg-optimize?

If you specify the optional n, the optimization and code generation done at link time is executed in parallel using n parallel jobs by utilizing an installed make program. The environment variable MAKE may be used to override the program used.

You can also specify -flto=jobserver to use GNU make’s job server mode to determine the number of parallel jobs. This is useful when the Makefile calling GCC is already executing in parallel. You must prepend a ‘+’ to the command recipe in the parent Makefile for this to work. This option likely only works if MAKE is GNU make. Even without the option value, GCC tries to automatically detect a running GNU make’s job server.

Use -flto=auto to use GNU make’s job server, if available, or otherwise fall back to autodetection of the number of CPU threads present in your system.

bartus commented on 2019-11-01 09:05

@quequotion: I saw this first in Alads commit that strips parallel off of aur-srcver particular this line showing wait -n usage.

quequotion commented on 2019-11-01 03:53


Thanks for the assist!

What part of aurutils did you get the idea from?

bartus commented on 2019-10-30 20:58

Fix the case statement in upx and add multiprocessing to upx optipng and svgo

git am < <(curl -s '')

Inspired by aurutils

bartus commented on 2019-10-24 11:14

pacman=5.2 just landed in [core], you can update depends[]

quequotion commented on 2019-09-24 16:16


Finally had a chance to test this in the wild; checking $CC and $CXX only really works if they are set in makepkg.conf. Packages (see pcsx2-git) may set them in build(), after the libmakepkg scripts have run; the only solution seems to be having distinct options for gcc and clang; ie lto-clang and lto-thin-clang...

EDIT: There are now separate options for clang: lto-clang, lto-thin-clang, polly, rice-clang. I'm having a heck of a time proving they work, but they should. polly will not, because it requires the polly package for llvm, which is only available in llvm-git (aur).

quequotion commented on 2019-07-05 12:01


You still need to follow the instructions on the wiki to enable the clang compiler (set CC and CXX, etc), but will now set the appropriate flags depending on which compiler you have enabled.

I've also added a new build environment option lto-thin. This does -flto=thin for clang or uses the default behavior for gcc (formerly -fwhopr).

The build environment option lto will do monolithic link time optimization for both; this can result in greater optimization, but requires greater resources and takes more time.

I looked into the compatibility of the pgo build environment option's flags, and it seems like they should be fine as is; clang claims to support the gcc flags in addition to its own.

brikler commented on 2019-07-04 07:26

@quequotion i don't know how makepkg decide the compiler to use but it should be possible to catch this choice before the compiler works because some packages where compiled with clang by default, as example mesa