[gentoo-dev] New eclass db-use

[gentoo-dev] New eclass db-use

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]


Hi all,

I have just committed a new eclass to the tree. This eclass has as purpose 
to make it easier to use berkeley db. Currently the eclass has two 
interesting functions (and some helpers that may or may not be 
interesting).

These functions are:
db_includedir
db_libname

Both functions can be used with and without arguments. Without arguments 
they will give the best bdb version. With arguments they will loop 
through the arguments which are version prefixes (they will be matched 
with "=sys-libs/db-${1}*"

The includedir function returns the include dir of the best matched db 
version. The libname function returns the libraryname of the best matched 
db. This libraryname has the form db-${ver}, and as such could be just 
appended to "-l". This means it is not the filename.

Paul;

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] New eclass db-use

[Bryan Ãstergaard]

On Thu, May 18, 2006 at 11:48:50AM +0200, Paul de Vrieze wrote:
> 
> Hi all,
> 
> I have just committed a new eclass to the tree. This eclass has as purpose 
> to make it easier to use berkeley db. Currently the eclass has two 
> interesting functions (and some helpers that may or may not be 
> interesting).
> 
> These functions are:
> db_includedir
> db_libname
> 
> Both functions can be used with and without arguments. Without arguments 
> they will give the best bdb version. With arguments they will loop 
> through the arguments which are version prefixes (they will be matched 
> with "=sys-libs/db-${1}*"
> 
> The includedir function returns the include dir of the best matched db 
> version. The libname function returns the libraryname of the best matched 
> db. This libraryname has the form db-${ver}, and as such could be just 
> appended to "-l". This means it is not the filename.
> 
Was this discussed on gentoo-dev mailinglist before committing to the
tree? Eclasses are supposed to be discussed on -dev prior to adding them
to the tree to catch any (obvious) mistakes etc.

This is particularly important for eclasses as they can't be removed or
changed in incompatible ways later due to the way portage handles them.

I don't have time to look at it myself right now but I'd still
appreciate posting the code to gentoo-dev and have other devs/users
comment on it.

Regards,
Bryan Østergaard
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New eclass db-use

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

On Thursday 18 May 2006 13:25, Bryan Ãstergaard wrote:
> Was this discussed on gentoo-dev mailinglist before committing to the
> tree? Eclasses are supposed to be discussed on -dev prior to adding
> them to the tree to catch any (obvious) mistakes etc.
>
> This is particularly important for eclasses as they can't be removed or
> changed in incompatible ways later due to the way portage handles them.
>
> I don't have time to look at it myself right now but I'd still
> appreciate posting the code to gentoo-dev and have other devs/users
> comment on it.

It has not been. As far as I know such a requirement does not exist. In 
any case, this eclass only provides utility functions to find the proper 
location of berkeley db. 

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] New eclass db-use

[Simon Stelling]

Paul de Vrieze wrote:
> It has not been. As far as I know such a requirement does not exist. In 

It does. The reason for it is pretty good, as kloeri mentioned: The API of an 
eclass may never change. See GLEP 33 for some horror scenarios [1] ;)

[1] http://www.gentoo.org/proj/en/glep/glep-0033.html

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New eclass db-use

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

On Thursday 18 May 2006 15:06, Simon Stelling wrote:
> Paul de Vrieze wrote:
> > It has not been. As far as I know such a requirement does not exist.
> > In
>
> It does. The reason for it is pretty good, as kloeri mentioned: The API
> of an eclass may never change. See GLEP 33 for some horror scenarios
> [1] ;)

Unfortunately this GLEP has not been implemented yet. This eclass would 
indeed be an ideal elib. Also, for this eclass the API requirements are 
not as strict as it is only intended to be used in unpack and compile 
stages.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] New eclass db-use

[Simon Stelling]

Paul de Vrieze wrote:
> Unfortunately this GLEP has not been implemented yet. This eclass would 
> indeed be an ideal elib. Also, for this eclass the API requirements are 
> not as strict as it is only intended to be used in unpack and compile 
> stages.

That's not my point. I mentioned it because it briefly shows why the current 
eclass system has its problems and why contacting -dev *before* adding a new 
eclass to the tree is essential.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New eclass db-use

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

On Thursday 18 May 2006 15:49, Simon Stelling wrote:
> Paul de Vrieze wrote:
> > Unfortunately this GLEP has not been implemented yet. This eclass
> > would indeed be an ideal elib. Also, for this eclass the API
> > requirements are not as strict as it is only intended to be used in
> > unpack and compile stages.
>
> That's not my point. I mentioned it because it briefly shows why the
> current eclass system has its problems and why contacting -dev *before*
> adding a new eclass to the tree is essential.

I see your point. This GLEP does not require contacting -dev at all 
though. Instead of this eclass I could have abused the db4fix eclass and 
be done with it. The new one has a better name, and sane design. It 
offers functions (and will offer more) that are long due and actually 
help ebuilds using berkeley db.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]