[pacman-dev] LTO and PGO build options

[Que Quotion]

>We don't need more options.  Use the tools already available to you.

I understand your need to minimize makepkg, I really do. Still, I
think there's a place for macros, if at least as third-party
supplements. makepkg itself is a package creation macro. Technicially
it is possible to do everything makepkg does in a terminal, but we
have this macro to save time, confusion, and trouble.

I only intend to save time, confusion and trouble. I came up with
qqbuild quite a while ago to resolve the difficulties I had with doing
it the ways you suggest and to minmize editing makepkg.conf (which I
personaly consider risky as well as tedious).

Anyway, the point is moot if you accept the patch I proposed in the
other thread.

>And it is still available - libmakepkg allows anybody to distribute additions like those to makepkg.  These sort of optimizations need to be provided at a distribution (or repo) level, not in makepkg itself.

Currently no such packages exist, but if you'll accept the new patch,
I have one tested and ready.

>Create two makepkg.conf files.  One with CFLAGS for PGO pass 1 and one with CLFAGS for PGO pass 2.  Use the --config switch to point at the one needed for that build.  That could even be done in a tiny wrapper.

As I said, I came up with qqbuild quite a while ago to deal with a
number of difficulties doing these things in makepkg. Using two config
files leaves open a lot of chances to make a mistake, and users would
then have to edit both files any time they needed to make a change to
one. There are a few reasons why my pgo macro figures out for itself
if it should be generating or utilizing.

Another reason to have a pgo macro in (lib)makepkg is the creation of
PROFDEST. At its best, qqbuild could only handle pgo when used in the
build directory, and as I mentioned in the forum it did silly things
like make the profile directory before build() ever ran--thiese are
limitations of /wrapping/ makepkg. Also, it isn't important for
makepkg itself, but this solves a problem with AUR helpers, like
yaourt, that don't keep build directories around after packages
install.

Again, moot point. The new patch I've proposed will allow for users to
create and distribute additional BUILDENV options through libmakepkg
for whatever their needs may be as supplemental packages, and they
won't be coming to you if they have trouble with them.