econf has respected --build/--target & CBUILD/CTARGET since at least 2004. it should be in PMS explicitly (the vars are already documented in ebuild-env-vars.tex). something simple like: --- a/pkg-mgr-commands.tex +++ b/pkg-mgr-commands.tex @@ -150,6 +150,8 @@ current phase function has returned. \item -{}-sysconfdir must be \t{\$\{EPREFIX\}/etc} \item -{}-localstatedir must be \t{\$\{EPREFIX\}/var/lib} \item -{}-host must be the value of the \t{CHOST} environment variable. + \item -{}-build must be the value of the \t{CBUILD} environment variable if set. + \item -{}-target must be the value of the \t{CTARGET} environment variable if set. \item -{}-libdir must be set according to Algorithm~\ref{alg:econf-libdir}. \item -{}-disable-dependency-tracking, if the EAPI is listed in table~\ref{tab:econf-options-table} as using it. This option will only be passed if the
${CBUILD:+--build=${CBUILD}} \ --host=${CHOST} \ ${CTARGET:+--target=${CTARGET}} \ [[ -z "${CBUILD}" ]] || LOCAL_EXTRA_ECONF="--build=${CBUILD} ${LOCAL_EXTRA_ECONF}" [[ -z "${CTARGET}" ]] || LOCAL_EXTRA_ECONF="--target=${CTARGET} ${LOCAL_EXTRA_ECONF}"
(In reply to Ulrich Müller from comment #1) > ${CBUILD:+--build=${CBUILD}} \ > --host=${CHOST} \ > ${CTARGET:+--target=${CTARGET}} \ > > > [[ -z "${CBUILD}" ]] || LOCAL_EXTRA_ECONF="--build=${CBUILD} > ${LOCAL_EXTRA_ECONF}" > [[ -z "${CTARGET}" ]] || LOCAL_EXTRA_ECONF="--target=${CTARGET} > ${LOCAL_EXTRA_ECONF}" Oops,
[Please ignore my two previous comments. Sorry for the bugspam.] Portage does this in phase-helpers.sh: ${CBUILD:+--build=${CBUILD}} \ --host=${CHOST} \ ${CTARGET:+--target=${CTARGET}} \ And Paludis, in build_functions.bash: [[ -z "${CBUILD}" ]] || LOCAL_EXTRA_ECONF="--build=${CBUILD} ${LOCAL_EXTRA_ECONF}" [[ -z "${CTARGET}" ]] || LOCAL_EXTRA_ECONF="--target=${CTARGET} ${LOCAL_EXTRA_ECONF}" (In reply to SpanKY from comment #0) > econf has respected --build/--target & CBUILD/CTARGET since at least 2004. Right, CBUILD is there since 2003-02-03, CTARGET since 2004-10-10: https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/portage/bin/ebuild.sh?r1=1.98&r2=1.99 https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/portage/bin/ebuild.sh?r1=1.198&r2=1.199 So I believe this is something that should be fixed retroactively in all existing EAPIs. > + \item -{}-build must be the value of the \t{CBUILD} environment variable if set. > + \item -{}-target must be the value of the \t{CTARGET} environment variable if set. Can you git format-patch this please?
(In reply to Ulrich Müller from comment #3) i can git send-email it to the group
(In reply to SpanKY from comment #4) > i can git send-email it to the group Fine with me.
We chose not to document cross-related behaviour in PMS because cross isn't supported by ebuilds (dependencies, for example). It's a bit odd to specify CBUILD and CTARGET when there's no way of using them.
(In reply to Ciaran McCreesh from comment #6) that's kind of misleading. their are edge cases that HDEPEND addresses, but overall, things work, and cross-compiling is supported in a lot of packages. people do embedded cross-compiles all the time (myself included) for a large number of packages unmodified. they also form the entire basis of CrOS which releases real devices for ARM/x86/x86_64/x32, and have done mips/arm64 developer builds. that grey area is not sufficient reason to not document this.
(In reply to SpanKY from comment #7) I tend to agree. Variables CBUILD and CTARGET are already mentioned in section 11.1 "Defined Variables", so also documenting their use in econf makes sense. Especially, when this agrees with the behaviour all three package managers.
This has been fixed some time ago: https://gitweb.gentoo.org/proj/pms.git/commit/?id=fa19a32ef1ca7c56dd56e477e3535ca5a310c8ee commit fa19a32ef1ca7c56dd56e477e3535ca5a310c8ee Author: Michał Górny <mgorny@gentoo.org> Date: Sun Feb 18 15:48:14 2018 +0100 pkg-mgr-commands: Add --build and --target to econf (retroactively) Amend the econf parameter list with --build and --target options corresponding to CBUILD and CTARGET variables respectively. They are useful for cross-compilation purposes (whose support is improved in EAPI 7), and all three package managers have been passing them dating back at least to 2005 and/or their inception appropriately. Discussion reference: https://archives.gentoo.org/gentoo-pms/threads/2018-02/ (split between several threads unfortunately)