From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 8CE52138334 for ; Fri, 21 Sep 2018 07:17:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A5FF0E088A; Fri, 21 Sep 2018 07:17:33 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 1DAD4E07F1 for ; Fri, 21 Sep 2018 07:17:32 +0000 (UTC) Received: from ernie.localnet ([95.222.27.28]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M9b4B-1fwPFg0Fvb-00Cy3s; Fri, 21 Sep 2018 09:17:19 +0200 From: Dennis Schridde To: gentoo-dev@lists.gentoo.org Cc: Guilherme Amadio Subject: Re: [gentoo-dev] [RFC] C++ standard in ebuilds Date: Fri, 21 Sep 2018 09:17:17 +0200 Message-ID: <3911746.QXzu3d5OL2@ernie> In-Reply-To: <20180918143122.GB25320@gentoo.org> References: <20180917153738.GA5402@gentoo.org> <20180918143122.GB25320@gentoo.org> 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; boundary="nextPart22311950.CPdMt4fk63"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Provags-ID: V03:K1:uXz/WpxsKJvK1c7mf9+EWYcmAbWHpO3QUAdBn6PEELLFSlwwVTF xQ2kbQQyTXrxfz8Db6SehRlJikjUMjSmrXDip21WqmAsElJEzfc82tLU0sgcre3/XKyLOdZ NmBwBtFp4L0xEsgAV53/ohwjXKv6QVakWwfhSeDV/weuP8e45yDltKX0ibKJ2e0uyXppJyq EWJvYjsSH3amUfEmHDi6w== X-UI-Out-Filterresults: notjunk:1;V01:K0:8VZ+o1wAT1E=:0z8p149ywZrT4PIqIHZ1Zp +Vy6bdhVq37NAziqhcxVLi9PUFNsNNW6stPNXvNw7eZACoLaCfzqbmmn7pVVIip051zhW9+JU y1UxFERRzA2/wi4oojdEY/Z2UUhFrrazEd9FeNHoKLqIQzfnsNAQ4TytW8BeKlunsk7tEMh8D oD2u44HgRX0Np+ZfZwX/MD16RTRxOMtXgDos5KGFTVOGpsKk3vGoS8/x4LoFwR9aHGE+Hoo4N R8cRKHM50S1AnCY0QCCxvwTA5i52JhF30RqTVa3yxQJBlT1RdI2OcgcQKvHgWKsamtcTFstCg tdgdSddf0PpPQ04SP9olMfVRgrs44f0brF24XRLpmSQtle10bAY9nO+kDBtgL47BhN7MlgKab JzJ4K6W9i5AeDX8PkzEW9NjEUIyQq4zrYQPwc6zuw5TfaYIj0oVvus/erx/rObp4YU0a8CkK7 eYUCmFxNvGtXXuMkWg1WhH0EI+/Ycb7dHU6MzxJyS/gLFrYq+7NSu/7nqtRVsM2e8QBq27ofW 0LyRnGsVesvZ7hO8jvX/IfUrS74URN/OjIMz6lPd3VitQdmX2qMgImIi54D6Ql5I8r/TqslwR MoZIJmWzwXBmmK76as5aouabNolNTj7FAC0MKYKKms9lhLoAlwTnTkjJ4Sbpgz72Jkp761VhF BLn1JhBEa1VUDZH+qtVQIQhzba1oQmzFVk8vYqkuHrw4pI018Of3uvW7Oj9PqB+JqtKoNcChJ D4ymNallC7ecBAkN2Aj955caocwEi8SobVa7DdX5autwCItwrAW9XEiyatew5DsfDBOqAECMH ywzed05g3fLZ1CkhbBZnZThI5ktrA== X-Archives-Salt: d8f834d6-2790-4f12-a326-341e6f6116fb X-Archives-Hash: db9e15d7a5dab428114d06ac6a7eb87c --nextPart22311950.CPdMt4fk63 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Tuesday, 18 September 2018 16:31:23 CEST Guilherme Amadio wrote: > On Mon, Sep 17, 2018 at 10:24:48AM -0700, Matt Turner wrote: > > I don't understand what a potential solution would be. > > > > The various projects use -std=c++XXX because that's what their code > > requires. -std=c++XXX can't generally be changed. If a dependent > > project is incompatible that's no different than any other case of > > incompatible dependencies in Gentoo. > > > > I think -std=c++XXX discussions before happened because gcc changed > > the C++ ABI with -std=c++11. I don't think that's particularly > > relevant here, since as far as I know different -std=c++XXX values > > don't change the ABI with current gcc. > > > > So I guess my understanding is that there isn't a problem different > > than existing incompatible dependencies, but maybe I have > > misunderstood you. > > My concern is with, say, package foo that depends on both bar and baz, > and bar and baz support from C++11 to C++17, but must be compiled with > the same version of the standard so that foo can link against both of > them without having a broken ABI. I think that depending on bar[c++14], > or having a similar mechanism to Python to handle "same version of the > standard" with ${CXXSTD_REQUIRED_USE} or similar in an eclass would be > nice. Maybe add a CXXABI USE_EXPAND variable and then handle this case similar to python-single-r1.eclass packages with CXXABI_COMPAT and CXXABI_USEDEP? --nextPart22311950.CPdMt4fk63 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEE0Ngi/nirHnbsz3NFz+h/M161qdwFAlukmv0ACgkQz+h/M161 qdyOLgv8CclqpX3DCGLi+KMwurAVRr5t3LWPXPIUeEbvhfRRUOt875afwGRgtlwW fNlclbj7KZEdJFApQZsnrfnMbJEVdyaXd0J0dP7wszwLUVVvhJTexQy9vLnbu04I NrKb7Oh7XmnpU+O9tWMuxU5esdwGhX8D1fNN24iteCyCztQNQJ/GV6VGDeOXE5E0 hEMcwpWxL0iV1vAkCCxf1G9MFIjKCu2aGpNvTWqcjNk9Eul5aDF+9umxzjAxTt5O Uazgi44IVNEanCyZ5/AIT6r1l1mW+zBXB7EFHhW+qi5l/QCtG6p5luXH3vlGINs3 VznLUakBOSTj7uPKofSWNGbVuyT0TBiwsfr/UOi6oIt8cbe7jUsItBNHpOeb5wqc 4KXvDt0sWcllm79iQlcZ5Up8+1h7XeS0m9kNAnsnAhIQkF04GB7KoXnXXj3mAv9r xQvmb+quXdTQqy8bzM0FnMftNozChmQT5mN06Shy/yevPJ/98RopUbH51fUNmHzm 19VTavCF =WLaF -----END PGP SIGNATURE----- --nextPart22311950.CPdMt4fk63--