Note: Due to technical difficulties, the Archives are currently not up to date.
GMANE provides an alternative service for most mailing lists. c.f. bug 424647
List Archive: gentoo-dev
| Navigation: |
|
Lists:
gentoo-dev:
< Prev
By Thread
Next >
< Prev
By Date
Next >
|
| Headers: |
|
To:
|
gentoo-dev@g.o
|
|
From:
|
Mike Frysinger <vapier@g.o>
|
|
Subject:
|
Re: Re: [gentoo-commits] gentoo-x86 commit in media-sound/cdparanoia: ChangeLog cdparanoia-3.10.2-r3.ebuild
|
|
Date:
|
Wed, 18 Jan 2012 06:56:44 -0500
|
|
On Wednesday 18 January 2012 06:42:37 Samuli Suominen wrote:
> On 01/18/2012 01:40 PM, Mike Frysinger wrote:
> > On Sunday 23 October 2011 09:50:04 Andreas K. Huettel wrote:
> >> On Sonntag 23 Oktober 2011 15:34:30 Samuli Suominen wrote:
> >>> If you only wanted to remove these files, you are free to use
> >>> INSTALL_MASK locally instead of downgrading the quality of tree.
> >>>
> >>> Do you have any idea how much time me, and aballier spent to make
> >>> cdparanoia's build system as clean as it is now? And then to coordinate
> >>> them with upstream xiph.org?
> >>> Then I see this... Not acceptable by any standards.
> >>
> >> I'd like to get my standards up to speed, so may I respectfully ask-
> >> what is, apart from link time, the Gentoo-user-visible difference
> >> between * removing the .a files in the ebuild
> >> * and not building them in the first place?
> >
> > there is no post-emerge visible difference, but i wouldn't underestimate
> > the speed of things. for most packages, you're talking about compiling
> > the files twice (once as PIC and once as not).
>
> [ ... grabbing random mail from this thread ... ]
>
> i've already fixed cdparanoid properly.
> it was pretty much 2 liner, so whatever was committed before was simply
> out of laziness to investigate.
come now, no need to jab people. the obvious answer to you might not have
been obvious to the committer. we're all just doing the best we can with the
time we have.
if you want some touch nuggets to tackle, take a look at the openssl ebuild.
its generation of static archives are less than ideal because the build system
creates one set of objects (all built with PIC), then produces a lib.so and
lib.a from that single set.
-mike
|
| Attachment: |
|
signature.asc (This is a digitally signed message part.)
|
|