On 20/03/16 19:03, Que Quotion wrote:
What is the advantage to all this beyond people adding "-flto" to their CFLAGS if they want LTO?
The advantage is not having to do that. Theoretically, the compiler devs expect LTO to always work and want reports when it does not. We should be able to enable LTO for every build, but my experience is that--occasionally--the linker fails.
Users so inclined could "set it and forget it" most of the time, and occasionally disable it if a package does not build. I find this more efficient than modifying the PKGBUILD of each package that could benefit from LTO.
Adding -flto to CFLAGS and forgetting also is fine. Remove it when the software is broken with LTO.
All modern builds should handle the rest by themselves.
Should, but don't last time I checked. A number of builds failed for not having {AR,RANLIB,NM}FLAGS set when attempting LTO. I see the complexity as another reason to have this built into makepkg instead of having to do all this tediousness on a per-package basis.
The less anyone has to edit PKGBUILDs for generic things like optimization, the better I think.
Add -flto to CFLAGS, report broken software upstream. I am not adding this to makepkg.
I'm guessing this is untested...
That's kinda like.. not testing it, yeah?
I've been using this for quite some time. Nearly everything compiles successfully with pgo. There were a couple of wrapper leftovers to fix in my initial post, see below. The problem with only me doing the testing is no one will ever beleive my success. I have been successful, believe it--or try it for yourself.
I was talking about the patch you provided being untested. You appear to have understood that as you have fixed it....
Anyway, I don't think PGO has a place in makepkg itself
Why not, specifically? We have other cflag stuff in there; besides, it should be disabled by default so users could opt-in when they feel ready. Do you know you can PGO just about any package in the repositories? It's still takes two build steps, but this macro saves a lot of tediousness over editing the individual PKGBUILDS. I don't see how it's any more or less worthy than ccache, upx, etc.
upx is dropped. optipng is dropped. I am not adding an option to makepkg that does non-deterministic optimisation. A