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 CB59D138334 for ; Mon, 25 Mar 2019 04:23:17 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F38EAE094B; Mon, 25 Mar 2019 04:23:13 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 9C0A0E0932 for ; Mon, 25 Mar 2019 04:23:13 +0000 (UTC) Received: from grubbs.orbis-terrarum.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 46FDD335CC8 for ; Mon, 25 Mar 2019 04:23:12 +0000 (UTC) Received: (qmail 17465 invoked by uid 10000); 25 Mar 2019 04:23:08 -0000 Date: Mon, 25 Mar 2019 04:23:08 +0000 From: "Robin H. Johnson" To: gentoo development Subject: Re: [gentoo-dev] the state of dev-lang/lua Message-ID: References: <20190323212327.GA24656@linux1.home> 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 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1Ow488MNN9B9o/ov" Content-Disposition: inline In-Reply-To: <20190323212327.GA24656@linux1.home> User-Agent: Mutt/1.11.1 (2018-12-01) X-Archives-Salt: 5437a4b5-a7c9-4df2-abc2-1c8a78a6d0ab X-Archives-Hash: 8bf5ccffebcf20ac1f4d6ae50ed3fdff --1Ow488MNN9B9o/ov Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 23, 2019 at 04:23:27PM -0500, William Hubbs wrote: > Hi all, >=20 > Soon I will be working on fixing up the state of dev-lang/lua, and there > are a couple of things I want to mention. >=20 > The first thing is liblua as a shared library. If you are using lua > internally in a program, upstream strongly recommends not linking it > this way; it is supposed to be statically linked into the executable. > Because of this, and because of the amount of custom patching we do to > maintain liblua as a shared library, I plan to stop creating the shared > library. Please don't go back to static libraries. Look at the other major distros, all of them shipped shared Lua as the primary method. I'm just going to link to the Ubuntu examples here, but Debian, Fedora & Arch are similar: https://packages.ubuntu.com/source/cosmic/lua5.1 https://packages.ubuntu.com/source/cosmic/lua5.2 https://packages.ubuntu.com/source/cosmic/lua5.3 https://packages.ubuntu.com/cosmic/amd64/liblua5.1-0/filelist https://packages.ubuntu.com/cosmic/amd64/liblua5.2-0/filelist https://packages.ubuntu.com/cosmic/amd64/liblua5.3-0/filelist Ubuntu & Debian DO ship the static library .a file, as part of the liblua5.X-dev binary package. That said, the pkgconfig files we output for Lua5.2 & Lua5.3 do have errors in some cases, bringing in the non-slotted include directory, and trying to use the non-slotted library soname; which need to be fixed properly. Upstream's original objections about static libraries mostly revolved around the lack of registers on i386 with -fPIC, as well as subtle breakage when the library SONAME was just generically 'liblua', without much version information, as this broke when functions were dropped. > I'm a bit undecided still about slotting lua. I'm sure we > need subslots so we can force rebuilds when new lua releases enter the > tree. However, I'm still unsure whether we need slots. I don't know of > many things in the tree that are locked to a specific version > of lua (there is only one package based on an irc conversation I > had this week). > Does anyone have any thoughts?=20 Lua needs first class slots, just like Python & Ruby, not just subslots. Changing between versions can be a major undertaking. I think the slots to start with should be: - lua5.1 - lua5.2 - lua5.3 - luajit5.1 (this is basically an alternative implementation of Lua5.1, much like pypy implements Python2). Porting between versions is non-trivial, as the API has changed in incompatible ways. There are two tricks to make porting easier, but they are not guaranteed.=20 1. USE=3Ddeprecated on Lua5.2/5.3 offers most of the prior version APIs; mostly from Lua5.3 back to Lua5.2 & Lua5.1 with the LUA_COMPAT_5_2 & LUA_COMPAT_5_1 compile-time defines. 2. In the other direction, there is 'lua-compat-5.3', which we don't have packaged; It offers parts of Lua-5.3 functionality to Lua-5.1/5.2. I'll quote from the docs: "This does not make Lua 5.2 (or even Lua 5.1) entirely compatible with Lua 5.3, but it brings the API closer to that of Lua 5.3." That project maintains a good list of what's not implemented: https://github.com/keplerproject/lua-compat-5.3#whats-not-implemented > Are there more packages in the tree that are locked to a specific version= of lua? Yes, several, and more on that in a second. I think packages will need one of two variables: LUA_SINGLE_TARGET LUA_TARGETS LUA_TARGETS is probably only going to be used by the dev-lua/ modules. LUA_SINGLE_TARGET is probably going to be used by MOST packages that include Lua as an embedded scripting language; of which I'll discuss a few below. The pain in Lua thusfar I see comes when one of the packages with embedded Lua scripting needs to consume a system-wide Lua module. Some Lua modules provide special-case handling for luajit, to ensure best performance. I personally work on net-proxy/haproxy, which supports ONLY Lua 5.3. It relies on some functionality that cannot be back-ported to earlier releases (heavy usage of coroutine/yield & uint64) I'm also about to add back sys-apps/likwid to the tree, for which the upstream bundles Lua 5.3, but the code explicitly is written to support a system-wide copy of Lua 5.2 or Lua 5.3. The ebuild now uses the system-wide copy of Lua 5.3. likwid ships as both a set of Lua scripts that bring in a special C library, as well as Lua scripting placed back into that C library. x11-wm/awesome is a good example of a package with support for multiple versions of Lua. For a long time upstream only supported Lua 5.1, but in the recent major versions of Awesome, the upstream dev has Lua 5.2 & Lua 5.3 support with a test environment. I'm running on my own local ebuild with Awesome linked against Lua 5.3 as I write this. dev-db/redis is a good example of where Upstream tried to port from 5.1 to newer versions, but did an incomplete job: - Try to compile it with Lua5.3 and it falls over numeric types. - Try to compile it with Lua5.2 and it falls over the lua_open/lua_newstate. --=20 Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robbat2@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 --1Ow488MNN9B9o/ov Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Robbat2 @ Orbis-Terrarum Networks - The text below is a digital signature. If it doesn't make any sense to you, ignore it. iQKSBAABCgB9FiEEveu2pS8Vb98xaNkRGTlfI8WIJsQFAlyYV6pfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEJE RUJCNkE1MkYxNTZGREYzMTY4RDkxMTE5Mzk1RjIzQzU4ODI2QzQACgkQGTlfI8WI JsRRTw/0D5hwWIR3IuAYQ3Iz+ZuRHiIEeTtybGjVyK/nsjF6pgr0y7cVr33yuPha l9wNvYgMeu9zAURrubPXHGzpSq/9EkOrZRf0fV4owE3HnZICZ0nELtFUCC/pPqpO n0WeNmGLHkE51dyGQWkBGsFqwCZOFBlVv6dxrVA7KHnhkcBMlArEcUL44W5a2wLd WrcQxUBn/3d0H04jMEpglxzfLjsMwU/Zz/QyIvs19INupHK1KLyLHawrEuywzcBm 9S0xZlkqubt/xlqYlPXBDXqGrx9bYLpkKy2GRqdMWSQlVR6sypCIMHeCV/W9t6TH WG/U4l03eE6ABUdiYg0uflZH6Ztoe8r6EMwk7FolQzPhNaktMU4OWhk4VA6Wr6LH 8LnIkZBZSV70ZvKGLDyxPipRv+sBNi7ajnot+goOQS2KJG+4yWtXAz/EKoz797LO rrHnb954UW0BAwMAsQnuMZPt5gibKDXWFPnnQPB0L08Og1vfHJ+kszjjjAvraObN y0998iwMj8GQO2G/+ghQVvWXkGhtEZ0wksJsTiKKA8DCgHjqB5gdYfu7tANRKZbm TY1+O290BIxiTBkUqZlsNQthFqJYA+0R3lJHL+xh4ETlZN35363XxcDnT3+ds7RV lqCOnOAOvkmQAYOLYCeihTSYiOxFy2wFQEW1ZHy7oFK1UqysmQ== =jFc4 -----END PGP SIGNATURE----- --1Ow488MNN9B9o/ov--