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

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

["Paweł Hajdan, Jr."]

[-- Attachment #1.1: Type: text/plain, Size: 714 bytes --]

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ł

[-- Attachment #1.2: gcc-4.7.3.ebuild.diff --]
[-- Type: text/plain, Size: 1184 bytes --]

--- gcc-4.7.3.ebuild.orig	2013-06-16 17:43:10.000000000 -0700
+++ gcc-4.7.3.ebuild	2013-06-16 17:43:09.000000000 -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

[-- Attachment #1.3: toolchain.eclass.diff --]
[-- Type: text/plain, Size: 4220 bytes --]

--- toolchain.eclass	2013-06-16 17:42:59.000000000 -0700
+++ toolchain-r1.eclass	2013-06-16 17:43:26.000000000 -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} == *9999* ]] &&
 	   [[ -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 version does not support uClibc"
-
+toolchain-r1_src_unpack() {
 	if [[ ${PV} == *9999* ]]; then
 		git-2_src_unpack
 	else
 		gcc_quick_unpack
 	fi
+}
 
+toolchain-r1_src_prepare() {
 	export BRANDING_GCC_PKGVERSION="Gentoo ${GCC_PVR}"
-	cd "${S}"
 
 	if ! use vanilla ; then
 		if [[ -n ${PATCH_VER} ]] ; then
@@ -1466,7 +1464,7 @@
 	export GCJFLAGS=${GCJFLAGS:-${CFLAGS}}
 }
 
-toolchain_src_compile() {
+toolchain-r1_src_configure() {
 	gcc_do_filter_flags
 	einfo "CFLAGS=\"${CFLAGS}\""
 	einfo "CXXFLAGS=\"${CXXFLAGS}\""
@@ -1482,10 +1480,14 @@
 	fi
 	# Build in a separate build tree
 	mkdir -p "${WORKDIR}"/build
-	pushd "${WORKDIR}"/build > /dev/null
+	cd "${WORKDIR}"/build
 
 	einfo "Configuring ${PN} ..."
 	gcc_do_configure
+}
+
+toolchain-r1_src_compile() {
+	cd "${WORKDIR}"/build
 
 	touch "${S}"/gcc/c-gperf.h
 
@@ -1495,18 +1497,16 @@
 
 	einfo "Compiling ${PN} ..."
 	gcc_do_make ${GCC_MAKE_TARGET}
-
-	popd > /dev/null
 }
 
-toolchain_src_test() {
+toolchain-r1_src_test() {
 	if use regression-test ; then
 		cd "${WORKDIR}"/build
 		emake -k check
 	fi
 }
 
-toolchain_src_install() {
+toolchain-r1_src_install() {
 	local x=
 
 	cd "${WORKDIR}"/build
@@ -2096,9 +2096,3 @@
 	#use treelang
 	return 0
 }
-
-# should kill these off once all the ebuilds are migrated
-gcc_pkg_setup() { toolchain_pkg_setup ; }
-gcc_src_unpack() { toolchain_src_unpack ; }
-gcc_src_compile() { toolchain_src_compile ; }
-gcc_src_test() { toolchain_src_test ; }

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

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

[Matt Turner]

On Thu, Jul 25, 2013 at 9:26 AM, "Paweł Hajdan, Jr."
<phajdan.jr@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).

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

[Ryan Hill]

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

On Thu, 25 Jul 2013 09:26:48 -0700
""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:

> 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.

I meant to work on this last week but got distracted.  I have a bunch of
build changes testing locally but need to make some cross compilers.

I don't think we will be moving to 5 very soon.  I have nothing against it but
Mike might be a harder sell.  I want USE deps so I'm going to do 2 at least,
then get the prefix guys on board for 3.

Like I said on the bug I don't think we want to do a new eclass (or if we did I
would make a toolchain-next for masked versions and backport stuff).


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Pacho Ramos]

El jue, 25-07-2013 a las 22:30 -0600, Ryan Hill escribió:
> On Thu, 25 Jul 2013 09:26:48 -0700
> ""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:
> 
> > 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.
> 
> I meant to work on this last week but got distracted.  I have a bunch of
> build changes testing locally but need to make some cross compilers.
> 
> I don't think we will be moving to 5 very soon.  I have nothing against it but
> Mike might be a harder sell.  I want USE deps so I'm going to do 2 at least,
> then get the prefix guys on board for 3.
> 
> Like I said on the bug I don't think we want to do a new eclass (or if we did I
> would make a toolchain-next for masked versions and backport stuff).
> 
> 

Last time I talked with him, Mike was ok with eapi4 for base-system
packages, but no idea if toolchain will have a special treatment. Better
wait for him to reply here :/

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

[Donnie Berkholz]

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

On 22:30 Thu 25 Jul     , Ryan Hill wrote:
> I don't think we will be moving to 5 very soon.  I have nothing 
> against it but Mike might be a harder sell.  I want USE deps so I'm 
> going to do 2 at least, then get the prefix guys on board for 3.

The council deprecated 1/2 in April so I'd avoid those.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux <http://dberkholz.com>
Analyst, RedMonk <http://redmonk.com/dberkholz/>

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