Re: [gentoo-dev] ebuild laziness and binpkg overhead

2012-06-12 Thread Mike Frysinger
On Tuesday 12 June 2012 23:54:45 Mike Frysinger wrote: > On Tuesday 12 June 2012 23:20:53 Michael Sterrett wrote: > > Calling "use" in global scope isn't allowed so what are you suggesting > > they do instead? > > as implied in the body of my message, put it into the relevant src_* func. > in thi

Re: [gentoo-dev] ebuild laziness and binpkg overhead

2012-06-12 Thread Mike Frysinger
On Tuesday 12 June 2012 23:20:53 Michael Sterrett wrote: > Calling "use" in global scope isn't allowed so what are you suggesting > they do instead? as implied in the body of my message, put it into the relevant src_* func. in this case, src_prepare. -mike signature.asc Description: This is a

Re: [gentoo-dev] ebuild laziness and binpkg overhead

2012-06-12 Thread Tim Harder
On 2012-06-12 Tue 20:20, Michael Sterrett wrote: > Calling "use" in global scope isn't allowed so what are you suggesting > they do instead? Can't they just do something similar to how most cmake-utils and autotools-utils users do things? For example: src_configure() {    G2CONF="${G2CONF}      

Re: [gentoo-dev] ebuild laziness and binpkg overhead

2012-06-12 Thread Michael Sterrett
Calling "use" in global scope isn't allowed so what are you suggesting they do instead? On Tue, Jun 12, 2012 at 11:02 PM, Mike Frysinger wrote: > i've noticed a growing trend where people put setup of variables into > pkg_setup that only matter to src_* funcs presumably so they don't have to > ca

Re: [gentoo-dev] [RFC] Setting F(C)FLAGS=${CFLAGS} in profiles

2012-06-12 Thread Mike Frysinger
On Tuesday 12 June 2012 13:55:45 Justin wrote: > these days still FFLAGS and FCFLAGS are unset by default. > Any objections to to default to CFLAGS of the profile equally to CXXFLAGS? sounds fine -mike signature.asc Description: This is a digitally signed message part.

[gentoo-dev] ebuild laziness and binpkg overhead

2012-06-12 Thread Mike Frysinger
i've noticed a growing trend where people put setup of variables into pkg_setup that only matter to src_* funcs presumably so they don't have to call the respective src_* func from an inherited eclass. unfortunately this adds pointless overhead to binpkgs. can we please move away from this pr

Re: [gentoo-dev] RFC: vcs-snapshot-r1.eclass -- a better eclass for VCS snapshots (and others)

2012-06-12 Thread Michael Weber
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/12/2012 04:46 PM, Michał Górny wrote: > Well, I was hoping to come up with something which doesn't involve > running additional 'tar -t', to be honest. I have to think about > it some more time. > FTR, filelist=$(tar xvC /tmp/xxx --strip-co

[gentoo-dev] Last rites: dev-python/apiextractor, dev-python/generatorrunner

2012-06-12 Thread Davide Pesavento
# Both have been merged into >=dev-python/shiboken-1.1.1. # Removal in 30 days. dev-python/apiextractor dev-python/generatorrunner signature.asc Description: This is a digitally signed message part.

Re: [gentoo-dev] [RFC] Setting F(C)FLAGS=${CFLAGS} in profiles

2012-06-12 Thread Justin
On 12.06.2012 21:30, Markos Chandras wrote: > On 06/12/2012 06:55 PM, Justin wrote: >> Hi, > >> these days still FFLAGS and FCFLAGS are unset by default. Any >> objections to to default to CFLAGS of the profile equally to >> CXXFLAGS? > > >> Thanks justin > > > This is the first time I see the

Re: [gentoo-dev] [RFC] Setting F(C)FLAGS=${CFLAGS} in profiles

2012-06-12 Thread Markos Chandras
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/12/2012 06:55 PM, Justin wrote: > Hi, > > these days still FFLAGS and FCFLAGS are unset by default. Any > objections to to default to CFLAGS of the profile equally to > CXXFLAGS? > > > Thanks justin > This is the first time I see these var

[gentoo-dev] [RFC] Setting F(C)FLAGS=${CFLAGS} in profiles

2012-06-12 Thread Justin
Hi, these days still FFLAGS and FCFLAGS are unset by default. Any objections to to default to CFLAGS of the profile equally to CXXFLAGS? Thanks justin signature.asc Description: OpenPGP digital signature

Re: [gentoo-dev] About forcing rebuilds of other packages issue

2012-06-12 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/06/12 06:49 PM, Brian Harring wrote: > On Sun, Jun 10, 2012 at 01:25:55PM +0100, Ciaran McCreesh wrote: >> On Sat, 09 Jun 2012 13:55:53 -0700 Zac Medico >> wrote: >>> A dependency atom will have optional SLOT and ABI_SLOT parts. >>> Using the

Re: [gentoo-dev] RFC: vcs-snapshot-r1.eclass -- a better eclass for VCS snapshots (and others)

2012-06-12 Thread Michał Górny
On Tue, 12 Jun 2012 15:26:58 +0200 Michael Weber wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > - From the eclass: > > # XXX: check whether the directory structure inside is > # fine? i.e. if the tarball has actually a parent dir. > > This should work with gnu and b

Re: [gentoo-dev] RFC: vcs-snapshot-r1.eclass -- a better eclass for VCS snapshots (and others)

2012-06-12 Thread Michał Górny
On Tue, 12 Jun 2012 15:09:54 +0200 Michael Weber wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 06/11/2012 04:25 PM, Michał Górny wrote: > > > > Committed onto vcs-snapshot.eclass after fixing all in-tree users. > > > > Thanks for the update. > > One suggestion: > > Have

Re: [gentoo-dev] RFC: vcs-snapshot-r1.eclass -- a better eclass for VCS snapshots (and others)

2012-06-12 Thread Michael Weber
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - From the eclass: # XXX: check whether the directory structure inside is # fine? i.e. if the tarball has actually a parent dir. This should work with gnu and bsd tar, and sed+sort+wc from sys-apps/coreutils as well as busybox. [ $

Re: [gentoo-dev] RFC: vcs-snapshot-r1.eclass -- a better eclass for VCS snapshots (and others)

2012-06-12 Thread Michael Weber
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/11/2012 04:25 PM, Michał Górny wrote: > > Committed onto vcs-snapshot.eclass after fixing all in-tree users. > Thanks for the update. One suggestion: Have you thought about using bsdtar from app-arch/libarchive instead of GNU ones? You'll