[gentoo-dev] Re: perl-module.class review

2009-09-21 Thread Torsten Veller 
* Ciaran McCreesh ciaran.mccre...@googlemail.com:
 Torsten Veller t...@gentoo.org wrote:
  +EXPORTED_FUNCTIONS=src_unpack src_compile src_test src_install
 
 You're probably not the only one using this trick, so it might be wise
 to use PERL_EXPORTED_FUNCTIONS or somesuch to avoid name collisions
 with other eclasses.

git and x-modular use EXPORTED_FUNCTIONS and
cmake and xfconf use EXPF.

| eclass/git.eclass:EXPORT_FUNCTIONS ${EXPORTED_FUNCTIONS}
| eclass/x-modular.eclass:EXPORT_FUNCTIONS ${EXPORTED_FUNCTIONS}
|
| eclass/cmake-utils.eclass:EXPORT_FUNCTIONS ${EXPF}
| eclass/xfconf.eclass:EXPORT_FUNCTIONS ${EXPF}

I'll use PERL_EXPORTED_FUNCTIONS in the perl eclass.

Thanks :)

Re: [gentoo-dev] Re: perl-module.class review

2009-09-21 Thread Tomáš Chvátal 
Dne pondělí 21 Září 2009 17:29:26 Torsten Veller napsal(a):
 * Ciaran McCreesh ciaran.mccre...@googlemail.com:
  Torsten Veller t...@gentoo.org wrote:
   +EXPORTED_FUNCTIONS=src_unpack src_compile src_test src_install
 
  You're probably not the only one using this trick, so it might be wise
  to use PERL_EXPORTED_FUNCTIONS or somesuch to avoid name collisions
  with other eclasses.
 
 git and x-modular use EXPORTED_FUNCTIONS and
 cmake and xfconf use EXPF.
 
 | eclass/git.eclass:EXPORT_FUNCTIONS ${EXPORTED_FUNCTIONS}
 | eclass/x-modular.eclass:EXPORT_FUNCTIONS ${EXPORTED_FUNCTIONS}
 |
 | eclass/cmake-utils.eclass:EXPORT_FUNCTIONS ${EXPF}
 | eclass/xfconf.eclass:EXPORT_FUNCTIONS ${EXPF}
 
 I'll use PERL_EXPORTED_FUNCTIONS in the perl eclass.
 
 Thanks :)
 
I think it is not required
EXPF=src_compile src_test src_install - definition, also nulls anything 
what was in it before :]
case ${EAPI:-0} in 
2) EXPF=${EXPF} src_configure ;;
1|0) ;;   
*) die Unknown EAPI, Bug eclass maintainers. ;;
esac 
EXPORT_FUNCTIONS ${EXPF}  - export

i used expf cause it was shorter
and in git eclass i was too lazy for adjusting for the shorter name :]


signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Re: perl-module.class review

2009-09-21 Thread Torsten Veller 
* Tomáš Chvátal scarab...@gentoo.org:
 I think it is not required
 EXPF=src_compile src_test src_install - definition, also nulls anything 
 what was in it before :]
 case ${EAPI:-0} in 
 2) EXPF=${EXPF} src_configure ;;
 1|0) ;;   
 *) die Unknown EAPI, Bug eclass maintainers. ;;
 esac 
 EXPORT_FUNCTIONS ${EXPF}  - export

And later in cmake-utils_src_compile you use:
| has src_configure ${EXPF} || cmake-utils_src_configure

What will happen if an EAPI=2 ebuild inherits cmake-utils and another eclass
also using EXPF that does not EXPORT_FUNCTIONS src_configure and the
ebuild uses cmake-utils_src_compile?

It will call cmake-utils_src_configure during src_configure and later in
cmake-utils_src_compile it will run cmake-utils_src_configure again,
won't it?

Re: [gentoo-dev] Re: perl-module.class review

2009-09-21 Thread Tomáš Chvátal 
Dne pondělí 21 Září 2009 18:03:56 Torsten Veller napsal(a):
 * Tomáš Chvátal scarab...@gentoo.org:
  I think it is not required
  EXPF=src_compile src_test src_install - definition, also nulls
  anything what was in it before :]
  case ${EAPI:-0} in
  2) EXPF=${EXPF} src_configure ;;
  1|0) ;;
  *) die Unknown EAPI, Bug eclass maintainers. ;;
  esac
  EXPORT_FUNCTIONS ${EXPF}  - export
 
 And later in cmake-utils_src_compile you use:
 | has src_configure ${EXPF} || cmake-utils_src_configure
 
 What will happen if an EAPI=2 ebuild inherits cmake-utils and another
  eclass also using EXPF that does not EXPORT_FUNCTIONS src_configure and
  the ebuild uses cmake-utils_src_compile?
 
 It will call cmake-utils_src_configure during src_configure and later in
 cmake-utils_src_compile it will run cmake-utils_src_configure again,
 won't it?
 
You dont do this magic before inherits, so you are safe, if you inherit in 
middle of your eclass code, then you probably deserve the breakage for 
writting such horrible thing ;]


A - inherit B
EXPF - value from B
A - define our own export_functions
EXPF - value from A


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: perl-module.class review

2009-09-21 Thread Maciej Mrozowski 
On Monday 21 of September 2009 17:38:53 Tomáš Chvátal wrote:

 I think it is not required
 EXPF=src_compile src_test src_install - definition, also nulls anything
 what was in it before :]
 case ${EAPI:-0} in
 2) EXPF=${EXPF} src_configure ;;
 1|0) ;;
 *) die Unknown EAPI, Bug eclass maintainers. ;;
 esac
 EXPORT_FUNCTIONS ${EXPF}  - export

How about unsetting variables after use in first place so that they no longer 
pollute global env.

-- 
regards
MM

--
Rudi Schuberth odkrywa kulisy swojego odchudzania. Ile schudnie?
Sprawdz  http://link.interia.pl/f236a

[gentoo-dev] Re: perl-module.class review

2009-09-21 Thread Torsten Veller 
* Tomáš Chvátal scarab...@gentoo.org:
 Dne pondělí 21 Září 2009 18:03:56 Torsten Veller napsal(a):
  * Tomáš Chvátal scarab...@gentoo.org:
   I think it is not required
   EXPF=src_compile src_test src_install - definition, also nulls
   anything what was in it before :]
   case ${EAPI:-0} in
   2) EXPF=${EXPF} src_configure ;;
   1|0) ;;
   *) die Unknown EAPI, Bug eclass maintainers. ;;
   esac
   EXPORT_FUNCTIONS ${EXPF}  - export
  
  And later in cmake-utils_src_compile you use:
  | has src_configure ${EXPF} || cmake-utils_src_configure
  
  What will happen if an EAPI=2 ebuild inherits cmake-utils and another
   eclass also using EXPF that does not EXPORT_FUNCTIONS src_configure and
   the ebuild uses cmake-utils_src_compile?
  
  It will call cmake-utils_src_configure during src_configure and later in
  cmake-utils_src_compile it will run cmake-utils_src_configure again,
  won't it?
  
 You dont do this magic before inherits, so you are safe, if you inherit in 
 middle of your eclass code, then you probably deserve the breakage for 
 writting such horrible thing ;]

I'am trying to give an example:

,- test.eclass
EXPF=pkg_postinst
EXPORT_FUNCTIONS ${EXPF}

test_pkg_postinst() {
einfo test_pkg_postinst
}
'- test.eclass

,- another_test.eclass
EXPF=src_configure src_compile
EXPORT_FUNCTIONS ${EXPF}

another_test_src_configure() {
einfo another_test_src_configure
}
another_test_src_compile() {
einfo another_test_src_compile
has src_configure ${EXPF} || another_test_src_configure
}
'- another_test.eclass

,- test.ebuild
EAPI=2
inherit another_test test

DESCRIPTION=
HOMEPAGE=
SRC_URI=

LICENSE=
SLOT=0
KEYWORDS=~amd64
IUSE=

'- test.ebuild

It outputs:

 * another_test_src_configure
 * another_test_src_compile
 * another_test_src_configure
 * test_pkg_postinst

if s/EXPF/TEST_EXPF/ in test.eclass, it does:

 * another_test_src_configure
 * another_test_src_compile
 * test_pkg_postinst

[gentoo-dev] Re: perl-module.class review

2009-09-21 Thread Torsten Veller 
* Maciej Mrozowski reave...@poczta.fm:
 How about unsetting variables after use in first place so that they no longer 
 pollute global env.

It's probably too late as it is used in functions like
cmake-utils_src_compile:
| has src_configure ${EXPF} || cmake-utils_src_configure

Re: [gentoo-dev] Re: perl-module.class review

2009-09-21 Thread Jeremy Olexa 
On Mon, Sep 21, 2009 at 11:55 AM, Torsten Veller ml...@veller.net wrote:
snip
 if s/EXPF/TEST_EXPF/ in test.eclass, it does:

  * another_test_src_configure
  * another_test_src_compile
  * test_pkg_postinst

Although I don't anticipate xfconf and cmake being used together, we
changed xfconf.eclass. ;) Thanks for your time to test there.

sed -i -e 's/EXPF/XFCONF_EXPF/g' xfconf.eclass

-Jeremy