[gentoo-dev] RFC: toolchain-r1.eclass

2013-07-25 Thread Paweł Hajdan, Jr.
About one month ago I've filed
https://bugs.gentoo.org/show_bug.cgi?id=474358 about modernizing
toolchain.eclass by creating new toolchain-r1.eclass and migrating
ebuilds using it to the new eclass.

Please see attachments and review the code.

One issue has already been raised, and it's prefix-related changes. I
don't know what to change there, but I'm happy to test suggested changes.

Then there is a question whether toolchain packages should use EAPI 5,
and I think providing an upgrade path is a good concern. Given
portage/python constraints though, it seems to me it would be fine. If
you think it'd be better, I could use a lower EAPI just in case.

All feedback is welcome.

Paweł
--- gcc-4.7.3.ebuild.orig   2013-06-16 17:43:10.0 -0700
+++ gcc-4.7.3.ebuild2013-06-16 17:43:09.0 -0700
@@ -2,6 +2,8 @@
 # Distributed under the terms of the GNU General Public License v2
 # $Header: /var/cvsroot/gentoo-x86/sys-devel/gcc/gcc-4.7.3.ebuild,v 1.2 
2013/05/20 10:56:06 aballier Exp $
 
+EAPI=5
+
 PATCH_VER=1.0
 UCLIBC_VER=1.0
 
@@ -18,7 +20,7 @@
 SSP_UCLIBC_STABLE=x86 amd64 ppc ppc64 arm
 #end Hardened stuff
 
-inherit toolchain
+inherit toolchain-r1
 
 DESCRIPTION=The GNU Compiler Collection
 
@@ -35,7 +37,7 @@
PDEPEND=${PDEPEND} elibc_glibc? ( =sys-libs/glibc-2.8 )
 fi
 
-src_unpack() {
+src_prepare() {
if has_version 'sys-libs/glibc-2.12' ; then
ewarn Your host glibc is too old; disabling automatic fortify.
ewarn Please rebuild gcc after upgrading to =glibc-2.12 
#362315
@@ -47,15 +49,15 @@
EPATCH_EXCLUDE+= 90_all_gcc-4.7-x32.patch
fi
 
-   toolchain_src_unpack
+   toolchain-r1_src_prepare
 
use vanilla  return 0
 
[[ ${CHOST} == ${CTARGET} ]]  epatch ${FILESDIR}/gcc-spec-env.patch
 }
 
-pkg_setup() {
-   toolchain_pkg_setup
+pkg_pretend() {
+   toolchain-r1_pkg_pretend
 
if use lto ; then
ewarn
--- toolchain.eclass2013-06-16 17:42:59.0 -0700
+++ toolchain-r1.eclass 2013-06-16 17:43:26.0 -0700
@@ -23,7 +23,7 @@
inherit git-2
 fi
 
-EXPORT_FUNCTIONS pkg_setup src_unpack src_compile src_test src_install 
pkg_postinst pkg_postrm
+EXPORT_FUNCTIONS pkg_pretend pkg_setup src_unpack src_prepare src_configure 
src_compile src_test src_install pkg_postinst pkg_postrm
 DESCRIPTION=The GNU Compiler Collection
 
 FEATURES=${FEATURES/multilib-strict/}
@@ -108,14 +108,15 @@
 
if tc_version_is_at_least 3 ; then
IUSE+= doc gcj gtk hardened multilib objc
+   REQUIRED_USE+= gcj? ( cxx )
 
tc_version_is_at_least 4.0  IUSE+= objc-gc mudflap
-   tc_version_is_at_least 4.1  IUSE+= libssp objc++
+   tc_version_is_at_least 4.1  IUSE+= libssp objc++  
REQUIRED_USE+= objc++? ( cxx )
tc_version_is_at_least 4.2  IUSE+= openmp
tc_version_is_at_least 4.3  IUSE+= fixed-point
tc_version_is_at_least 4.6  IUSE+= graphite
tc_version_is_at_least 4.6  IUSE+= lto
-   tc_version_is_at_least 4.7  IUSE+= go
+   tc_version_is_at_least 4.7  IUSE+= go  REQUIRED_USE+= 
go? ( cxx )
fi
 fi
 
@@ -559,7 +560,7 @@
 # specs + env.d logic 
 
 # pkg_* 
-toolchain_pkg_setup() {
+toolchain-r1_pkg_pretend() {
if [[ -n ${PRERELEASE}${SNAPSHOT} || ${PV} == ** ]] 
   [[ -z ${I_PROMISE_TO_SUPPLY_PATCHES_WITH_BUGS} ]]
then
@@ -567,21 +568,19 @@
This is to try and cut down on people filing bugs for 
a compiler we do not currently support.
fi
 
+   [[ -z ${UCLIBC_VER} ]]  [[ ${CTARGET} == *-uclibc* ]]  die Sorry, 
this version does not support uClibc
+}
+
+toolchain-r1_pkg_setup() {
# we dont want to use the installed compiler's specs to build gcc!
unset GCC_SPECS
 
-   if ! use_if_iuse cxx ; then
-   use_if_iuse go  ewarn 'Go requires a C++ compiler, disabled 
due to USE=-cxx'
-   use_if_iuse objc++  ewarn 'Obj-C++ requires a C++ compiler, 
disabled due to USE=-cxx'
-   use_if_iuse gcj  ewarn 'GCJ requires a C++ compiler, disabled 
due to USE=-cxx'
-   fi
-
want_minispecs
 
unset LANGUAGES #265283
 }
 
-toolchain_pkg_postinst() {
+toolchain-r1_pkg_postinst() {
do_gcc_config
 
if ! is_crosscompile ; then
@@ -617,7 +616,7 @@
fi
 }
 
-toolchain_pkg_postrm() {
+toolchain-r1_pkg_postrm() {
# to make our lives easier (and saner), we do the fix_libtool stuff 
here.
# rather than checking SLOT's and trying in upgrade paths, we just see 
if
# the common libstdc++.la exists in the ${LIBPATH} of the gcc that we 
are
@@ -694,17 +693,16 @@
die Failed to fixup file ${jfile} for rename to grmic
done
 }
-toolchain_src_unpack() {
-   [[ -z ${UCLIBC_VER} ]]  [[ ${CTARGET} == *-uclibc* ]]  die Sorry, 
this 

Re: [gentoo-dev] RFC: toolchain-r1.eclass

2013-07-25 Thread Matt Turner
On Thu, Jul 25, 2013 at 9:26 AM, Paweł Hajdan, Jr.
phajdan...@gentoo.org wrote:
 Then there is a question whether toolchain packages should use EAPI 5,

EAPI=5 would be useful for both the mips team (for bug 477956) and for
catalyst builders (for subslot dependencies when dealing with binary
packages).