The test case I've been using was posted to lua-l in Feb by Sascha Zelzer, but the archives aren't public so I can't just link to it.

Of course I have no objections (moving the license text from LICENSE into the source files is completely compatible with both the intent and the stated terms of the license).

I'm happy to pick up the flavors work again if there's any likelihood of it actually going anywhere.

While we're in here changing stuff, is it also worth adding a patch for the upvaluejoin bug? The bug in itself is a non-issue, but some prat filed a CVE for it.

I think in the short term there's no point in adding an option, and instead we should just append -lpthread to LIBS, since we ignore LIBS when building the .so anyway.

Russ, did you check whether that test actually failed without the patch? Because it works fine for me without changing a thing.

Update to 3.0.1.

So, once again, are we done here? I have nothing more to add.

I'm told there's a 3.0.1 release likely within a week or so that fixes both the bug and the build process issues discussed here.

Remove an unnecessary conditional as pointed out by mat.

Track changes requested by mat for the 5.3 port.

Include mat's latest requested changes.

Flavors stuff is up at D16494

In D14709#349874, @russ.haley_gmail.com wrote:

Hi @dbn, Lua 5.4 is still in a beta phase so my preference is to hold this port until the Lua 5.4 official release, then update and push it to the repository. @andrew_tao173.riddles.org.uk has already indicated his preference to hold the port until the Lua release (unless something has changed?)

So are we done here? I have nothing more to add.

So are we done here? I have nothing more to add.

Style/format fixes

• Rebase against current existing port rather than previous version.
  • Add USES+=gmake
  • Add Makefile patches to respect $(DESTDIR) so that make stage works.
  • Fix an upstream bug.
  • Regenerate pkg-plist to match new version's files.

No, seems there's lots more wrong with this - at least the install is broken (looks like it's not respecting the staging dir)

Looks like a missing USES+=gmake

Doesn't build for me. Trying to figure out why.

Changes in line with 5.3.5 patch:

• change DOCSDIR to lua53/lua so that lua53/${PORTNAME} could be used for lua module ports
  • reorganize DOCS install so that check-plist doesn't complain

Sync with 5.3.5 work.

New version to fix the libedit issue.

Use DISTVERSION. This corrects the package version too (now 5.4.0.w2)

Change OPTIONS_DEFAULT+= to just = in accordance with nitpicking on the 5.3.5 patch.

Remove use of ${PORTNAME} in line with discussions over on the 5.3.5 patch.

mat: like this?

This is now a diff against the result of 'svn cp lua53 lua54' as requested by mat.

Added ASSERT and APICHECK options.

In D14709#345221, @russ.haley_gmail.com wrote:

I may be mistaken, but the experimental (not expeditionary!) run only build packages so I'm hoping we can get the build output and see what needs upgrading. I see now that I can request an experimantal run on Bugzilla so I'll submit one today.

In D14709#345216, @russ.haley_gmail.com wrote:

In D14709#345215, @andrew_tao173.riddles.org.uk wrote:

Note that work2 is not ready for prime time yet (garbage collector bugs, at least)

I didn't see anything on the mailing list that would preclude adding it to the ports collection, or at the very least performing an expeditionary run (if that's possible). @mat, @dbn, I'm keen to get 5.3.5 or preferably 5.4 "build tested" against other packages because I've got a week off work right now with no kids.

Note that work2 is not ready for prime time yet (garbage collector bugs, at least)

Fix silly mistake in previous diff

In D13690#345170, @russ.haley_gmail.com wrote:

In D13690#345167, @andrew_tao173.riddles.org.uk wrote:

Probably not worth adding options just for readline, but what about installing the HTML docs? I think that would be a good option (or indeed a default).

I think it would be an excellent default.

New diff with my suggested version for the work2 release.

In D13690#345147, @russ.haley_gmail.com wrote:

@andrew_tao173.riddles.org.uk, I am very grateful for your tutelage and contributions. Do you want to see the readline options from D14709 left in? I had two thoughts: 1) anyone who doesn't want readline support is probably building Lua themselves and 2) with the freebsd target working, we could create an option for the generic target, that does not include readline.

I personally don't feel the extra complexity of the options adds value since the source Makefile is patched to use editline.

The so isn't working because there is nothing here to build it; the makefile distributed with Lua does not try to build one and never did, the ports for earlier Lua versions patch the makefile to add it.