| Summary: | fortran-2.eclass: build related checks in pkg_setup should be moved elsewhere | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Fabio Erculiani (RETIRED) <lxnay> |
| Component: | Eclasses | Assignee: | Justin Lecher (RETIRED) <jlec> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | sci |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://bugs.sabayon.org/show_bug.cgi?id=4170 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 478552, 478554, 478558, 478562, 478564, 478566, 478568, 478572, 478574, 478576, 478578, 478580, 478582, 478584, 478586, 478588, 478590, 478592, 478594, 478596, 478598, 478600, 478602, 478604, 478606, 478608, 478610, 478612, 478614, 478616, 478618, 478620, 478622, 478624, 478626, 478628, 478630, 478632, 478634, 478636, 573088 | ||
| Bug Blocks: | |||
| Deadline: | 2013-09-30 | ||
(In reply to Fabio Erculiani from comment #0) > doing build > related checks in pkg_setup is also considered bad (not sure if it's > enforced by qa@). I don't know anything about that. A lot of eclasses do toolchain related thing in pkg_setup. However they must ensure it does not break binpkgs. That is achievable by: if [[ ${MERGE_TYPE} != binary ]]; then foo fi other ebuilds do this in pkg_pretend src_prepare is definitely wrong Using ${MERGE_TYPE} is definitely the best way to fix this, but several ebuilds are just using src_prepare, because ${MERGE_TYPE} was introduced only recently.
The problem with src_prepare is that you do src_unpack for no reason then. Environment/Toolchain checks should be very early. ${MERGE_TYPE} is EAPI-4 IIRC. So definitely not something we can easily use in the toolchain zone I guess.
(In reply to Fabio Erculiani from comment #4) > ${MERGE_TYPE} is EAPI-4 IIRC. So definitely not something we can easily use > in the toolchain zone I guess. Good thing is that fortran is a sci thing and not something toolchain cares about. I checked the tree and the majority of packages has only old versions in EAPI <4. I will go for MERGE_TYPE here. For now I will add a QA warning in the eclass for deprecation of EAPI < 4 and will go through the tree and clean old ebuilds. I really like to avoid shifting the test around and I think after reading the devmanual ("Purpose: Pre-build environment configuration and checks") it is correctly placed there. + 29 Jul 2013; Justin Lecher <jlec@gentoo.org> fortran-2.eclass: + Fortran-2.eclass: enhance support for binary packages, #477070 + Everything with higher EAPI than 3 will handle bin packages just fine. commit 9fda59d6b5d979db17a70d27aaedeec235474c27 Author: Justin Lecher <jlec@gentoo.org> Date: Sat Mar 18 10:16:05 2017 +0000 Drop support for EAPI < 4 in fortran.eclass https://bugs.gentoo.org/show_bug.cgi?id=573088 https://bugs.gentoo.org/show_bug.cgi?id=477070 https://bugs.sabayon.org/show_bug.cgi?id=4170 Signed-off-by: Justin Lecher <jlec@gentoo.org> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9fda59d6b5d979db17a70d27aaedeec235474c27 |
Please see the downstream bug at URL. In Sabayon we have split gcc (base-gcc for libraries, gcc for the actual toolchain). Even though I understand that's not your business, doing build related checks in pkg_setup is also considered bad (not sure if it's enforced by qa@). Could you please move the bits below somewhere else? Perhaps in src_prepare? kthx! if [[ ${FORTRAN_NEED_OPENMP} == 1 ]]; then if _fortran-has-openmp; then einfo "${FC} has OPENMP support" else die "Please install current gcc with USE=openmp or set the FC variable to a compiler that supports OpenMP" fi fi