From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 71E9D138010 for ; Sun, 24 Mar 2013 15:40:39 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C37C3E085A; Sun, 24 Mar 2013 15:40:35 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9FF21E07F8 for ; Sun, 24 Mar 2013 15:40:34 +0000 (UTC) Received: from pomiocik.lan (unknown [83.238.59.230]) (using SSLv3 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id BE6B633BF48; Sun, 24 Mar 2013 15:40:32 +0000 (UTC) Date: Sun, 24 Mar 2013 16:41:15 +0100 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: gentoo-dev@lists.gentoo.org Cc: aballier@gentoo.org Subject: Re: [gentoo-dev] [PATCH 2/2] Support wrapping headers for multilib ABIs. Message-ID: <20130324164115.1af3b499@pomiocik.lan> In-Reply-To: <20130324161452.63a55140@portable> References: <20130323172532.1b1100e2@pomiocik.lan> <1364055998-23674-2-git-send-email-mgorny@gentoo.org> <20130324161452.63a55140@portable> Organization: Gentoo X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA512; boundary="Sig_/yL_xjYd6u8_=t9eVKzZPQQR"; protocol="application/pgp-signature" X-Archives-Salt: 61204227-4c85-45e9-9d27-fe5b56777115 X-Archives-Hash: 3d1342045ba1e8bd07a21d57c1be5e5b --Sig_/yL_xjYd6u8_=t9eVKzZPQQR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, 24 Mar 2013 16:14:52 +0100 Alexis Ballier wrote: > On Sat, 23 Mar 2013 17:26:38 +0100 > Micha=C5=82 G=C3=B3rny wrote: >=20 > > --- > > gx86/eclass/autotools-multilib.eclass | 82 > > +++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) > >=20 > > 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 >=20 >=20 > 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 > > =20 > > EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test > > src_install=20 > > +# @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=3D( > > +# /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 "${@}" > > } > > =20 > > +_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=3D${f#/} > > + > > + if [[ ${f} !=3D usr/include/* ]]; then > > + die "Wrapping headers outside > > of /usr/include is not supported at the moment." > > + fi >=20 > 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=3D${f#usr/include/} > > + > > + local dir=3D${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 + >=20 > 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 >=20 > 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. > [...] >=20 > 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 >=20 > 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. --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/yL_xjYd6u8_=t9eVKzZPQQR Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQJ8BAEBCgBmBQJRTx6gXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEK3zAQAL0tz1HQuAMucisCIS0nIjzp amJ08OMzmvxU9DCf4tlocOCG3JgPFRqx/BcQZ6pPbrZXVksmwlCweOBxuTPGnV35 KXi0l09nNniRB1+uJey37KlUxT3osDUZ2GMwmW+FCcvZud1Ud4zh9az5xvhs796v MZ6oKFE6z8TXmVXm3LAJbnazKzEXTe9v8Ojn8+cCJACx2nfWHZeMr9TW5Q83kmbn echfzWtaVuysGwBfvMATrrqMQPMXnJTQXrgyRp3QSGg+LhQQjncuN++nBXo1/z0i mMTyAHeqnrpDH/G28OUnFlNi0z3ZznY0NPzC8/FJFFcTKOEyUigvmG/Sgjww4SMX 45Lcr9W79tgdpzYg8lYULPJf6KjZ35hIGVS3zMIJOMXEnzT8yKAjt/BWocztMVIw TFJX/52+RffcZQqdlVWN1ZqCpHxprej3EjatV/iy17MpAGTFRu9e/f0m5nRhHuRM eZv1jPqFkenVqutBQ38sIRxq8ADKFEywgYGyV0C4SSPphMaWimwn/ohT6UbljYg7 uI+YMxaB0XDyKLv0THlQHycyKHABxdNfmWN8rr0D/S7JMTnQC+7rKMp7UECTDBSm 5PCmFbwr2ScVWPOkiMRg2DEBcJJW0RozAJpTujTvy3V0q4ZClCWB80DvbMOyMecI dmLn7/qIQPkxUNM4cmRi =pvf5 -----END PGP SIGNATURE----- --Sig_/yL_xjYd6u8_=t9eVKzZPQQR--