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: Maciej Mrozowski <reavertm@...>
Subject: Re: Re: New eclass: scons.eclass
Date: Mon, 23 Aug 2010 19:36:50 +0200
On Monday 23 of August 2010 17:11:47 Michał Górny wrote:
> On Sun, 22 Aug 2010 23:03:44 +0200
> 
> Maciej Mrozowski <reavertm@...> wrote:
> > I'd suggest providing all src_* phases except src_unpack.
> 
> Providing a blank src_configure() would be fine but...
> 
> > Even src_prepare that calls base_src_prepare - to get PATCHES and
> > epatch_user support - for simplicity requiring EAPI-2 as providing
> > src_unpack in buildsystem eclasses is a bad design (like providing
> > src_prepare in scm eclasses - this one is yet to be fixed).
> 
> Why would I do that? If an ebuild needs to use base_src_prepare(), why
> can't it simply inherit the base eclass? Nothing buildsystem-specific
> needs to be done in src_prepare() here.
> And requiring EAPI=2 is even more pointless as SCons doesn't mostly
> distinguish between 'configure' and 'build' phases.

Because if you're to provide src_prepare, for EAPI<2 you need to provide 
src_unpack as well but it's wrong in buildsystem eclasses as I already pointed 
out (since src_unpack:EAPI1 -> src_unpack:EAPI2 + src_prepare:EAPI2), and 
requiring EAPI-2 allows you to avoid it.
If you don't care for PATCHES or user_patches and hence compliance with other 
buildsystem eclasses, feel free.

> > Also calling base_src_install in scons_src_install if possible would
> > be nice (DOCS, HTML_DOCS support) - to make it resemble cmake-utils,
> > autotools-utils, and a bit of distutils, qt4-edge and gnome2 eclasses.
> 
> Even more pointless. Although we can assume many of the SConstruct
> files use the name 'install' for their 'install' target, we can't do
> that for 'DESTDIR' or how a particular project calls it. Not to mention
> some don't provide such a thing at all. Every SCons-based ebuild should
> redefine src_install().

Like I said, if you don't care for consistency with the rest, feel free to 
ignore.
If SCons is unpredictable, then don't provide *any* phases and only functions 
and rename it to scons-utils to match its purpose (we're quite likely planning 
to rename cmake-utils.eclass to cmake.eclass for said consistency, 
unfortunately it was introduced in first place with such name and provided 
phases).
What I hate is deliberately introduced inconsistency in ebuild API's.

-- 
regards
MM
Attachment:
signature.asc (This is a digitally signed message part.)
Replies:
Re: New eclass: scons.eclass
-- Michał Górny
References:
New eclass: scons.eclass
-- Michał Górny
Re: Re: New eclass: scons.eclass
-- Maciej Mrozowski
Re: Re: New eclass: scons.eclass
-- Michał Górny
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: New eclass: scons.eclass
Next by thread:
Re: New eclass: scons.eclass
Previous by date:
Re: Re: The future of sys-apps/openrc in Gentoo
Next by date:
Re: Re: The future of sys-apps/openrc in Gentoo


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.