There are features in more recent EAPIs that could be used by the core packages. Care should be taken to provide an upgrade path - just note that there are requirements created by e.g. python and portage anyway. I'll attach draft patches for toolchain.eclass and gcc ebuild - feedback is welcome and I can later proceed to do a similar thing for example for binutils.
Created attachment 351678 [details, diff] toolchain.eclass.diff
Created attachment 351680 [details, diff] gcc-4.7.3.ebuild.diff
I'm surprised there are no prefix changes.
New EAPIs could be supported without introduction of new eclass. E.g.: if has "${EAPI:-0}" 0 1 2 3; then EXPORT_FUNCTIONS pkg_setup src_unpack src_compile src_test src_install pkg_postinst pkg_postrm else EXPORT_FUNCTIONS pkg_pretend pkg_setup src_unpack src_prepare src_configure src_compile src_test src_install pkg_postinst pkg_postrm fi ... if ! has "${EAPI:-0}" 0 1 2 3; then REQUIRED_USE+=" gcj? ( cxx )" fi
Yes, there won't be a new eclass, i'm working on the existing one.
Created attachment 354370 [details, diff] prefix.patch toolchain eclass Prefix support. TODO: do we really need to guard against symlink in EPREFIX? Can we make it a function to reduce code duplication?
Created attachment 354372 [details, diff] darwin.patch darwin libtool fix, and rpath?? (TODO: not sure of the source)
Created attachment 354374 [details, diff] includes.patch Seems that in Prefix we retained the fixinclude hack. What's special for ia64?
(In reply to Benda Xu from comment #6) > Created attachment 354370 [details, diff] [details, diff] > prefix.patch > > toolchain eclass Prefix support. > > TODO: do we really need to guard against symlink in EPREFIX? Can we make it > a function to reduce code duplication? We also need a way to distinguish between gentoo-fbsd (vanilla) and gentoo-freebsd (Prefix)
Created attachment 354376 [details, diff] prefix.patch I think we'd better drop support for EPREFIX with a symlink, it can be avoided after all. Comments, haubi?
Created attachment 355744 [details, diff] prefix.patch drop TPREFIX and add a warning for EPREFIX with a symlink as per bug 478434 comment 3.
Hey, guys. Have you reviewed the patches? Comments welcome so that I could improve it to meet the quality standard.
I'm working on refactoring the eclass now to make separating stuff into the new phase functions a bit cleaner. Benda, I'd like you to open a new bug for the prefix changes, and I'll need Mike to do the review because I'm really not qualified. It would be best if you could wait until this bug is closed as any patch you make now won't apply after I'm done here. I'm strongly considering adding a new toolchain-next eclass for unstable gcc ebuilds. This would allow us to test big changes without breaking stable versions. Mike, what do you think?
(In reply to Ryan Hill from comment #13) > I'm working on refactoring the eclass now to make separating stuff into the > new phase functions a bit cleaner. Benda, I'd like you to open a new bug > for the prefix changes, and I'll need Mike to do the review because I'm > really not qualified. It would be best if you could wait until this bug is > closed as any patch you make now won't apply after I'm done here. I am aware that there is a lot of work for a refactorization. I'm okay with plan.
other toolchain packages (binutils/gdb/glibc) are handled in other bugs (and are done now), so this bug is only about gcc
Now that the toolchain.eclass in tree already supports EAPI 4 and 5, we can close this bug and open a Prefix bug separately, right?
yes, let's handle any more issues in new bugs
