[arch-general] makepkg.conf CFLAGS

Leonid Isaev lisaev at umail.iu.edu
Mon Jun 2 14:09:03 EDT 2014


On Mon, 2 Jun 2014 23:53:38 +0600
Rashif Ray Rahman <schiv at archlinux.org> wrote:

> On 2 June 2014 18:56, Yamakaky <yamakaky at yamaworld.fr> wrote:
> >
> >> I believe when the decision was made it was simply based on the fact
> >> that being able to share is worth more for the community than local
> >> optimization.
> >
> > PKGBUILDs and packages from repositories have to be portable, but it's
> > not a requirement for self-build AUR packages. Who shares binary
> > packages from AUR ?
> 
> Anybody can share binary packages that they build off of AUR
> buildscripts -- that is exactly what we allow by making these flags
> the default.
> 
> With local optimization, users end up spending time rebuilding. You
> may build a bunch of packages and decide to share them from a repo, or
> you may want help from somebody else with runtime problems that you're
> having.
> 
> There is no statistical backing here AFAIK, so if you feel strongly
> about it, you are welcome to approach the pacman developers in order
> to reach a new conclusion.
> 

Remember also that gcc optimization flags make difference only for programs
which run in or close to realtime. Examples include lapack/arpack, blender,
or your own HPC code. For everything else advanced optimization via -march= and
-O? flags yields no measurable performance increase.

Even if you build e.g. thunderbird using -O1 for a generic x86_64 machine,
you'll not notice any slowdown compared to an "optimized" build (actually,
that's how I build all my local packages).

Cheers,
-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
                  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20140602/b074534c/attachment.asc>


More information about the arch-general mailing list