Gentoo Logo
Gentoo Spaceship




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: Michał Górny <mgorny@g.o>
Subject: Re: [PATCH eutils] Move remove_libtool_files() from autotools-utils for wider use.
Date: Thu, 31 May 2012 07:46:41 +0200
On Wed, 30 May 2012 17:19:49 -0400
Mike Frysinger <vapier@g.o> wrote:

> On Monday 28 May 2012 03:58:56 Michał Górny wrote:
> > +# @USAGE: [all]
> 
> this is incorrect.  the usage is:
> 	<all | files to remove>

No, it's perfectly valid. Moreover, it even explains what the function
actually does rather than your imagination.

But if we're not interested in keeping it compatible, I'd probably
start with making it '--all'.

> > +		local arg
> > +		for arg in $(find "${D}" -name '*.pc' -exec \
> > +					sed -n -e 's;^Libs:;;p' {}
> > +); do
> > +			[[ ${arg} == -l* ]] &&
> > pc_libs+=(lib${arg#-l}.la)
> > +		done
> 
> let sed do the processing:
> pc_libs=(
> 	$(find "${D}" -name '*.pc' \
> 		-exec sed -n -e '/^Libs:/{s|^[^:]*:||;s: :\n:g;p}' {}
> + | \ sed -n '/^-l/{s:^-l:lib:;s:$:.la:;p}')
> )

Nope. My poor eyes are too weak to disband all those magical characters.

> however, i'd point out that parsing these files directly doesn't
> actually work. some .pc files use variables in the filename which
> isn't expanded by using sed. thus your only recourse is to let
> pkg-config expand things for you.

Right. I'll have to think about this a little.

> although, since we don't call die or anything, we can pipeline it to
> speed things up a bit:
> 	pc_libs=( $(
> 		tpc="${T}/.pc"
> 		find "${D}" -name '*.pc' -type f | \
> 		while read pc ; do
> 			sed -e '/^Requires:/d' "${pc}" > "${tpc}"
> 			$(tc-getPKG_CONFIG) --libs "${tpc}"
> 		done | tr ' ' '\n' | sort -u | \
> 		sed -n '/^-l/{s:^-l:lib:;s:$:.la:;p}'
> 		rm -f "${tpc}"
> 	) )

Could you remind me, please, what performance-critical use of this
function does justify making it so harsh?

> > +		local archivefile=${f/%.la/.a}
> 
> remove the suffix and it'll be faster i think:
> 	local archivefile="${f%.la}.a"

Hmm, it's indeed inconsistent.

> > +		[[ "${f}" != "${archivefile}" ]] || die 'regex
> > sanity check failed'
> 
> no need to quote the ${f}, but eh

Yep.

> > +			rm -f "${archivefile}" || die
> 
> `rm -f` almost never fails.  in the edge cases where it does, you've
> got bigger problems.

And that problem is good enough to die here.

> > +		elif has "$(basename "${f}")" "${pc_libs[@]}"; then
> 
> use ${f##*/} rather than `basename`

Hmm, yes. I'd split it out to a sep var as I see you used it already
more than once.

> > +			removing='covered by .pc'
> > +		elif [[ ! $(sed -n -e \
> > +			"s/^\(dependency_libs\|inherited_linker_flags\)='\(.*\)'$/\2/p"
> > \
> > +			"${f}") ]]; then removing='no libs & flags'
> 
> unwrap that body, and use -r rather than escaping the (|) chars

Will do.

Expect a new version in next 12hrs.

-- 
Best regards,
Michał Górny
Attachment:
signature.asc (PGP signature)
Replies:
Re: [PATCH eutils] Move remove_libtool_files() from autotools-utils for wider use.
-- Mike Frysinger
References:
[PATCH eutils] Move remove_libtool_files() from autotools-utils for wider use.
-- Michał Górny
Re: [PATCH eutils] Move remove_libtool_files() from autotools-utils for wider use.
-- Mike Frysinger
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: [PATCH eutils] Move remove_libtool_files() from autotools-utils for wider use.
Next by thread:
Re: [PATCH eutils] Move remove_libtool_files() from autotools-utils for wider use.
Previous by date:
Re: Should packages auto-eselect alternative implementation on removal?
Next by date:
Re: [PATCH eutils] Move remove_libtool_files() from autotools-utils for wider use.


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.