On Sun, 24 Mar 2013 16:14:52 +0100 Alexis Ballier <[email protected]> wrote:
> On Sat, 23 Mar 2013 17:26:38 +0100 > Michał Górny <[email protected]> wrote: > > > --- > > gx86/eclass/autotools-multilib.eclass | 82 > > +++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) > > > > diff --git a/gx86/eclass/autotools-multilib.eclass > > b/gx86/eclass/autotools-multilib.eclass index d7372b0..c65c777 100644 > > --- a/gx86/eclass/autotools-multilib.eclass > > +++ b/gx86/eclass/autotools-multilib.eclass > > > why not multilib-build ? Because it has two parts which have to be called at the right time. It doesn't have a public API yet, so I'm putting it where I can test it sanely. > > @@ -33,6 +33,28 @@ inherit autotools-utils multilib-build > > > > EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test > > src_install > > +# @ECLASS-VARIABLE: MULTILIB_WRAPPED_HEADERS > > +# @DESCRIPTION: > > +# A list of headers to wrap for multilib support. The listed headers > > +# will be moved to a non-standard location and replace with a file > > +# including them conditionally to current ABI. > > +# > > +# This variable has to be a bash array. Paths shall be relative to > > +# installation root (${D}), and name regular files. Recursive > > wrapping +# is not supported. > > +# > > +# Please note that header wrapping is *discouraged*. It is preferred > > to +# install all headers in a subdirectory of libdir and use > > pkg-config to +# locate the headers. Some C preprocessors will not > > work with wrapped +# headers. > > +# > > +# Example: > > +# @CODE > > +# MULTILIB_WRAPPED_HEADERS=( > > +# /usr/include/foobar/config.h > > +# ) > > +# @CODE > > + > > autotools-multilib_src_prepare() { > > autotools-utils_src_prepare "${@}" > > } > > @@ -49,13 +71,73 @@ autotools-multilib_src_test() { > > multilib_foreach_abi autotools-utils_src_test "${@}" > > } > > > > +_autotools-multilib_wrap_headers() { > > + debug-print-function ${FUNCNAME} "$@" > > + local f > > + > > + for f in "${MULTILIB_WRAPPED_HEADERS[@]}"; do > > + # drop leading slash if it's there > > + f=${f#/} > > + > > + if [[ ${f} != usr/include/* ]]; then > > + die "Wrapping headers outside > > of /usr/include is not supported at the moment." > > + fi > > Do you really want to support this at some point? Why? Honestly? No. But if people need it, I don't see much of a problem to add the support in the future. > I'd just go for paths relative to $EPREFIX/usr/include (or > $ED/usr/include) for MULTILIB_WRAPPED_HEADERS. That would simplify the > code. That's true. But on the other hand, that would introduce yet another root for paths which would probably end up being confusing. Using /usr/include/... feels more natural IMO. And of course, it leaves the possibility of supporting other locations in the future. > > + # and then usr/include > > + f=${f#usr/include/} > > + > > + local dir=${f%/*} > > + > > + # $CHOST shall be set by multilib_toolchain_setup > > + dodir "/tmp/multilib-include/${CHOST}/${dir}" > > + mv "${ED}/usr/include/${f}" > > "${ED}/tmp/multilib-include/${CHOST}/${dir}/" || die + > > why not use $T rather than $ED/tmp ? I prefer using $D rather than $T for files which are intended to be installed. Purely theoretically, $T could be on another filesystem than $D. Then, moving the file back and forth could cause it to lose some of the metadata -- and will be slower, of course. > > + if [[ ! -f ${ED}/tmp/multilib-include/${f} ]]; then > > + dodir "/tmp/multilib-include/${dir}" > > + cat > "${ED}/tmp/multilib-include/${f}" > > <<_EOF_ || die +/* This file is auto-generated by > > autotools-multilib.eclass > > + * as a multilib-friendly wrapper to /${f}. For the original content, > > + * please see the files that are #included below. > > + */ > > +_EOF_ > > + fi > > + > > + local defs > > + case "${ABI}" in > > didn't you say $ABI may have name collisions? > considering the code below, it seems much safer to match on $CHOST Yes, that's why I've put the whole matching inline instead of introducing a function to obtain the values. The current design of the eclass -- which was quite stupid of me -- doesn't provide a way to access that ABI_* thing. I am going to change that in the future but don't want to step into two different issues at a time. At a first glance, $CHOST sounds like a neat idea. But I'm afraid it's not a really safe choice. From a quick glance, CHOST values for x86 were: i*86-pc-linux-gnu x86_64-pc-linux-gnu x86_64-pc-linux-gnux32 I feel like there's a lot of variables here, ends up in a bit ugly pattern matching IMO. > [...] > > It'd be nice to have an attempt to support all the ABIs gentoo supports > in that file: I'd prefer to spot possible problems with this solution > vs. sedding a template for example to be seen before having to rewrite > it. > For example, IIRC, ppc64 defines both __powerpc__ and __powerpc64__, > the natural way would be: > #if defined(__powerpc64__) > ppc64 stuff > #elif defined(__powerpc__) > ppc stuff > #endif > > with your approach that'd be: > #if defined(__powerpc__) && !defined(__powerpc64__) > ppc stuff > #elif defined(__powerpc64__) > ppc64 stuff > #endif I had the same problem with x32. I've chosen the solution which worked and was easy to implement. > doing with a template has its disadvantages but allows more flexibility > in how the #ifery is written; I don't want to realize your approach > cannot deal with some weird arches after it has been deployed. To be honest, I can't really imagine how we could work with a template here. It would at least require the function to be aware of other ABIs which I really wanted to avoid. Of course, then there's the whole code to handle it, and honestly I don't have a vision how it would work. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
