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 4729F138334 for ; Fri, 14 Dec 2018 21:02:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A2336E0C3B; Fri, 14 Dec 2018 21:02:47 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 3818CE0C22 for ; Fri, 14 Dec 2018 21:02:46 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 9B660335C08; Fri, 14 Dec 2018 21:02:43 +0000 (UTC) Message-ID: <1544821351.7371.5.camel@gentoo.org> Subject: Re: [gentoo-dev] How to handle ROC forks of llvm and clang From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org, llvm@gentoo.org Cc: gienah@gentoo.org, gentoo@holzke.net Date: Fri, 14 Dec 2018 22:02:31 +0100 In-Reply-To: <5d774dabaee69376e4780c076fb271a6@gentoo.org> References: <5d774dabaee69376e4780c076fb271a6@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-t15gykVsvvqo4C2rnwPM" X-Mailer: Evolution 3.26.6 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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply Mime-Version: 1.0 X-Archives-Salt: 0fa413da-f02d-4c7a-889f-814ea54bc685 X-Archives-Hash: e67298bba0eee39a6c2f2ea24f715777 --=-t15gykVsvvqo4C2rnwPM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2018-12-14 at 15:00 -0500, Craig Andrews wrote: > I'm working on packaging the Radeon Open Compute (ROC) packages for=20 > Gentoo with first goal being to get the OpenCL runtime working. >=20 > The OpenCL runtime can be found at:=20 > https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime >=20 > It has a mess of dependencies; I can handle most of them (not that it'll= =20 > be easy, but at least I know what to do). The 3 troublemakers I'd like= =20 > to discuss are the ROC forks of: > llvm: https://github.com/RadeonOpenCompute/llvm/ > clang: https://github.com/RadeonOpenCompute/clang/ > ldd: https://github.com/RadeonOpenCompute/ldd/ >=20 > Potential approaches include: > 1) Create new packages for each: sys-devel/radeon-open-compute-llvm,=20 > sys-devel/radeon-open-compute-clang, sys-devel/radeon-open-compute-lld Are you really going to maintain that? Are they going to block stock LLVM packages, and require everyone to go through hell, or are they going to be just bundled packages masked as unbundled? > 2) Add use flags to existing packages that apply the ROC changes as a=20 > patch > 3) Add use flags to existing packages that use ROC archives as the=20 > SRC_URIs What makes you believe that ROC is special enough to deserve this?=20 There are Rust fork, Julia fork... all of them going to 'eventually' be merged upstream. Trying to allow even some of them is going to turn LLVM into a maintenance PITA. Not to mention it ain't easy already. > 4) Take the approach justxi did in his overlay which is to bundle these= =20 > dependencies wherever they're needed; for example, take a look at=20 > https://github.com/justxi/rocm/blob/master/media-libs/ROCm-OpenCL-Runtime= /ROCm-OpenCL-Runtime-1.7.0-r3.ebuild >=20 > Personally, I dislike (4), as it's contrary to the bundling policy that= =20 > Gentoo tries to follow. It's no different from (1), except in (1) you pretend it isn't bundled, except it's something nobody else is going to do. > Since ROC will eventually upstream all of it's work, (2) is ideal - but= =20 > I have no idea what the timeline on that upstreaming effort may be, and= =20 > I can't find anything that gives a hint. So bundle it until it's actually merged. This reduces the work right now, and makes it possible to switch to a 'proper' solution with minimum effort. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-t15gykVsvvqo4C2rnwPM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQKTBAABCgB9FiEEXr8g+Zb7PCLMb8pAur8dX/jIEQoFAlwUGmdfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDVF QkYyMEY5OTZGQjNDMjJDQzZGQ0E0MEJBQkYxRDVGRjhDODExMEEACgkQur8dX/jI EQrAhhAA5/RUzUyVbU7gh6Kc0SWvLfXsfQPxWEIwEI788auvZuM2dJGEp5Eu0C5t 29r4t5jCIyvLtTb40pnytTePaIvUOBA6QizgrE4KeriqtAznBwNzxULB+IybCVTg rcXYKSOxho2ij+sPPtmExlJc19z6bkL3dc5fgm6vR7Veluzggx0bg5a8deUB8Gvn GJ0xwo2z1gu88bOSLwC1LmVvbgoB7eAytsejUbgmjKu7AanPTafgPoPniaD1nqy2 wGP9Wfc5qYB8oS1pcrfYBnOQlRNruJHZwmOeGdp4qF7P23gRnkokwdXxheyWGGbH CZhDZkFxhMXc2exNt5HSIwoPCbiu26fmziMZNLXki4zmoPSvZPXXFDfrRpuFrrrn sj1sXKJ49+96gybOl5p3pLTcNlJLLb8CSvYY0mt0PHl2HuB7hs5sBCgFpSDkEZq8 1p9uW6NX3XMGW9OO4ZTfmhGxa5nXjWJZxbRKgXlj6YHDMA4+qXj5eB/TdbB9ulrT h5FjdeJeZhNo8t6597xGw5jpIBbKCCQe748kACOAKQMcJumxKVi5yiBmQDqtXDyc Hy4ITEPeZub6o9MwZCjSKhfbqRzTsRmW4L65FMMIV4baUXmBXBIduWcqWpnqFTHZ k4njG+HiM5Gbi60E8yzEj0O7HtzqnFmKlv4UAD7L7xjlskhCisY= =otte -----END PGP SIGNATURE----- --=-t15gykVsvvqo4C2rnwPM--