Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Thomas Sachau <tommy@g.o>
Subject: Re: Re: spec draft for cross-compile support in future EAPI (EAPI-5)
Date: Sun, 17 Jun 2012 14:02:26 +0200
Duncan schrieb:
> Thomas Sachau posted on Sat, 16 Jun 2012 12:31:40 +0200 as excerpted:
> 
>> Since i am not that sure about my ability to write formal specs, i am
>> presenting my first draft for further review and suggestions for
>> improvement.
> 
> Just a format suggestion.  Call it nitpicky if you want, and yes, my 
> client isn't perfect, but I'm sure people with a bit of experience 
> writing such specs will tell you I'm not alone...
> 
> Several of your points ended up as very long single lines.  My client can 
> wrap, but that wraps the points as well (so for example 2.1 starts in the 
> middle of a line).  So I was left with the choice to either massively 
> horizontally scroll, or of trying to figure out where one point ended and 
> another began, since wrapping it... /wrapped/ it, so points appeared in 
> the middle of a line.
> 
> Please:
> 
> * If you use long lines, leave a vertical space (blank line) between 
> points so when a client wraps them, they wrap as individual paragraphs.
> 
> * Alternatively, wrap at something sensible. (The traditional wrap for 
> posting is 72 chars or so, 80 minus a few to allow a few levels of 
> quoting without rewrap.  I wouldn't complain at 90, but if you're going 
> to bother, you might as well go the standard route and avoid further 
> issues.)
> 
> Long lines as paragraphs would probably be easier especially early in the 
> process when you're modifying a lot, but you still risk (even more) 
> limited clients having issues with it.  YMMV.
> 

I suggest you look for a better client to handle the line wrapping
better. ;-) In the meantime, the same file attached with wrapped lines.

-- 

Thomas Sachau
Gentoo Linux Developer


For amd64 users, there is sometimes the issue, that they need 32bit libs for
certain packages (e.g. wine or many binary-only packages). Currently,
they only get them prepackaged in binary form with the emul-linux-x86-*
packages. But those packages have a few issues (list does not have to be
complete):

-they only contain a limited set of 32bit packages
-they are precompiled, so the user cannot define his own flags
-they have to be manually maintained and updated


So the idea was to add the ability to compile 32bit packages with support from
the package manager, so there is no need for additional packages to
maintain. After this was originally implemented, it was further extended
to allow cross-compilation for other targets, not only limited to 32bit
packages.


The basic way, how this should work:

1. Check for the current profile being multilib, this means, that the
MULTILIB_ABIS var exists and has more then 1 (space seperated) value.
Additionally, the DEFAULT_ABI var has to be defined and its content should
be part of the MULTILIB_ABIS var. Only continue with the following steps,
if this is true
2.1 Take the entries from MULTILIB_ABIS var and add a USE flag for each of them
in the form of multilib_abi_$value
2.2 Add "abiwrapper" as a USE flag
3. Check, if the package has USE=multilib enabled. Only continue with the
following steps, if this is false.
4. Add a use dependency for each USE flag added in step 2 for all dependencies
except those defined in a space seperated list of the NO_AUTO_FLAG var. The
dependency should then look like category/package[multilib_abi_$value?]
5. Find the first enabled USE flag from the list of step 2, start with
multilib_abi_$DEFAULT_ABI during the search. If none is enabled, use
multilib_abi_$DEFAULT_ABI. In the following, $ABI will reference the $value
part of the selected USE flag.
6. Before the pkg_setup phase is executed, setup the environment as following:
	-export CHOST with $CHOST_$DEFAULT_ABI
	-export $CC with $CHOST-gcc
	-export $CXX with $CHOST-g++
	-export $FC with $CHOST-gfortran
	-export $CHOST with $CHOST_$ABI
	-export $CBUILD with $CHOST_$ABI
	-export $CDEFINE with $CDEFINE_$ABI
	-export $CCASFLAGS with ${CCASFLAGS:-${CFLAGS}} and append $CFLAGS_$ABI
	-export $CFLAGS with $CFLAGS and append $CFLAGS_$ABI
	-export $CPPFLAGS with $CPPFLAGS and append $CPPFLAGS_$ABI
	-export $CXXFLAGS with $CXXFLAGS and append $CFLAGS_$ABI
	-export $FCFLAGS with $FCFLAGS and append $CFLAGS_$ABI
	-export $FFLAGS with $FFLAGS and append $CFLAGS_$ABI
	-export $ASFLAGS with $ASFLAGS and append $ASFLAGS_$ABI
	-export $LDFLAGS with $LDFLAGS and append $CFLAGS_$ABI
	-export $PKG_CONFIG_PATH with /usr/$LIBDIR_$ABI/pkgconfig

7. After src_install is finished:
7.1 Execute the following or equivalent code (prep_ml_binaries is a function
from multilib-portage from [1]):
prep_ml_binaries $(find "${D}"usr/bin "${D}"usr/sbin "${D}"bin "${D}"sbin -type f -name '*-config' 2>/dev/null)
7.2 If USE flag abiwrapper is enabled, execute:
local noabi=()
for i in ${MULTILIB_ABIS}; do
	noabi+=( ! -name '*-'${i} )
done
if use abiwrapper ; then
	for i in $(find "${D}"usr/bin/ "${D}"usr/sbin "${D}"bin "${D}"sbin -type f ${noabi[@]} 2>/dev/null); do
		prep_ml_binaries "${i}"
	done
fi
7.3. After src_install, do the following checks:
	-is $Dusr/include not empty
	-is $usr/$LIBDIR_$ABI not empty
	-is abiwrapper USE flag enabled and any of /bin /usr/bin /sbin
	 /usr/sbin not empty
If any of those checks is true, save the content of $D to $D.$ABI. Check if
another USE flag from step 2 is enabled, if no, then continue with step 8,
otherwise reset everything to the state before pkg_setup. Find the next enabled
USE flag from step 5 and continue with that on step 6.
8. If there have been at least 2 USE flags from step 2 enabled, check if the
header files between the different target $ABIs differ. Move the files, that
dont differ, back to $D. If files differ, they are moved to 
$Dusr/include/gentoo-multilib/$ABI and the following or equivalent code is
executed in $D ($ALL_ABIS is the content of $MULTILIB_ABIS, for which the USE
flags from step 2 have been enabled) (_create_abi_includes is a function from
multilib-portage from [1]):
set --
for diffabi in ${ALL_ABIS}; do
	local define_var=CDEFINE_${diffabi}
	set -- "$@" "${!define_var}:${dir}/gentoo-multilib/${diffabi}"
done
_create_abi_includes "$@"
Now move the rest of the content of the temporary dirs back into $D with the
content of $D.$DEFAULT_ABI being the last.
9. pkg_preinst, pkg_postinst, pkg_prerm and pkg_postrm are executed within a
loop of the following form
for each enabled USE flag from step 2 do
	setup environment as described in step 6
	execute phase
done

[1]: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob;f=bin/auto-multilib.sh;hb=refs/heads/multilib

Optional: The code from step 6, 7.1, 7.2 and 8 (for managing the headers) could
be moved into an eclass. Then the PM executes this or an equivalent internal
function with newer versions of that eclass overwrite the internal functions.
That way, those parts could be updated without the need to update change
the PMS or to wait for another EAPI for an update/change.
Attachment:
signature.asc (OpenPGP digital signature)
Replies:
Re: Re: spec draft for cross-compile support in future EAPI (EAPI-5)
-- Thomas Sachau
Re: spec draft for cross-compile support in future EAPI (EAPI-5)
-- Duncan
References:
spec draft for cross-compile support in future EAPI (EAPI-5)
-- Thomas Sachau
Re: spec draft for cross-compile support in future EAPI (EAPI-5)
-- Duncan
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: spec draft for cross-compile support in future EAPI (EAPI-5)
Next by thread:
Re: spec draft for cross-compile support in future EAPI (EAPI-5)
Previous by date:
Re: Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual
Next by date:
Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.