Oh, you're talking about CFLAGS *in makepkg.conf* as I've pointed out, that won't always work when it should.
On Sun, Mar 20, 2016 at 7:16 PM, Que Quotion <[email protected]> wrote: > >Adding -flto to CFLAGS and forgetting also is fine. Remove it when the > software is broken with LTO. > > The only way this makes logical sense is if you mean for *packagers* to do > so, but I have never known any to do so. I don't think it's any more > appropriate to distribute PKGBUILDs with optimizations enabled by default. > Much better to leave that to users; much too troublesome to ask them to edit > each PKGBUILD they want to optimize. Doing this in makepkg works better than > a wrapper script, and involves less work for both users and packagers--who > would also have the opportunity to specify packages that must not use LTO. > > >Add -flto to CFLAGS, report broken software upstream. I am not adding > this to makepkg. > > That's dissapointing. There's practically no downside to having LTO available > in makepkg.>I was talking about the patch you provided being untested. You > appear > to have understood that as you have fixed it.... > > Yeah, and you were right--but you came to that conclusion on a whim. > > >upx is dropped. optipng is dropped. > > Oh, I see. Sorry to hear about that. makepkg's automated (opt-in) > optimization of packages is one of the features I considered vastly superior > to other package creation tools. > > >I am not adding an option to makepkg that does non-deterministic > optimisation. > > It always would have been an option for users to choose, not a policy, ie > "enable at your own (negligible) risk". > > I don't think I have the constitution to maintain a makepkg fork for extra > optimization features, but its sounding like a good idea. > >
