Hi there!
I'm working on a cross compilation to native windows from an Interix
Gentoo Prefix, using the normal Prefix portage tree. My setup is nearly
the same as when really cross compiling, except that I can execute what
I compile.
I use command line utilities (DEPEND atoms) from Interix, and
On 16-10-2008 09:27:29 +0200, Duft Markus wrote:
Now some package of mine in a local overlay requires bison and flex.
It's quite hard to get those to build _and_ work on winnt, so I though
about splitting the bison ebuilds in dev-util/bison and
dev-libs/bison-runtime (and the same for flex).
On Thu, Oct 16, 2008 at 09:27:29AM +0200, Duft Markus wrote:
Now some package of mine in a local overlay requires bison and flex.
It's quite hard to get those to build _and_ work on winnt, so I though
about splitting the bison ebuilds in dev-util/bison and
dev-libs/bison-runtime (and the same
On Thu, Oct 16, 2008 at 09:27:29AM +0200, Duft Markus wrote:
Now some package of mine in a local overlay requires bison and flex.
It's quite hard to get those to build _and_ work on winnt, so I
though
about splitting the bison ebuilds in dev-util/bison and
dev-libs/bison-runtime (and
While the rule of thumb has been if an eclass needs something it should
provide it's own depends. However the virtualx eclass needs to be
different simply because in some cases it's only uses for tests (this is
it's most common usage in the whole) tree. When it's used for tests
pulling in the
Doug Goldstein [EMAIL PROTECTED] writes:
It'd be a lot more consistent if ebuilds provided a USE flag or directly
depended on the xorg-server and then used the functions in the eclass.
So in summary, those are the changes I plan on making very shortly. If
someone's got some input, please
Doug Goldstein wrote:
While the rule of thumb has been if an eclass needs something it should
provide it's own depends. However the virtualx eclass needs to be
different simply because in some cases it's only uses for tests (this is
it's most common usage in the whole) tree. When it's used for
Diego 'Flameeyes' Pettenò wrote:
Doug Goldstein [EMAIL PROTECTED] writes:
It'd be a lot more consistent if ebuilds provided a USE flag or directly
depended on the xorg-server and then used the functions in the eclass.
So in summary, those are the changes I plan on making very shortly. If
Doug Goldstein wrote:
Diego 'Flameeyes' Pettenò wrote:
Doug Goldstein [EMAIL PROTECTED] writes:
It'd be a lot more consistent if ebuilds provided a USE flag or directly
depended on the xorg-server and then used the functions in the eclass.
So in summary, those are the changes I
Doug Goldstein wrote:
While the rule of thumb has been if an eclass needs something it should
provide it's own depends. However the virtualx eclass needs to be
different simply because in some cases it's only uses for tests (this is
it's most common usage in the whole) tree. When it's used for
Arun Raghavan wrote:
I've not really got an opinion on the topic, per se, but fwiw, this is
really not a meaningful statistic. *If* parsing strings in the ebuild is
not a trivial part of the overall ebuild parsing process, then yes, this
is a significant gain and should be treated as such. I
Peter Volkov wrote:
Steve, your example only tests how much time bash takes to parse string.
It's obvious that in quoted strings some expansions could be avoided and
thus bash works faster.
Yeah that's all I wanted to get across.
But although ebuilds use bash syntax they are
interpreted
Ciaran McCreesh wrote:
On Wed, 15 Oct 2008 20:28:43 +0100
Steve Long [EMAIL PROTECTED] wrote:
Fernando J. Pereda wrote:
A big gain in the context of ebuilds and source packages. Well done.
Yes, almost as important as not sourcing any ebuilds, so let's all
stick an EAPI extension on the
Ciaran McCreesh wrote:
Steve Long wrote:
Ciaran McCreesh wrote:
Markus Meier wrote:
server16
Already been discussed, can't be done.
What does it break?
Have a look at, for example, [1], where Mike already gave you an
answer one of the previous times we
On Thu, 16 Oct 2008 22:01:40 +0100 Ranjit Singh wrote:
If you really think that EAPI as an extension has anything to do
with performance
You mentioned performance a few times in that lovely thread when it
got shot down, I believe in the context of metadata generation:
Performance hit
On Thu, 16 Oct 2008 22:06:40 +0100
Steve Long [EMAIL PROTECTED] wrote:
Have a look at, for example, [1], where Mike already gave you an
answer one of the previous times we discussed it.
I'm aware of the prior discussion.
Re-read it, and tell me what it breaks, if you can.
Well, which part
On Thu, Oct 16, 2008 at 10:01:40PM +0100, Steve Long wrote:
Ciaran McCreesh wrote:
On Wed, 15 Oct 2008 20:28:43 +0100
Steve Long [EMAIL PROTECTED] wrote:
Fernando J. Pereda wrote:
A big gain in the context of ebuilds and source packages. Well done.
Yes, almost as important as not
On 11:35 Thu 16 Oct , Doug Goldstein wrote:
Doug Goldstein wrote:
While the rule of thumb has been if an eclass needs something it should
provide it's own depends. However the virtualx eclass needs to be
different simply because in some cases it's only uses for tests (this is
it's
This is your friendly reminder ! Same bat time (typically the 2nd 4th
Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
irc.freenode.net) !
If you have something you'd wish for us to chat about, maybe even vote
on, let us know! Simply reply to this e-mail for the whole
On Thursday 16 October 2008 23:54:32 Donnie Berkholz wrote:
I'm not sure whether this would work, but one idea would be to handle
dependencies depending on what's in IUSE of the ebuild inheriting.
That would require ebuilds to set IUSE before inheriting the eclass.
--
Bo Andresen
On Monday 13 October 2008, Ciaran McCreesh wrote:
On Mon, 13 Oct 2008 10:42:21 -0700
Donnie Berkholz [EMAIL PROTECTED] wrote:
It seems to me that this is an EAPI=0 change. Since EAPI=1 and
EAPI=2 are just differences to EAPI=0, they wouldn't be voted on.
Since EAPI=0 isn't actually
21 matches
Mail list logo
