Re: lua ports: versions/flavors handling
Jeremie Courreges-Anglas writes: > j...@wxcvbn.org (Jeremie Courreges-Anglas) writes: > >> Some time ago I took a look at hooking lua53 flavors in the ports that >> support it. It turned out that some ports were already broken with >> particular versions of lua (the most common errors are missing functions >> at dlopen time, and module() errors), yet they were hooked up. >> >> So it's not just about adding lua53 flavors, but about having >> a consistent ports tree. In the end, I think that lua.port.mk should >> stop populating FLAVORS automatically, so that people hacking on lua >> have to explicitely enable the lua versions they tested. Just like for >> python.port.mk. >> >> The diff to explicitely add FLAVORS / hook them up is not ripe yet, >> but first I'd like to know if people object to the proposal above. > > afaik we can stop automatically adding FLAVORS in lua.port.mk; it would > be nice if someone could put this in a bulk to confirm. Committed, thanks Antoine for the bulk build test. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: lua ports: versions/flavors handling
j...@wxcvbn.org (Jeremie Courreges-Anglas) writes: > Some time ago I took a look at hooking lua53 flavors in the ports that > support it. It turned out that some ports were already broken with > particular versions of lua (the most common errors are missing functions > at dlopen time, and module() errors), yet they were hooked up. > > So it's not just about adding lua53 flavors, but about having > a consistent ports tree. In the end, I think that lua.port.mk should > stop populating FLAVORS automatically, so that people hacking on lua > have to explicitely enable the lua versions they tested. Just like for > python.port.mk. > > The diff to explicitely add FLAVORS / hook them up is not ripe yet, > but first I'd like to know if people object to the proposal above. afaik we can stop automatically adding FLAVORS in lua.port.mk; it would be nice if someone could put this in a bulk to confirm. Index: lua.port.mk === RCS file: /d/cvs/ports/lang/lua/lua.port.mk,v retrieving revision 1.34 diff -u -p -p -u -r1.34 lua.port.mk --- lua.port.mk 7 Jun 2016 11:51:52 - 1.34 +++ lua.port.mk 17 Oct 2016 13:34:49 - @@ -10,18 +10,6 @@ CATEGORIES +=lang/lua # Define the default version and use that if MODLUA_VERSION is not set. MODLUA_DEFAULT_VERSION = 5.1 -# If a port already has flavors, append our lua flavors to it, unless it -# requests specific versions of lua. Otherwise set the FLAVORS list to -# just the lua flavors. -_MODLUA_FLAVORS = lua52 lua53 -.if !defined(MODLUA_VERSION) -. if !defined(FLAVORS) -FLAVORS ?= ${_MODLUA_FLAVORS} -. elif !${FLAVORS:M${_MODLUA_FLAVORS}} -FLAVORS += ${_MODLUA_FLAVORS} -. endif -.endif - FLAVOR ?= # empty # without a flavor, assume ${MODLUA_DEFAULT_VERSION} -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: lualdoc & awesome (was: Re: lua ports: versions/flavors handling)
On Mon, Oct 17, 2016 at 7:51 PM, Jeremie Courreges-Anglas wrote: > > The switch to explicit FLAVORS is almost complete, there are two > remaining ports, luaposix and lualdoc. > > lualdoc is packaged as a library that supports flavors, but afaik it is > a standalone tool. Debian for example packages it as "lua-ldoc", not > "lua5.1-ldoc". > > Here's a diff to switch it to a standalone tool. Since x11/awesome is > its only consumer, I used MODLUA_VERSION = 5.2 so that people that build > from source don't need to install two lua versions (well, that's > cheap...). > > I added a @pkgpath so that people who have lua52ldoc installed can > transparently upgrade, but should I also add bin/lua51 and bin/lua52 > symlinks? I'd prefer not... > > Bonus: x11/awesome/patches loses weight. > > Thoughts? Reads ok to me, but why have you removed doxygen too?
lualdoc & awesome (was: Re: lua ports: versions/flavors handling)
The switch to explicit FLAVORS is almost complete, there are two remaining ports, luaposix and lualdoc. lualdoc is packaged as a library that supports flavors, but afaik it is a standalone tool. Debian for example packages it as "lua-ldoc", not "lua5.1-ldoc". Here's a diff to switch it to a standalone tool. Since x11/awesome is its only consumer, I used MODLUA_VERSION = 5.2 so that people that build from source don't need to install two lua versions (well, that's cheap...). I added a @pkgpath so that people who have lua52ldoc installed can transparently upgrade, but should I also add bin/lua51 and bin/lua52 symlinks? I'd prefer not... Bonus: x11/awesome/patches loses weight. Thoughts? Index: devel/Makefile === RCS file: /d/cvs/ports/devel/Makefile,v retrieving revision 1.1551 diff -u -p -r1.1551 Makefile --- devel/Makefile 16 Oct 2016 23:52:31 - 1.1551 +++ devel/Makefile 17 Oct 2016 17:25:36 - @@ -434,7 +434,6 @@ SUBDIR += luafs,lua52 SUBDIR += luafs,lua53 SUBDIR += lualdoc - SUBDIR += lualdoc,lua52 SUBDIR += luapack SUBDIR += luapack,lua52 SUBDIR += luaposix Index: devel/lualdoc/Makefile === RCS file: /d/cvs/ports/devel/lualdoc/Makefile,v retrieving revision 1.16 diff -u -p -r1.16 Makefile --- devel/lualdoc/Makefile 26 Aug 2016 07:51:49 - 1.16 +++ devel/lualdoc/Makefile 17 Oct 2016 17:29:17 - @@ -7,6 +7,7 @@ GH_PROJECT =LDoc GH_TAGNAME = 1.4.5 PKGNAME = lualdoc-${GH_TAGNAME} CATEGORIES = devel +REVISION = 0 HOMEPAGE = http://stevedonovan.github.io/ldoc/ @@ -18,9 +19,10 @@ PERMIT_PACKAGE_CDROM =Yes MODULES = lang/lua MODLUA_RUN_DEPENDS = devel/lua-penlight +MODLUA_SA =Yes +MODLUA_VERSION = 5.2 NO_BUILD = Yes - NO_TEST = Yes do-install: @@ -35,7 +37,6 @@ do-install: ${MODLUA_DATADIR}/ldoc/html/ ${INSTALL_DATA} ${WRKSRC}/doc/*.md ${MODLUA_DOCDIR} ${INSTALL_DATA} ${WRKSRC}/readme.md ${MODLUA_DOCDIR} - ${SUBST_PROGRAM} \ - ${WRKSRC}/ldoc.lua ${PREFIX}/bin/ldoc${MODLUA_DEP_VERSION} + ${SUBST_PROGRAM} ${WRKSRC}/ldoc.lua ${PREFIX}/bin/ldoc .include Index: devel/lualdoc/pkg/PLIST === RCS file: /d/cvs/ports/devel/lualdoc/pkg/PLIST,v retrieving revision 1.4 diff -u -p -r1.4 PLIST --- devel/lualdoc/pkg/PLIST 26 Aug 2016 07:51:49 - 1.4 +++ devel/lualdoc/pkg/PLIST 17 Oct 2016 17:23:15 - @@ -1,5 +1,6 @@ @comment $OpenBSD: PLIST,v 1.4 2016/08/26 07:51:49 dcoppa Exp $ -bin/ldoc${MODLUA_DEP_VERSION} +@pkgpath devel/lualdoc,lua52 +bin/ldoc share/doc/${FULLPKGNAME}/ share/doc/${FULLPKGNAME}/doc.md share/doc/${FULLPKGNAME}/readme.md Index: x11/awesome/Makefile === RCS file: /d/cvs/ports/x11/awesome/Makefile,v retrieving revision 1.102 diff -u -p -r1.102 Makefile --- x11/awesome/Makefile22 Aug 2016 13:45:09 - 1.102 +++ x11/awesome/Makefile17 Oct 2016 14:18:37 - @@ -38,13 +38,12 @@ LIB_DEPENDS=devel/libexecinfo \ x11/dbus \ x11/libxdg-basedir -MODLUA_BUILD_DEPENDS= devel/lua-lgi \ - devel/lualdoc +MODLUA_BUILD_DEPENDS= devel/lua-lgi -BUILD_DEPENDS= textproc/asciidoc>=8.4.5 \ +BUILD_DEPENDS= devel/lualdoc \ + textproc/asciidoc>=8.4.5 \ textproc/xmlto \ - graphics/ImageMagick \ - devel/doxygen + graphics/ImageMagick MODLUA_RUN_DEPENDS=devel/lua-lgi Index: x11/awesome/patches/patch-awesomeConfig_cmake === RCS file: /d/cvs/ports/x11/awesome/patches/patch-awesomeConfig_cmake,v retrieving revision 1.18 diff -u -p -r1.18 patch-awesomeConfig_cmake --- x11/awesome/patches/patch-awesomeConfig_cmake 22 Aug 2016 13:45:09 - 1.18 +++ x11/awesome/patches/patch-awesomeConfig_cmake 17 Oct 2016 17:27:57 - @@ -1,6 +1,6 @@ $OpenBSD: patch-awesomeConfig_cmake,v 1.18 2016/08/22 13:45:09 dcoppa Exp $ --- awesomeConfig.cmake.orig Sun Mar 6 15:05:54 2016 -+++ awesomeConfig.cmakeMon Aug 22 15:33:26 2016 awesomeConfig.cmakeMon Oct 17 19:27:40 2016 @@ -16,12 +16,11 @@ option(COMPRESS_MANPAGES "compress manpages" ON) option(GENERATE_DOC "generate API documentation" ON) @@ -19,7 +19,7 @@ $OpenBSD: patch-awesomeConfig_cmake,v 1. # }}} # {{{ Endianness -@@ -43,29 +42,21 @@ macro(a_find_program var prg req) +@@ -43,11 +42,7 @@ macro(a_find_program var prg req) endif() endmacro() @@ -31,17 +31,7 @@ $OpenBSD: patch-awesomeConfig_cmake,v 1. # programs needed for man pages a_fin
Re: lua ports: versions/flavors handling
On Wed, Oct 12, 2016 at 05:42:00PM +0200, Jeremie Courreges-Anglas wrote: > > Some time ago I took a look at hooking lua53 flavors in the ports that > support it. It turned out that some ports were already broken with > particular versions of lua (the most common errors are missing functions > at dlopen time, and module() errors), yet they were hooked up. > There are basically two use cases for Lua. One you have an app that extends itself for scripting and usually specify one Lua version to run at. Like HexChat that recommends lua52 or newer for their scripts. And then you have the libraries. Those *should* support all Lua versions but often neglect have them fail at the newer ones. If the library is decent enough though, then there's usually a newer version somewhere that fixes that issue, or the issues are trivially fixed. The Lua maintainers provide very easy pointers on how to support all major Lua versions. > So it's not just about adding lua53 flavors, but about having > a consistent ports tree. In the end, I think that lua.port.mk should > stop populating FLAVORS automatically, so that people hacking on lua > have to explicitly enable the lua versions they tested. Just like for > python.port.mk. > It would certainly be the easiest solutions yes. And I am sure that there are projects which are beyond hope. But I'd rather invest the work and get the good ones to support all flavours, and cleanse the rest. > The diff to explicitly add FLAVORS / hook them up is not ripe yet, > but first I'd like to know if people object to the proposal above. Those are my €0.02 Regards, Florian
lua ports: versions/flavors handling
Some time ago I took a look at hooking lua53 flavors in the ports that support it. It turned out that some ports were already broken with particular versions of lua (the most common errors are missing functions at dlopen time, and module() errors), yet they were hooked up. So it's not just about adding lua53 flavors, but about having a consistent ports tree. In the end, I think that lua.port.mk should stop populating FLAVORS automatically, so that people hacking on lua have to explicitely enable the lua versions they tested. Just like for python.port.mk. The diff to explicitely add FLAVORS / hook them up is not ripe yet, but first I'd like to know if people object to the proposal above. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE