Paths

Table of Contentst

9/58
Makefile
9/58
distinfo
-
files/
9/58
extra-patch-assert
9/58
lua-5.3.pc.in
9/58
lua-5.4.pc.in
-
patch-src_Makefile
-
patch-src__Makefile
-
patch-src__ldebug.c
-
patch-src__lgc.c
-
patch-src__liolib.c
-
patch-src__lparser.c
-
pkg-plist

[new port] lang/lua54 - new port for Lua 5.4.0
ClosedPublic
Actions

Authored by russ.haley_gmail.com on Mar 16 2018, 6:28 AM.

Details

Reviewers

mat
dbn
andrew_tao173.riddles.org.uk

Group Reviewers

portmgr
O5: Ports Framework	(Owns No Changed Paths)

Commits

rP552438: [NEW PORT] lang/lua54 - Lua 5.4.1

Summary

Hi,

This is a port for Lua 5.4.0

The Lua Manual can be found here:
https://www.lua.org/manual/5.4/

Andrew Gierth has added editline and documentation options to the port.

Built and lightly tested on Ghost BSD 20 (FreeBSD 12.1 STABLE).

Diff Detail

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

mat added inline comments.Jul 16 2018, 7:37 AM

Makefile
10	Remove.

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

Also includes mat's other requested changes.

Could you use devel/arcanist, or at least generate a diff with full context like it does, with svn diff -x -U9999 or git diff -U9999.

mat: like this?

andrew_tao173.riddles.org.uk added a reviewer: andrew_tao173.riddles.org.uk.Jul 16 2018, 2:40 PM

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

andrew_tao173.riddles.org.uk retitled this revision from Lua 5.4.0 to lang/lua54 - new port for Lua 5.4.0.Jul 18 2018, 2:21 PM

andrew_tao173.riddles.org.uk set the repository for this revision to rP FreeBSD ports repository.

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

mat added inline comments.Jul 18 2018, 3:25 PM

Makefile
4–5	This should probably be: DISTVERSION= 5.4.0-work2

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

Sync with 5.3.5 work.

This adds the dynamic-libedit patch (which is an extra patch here, rather than unconditionally patching lua.c as in 5.3.5, because unlike 5.3.5 we don't otherwise have any need to patch that file). Other changes are just cosmetic.

Changes in line with 5.3.5 patch:

move DOCSDIR to lua54/lua to free up lua54/${PORTNAME} for module ports
change doc install to avoid complaints from check-plist

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

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

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

I'm happy with it.

I cannot comment on the specifics of lua (i.e. do these changes work), I've never used lua and haven't tested it. However, I am happy with the above changes with the following comments:

I assume the indentation is correct, despite it not rendering correctly in Chrome
Please try to upstream all patches

@jbeich: your thoughts?

And, who will commit this change?

In D14709#349808, @dbn wrote:

I cannot comment on the specifics of lua (i.e. do these changes work), I've never used lua and haven't tested it. However, I am happy with the above changes with the following comments:

I assume the indentation is correct, despite it not rendering correctly in Chrome

Please try to upstream all patches

@jbeich: your thoughts?

And, who will commit this change?

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?)

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?)

I didn't say to hold it until release, I said -work2 was "not ready for prime time" or some such. But in the absence of any statement from the Lua devs about the likely timing of a -work3 or a final 5.4.0, I see these options:

make the port available anyway as is (it doesn't seem unusual to have ports for non-final releases of languages, see e.g. tcl87)
add a patch to stop it enabling the generational GC by default in lua.c (generational GC has known crash/corruption bugs in -work2) and make it available
combine options 1 and 2 by making the patch an option
sit on it until there's a (hopefully more stable) -work3 or final release, but we have no idea of the timeline for this

I'm not all that keen on option 1, but any of options 1-3 might be useful from a Lua development point of view.

Another factor to consider is updating Uses/lua.mk (which doesn't recognize 5.4 yet). I have been testing the idea of giving USES=lua a flavors option for lua modules to use and it seems to work well - I could put that work up as a separate revision for review?

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

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?)

I didn't say to hold it until release, I said -work2 was "not ready for prime time" or some such. But in the absence of any statement from the Lua devs about the likely timing of a -work3 or a final 5.4.0, I see these options:

make the port available anyway as is (it doesn't seem unusual to have ports for non-final releases of languages, see e.g. tcl87)

add a patch to stop it enabling the generational GC by default in lua.c (generational GC has known crash/corruption bugs in -work2) and make it available

combine options 1 and 2 by making the patch an option

sit on it until there's a (hopefully more stable) -work3 or final release, but we have no idea of the timeline for this

I'm not all that keen on option 1, but any of options 1-3 might be useful from a Lua development point of view.

Another factor to consider is updating Uses/lua.mk (which doesn't recognize 5.4 yet). I have been testing the idea of giving USES=lua a flavors option for lua modules to use and it seems to work well - I could put that work up as a separate revision for review?

I had started a review for updating Uses/lua.mk last year (https://reviews.freebsd.org/D13691 - feel free to re-use this or start a new one). This review is when I was informed about the previous exp-run and why Lua was still at 5.2. My plan had been to follow the Lua releases and try to get everything updated to 5.3, but I have nothing against your suggestions. Option 2 would be my preference; it seems like the best "bang for the buck".

I'm keen to see your flavors work!

Flavors stuff is up at D16494

Track changes requested by mat for the 5.3 port.

Now that a 5.4.0-beta release has been made, and there are signs that features are actually stabilizing (there have been many changes since work2), perhaps we could pick this up again. The distinfo needs an update of course.

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

Now that a 5.4.0-beta release has been made, and there are signs that features are actually stabilizing (there have been many changes since work2), perhaps we could pick this up again. The distinfo needs an update of course.

Yes, I'll start on that now. Thanks for the ping.

Updated for the latest Lua 5.4 Beta release.

When the ASSERT option is selected, the extra-patch-assert file fails to apply cleanly. I tried to port it over but I there has been a change to lgc.c and I don't know enough about lgc to apply the patch (Help Andrew?).
I tested all the other options and they all compiled.
I installed Lua54 beta in the default configuration without issue.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199480

Is this patch for arc4random something that we should look at applying?

hmmmm?

> Installing for lua54-5.4.0.b_1

> Checking if lua54 is already installed

> Registering installation for lua54-5.4.0.b_1

pkg-static: duplicate file listing: /usr/local/share/doc/lua54/lua/contents.html, ignoring
pkg-static: duplicate file listing: /usr/local/share/doc/lua54/lua/index.css, ignoring
pkg-static: duplicate file listing: /usr/local/share/doc/lua54/lua/logo.gif, ignoring
pkg-static: duplicate file listing: /usr/local/share/doc/lua54/lua/lua.css, ignoring
pkg-static: duplicate file listing: /usr/local/share/doc/lua54/lua/manual.css, ignoring
pkg-static: duplicate file listing: /usr/local/share/doc/lua54/lua/manual.html, ignoring
pkg-static: duplicate file listing: /usr/local/share/doc/lua54/lua/osi-certified-72x60.png, ignoring
pkg-static: duplicate file listing: /usr/local/share/doc/lua54/lua/readme.html, ignoring
Installing lua54-5.4.0.b_1...

When the ASSERT option is selected, the extra-patch-assert file fails to apply cleanly. I tried to port it over but I there has been a change to lgc.c and I don't know enough about lgc to apply the patch (Help Andrew?).

The assert patch no longer needs to touch lgc.c, since that was fixing a bug with a misplaced assert that is now fixed upstream. Only the change to lprefix.h is needed now.

You seem to have duplicated a patch? There should be no patch for lua.c other than the extra-patch-libedit-dl one.

andrew_tao173.riddles.org.uk added inline comments.Oct 17 2019, 8:55 PM

lua54/pkg-plist
13 ↗	(On Diff #63394)	These %%PORTDOCS%% lines should not be here, PORTDOCS in the makefile automatically handles adding them to the plist. I think this explains your duplication warnings.

New patch to address comments, thank you Andrew.

Update: retested the default LIBEDIT_DL configuration and I don't get command line history

russellh@gbsd2 ~/f/p/l/l/w/l/src> ./lua54
Lua 5.4.0  Copyright (C) 1994-2019 Lua.org, PUC-Rio
> print('test')
test
> ^[[A^C⏎

but it works fine with libreadline:

russellh@gbsd2 ~/f/p/l/l/w/l/src> ./lua54
Lua 5.4.0  Copyright (C) 1994-2019 Lua.org, PUC-Rio
> print('test')
test
> print('test')
test

Build output for LIBEDIT_DL is here: https://pastebin.com/UTVrdZVX

Addressed andrews comments. Fixed missing patch for LIBEDIT_DL and tested LIBEDIT_DL option. twice. :-/

Added option for arc4random random seed. I tested running math.random and it looked randomish to me? I don't know what I'm looking for but the flags were present in the build output:

...
--- liolib.o ---
cc  -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_POSIX -DLUA_USE_DLOPEN -DLUA_USE_READLINE_DL -isystem /usr/local/include -O2 -pipe  -fPIC -D__BSD_VISIBLE -DLUA_USER_H='<stdlib.h>' -D'lua_makeseed()=cast(unsigned int, arc4random())' -fstack-protector-strong -isystem /usr/local/include  -c liolib.c -o liolib.o
--- lmathlib.o ---
cc  -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_POSIX -DLUA_USE_DLOPEN -DLUA_USE_READLINE_DL -isystem /usr/local/include -O2 -pipe  -fPIC -D__BSD_VISIBLE -DLUA_USER_H='<stdlib.h>' -D'lua_makeseed()=cast(unsigned int, arc4random())' -fstack-protector-strong -isystem /usr/local/include  -c lmathlib.c -o lmathlib.o
...

russ.haley_gmail.com mentioned this in D17814: devel/lua-luarocks: update to 3.2.1.Oct 19 2019, 5:27 AM

Looks like Roberto snuck some hardcoded -Os options into the makefile, we need to either patch those back out or think of something else to do with them.

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

Looks like Roberto snuck some hardcoded -Os options into the makefile, we need to either patch those back out or think of something else to do with them.

You should ask about that on the mailing list. -O2 is specified twice, as well as -Os. Which option does the compiler take?

cc -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_POSIX -DLUA_USE_DLOPEN -DLUA_USE_READLINE_DL -isystem /usr/local/include -O2 -pipe -fPIC -D__BSD_VISIBLE -DLUA_USER_H='<stdlib.h>' -D'lua_makeseed()=cast(unsigned int, arc4random())' -fstack-protector-strong -isystem /usr/local/include -Os -c lcode.c

Complete build output here: https://pastebin.com/pB2N7D3w

Patch out targets that added -Os to llex.o, lparser.o, and lcode.o.

Build output here https://pastebin.com/2tLGT9RA

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

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

Looks like Roberto snuck some hardcoded -Os options into the makefile, we need to either patch those back out or think of something else to do with them.

You should ask about that on the mailing list. -O2 is specified twice, as well as -Os. Which option does the compiler take?

Generally the last one.

cc -O2 -Wall -Wextra -DLUA_COMPAT_5_3 -DLUA_USE_POSIX -DLUA_USE_DLOPEN -DLUA_USE_READLINE_DL -isystem /usr/local/include -O2 -pipe -fPIC -D__BSD_VISIBLE -DLUA_USER_H='<stdlib.h>' -D'lua_makeseed()=cast(unsigned int, arc4random())' -fstack-protector-strong -isystem /usr/local/include -Os -c lcode.c

That first -O2 needs to be patched out as well - wasn't there something for that in files/patch-src_Makefile before?

Patch out CFLAGS optimization in third party makefile as per handbook:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-cflags.html

russ.haley_gmail.com added inline comments.Nov 5 2019, 5:36 AM

../lua54/Makefile
116 ↗	(On Diff #63951)	Did the base FreeBSD bug that caused us to require this ever get fixed? I tried following the bug report but lost track of it.

Update to lua 5.4.0-rc1

Update to match recent changes to Lua framework; connect to the build; add the new version to the list of supported versions in default-versions and Uses/lua.mk.

Allowing 5.4 in Uses/lua.mk does have the potential to break builds of ports that specify, e.g., USES=lua:53+ (so that the default version of 5.2 is not in range) and where they use interfaces that change from 5.3 to 5.4. I'm not sure how many cases of this there are (if any); I will do my own test run soon, but an exp-run will likely be needed at some point.

Now that there's an actual release candidate, we can think about pushing this forward.

Herald added a reviewer: portmgr. · View Herald TranscriptApr 15 2020, 6:32 PM

Test results: adding support for 5.4 causes only two ports (archivers/urbackup-server and x11-toolkits/termit) to switch from lua 5.3 to 5.4 when LUA_DEFAULT is 5.2. (They would not switch if the default were 5.3; both are declared as lua:53+, and the default version is chosen if it is in range, otherwise the latest available version in the range.)

Both of them fail to build as a result.

For archivers/urbackup-server, it's because it has a configure script that looks only for lua53 and older versions.

For x11-toolkits/termit it's because it uses cmake to build, and cmake has no idea that lua54 exists so it also has a hardcoded check for lua53 and older.

In both cases, adding appropriate CONFIGURE_ENV or CMAKE_ARGS *might* fix the issue; I'll have a poke at them.

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

Update to lua 5.4.0-rc1

Update to match recent changes to Lua framework; connect to the build; add the new version to the list of supported versions in default-versions and Uses/lua.mk.

Allowing 5.4 in Uses/lua.mk does have the potential to break builds of ports that specify, e.g., USES=lua:53+ (so that the default version of 5.2 is not in range) and where they use interfaces that change from 5.3 to 5.4. I'm not sure how many cases of this there are (if any); I will do my own test run soon, but an exp-run will likely be needed at some point.

Now that there's an actual release candidate, we can think about pushing this forward.

I'm not sure what I'm doing wrong but I get the lua54 port files in my ports root directory if I apply this patch.

russellh@gbsd2 ~/f/ports> patch <  ~/freebsd/patches/D14709.diff

Should work with patch -p1

Change the two ports that declared themselves lua:53+ to just lua:53, since they don't seem to respond sanely to attempts to force configuration with 5.4 using environment vars.

(In my documentation patch for the porter's manual, I've added a note about why this style of version specification should be avoided. See https://reviews.freebsd.org/D24430 for details.)

In my opinion, it's a bug in Mk/Uses/lua.mk that USES=lua:53+ chooses lua 5.4 over 5.3

In D14709#538585, @antoine wrote:

In my opinion, it's a bug in Mk/Uses/lua.mk that USES=lua:53+ chooses lua 5.4 over 5.3

What alternative logic do you suggest?

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

In D14709#538585, @antoine wrote:

In my opinion, it's a bug in Mk/Uses/lua.mk that USES=lua:53+ chooses lua 5.4 over 5.3

What alternative logic do you suggest?

Maybe chose the closest from default version that fits the constraints

In D14709#538596, @antoine wrote:

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

In D14709#538585, @antoine wrote:

In my opinion, it's a bug in Mk/Uses/lua.mk that USES=lua:53+ chooses lua 5.4 over 5.3

What alternative logic do you suggest?

Maybe chose the closest from default version that fits the constraints

In other words, choose the lowest version in the range if the default version is below the start of the range, or the highest version if it is above the end?

Should the rule be the same for 53+ as for, say, 53-54 ?

(I should note, I did not change the version selection logic much in my patch for lua.mk; the old lua.mk would choose the highest version in these kinds of cases too.)

I'm honestly not sure that there's a rule that works well for all kinds of ports. The only (unflavored) ports for which lua:53+ really make sense would be ones that are actually written in Lua, rather than embedding Lua into C code (or whatever other language), because the Lua API has breaking changes between every version (while the 5.3 to 5.4 changes are relatively small, there's no guarantee at all about future versions).

The major benefit I can see from your suggested rule is that it would ensure that advancing LUA_DEFAULT would not cause any port to suddenly switch to an older version of Lua, whereas with the current logic, a 53+ port will build with 5.4 once that is added, but revert to 5.3 if LUA_DEFAULT was changed from the current value of 5.2 to 5.3.

The downside would seem to be that ports that really can benefit from a newer Lua version would be stuck on an older one.

In the specific case of the two ports referenced here, I think it's clearly a bug in the ports that they specify 53+ when they cannot actually build with anything other than exactly 5.3.

Others have supported the "closest to default" rule, so I'll put up a separate patch for that.

andrew_tao173.riddles.org.uk mentioned this in D24430: Update porters handbook for Lua changes.Apr 18 2020, 8:54 PM

andrew_tao173.riddles.org.uk mentioned this in D24492: Change version selection logic in Mk/Uses/lua.mk.Apr 18 2020, 11:47 PM

Updated to use the official release Lua 5.4.0

russ.haley_gmail.com mentioned this in D25784: Add `flavors` support to devel/lua-luarocks.Jul 23 2020, 6:48 AM

Please make sure that when committed, this is done by first copying lang/lua53 to lang/lua54.

lang/lua54/Makefile
95–122 ↗	(On Diff #74830)	All this needs to happen before the options block, see https://www.freebsd.org/doc/en/books/porters-handbook/porting-order.html.

kevans mentioned this in rP543000: Update version selection logic for USES= lua.Jul 24 2020, 4:39 AM

Removed non-relevant ports packages included by mistake
Copied current Lua53 makefile and adjusted for Lua54.
Moved OPTIONS variable block below build variables (will submit a correction to lua53 as well)

russ.haley_gmail.com marked an inline comment as done.Jul 24 2020, 9:37 PM

russ.haley_gmail.com retitled this revision from lang/lua54 - new port for Lua 5.4.0 to [new port] lang/lua54 - new port for Lua 5.4.0.Jul 24 2020, 9:40 PM

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

Removed non-relevant ports packages included by mistake

They were not included by mistake; they were the ports which would otherwise have broken by adding lua54 as per previous discussion.

However, the change to version selection logic from D24492 does hopefully obviate that issue, since now adding lua54 won't change the lua version used by any existing port.

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

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

Removed non-relevant ports packages included by mistake

They were not included by mistake; they were the ports which would otherwise have broken by adding lua54 as per previous discussion.

However, the change to version selection logic from D24492 does hopefully obviate that issue, since now adding lua54 won't change the lua version used by any existing port.

Ah, I thought I had mucked something. Shall I restore them?

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

Ah, I thought I had mucked something. Shall I restore them?

Nope. Their maintainers can deal with them in due course.

Accepting as portmgr for the Mk bits.

Update to 5.4.1

Better handling of ASSERT option (no need for a patch file)

Reorder things to pacify portclippy

kevans mentioned this in rP552431: lang/lua53: update to 5.3.6.Oct 15 2020, 5:28 PM

This revision was not accepted when it landed; it landed in state Needs Review.Oct 15 2020, 5:55 PM

Closed by commit rP552438: [NEW PORT] lang/lua54 - Lua 5.4.1 (authored by kevans). · Explain Why

This revision was automatically updated to reflect the committed changes.

kevans added a commit: rP552438: [NEW PORT] lang/lua54 - Lua 5.4.1.

Owners added a reviewer: O5: Ports Framework.Oct 15 2020, 5:55 PM

Revision Contents
Changeset List

Path

Size


	lua54/

Makefile

159 lines

distinfo

6 lines

files/

	lua-5.4.pc.in
	lua-5.3.pc.in

2 lines

	patch-src_Makefile
	patch-src__Makefile

30 lines

pkg-plist

28 lines

files/

extra-patch-assert

11 lines

lua-5.3.pc.in

patch-src__Makefile

lua54/

files/

Diff 45464

View Options

Makefile

	# Created by: GreenDog <fiziologus@gmail.com>			# Created by: GreenDog <fiziologus@gmail.com>
	# $FreeBSD$			# $FreeBSD$
				matUnsubmitted Done Inline Actions The credit will alreay be present in the commit message, please do not add more in the Makefile. mat: The credit will alreay be present in the commit message, please do not add more in the Makefile.
				matUnsubmitted Not Done Inline Actions Please, DO NOT CHANGE the header. mat: Please, DO NOT CHANGE the header.

	PORTNAME= lua			PORTNAME= lua
	PORTVERSION= 5.3.4			DISTVERSION= 5.3.5
	PORTREVISION= 2
	CATEGORIES= lang			CATEGORIES= lang
				matUnsubmitted Done Inline Actions This should be resetted when updating the version. mat: This should be resetted when updating the version.
				matUnsubmitted Not Done Inline Actions This was not done. Please remove PORTREVISION, or set it to 0. mat: This was not done. Please remove PORTREVISION, or set it to 0.
	MASTER_SITES= http://www.lua.org/ftp/			MASTER_SITES= https://www.lua.org/ftp/
	PKGNAMESUFFIX= 53			PKGNAMESUFFIX= 53

	MAINTAINER= russ.haley@gmail.com			MAINTAINER= russ.haley@gmail.com
	COMMENT= Small, compilable scripting language providing easy access to C code			COMMENT= Powerful, efficient, lightweight, embeddable scripting language
				matUnsubmitted Not Done Inline Actions Most scripting languages are embeddables, is lua not compilable any more ? mat: Most scripting languages are embeddables, is lua not compilable any more ?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions What does "compilable" mean? There is a bytecode compiler, which is useful for syntax checking and faster code loading, but has no effect whatsoever on execution speed (since code loaded as text is compiled to the same bytecode before execution anyway). Bytecode compilation is also of limited usefulness since the bytecode is version and platform dependent. I think most people would interpret "compilable" as implying faster execution, or execution of machine instructions rather than interpreted code, which is not the case here. andrew_tao173.riddles.org.uk: What does "compilable" mean? There is a bytecode compiler, which is useful for syntax checking…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions @andrew_tao173.riddles.org.uk is correct, that's why I changed it. I finally decided on the current phrasing because 'compilable' is not in the official description and I was too cowardly to change it entirely. I will change it to the official description on Lua.org: Lua is a powerful, efficient, lightweight, embeddable scripting language. russ.haley_gmail.com: @andrew_tao173.riddles.org.uk is correct, that's why I changed it. I finally decided on the…

	LICENSE= MIT			LICENSE= MIT

	USES= libedit
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions This is simply handled in the code patch to lua.c. As far as I can tell, editline is a standard package in FreeBSD 4.4? https://www.freebsd.org/cgi/man.cgi?editline russ.haley_gmail.com: This is simply handled in the code patch to lua.c. As far as I can tell, editline is a standard…
	LUA_VER= 5.3			LUA_VER= 5.3
	USE_LDCONFIG= yes			USE_LDCONFIG= yes

	# Overriding __MAKE_CONF makes sure that we don't re-parse			# Overriding __MAKE_CONF makes sure that we don't re-parse
	# /etc/make.conf during do-build, which would jeopardize the build			# /etc/make.conf during do-build, which would jeopardize the build
	# if, for instance, the user set CFLAGS=mumble			# if, for instance, the user set CFLAGS=mumble
	# NOTE: /etc/make.conf is read BEFORE Makefile, so we already			# NOTE: /etc/make.conf is read BEFORE Makefile, so we already
	# have its settings when we get here.			# have its settings when we get here.
	# See http://wiki.freebsd.org/MatthiasAndree/LuaLessonsLearnt			# See http://wiki.freebsd.org/MatthiasAndree/LuaLessonsLearnt
	MAKE_ARGS= __MAKE_CONF=${NONEXISTENT}			MAKE_ARGS= __MAKE_CONF=${NONEXISTENT}
	# liblua.so requires libm, so make sure it has an explicit dependency
	# so that applications need not second-guess lua's dependencies.
	CPPFLAGS+= -I${LOCALBASE}/include
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions Unnecessary if the standard editline package is used. https://www.freebsd.org/cgi/man.cgi?editline russ.haley_gmail.com: Unnecessary if the standard editline package is used. https://www.freebsd.org/cgi/man.cgi?
	LDFLAGS+= -lm -pthread
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions As per an email with Jan Beich: -pthread was inherited from https://svnweb.freebsd.org/changeset/ports/324286 which was probably fixed by https://svnweb.freebsd.org/changeset/base/276630 How do I test this? russ.haley_gmail.com: As per an email with Jan Beich: -pthread was inherited from https://svnweb.freebsd.
	BUILD_WRKSRC= ${WRKSRC}/src			BUILD_WRKSRC= ${WRKSRC}/src
	MAKE_ARGS+= MYCFLAGS="${CFLAGS} ${CPPFLAGS} -DLUA_USE_LINUX" \
				# Source, destination, and filenames to copy for the DOCS option
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions These variable have been added to standardize with lua.mk and hopefully other packages if I have time. russ.haley_gmail.com: These variable have been added to standardize with lua.mk and hopefully other packages if I…
				# (automatically added to pkg-plist if DOCS is set)
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions No. Linking lua53 with pthread might be defensible (though I personally don't think it is), but linking liblua.so against pthread is not on. andrew_tao173.riddles.org.uk: No. Linking lua53 with pthread might be defensible (though I personally don't think it is), but…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions I was unable to find a definitive test to indicate if Lua requires linking pthread. As I had seen mention of it in luaossl, I built Lua with and without linking to pthread and created a public key. In both tests I "required" luaossl and successfully created a public key using 1.0.2k. I emailed the luaossl maintainer (actually, I emailed the author wahern who directed me to the current maintainer duarnimator). Duarnimator indicated that openssl pre 1.1.0 needs pthreads and he pointed me to the sources: https://github.com/wahern/luaossl/blob/357a7f6da9e6ae442b3c3b9e43396b3cf2e1a91d/src/openssl.c#L11127 At this juncture I have assumed my tests were faulty and added -pthread back in. If you can indicate some tests I could try on any package that would prove this one way or the other (or confirm that my original test was valid) I would like to remove it entirely. To keep all the information together, here is the previous comment on that topic. As per an email with Jan Beich: -pthread was inherited from https://svnweb.freebsd.org/changeset/ports/324286 which was probably fixed by https://svnweb.freebsd.org/changeset/base/276630 russ.haley_gmail.com: I was unable to find a definitive test to indicate if Lua requires linking pthread. As I had…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions For reference on the luaossl requirement, see http://25thandclement.com/~william/projects/luaossl.pdf section 1.2.3 russ.haley_gmail.com: For reference on the luaossl requirement, see http://25thandclement.
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions I think you're missing the point about pthreads. Lua itself has no interaction with threads at all (unless you explicitly modify it to lock the interpreter, which the port doesn't do). Therefore, it's inappropriate for lublua.so (which will never call any pthread function) to force libthr into the process. (Remember that liblua.so might be being loaded because of a reference from a dlopen'd module - this is actually not uncommon) The bug fix you reference (base/276630) is specifically about loading libthr via dlopen, so without that fix, linking lublua.so against libthr actually makes things worse, since any dynamic load of a lua interpreter would trigger the bug even if no pthread-using module was ever used from Lua. If some extension that you want to load from Lua needs to pull in pthreads, then there are two possibilities: either it's enough for the extension .so to reference libthr to pull it in, or if there's an unfixed bug of the same kind as base/276630, then it's not enough for liblua.so to reference libthr, but rather the main executable must do so. andrew_tao173.riddles.org.uk: I think you're missing the point about pthreads. Lua itself has no interaction with threads at…
				russ.haley_gmail.comAuthorUnsubmitted Done Inline Actions I'm struggling to understand if/why libmath is required for the shared object at all but I don't currently have any code that uses liblua.so. I'll postulate that we should do a second exp run with -lm removed to see if anything breaks? russ.haley_gmail.com: I'm struggling to understand if/why libmath is required for the shared object at all but I…
				andrew_tao173.riddles.org.ukUnsubmitted Done Inline Actions Lua calls functions from libm. If you try and load liblua.so into a main program that doesn't export the libm functions, it'll fail unless liblua.so pulls in libm itself. So it's always correct for liblua.so to be linked against libm. andrew_tao173.riddles.org.uk: Lua calls functions from libm. If you try and load liblua.so into a main program that doesn't…
				# We override DOCSDIR to get a per-version subdir.
				# We put the docs for Lua proper in a lua/ subdir of the version subdir
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions Ken Sasaki (lua-stdlib-normalize / lua-stdlib-debug maintainer) suggested in a bugzilla thread that perhaps modules should be installing docs under doc/lua5N/port-name, so perhaps we should consider installing the docs for Lua proper under doc/lua5N/lua to allow that without creating a mess? andrew_tao173.riddles.org.uk: Ken Sasaki (lua-stdlib-normalize / lua-stdlib-debug maintainer) suggested in a bugzilla thread…
				# so that ports for Lua modules can use the version subdir too without
				# making a mess.
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions This is the standard make target for freebsd in lua. russ.haley_gmail.com: This is the standard make target for freebsd in lua.
				DOCSDIR= ${PREFIX}/share/doc/lua${PKGNAMESUFFIX}/lua
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions I would like to remove the renaming of the lua build output and postpone it until the install step, or a preinstall rename. Input appreciated. russ.haley_gmail.com: I would like to remove the renaming of the lua build output and postpone it until the install…
				PORTDOCS= *
				BUILD_WRKDOC= ${WRKSRC}/doc

				LUA_PREFIX= ${PREFIX}

				# 2018-03-17: AG - These should match lua.mk, but we can't include that here
				LUA_CMD= lua${PKGNAMESUFFIX}
				LUAC_CMD= luac${PKGNAMESUFFIX}
				LUA_INCDIR= ${LUA_PREFIX}/include/lua${PKGNAMESUFFIX}
				LUA_LIBDIR= ${LUA_PREFIX}/lib

				LUA_LIB_STATIC= liblua-${LUA_VER}.a
				LUA_LIB_SHARED= liblua-${LUA_VER}.so
				LUA_PC_FILE= lua-${LUA_VER}.pc

				# using the "bsd" target rather than "freebsd" saves patching out the
				# assumption of using base libedit in order to make it configurable. "bsd"
				# is "generic" plus the POSIX and DLOPEN options, plus -Wl,-E at link time;
				# it doesn't set CC either, which makes it easier for us to control that too.
				ALL_TARGET=bsd
				matUnsubmitted Not Done Inline Actions Why `+=`? mat: Why `+=`?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions I probably cargo-culted that in from some example when adding options to the lua54 port, and russ got it from me. No reason not to change it to just = andrew_tao173.riddles.org.uk: I probably cargo-culted that in from some example when adding options to the lua54 port, and…

				# Options

				OPTIONS_DEFAULT=LIBEDIT_DL DOCS

				OPTIONS_GROUP= DOCSGRP DEBUGGRP
				OPTIONS_SINGLE= EDITGRP

				OPTIONS_GROUP_DOCSGRP= DOCS
				OPTIONS_GROUP_DEBUGGRP= ASSERT APICHECK

				OPTIONS_SINGLE_EDITGRP= EDITNONE LIBEDIT_DL LIBEDIT READLINE

				# Option descriptions

				DEBUGGRP_DESC= Debugging options
				ASSERT_DESC= Enable interpreter assertions
				APICHECK_DESC= Enable API checks

				DOCSGRP_DESC= Documentation options
				DOCS_DESC= Install language and API reference (HTML, ~400kB)
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions Well, this sucks: qa.sh doesn't allow this and demands that you use the port instead. The problem with using the port libedit is that it links against the wrong libncurses, leading to compatibility problems when you try and use the lua curses module. Same problem exists with readline. I was hoping to avoid that problem this way, but if linking to base libedit isn't an option then we're going to need a much more involved solution, such as installing an extra lua binary without editing support. andrew_tao173.riddles.org.uk: Well, this sucks: qa.sh doesn't allow this and demands that you use the port instead. The…

				EDITGRP_DESC= Interactive command-line editing
				matUnsubmitted Not Done Inline Actions extra white space before `=`. mat: extra white space before `=`.
				EDITNONE_DESC= No command-line editing
				LIBEDIT_DL_DESC=Use dynamically loaded libedit (recommended)
				matUnsubmitted Not Done Inline Actions Please restore the header. mat: Please restore the header.
				LIBEDIT_DESC= Use libedit (breaks lcurses)
				READLINE_DESC= Use GNU Readline (breaks lcurses)

				# Option implementations

				ASSERT_EXTRA_PATCHES= ${PATCHDIR}/extra-patch-assert

				APICHECK_CPPFLAGS= -DLUA_USE_APICHECK

				# EDITNONE currently requires no settings

				matUnsubmitted Not Done Inline Actions To silence what exactly? Do not add inactive code because a third party lint tool gives you warnings. Also, what happens if libedit or libreadline is installed, and one selects this option? mat: To silence what exactly? Do not add inactive code because a third party lint tool gives you…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions portlint, which is prominently mentioned in the porters manual, counts as a third-party tool? Without that line or something logically equivalent, portlint reports: WARN: Makefile: EDITNONE is listed in OPTIONS_DEFINE, but no PORT_OPTIONS:MEDITNONE appears. Obviously that can just be ignored, which I did for a while, but I figured that it cost nothing to suppress the warning. If one selects EDITNONE, then regardless of what is or is not installed, the lua53 binary will not do command-line editing, when running interactively it'll just fgets from stdin. I thought the description of that was clear enough. No dependency on libedit or readline will be generated and no library other than libc and libm will be linked. andrew_tao173.riddles.org.uk: portlint, which is prominently mentioned in the porters manual, counts as a third-party tool?
				matUnsubmitted Not Done Inline Actions Mmm, if the option does nothing then do not add it. And instead of using an OPTIONS_SINGLE, use OPTIONS_RADIO. https://www.freebsd.org/doc/en/books/porters-handbook/makefile-options.html mat: Mmm, if the option does nothing then do not add it. And instead of using an OPTIONS_SINGLE…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions From a user perspective it seemed much clearer to have an explicit option for it (which could have a description). Without it, it's not at all clear that no editing is even an available option. andrew_tao173.riddles.org.uk: From a user perspective it seemed much clearer to have an explicit option for it (which could…
				matUnsubmitted Not Done Inline Actions The reason we have SINGLE (1) and RADIO (0,1) is to handle those case. You can add a few words to `EDITGRP_DESC` to say that having none is ok, or add a pkg-help file to be more verbose. But do not add a non functionnal variable only to please portlint. mat: The reason we have SINGLE (1) and RADIO (0,1) is to handle those case. You can add a few words…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions I'm OK with taking the variable out and just ignoring the warning, but changing the UI appearance just based on the fact that we don't actually need any special option processing to implement EDITNONE seems to me to be putting the cart before the horse. andrew_tao173.riddles.org.uk: I'm OK with taking the variable out and just ignoring the warning, but changing the UI…
				LIBEDIT_DL_USES= libedit
				LIBEDIT_DL_CPPFLAGS= -DLUA_USE_READLINE_DL

				LIBEDIT_USES= libedit
				LIBEDIT_CPPFLAGS= -DLUA_USE_READLINE
				matUnsubmitted Not Done Inline Actions missing tab after `=`. mat: missing tab after `=`.
				LIBEDIT_LIBS= -ledit

				READLINE_USES= readline
				READLINE_CPPFLAGS= -DLUA_USE_READLINE
				READLINE_LIBS= -lreadline

				matUnsubmitted Not Done Inline Actions This is not used anywhere, what is it for? mat: This is not used anywhere, what is it for?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions It's the only way to stop bsd.port.mk from adding -fno-strict-aliasing to CFLAGS. Lua does not require this flag. andrew_tao173.riddles.org.uk: It's the only way to stop bsd.port.mk from adding -fno-strict-aliasing to CFLAGS. Lua does not…
				matUnsubmitted Not Done Inline Actions But is it broken with it? mat: But is it broken with it?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions -fno-strict-aliasing only reduces optimization, so absent compiler bugs it can't "break" anything. However since Lua is an actively maintained piece of code which is tested with modern compilers, for which performance is a factor, I think it best to follow the upstream's selection of compile options in the absence of an overriding reason to do otherwise. andrew_tao173.riddles.org.uk: -fno-strict-aliasing only reduces optimization, so absent compiler bugs it can't "break"…
				# end of option vars

				CFLAGS+= -fPIC

				WITHOUT_NO_STRICT_ALIASING=yes

				MAKE_ARGS+= CC="${CC}" \
				MYCFLAGS="${CPPFLAGS} ${CFLAGS}" \
	MYLDFLAGS="${LDFLAGS}" \			MYLDFLAGS="${LDFLAGS}" \
	MYLIBS="-Wl,-E -L${LOCALBASE}/lib -ledit" \			MYLIBS="${LIBS}" \
	CC="${CC}" \			LUA_T=${LUA_CMD} \
	LUA_T=lua53 \			LUAC_T=${LUAC_CMD} \
	LUAC_T=luac53 \			LUA_A=${LUA_LIB_STATIC} \
	LUA_A=liblua-${LUA_VER}.a \			LUA_SO=${LUA_LIB_SHARED} \
	LUA_SO=liblua-${LUA_VER}.so \			LUA_SONAME=${LUA_LIB_SHARED} \
	LUA_SONAME=liblua-${LUA_VER}.so \			TO_BIN="${LUA_CMD} ${LUAC_CMD}" \
	TO_BIN="lua53 luac53" \			TO_LIB="${LUA_LIB_SHARED} ${LUA_LIB_STATIC}" \
	TO_LIB="liblua-${LUA_VER}.a liblua-${LUA_VER}.so" \
	INSTALL_TOP=${STAGEDIR}${PREFIX} \			INSTALL_TOP=${STAGEDIR}${PREFIX} \
	INSTALL_INC=${STAGEDIR}${PREFIX}/include/lua53 \			INSTALL_INC=${STAGEDIR}${LUA_INCDIR} \
	INSTALL_EXEC="${INSTALL_PROGRAM}"			INSTALL_EXEC="${INSTALL_PROGRAM}"

	# Cope with the lack of support for Lua 5.2 in bsd.lua.mk. These			SUB_FILES= ${LUA_PC_FILE}
	# overrides, which are required below, should be removed once bsd.lua.mk
	# understands this lua version.
	LUA_PREFIX?= ${PREFIX}
	LUA_SUBDIR?= lua${PKGNAMESUFFIX}
	LUA_INCDIR?= ${LUA_PREFIX}/include/${LUA_SUBDIR}
	LUA_LIBDIR?= ${LUA_PREFIX}/lib

	SUB_FILES= lua-${LUA_VER}.pc
	SUB_LIST= version=${PORTVERSION} \			SUB_LIST= version=${PORTVERSION} \
	includedir=${LUA_INCDIR} \			includedir=${LUA_INCDIR} \
	libdir=${LUA_LIBDIR} \			libdir=${LUA_LIBDIR} \
	soname=lua-${LUA_VER}			soname=lua-${LUA_VER}
				matUnsubmitted Done Inline Actions Why? mat: Why?
				russ.haley_gmail.comAuthorUnsubmitted Done Inline Actions I'm not sure I understand the question @mat? I'll assume the question is "Why use variables" and say, I was trying to remove the hard coded 'lua' and 'lua53' strings to make it more consistent and usable for the upcoming 5.4 port. To be more accurate, this is a revision of the 5.4 port Makefile 'backported' to 5.3 russ.haley_gmail.com: I'm not sure I understand the question @mat? I'll assume the question is "Why use variables"…
				andrew_tao173.riddles.org.ukUnsubmitted Done Inline Actions the problem here is that soname= and LUA_LIB_SHARED don't match if PORTNAME is changed. Either both names should be based on PORTNAME or neither should. andrew_tao173.riddles.org.uk: the problem here is that soname= and LUA_LIB_SHARED don't match if PORTNAME is changed. Either…
				matUnsubmitted Not Done Inline Actions Yes, why remove `lua`? This will never change, so, there is no point of having it as a variable. (Well, unless the language is renamed, but I don't see that happening.) mat: Yes, why remove `lua`? This will never change, so, there is no point of having it as a…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions Yes, why remove lua? This will never change, so, there is no point of having it as a variable. (Well, unless the language is renamed, but I don't see that happening.) I suppose the reason is two fold: 1) I'm learning as I go and it seemed like something to clean up and 2) my "OCD" made me cringe when I looked at it. I can change it back if it offends, as I am largely indifferent. russ.haley_gmail.com: > Yes, why remove lua? This will never change, so, there is no point of having it as a variable.
				matUnsubmitted Not Done Inline Actions It would be better to keep `lua` as it was before, using a 11 characters of variable for a 3 letter constant is a bit overboard. mat: It would be better to keep `lua` as it was before, using a 11 characters of variable for a 3…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions I am grateful for you taking the time to review my work. Please let me know what else you wish to see amended. russ.haley_gmail.com: I am grateful for you taking the time to review my work. Please let me know what else you wish…
				andrew_tao173.riddles.org.ukUnsubmitted Done Inline Actions Wrong value for soname= there. LUA_LUB_SHARED is liblua-5.3.so, but soname= needs to be lua-5.3.so without the 'lib' prefix. andrew_tao173.riddles.org.uk: Wrong value for soname= there. LUA_LUB_SHARED is liblua-5.3.so, but soname= needs to be lua-5.3.
				andrew_tao173.riddles.org.ukUnsubmitted Done Inline Actions uh, I mean soname needs to be lua-5.3 without either the 'lib' prefix or the '.so' suffix. andrew_tao173.riddles.org.uk: uh, I mean soname needs to be lua-5.3 without either the 'lib' prefix or the '.so' suffix.

	CFLAGS+= -fPIC
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions Added to the base Makefile russ.haley_gmail.com: Added to the base Makefile

	post-patch:			post-patch:
	@${REINPLACE_CMD} -e 's,rand *(,random(,g' \			@${REINPLACE_CMD} -e "/LUA_ROOT/s,/usr/local,${LUA_PREFIX}," \
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions The code that this patches is not reachable due to the USE_POSIX. http://lua-users.org/lists/lua-l/2017-09/msg00089.html From lmathlib.c #if !defined(l_rand) /* { / #if defined(LUA_USE_POSIX) #define l_rand() random() #define l_srand(x) srandom(x) #define L_RANDMAX 2147483647 / (2^31 - 1), following POSIX / #else #define l_rand() rand() #define l_srand(x) srand(x) #define L_RANDMAX RAND_MAX #endif #endif / } / from luaconf.h #if defined(LUA_USE_LINUX) #define LUA_USE_POSIX #define LUA_USE_DLOPEN / needs an extra library: -ldl / #define LUA_USE_READLINE / needs some extra libraries / #endif russ.haley_gmail.com:* The code that this patches is not reachable due to the USE_POSIX. http://lua-users.
	${WRKSRC}/src/lmathlib.c			${WRKSRC}/src/luaconf.h
	@${REINPLACE_CMD} -e "/LUA_ROOT/s\|/usr/local\|${LUA_PREFIX}\| ; \
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions luaconf.h contains no readline reference and I instead created a patch for lua.c. This makes the code changes in one place (patch files) and the changes required are easily visible (in the patch file). russ.haley_gmail.com: luaconf.h contains no readline reference and I instead created a patch for lua.c. This makes…
	andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions This removal isn't quite right because the point of editing luaconf.h here is not to deal with readline, but rather to fix LUA_ROOT to ensure it matches ${PREFIX}. By default these are both /usr/local, so it's not obvious if this step is missed, but if ${PREFIX} is set to something else it's important that LUA_ROOT in luaconf.h be updated to match. andrew_tao173.riddles.org.uk: This removal isn't quite right because the point of editing luaconf.h here is not to deal with…
	s,readline/,editline/,g ; \
	/history\.h/d" \
	${WRKSRC}/src/luaconf.h ${WRKSRC}/src/lua.c

				post-patch-LIBEDIT-on:
				@${REINPLACE_CMD} -e "s,readline/,editline/,g ; \
				/history\.h/d" ${WRKSRC}/src/lua.c

				post-patch-LIBEDIT_DL-on:
				@${REINPLACE_CMD} \
				-e "/^#def.*LUA_READLINE_LIBPATH/s,/usr/local,${LOCALBASE}," \
				${WRKSRC}/src/lua.c

	post-install:			post-install:
	@${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/liblua-${LUA_VER}.so			${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/${LUA_LIB_SHARED}
	@${MV} ${STAGEDIR}${PREFIX}/man/man1/lua.1 \			${MV} ${STAGEDIR}${PREFIX}/man/man1/lua.1 \
	${STAGEDIR}${PREFIX}/man/man1/lua53.1			${STAGEDIR}${PREFIX}/man/man1/${LUA_CMD}.1
	@${MV} ${STAGEDIR}${PREFIX}/man/man1/luac.1 \			${MV} ${STAGEDIR}${PREFIX}/man/man1/luac.1 \
	${STAGEDIR}${PREFIX}/man/man1/luac53.1			${STAGEDIR}${PREFIX}/man/man1/${LUAC_CMD}.1
	${INSTALL_DATA} ${WRKDIR}/lua-${LUA_VER}.pc \			${INSTALL_DATA} ${WRKDIR}/${LUA_PC_FILE} \
	${STAGEDIR}${PREFIX}/libdata/pkgconfig			${STAGEDIR}${PREFIX}/libdata/pkgconfig

				post-install-DOCS-on:
				${MKDIR} ${STAGEDIR}${DOCSDIR}
				(cd ${BUILD_WRKDOC} && \
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions make check-orphans doesn't like this, I'll fix in the next patch andrew_tao173.riddles.org.uk: make check-orphans doesn't like this, I'll fix in the next patch
				${COPYTREE_SHARE} . ${STAGEDIR}${DOCSDIR} '-not -name *\.1')

	.include <bsd.port.mk>			.include <bsd.port.mk>
				matUnsubmitted Not Done Inline Actions Any reason not to simply COPYTREE_SHARE all that directory in DOCSDIR? mat: Any reason not to simply COPYTREE_SHARE all that directory in DOCSDIR?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions BUILD_WRKDOC also has the lua.1 and luac.1 files in it that are installed as manpages rather than docs. In a previous version I had it copying those files anyway, but just not including them in PORTDOCS so they didn't get installed. But check-plist objects to that. andrew_tao173.riddles.org.uk: BUILD_WRKDOC also has the lua.1 and luac.1 files in it that are installed as manpages rather…
				matUnsubmitted Not Done Inline Actions This does not really say why you cannot use COPYTREE_SHARE. cd ${BUILD_WRKDOC} && ${COPYTREE_SHARE} . ${STAGEDIR}${DOCSDIR} '-not -name ".1"' mat:* This does not really say why you cannot use COPYTREE_SHARE. ``` cd ${BUILD_WRKDOC} &&…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions I just tried that, it doesn't work as given (it copies lua.1 and luac.1 anyway). Looks like COPYTREE_SHARE doesn't actually work with wildcards in the third arg, due to issues of shell quoting. "-not -name lua.1 -not -name luac.1" works, but now it's starting to look like not so much of an improvement over the previous form. andrew_tao173.riddles.org.uk: I just tried that, it doesn't work as given (it copies lua.1 and luac.1 anyway). Looks like…
				matUnsubmitted Not Done Inline Actions Mmmm, wildcards are supported, maybe you need to reverse the `"` and `'` order, like `"-not -name '.1'"`. Or write it as `'-not -name \.1'` mat: Mmmm, wildcards are supported, maybe you need to reverse the `"` and `'` order, like `"-not…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions None of those work. andrew_tao173.riddles.org.uk: None of those work.
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions Apparently the magic incantation is to escape with \ some part of the filename pattern other than the wildcard characters; this works because of an odd interaction between shell and find(1) related to the fact that find(1) does an extra layer of unescaping for itself, while the escape character prevents the pattern from matching any files in the shell (assuming there are no files with \ in the names). i.e. '-not -name \.1' works this is ... not at all well documented, while there is an example in bsd.port.mk it completely fails to point out the important aspect, and the ports handbook doesn't mention it at all. It also seems rather fragile to me. andrew_tao173.riddles.org.uk:* Apparently the magic incantation is to escape with \ some part of the filename pattern //other…
				matUnsubmitted Not Done Inline Actions Damn, I knew there was something strange happening. One day I'll try to figure out what really happens and why, and document it properly. mat: Damn, I knew there was something strange happening. One day I'll try to figure out what really…

View Options

distinfo

	# Created by: GreenDog <fiziologus@gmail.com>			# Created by: GreenDog <fiziologus@gmail.com>
	# $FreeBSD$			# $FreeBSD$
				matUnsubmitted Done Inline Actions The credit will alreay be present in the commit message, please do not add more in the Makefile. mat: The credit will alreay be present in the commit message, please do not add more in the Makefile.
				matUnsubmitted Not Done Inline Actions Please, DO NOT CHANGE the header. mat: Please, DO NOT CHANGE the header.

	PORTNAME= lua			PORTNAME= lua
	PORTVERSION= 5.3.4			DISTVERSION= 5.3.5
	PORTREVISION= 2
	CATEGORIES= lang			CATEGORIES= lang
				matUnsubmitted Done Inline Actions This should be resetted when updating the version. mat: This should be resetted when updating the version.
				matUnsubmitted Not Done Inline Actions This was not done. Please remove PORTREVISION, or set it to 0. mat: This was not done. Please remove PORTREVISION, or set it to 0.
	MASTER_SITES= http://www.lua.org/ftp/			MASTER_SITES= https://www.lua.org/ftp/
	PKGNAMESUFFIX= 53			PKGNAMESUFFIX= 53

	MAINTAINER= russ.haley@gmail.com			MAINTAINER= russ.haley@gmail.com
	COMMENT= Small, compilable scripting language providing easy access to C code			COMMENT= Powerful, efficient, lightweight, embeddable scripting language
				matUnsubmitted Not Done Inline Actions Most scripting languages are embeddables, is lua not compilable any more ? mat: Most scripting languages are embeddables, is lua not compilable any more ?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions What does "compilable" mean? There is a bytecode compiler, which is useful for syntax checking and faster code loading, but has no effect whatsoever on execution speed (since code loaded as text is compiled to the same bytecode before execution anyway). Bytecode compilation is also of limited usefulness since the bytecode is version and platform dependent. I think most people would interpret "compilable" as implying faster execution, or execution of machine instructions rather than interpreted code, which is not the case here. andrew_tao173.riddles.org.uk: What does "compilable" mean? There is a bytecode compiler, which is useful for syntax checking…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions @andrew_tao173.riddles.org.uk is correct, that's why I changed it. I finally decided on the current phrasing because 'compilable' is not in the official description and I was too cowardly to change it entirely. I will change it to the official description on Lua.org: Lua is a powerful, efficient, lightweight, embeddable scripting language. russ.haley_gmail.com: @andrew_tao173.riddles.org.uk is correct, that's why I changed it. I finally decided on the…

	LICENSE= MIT			LICENSE= MIT

	USES= libedit
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions This is simply handled in the code patch to lua.c. As far as I can tell, editline is a standard package in FreeBSD 4.4? https://www.freebsd.org/cgi/man.cgi?editline russ.haley_gmail.com: This is simply handled in the code patch to lua.c. As far as I can tell, editline is a standard…
	LUA_VER= 5.3			LUA_VER= 5.3
	USE_LDCONFIG= yes			USE_LDCONFIG= yes

	# Overriding __MAKE_CONF makes sure that we don't re-parse			# Overriding __MAKE_CONF makes sure that we don't re-parse
	# /etc/make.conf during do-build, which would jeopardize the build			# /etc/make.conf during do-build, which would jeopardize the build
	# if, for instance, the user set CFLAGS=mumble			# if, for instance, the user set CFLAGS=mumble
	# NOTE: /etc/make.conf is read BEFORE Makefile, so we already			# NOTE: /etc/make.conf is read BEFORE Makefile, so we already
	# have its settings when we get here.			# have its settings when we get here.
	# See http://wiki.freebsd.org/MatthiasAndree/LuaLessonsLearnt			# See http://wiki.freebsd.org/MatthiasAndree/LuaLessonsLearnt
	MAKE_ARGS= __MAKE_CONF=${NONEXISTENT}			MAKE_ARGS= __MAKE_CONF=${NONEXISTENT}
	# liblua.so requires libm, so make sure it has an explicit dependency
	# so that applications need not second-guess lua's dependencies.
	CPPFLAGS+= -I${LOCALBASE}/include
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions Unnecessary if the standard editline package is used. https://www.freebsd.org/cgi/man.cgi?editline russ.haley_gmail.com: Unnecessary if the standard editline package is used. https://www.freebsd.org/cgi/man.cgi?
	LDFLAGS+= -lm -pthread
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions As per an email with Jan Beich: -pthread was inherited from https://svnweb.freebsd.org/changeset/ports/324286 which was probably fixed by https://svnweb.freebsd.org/changeset/base/276630 How do I test this? russ.haley_gmail.com: As per an email with Jan Beich: -pthread was inherited from https://svnweb.freebsd.
	BUILD_WRKSRC= ${WRKSRC}/src			BUILD_WRKSRC= ${WRKSRC}/src
	MAKE_ARGS+= MYCFLAGS="${CFLAGS} ${CPPFLAGS} -DLUA_USE_LINUX" \
				# Source, destination, and filenames to copy for the DOCS option
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions These variable have been added to standardize with lua.mk and hopefully other packages if I have time. russ.haley_gmail.com: These variable have been added to standardize with lua.mk and hopefully other packages if I…
				# (automatically added to pkg-plist if DOCS is set)
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions No. Linking lua53 with pthread might be defensible (though I personally don't think it is), but linking liblua.so against pthread is not on. andrew_tao173.riddles.org.uk: No. Linking lua53 with pthread might be defensible (though I personally don't think it is), but…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions I was unable to find a definitive test to indicate if Lua requires linking pthread. As I had seen mention of it in luaossl, I built Lua with and without linking to pthread and created a public key. In both tests I "required" luaossl and successfully created a public key using 1.0.2k. I emailed the luaossl maintainer (actually, I emailed the author wahern who directed me to the current maintainer duarnimator). Duarnimator indicated that openssl pre 1.1.0 needs pthreads and he pointed me to the sources: https://github.com/wahern/luaossl/blob/357a7f6da9e6ae442b3c3b9e43396b3cf2e1a91d/src/openssl.c#L11127 At this juncture I have assumed my tests were faulty and added -pthread back in. If you can indicate some tests I could try on any package that would prove this one way or the other (or confirm that my original test was valid) I would like to remove it entirely. To keep all the information together, here is the previous comment on that topic. As per an email with Jan Beich: -pthread was inherited from https://svnweb.freebsd.org/changeset/ports/324286 which was probably fixed by https://svnweb.freebsd.org/changeset/base/276630 russ.haley_gmail.com: I was unable to find a definitive test to indicate if Lua requires linking pthread. As I had…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions For reference on the luaossl requirement, see http://25thandclement.com/~william/projects/luaossl.pdf section 1.2.3 russ.haley_gmail.com: For reference on the luaossl requirement, see http://25thandclement.
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions I think you're missing the point about pthreads. Lua itself has no interaction with threads at all (unless you explicitly modify it to lock the interpreter, which the port doesn't do). Therefore, it's inappropriate for lublua.so (which will never call any pthread function) to force libthr into the process. (Remember that liblua.so might be being loaded because of a reference from a dlopen'd module - this is actually not uncommon) The bug fix you reference (base/276630) is specifically about loading libthr via dlopen, so without that fix, linking lublua.so against libthr actually makes things worse, since any dynamic load of a lua interpreter would trigger the bug even if no pthread-using module was ever used from Lua. If some extension that you want to load from Lua needs to pull in pthreads, then there are two possibilities: either it's enough for the extension .so to reference libthr to pull it in, or if there's an unfixed bug of the same kind as base/276630, then it's not enough for liblua.so to reference libthr, but rather the main executable must do so. andrew_tao173.riddles.org.uk: I think you're missing the point about pthreads. Lua itself has no interaction with threads at…
				russ.haley_gmail.comAuthorUnsubmitted Done Inline Actions I'm struggling to understand if/why libmath is required for the shared object at all but I don't currently have any code that uses liblua.so. I'll postulate that we should do a second exp run with -lm removed to see if anything breaks? russ.haley_gmail.com: I'm struggling to understand if/why libmath is required for the shared object at all but I…
				andrew_tao173.riddles.org.ukUnsubmitted Done Inline Actions Lua calls functions from libm. If you try and load liblua.so into a main program that doesn't export the libm functions, it'll fail unless liblua.so pulls in libm itself. So it's always correct for liblua.so to be linked against libm. andrew_tao173.riddles.org.uk: Lua calls functions from libm. If you try and load liblua.so into a main program that doesn't…
				# We override DOCSDIR to get a per-version subdir.
				# We put the docs for Lua proper in a lua/ subdir of the version subdir
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions Ken Sasaki (lua-stdlib-normalize / lua-stdlib-debug maintainer) suggested in a bugzilla thread that perhaps modules should be installing docs under doc/lua5N/port-name, so perhaps we should consider installing the docs for Lua proper under doc/lua5N/lua to allow that without creating a mess? andrew_tao173.riddles.org.uk: Ken Sasaki (lua-stdlib-normalize / lua-stdlib-debug maintainer) suggested in a bugzilla thread…
				# so that ports for Lua modules can use the version subdir too without
				# making a mess.
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions This is the standard make target for freebsd in lua. russ.haley_gmail.com: This is the standard make target for freebsd in lua.
				DOCSDIR= ${PREFIX}/share/doc/lua${PKGNAMESUFFIX}/lua
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions I would like to remove the renaming of the lua build output and postpone it until the install step, or a preinstall rename. Input appreciated. russ.haley_gmail.com: I would like to remove the renaming of the lua build output and postpone it until the install…
				PORTDOCS= *
				BUILD_WRKDOC= ${WRKSRC}/doc

				LUA_PREFIX= ${PREFIX}

				# 2018-03-17: AG - These should match lua.mk, but we can't include that here
				LUA_CMD= lua${PKGNAMESUFFIX}
				LUAC_CMD= luac${PKGNAMESUFFIX}
				LUA_INCDIR= ${LUA_PREFIX}/include/lua${PKGNAMESUFFIX}
				LUA_LIBDIR= ${LUA_PREFIX}/lib

				LUA_LIB_STATIC= liblua-${LUA_VER}.a
				LUA_LIB_SHARED= liblua-${LUA_VER}.so
				LUA_PC_FILE= lua-${LUA_VER}.pc

				# using the "bsd" target rather than "freebsd" saves patching out the
				# assumption of using base libedit in order to make it configurable. "bsd"
				# is "generic" plus the POSIX and DLOPEN options, plus -Wl,-E at link time;
				# it doesn't set CC either, which makes it easier for us to control that too.
				ALL_TARGET=bsd
				matUnsubmitted Not Done Inline Actions Why `+=`? mat: Why `+=`?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions I probably cargo-culted that in from some example when adding options to the lua54 port, and russ got it from me. No reason not to change it to just = andrew_tao173.riddles.org.uk: I probably cargo-culted that in from some example when adding options to the lua54 port, and…

				# Options

				OPTIONS_DEFAULT=LIBEDIT_DL DOCS

				OPTIONS_GROUP= DOCSGRP DEBUGGRP
				OPTIONS_SINGLE= EDITGRP

				OPTIONS_GROUP_DOCSGRP= DOCS
				OPTIONS_GROUP_DEBUGGRP= ASSERT APICHECK

				OPTIONS_SINGLE_EDITGRP= EDITNONE LIBEDIT_DL LIBEDIT READLINE

				# Option descriptions

				DEBUGGRP_DESC= Debugging options
				ASSERT_DESC= Enable interpreter assertions
				APICHECK_DESC= Enable API checks

				DOCSGRP_DESC= Documentation options
				DOCS_DESC= Install language and API reference (HTML, ~400kB)
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions Well, this sucks: qa.sh doesn't allow this and demands that you use the port instead. The problem with using the port libedit is that it links against the wrong libncurses, leading to compatibility problems when you try and use the lua curses module. Same problem exists with readline. I was hoping to avoid that problem this way, but if linking to base libedit isn't an option then we're going to need a much more involved solution, such as installing an extra lua binary without editing support. andrew_tao173.riddles.org.uk: Well, this sucks: qa.sh doesn't allow this and demands that you use the port instead. The…

				EDITGRP_DESC= Interactive command-line editing
				matUnsubmitted Not Done Inline Actions extra white space before `=`. mat: extra white space before `=`.
				EDITNONE_DESC= No command-line editing
				LIBEDIT_DL_DESC=Use dynamically loaded libedit (recommended)
				matUnsubmitted Not Done Inline Actions Please restore the header. mat: Please restore the header.
				LIBEDIT_DESC= Use libedit (breaks lcurses)
				READLINE_DESC= Use GNU Readline (breaks lcurses)

				# Option implementations

				ASSERT_EXTRA_PATCHES= ${PATCHDIR}/extra-patch-assert

				APICHECK_CPPFLAGS= -DLUA_USE_APICHECK

				# EDITNONE currently requires no settings

				matUnsubmitted Not Done Inline Actions To silence what exactly? Do not add inactive code because a third party lint tool gives you warnings. Also, what happens if libedit or libreadline is installed, and one selects this option? mat: To silence what exactly? Do not add inactive code because a third party lint tool gives you…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions portlint, which is prominently mentioned in the porters manual, counts as a third-party tool? Without that line or something logically equivalent, portlint reports: WARN: Makefile: EDITNONE is listed in OPTIONS_DEFINE, but no PORT_OPTIONS:MEDITNONE appears. Obviously that can just be ignored, which I did for a while, but I figured that it cost nothing to suppress the warning. If one selects EDITNONE, then regardless of what is or is not installed, the lua53 binary will not do command-line editing, when running interactively it'll just fgets from stdin. I thought the description of that was clear enough. No dependency on libedit or readline will be generated and no library other than libc and libm will be linked. andrew_tao173.riddles.org.uk: portlint, which is prominently mentioned in the porters manual, counts as a third-party tool?
				matUnsubmitted Not Done Inline Actions Mmm, if the option does nothing then do not add it. And instead of using an OPTIONS_SINGLE, use OPTIONS_RADIO. https://www.freebsd.org/doc/en/books/porters-handbook/makefile-options.html mat: Mmm, if the option does nothing then do not add it. And instead of using an OPTIONS_SINGLE…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions From a user perspective it seemed much clearer to have an explicit option for it (which could have a description). Without it, it's not at all clear that no editing is even an available option. andrew_tao173.riddles.org.uk: From a user perspective it seemed much clearer to have an explicit option for it (which could…
				matUnsubmitted Not Done Inline Actions The reason we have SINGLE (1) and RADIO (0,1) is to handle those case. You can add a few words to `EDITGRP_DESC` to say that having none is ok, or add a pkg-help file to be more verbose. But do not add a non functionnal variable only to please portlint. mat: The reason we have SINGLE (1) and RADIO (0,1) is to handle those case. You can add a few words…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions I'm OK with taking the variable out and just ignoring the warning, but changing the UI appearance just based on the fact that we don't actually need any special option processing to implement EDITNONE seems to me to be putting the cart before the horse. andrew_tao173.riddles.org.uk: I'm OK with taking the variable out and just ignoring the warning, but changing the UI…
				LIBEDIT_DL_USES= libedit
				LIBEDIT_DL_CPPFLAGS= -DLUA_USE_READLINE_DL

				LIBEDIT_USES= libedit
				LIBEDIT_CPPFLAGS= -DLUA_USE_READLINE
				matUnsubmitted Not Done Inline Actions missing tab after `=`. mat: missing tab after `=`.
				LIBEDIT_LIBS= -ledit

				READLINE_USES= readline
				READLINE_CPPFLAGS= -DLUA_USE_READLINE
				READLINE_LIBS= -lreadline

				matUnsubmitted Not Done Inline Actions This is not used anywhere, what is it for? mat: This is not used anywhere, what is it for?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions It's the only way to stop bsd.port.mk from adding -fno-strict-aliasing to CFLAGS. Lua does not require this flag. andrew_tao173.riddles.org.uk: It's the only way to stop bsd.port.mk from adding -fno-strict-aliasing to CFLAGS. Lua does not…
				matUnsubmitted Not Done Inline Actions But is it broken with it? mat: But is it broken with it?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions -fno-strict-aliasing only reduces optimization, so absent compiler bugs it can't "break" anything. However since Lua is an actively maintained piece of code which is tested with modern compilers, for which performance is a factor, I think it best to follow the upstream's selection of compile options in the absence of an overriding reason to do otherwise. andrew_tao173.riddles.org.uk: -fno-strict-aliasing only reduces optimization, so absent compiler bugs it can't "break"…
				# end of option vars

				CFLAGS+= -fPIC

				WITHOUT_NO_STRICT_ALIASING=yes

				MAKE_ARGS+= CC="${CC}" \
				MYCFLAGS="${CPPFLAGS} ${CFLAGS}" \
	MYLDFLAGS="${LDFLAGS}" \			MYLDFLAGS="${LDFLAGS}" \
	MYLIBS="-Wl,-E -L${LOCALBASE}/lib -ledit" \			MYLIBS="${LIBS}" \
	CC="${CC}" \			LUA_T=${LUA_CMD} \
	LUA_T=lua53 \			LUAC_T=${LUAC_CMD} \
	LUAC_T=luac53 \			LUA_A=${LUA_LIB_STATIC} \
	LUA_A=liblua-${LUA_VER}.a \			LUA_SO=${LUA_LIB_SHARED} \
	LUA_SO=liblua-${LUA_VER}.so \			LUA_SONAME=${LUA_LIB_SHARED} \
	LUA_SONAME=liblua-${LUA_VER}.so \			TO_BIN="${LUA_CMD} ${LUAC_CMD}" \
	TO_BIN="lua53 luac53" \			TO_LIB="${LUA_LIB_SHARED} ${LUA_LIB_STATIC}" \
	TO_LIB="liblua-${LUA_VER}.a liblua-${LUA_VER}.so" \
	INSTALL_TOP=${STAGEDIR}${PREFIX} \			INSTALL_TOP=${STAGEDIR}${PREFIX} \
	INSTALL_INC=${STAGEDIR}${PREFIX}/include/lua53 \			INSTALL_INC=${STAGEDIR}${LUA_INCDIR} \
	INSTALL_EXEC="${INSTALL_PROGRAM}"			INSTALL_EXEC="${INSTALL_PROGRAM}"

	# Cope with the lack of support for Lua 5.2 in bsd.lua.mk. These			SUB_FILES= ${LUA_PC_FILE}
	# overrides, which are required below, should be removed once bsd.lua.mk
	# understands this lua version.
	LUA_PREFIX?= ${PREFIX}
	LUA_SUBDIR?= lua${PKGNAMESUFFIX}
	LUA_INCDIR?= ${LUA_PREFIX}/include/${LUA_SUBDIR}
	LUA_LIBDIR?= ${LUA_PREFIX}/lib

	SUB_FILES= lua-${LUA_VER}.pc
	SUB_LIST= version=${PORTVERSION} \			SUB_LIST= version=${PORTVERSION} \
	includedir=${LUA_INCDIR} \			includedir=${LUA_INCDIR} \
	libdir=${LUA_LIBDIR} \			libdir=${LUA_LIBDIR} \
	soname=lua-${LUA_VER}			soname=lua-${LUA_VER}
				matUnsubmitted Done Inline Actions Why? mat: Why?
				russ.haley_gmail.comAuthorUnsubmitted Done Inline Actions I'm not sure I understand the question @mat? I'll assume the question is "Why use variables" and say, I was trying to remove the hard coded 'lua' and 'lua53' strings to make it more consistent and usable for the upcoming 5.4 port. To be more accurate, this is a revision of the 5.4 port Makefile 'backported' to 5.3 russ.haley_gmail.com: I'm not sure I understand the question @mat? I'll assume the question is "Why use variables"…
				andrew_tao173.riddles.org.ukUnsubmitted Done Inline Actions the problem here is that soname= and LUA_LIB_SHARED don't match if PORTNAME is changed. Either both names should be based on PORTNAME or neither should. andrew_tao173.riddles.org.uk: the problem here is that soname= and LUA_LIB_SHARED don't match if PORTNAME is changed. Either…
				matUnsubmitted Not Done Inline Actions Yes, why remove `lua`? This will never change, so, there is no point of having it as a variable. (Well, unless the language is renamed, but I don't see that happening.) mat: Yes, why remove `lua`? This will never change, so, there is no point of having it as a…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions Yes, why remove lua? This will never change, so, there is no point of having it as a variable. (Well, unless the language is renamed, but I don't see that happening.) I suppose the reason is two fold: 1) I'm learning as I go and it seemed like something to clean up and 2) my "OCD" made me cringe when I looked at it. I can change it back if it offends, as I am largely indifferent. russ.haley_gmail.com: > Yes, why remove lua? This will never change, so, there is no point of having it as a variable.
				matUnsubmitted Not Done Inline Actions It would be better to keep `lua` as it was before, using a 11 characters of variable for a 3 letter constant is a bit overboard. mat: It would be better to keep `lua` as it was before, using a 11 characters of variable for a 3…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions I am grateful for you taking the time to review my work. Please let me know what else you wish to see amended. russ.haley_gmail.com: I am grateful for you taking the time to review my work. Please let me know what else you wish…
				andrew_tao173.riddles.org.ukUnsubmitted Done Inline Actions Wrong value for soname= there. LUA_LUB_SHARED is liblua-5.3.so, but soname= needs to be lua-5.3.so without the 'lib' prefix. andrew_tao173.riddles.org.uk: Wrong value for soname= there. LUA_LUB_SHARED is liblua-5.3.so, but soname= needs to be lua-5.3.
				andrew_tao173.riddles.org.ukUnsubmitted Done Inline Actions uh, I mean soname needs to be lua-5.3 without either the 'lib' prefix or the '.so' suffix. andrew_tao173.riddles.org.uk: uh, I mean soname needs to be lua-5.3 without either the 'lib' prefix or the '.so' suffix.

	CFLAGS+= -fPIC
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions Added to the base Makefile russ.haley_gmail.com: Added to the base Makefile

	post-patch:			post-patch:
	@${REINPLACE_CMD} -e 's,rand *(,random(,g' \			@${REINPLACE_CMD} -e "/LUA_ROOT/s,/usr/local,${LUA_PREFIX}," \
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions The code that this patches is not reachable due to the USE_POSIX. http://lua-users.org/lists/lua-l/2017-09/msg00089.html From lmathlib.c #if !defined(l_rand) /* { / #if defined(LUA_USE_POSIX) #define l_rand() random() #define l_srand(x) srandom(x) #define L_RANDMAX 2147483647 / (2^31 - 1), following POSIX / #else #define l_rand() rand() #define l_srand(x) srand(x) #define L_RANDMAX RAND_MAX #endif #endif / } / from luaconf.h #if defined(LUA_USE_LINUX) #define LUA_USE_POSIX #define LUA_USE_DLOPEN / needs an extra library: -ldl / #define LUA_USE_READLINE / needs some extra libraries / #endif russ.haley_gmail.com:* The code that this patches is not reachable due to the USE_POSIX. http://lua-users.
	${WRKSRC}/src/lmathlib.c			${WRKSRC}/src/luaconf.h
	@${REINPLACE_CMD} -e "/LUA_ROOT/s\|/usr/local\|${LUA_PREFIX}\| ; \
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions luaconf.h contains no readline reference and I instead created a patch for lua.c. This makes the code changes in one place (patch files) and the changes required are easily visible (in the patch file). russ.haley_gmail.com: luaconf.h contains no readline reference and I instead created a patch for lua.c. This makes…
	andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions This removal isn't quite right because the point of editing luaconf.h here is not to deal with readline, but rather to fix LUA_ROOT to ensure it matches ${PREFIX}. By default these are both /usr/local, so it's not obvious if this step is missed, but if ${PREFIX} is set to something else it's important that LUA_ROOT in luaconf.h be updated to match. andrew_tao173.riddles.org.uk: This removal isn't quite right because the point of editing luaconf.h here is not to deal with…
	s,readline/,editline/,g ; \
	/history\.h/d" \
	${WRKSRC}/src/luaconf.h ${WRKSRC}/src/lua.c

				post-patch-LIBEDIT-on:
				@${REINPLACE_CMD} -e "s,readline/,editline/,g ; \
				/history\.h/d" ${WRKSRC}/src/lua.c

				post-patch-LIBEDIT_DL-on:
				@${REINPLACE_CMD} \
				-e "/^#def.*LUA_READLINE_LIBPATH/s,/usr/local,${LOCALBASE}," \
				${WRKSRC}/src/lua.c

	post-install:			post-install:
	@${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/liblua-${LUA_VER}.so			${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/${LUA_LIB_SHARED}
	@${MV} ${STAGEDIR}${PREFIX}/man/man1/lua.1 \			${MV} ${STAGEDIR}${PREFIX}/man/man1/lua.1 \
	${STAGEDIR}${PREFIX}/man/man1/lua53.1			${STAGEDIR}${PREFIX}/man/man1/${LUA_CMD}.1
	@${MV} ${STAGEDIR}${PREFIX}/man/man1/luac.1 \			${MV} ${STAGEDIR}${PREFIX}/man/man1/luac.1 \
	${STAGEDIR}${PREFIX}/man/man1/luac53.1			${STAGEDIR}${PREFIX}/man/man1/${LUAC_CMD}.1
	${INSTALL_DATA} ${WRKDIR}/lua-${LUA_VER}.pc \			${INSTALL_DATA} ${WRKDIR}/${LUA_PC_FILE} \
	${STAGEDIR}${PREFIX}/libdata/pkgconfig			${STAGEDIR}${PREFIX}/libdata/pkgconfig

				post-install-DOCS-on:
				${MKDIR} ${STAGEDIR}${DOCSDIR}
				(cd ${BUILD_WRKDOC} && \
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions make check-orphans doesn't like this, I'll fix in the next patch andrew_tao173.riddles.org.uk: make check-orphans doesn't like this, I'll fix in the next patch
				${COPYTREE_SHARE} . ${STAGEDIR}${DOCSDIR} '-not -name *\.1')

	.include <bsd.port.mk>			.include <bsd.port.mk>
				matUnsubmitted Not Done Inline Actions Any reason not to simply COPYTREE_SHARE all that directory in DOCSDIR? mat: Any reason not to simply COPYTREE_SHARE all that directory in DOCSDIR?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions BUILD_WRKDOC also has the lua.1 and luac.1 files in it that are installed as manpages rather than docs. In a previous version I had it copying those files anyway, but just not including them in PORTDOCS so they didn't get installed. But check-plist objects to that. andrew_tao173.riddles.org.uk: BUILD_WRKDOC also has the lua.1 and luac.1 files in it that are installed as manpages rather…
				matUnsubmitted Not Done Inline Actions This does not really say why you cannot use COPYTREE_SHARE. cd ${BUILD_WRKDOC} && ${COPYTREE_SHARE} . ${STAGEDIR}${DOCSDIR} '-not -name ".1"' mat:* This does not really say why you cannot use COPYTREE_SHARE. ``` cd ${BUILD_WRKDOC} &&…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions I just tried that, it doesn't work as given (it copies lua.1 and luac.1 anyway). Looks like COPYTREE_SHARE doesn't actually work with wildcards in the third arg, due to issues of shell quoting. "-not -name lua.1 -not -name luac.1" works, but now it's starting to look like not so much of an improvement over the previous form. andrew_tao173.riddles.org.uk: I just tried that, it doesn't work as given (it copies lua.1 and luac.1 anyway). Looks like…
				matUnsubmitted Not Done Inline Actions Mmmm, wildcards are supported, maybe you need to reverse the `"` and `'` order, like `"-not -name '.1'"`. Or write it as `'-not -name \.1'` mat: Mmmm, wildcards are supported, maybe you need to reverse the `"` and `'` order, like `"-not…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions None of those work. andrew_tao173.riddles.org.uk: None of those work.
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions Apparently the magic incantation is to escape with \ some part of the filename pattern other than the wildcard characters; this works because of an odd interaction between shell and find(1) related to the fact that find(1) does an extra layer of unescaping for itself, while the escape character prevents the pattern from matching any files in the shell (assuming there are no files with \ in the names). i.e. '-not -name \.1' works this is ... not at all well documented, while there is an example in bsd.port.mk it completely fails to point out the important aspect, and the ports handbook doesn't mention it at all. It also seems rather fragile to me. andrew_tao173.riddles.org.uk:* Apparently the magic incantation is to escape with \ some part of the filename pattern //other…
				matUnsubmitted Not Done Inline Actions Damn, I knew there was something strange happening. One day I'll try to figure out what really happens and why, and document it properly. mat: Damn, I knew there was something strange happening. One day I'll try to figure out what really…

View Options

files/extra-patch-assert

	# Created by: GreenDog <fiziologus@gmail.com>			# Created by: GreenDog <fiziologus@gmail.com>
	# $FreeBSD$			# $FreeBSD$
				matUnsubmitted Done Inline Actions The credit will alreay be present in the commit message, please do not add more in the Makefile. mat: The credit will alreay be present in the commit message, please do not add more in the Makefile.
				matUnsubmitted Not Done Inline Actions Please, DO NOT CHANGE the header. mat: Please, DO NOT CHANGE the header.

	PORTNAME= lua			PORTNAME= lua
	PORTVERSION= 5.3.4			DISTVERSION= 5.3.5
	PORTREVISION= 2
	CATEGORIES= lang			CATEGORIES= lang
				matUnsubmitted Done Inline Actions This should be resetted when updating the version. mat: This should be resetted when updating the version.
				matUnsubmitted Not Done Inline Actions This was not done. Please remove PORTREVISION, or set it to 0. mat: This was not done. Please remove PORTREVISION, or set it to 0.
	MASTER_SITES= http://www.lua.org/ftp/			MASTER_SITES= https://www.lua.org/ftp/
	PKGNAMESUFFIX= 53			PKGNAMESUFFIX= 53

	MAINTAINER= russ.haley@gmail.com			MAINTAINER= russ.haley@gmail.com
	COMMENT= Small, compilable scripting language providing easy access to C code			COMMENT= Powerful, efficient, lightweight, embeddable scripting language
				matUnsubmitted Not Done Inline Actions Most scripting languages are embeddables, is lua not compilable any more ? mat: Most scripting languages are embeddables, is lua not compilable any more ?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions What does "compilable" mean? There is a bytecode compiler, which is useful for syntax checking and faster code loading, but has no effect whatsoever on execution speed (since code loaded as text is compiled to the same bytecode before execution anyway). Bytecode compilation is also of limited usefulness since the bytecode is version and platform dependent. I think most people would interpret "compilable" as implying faster execution, or execution of machine instructions rather than interpreted code, which is not the case here. andrew_tao173.riddles.org.uk: What does "compilable" mean? There is a bytecode compiler, which is useful for syntax checking…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions @andrew_tao173.riddles.org.uk is correct, that's why I changed it. I finally decided on the current phrasing because 'compilable' is not in the official description and I was too cowardly to change it entirely. I will change it to the official description on Lua.org: Lua is a powerful, efficient, lightweight, embeddable scripting language. russ.haley_gmail.com: @andrew_tao173.riddles.org.uk is correct, that's why I changed it. I finally decided on the…

	LICENSE= MIT			LICENSE= MIT

	USES= libedit
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions This is simply handled in the code patch to lua.c. As far as I can tell, editline is a standard package in FreeBSD 4.4? https://www.freebsd.org/cgi/man.cgi?editline russ.haley_gmail.com: This is simply handled in the code patch to lua.c. As far as I can tell, editline is a standard…
	LUA_VER= 5.3			LUA_VER= 5.3
	USE_LDCONFIG= yes			USE_LDCONFIG= yes

	# Overriding __MAKE_CONF makes sure that we don't re-parse			# Overriding __MAKE_CONF makes sure that we don't re-parse
	# /etc/make.conf during do-build, which would jeopardize the build			# /etc/make.conf during do-build, which would jeopardize the build
	# if, for instance, the user set CFLAGS=mumble			# if, for instance, the user set CFLAGS=mumble
	# NOTE: /etc/make.conf is read BEFORE Makefile, so we already			# NOTE: /etc/make.conf is read BEFORE Makefile, so we already
	# have its settings when we get here.			# have its settings when we get here.
	# See http://wiki.freebsd.org/MatthiasAndree/LuaLessonsLearnt			# See http://wiki.freebsd.org/MatthiasAndree/LuaLessonsLearnt
	MAKE_ARGS= __MAKE_CONF=${NONEXISTENT}			MAKE_ARGS= __MAKE_CONF=${NONEXISTENT}
	# liblua.so requires libm, so make sure it has an explicit dependency
	# so that applications need not second-guess lua's dependencies.
	CPPFLAGS+= -I${LOCALBASE}/include
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions Unnecessary if the standard editline package is used. https://www.freebsd.org/cgi/man.cgi?editline russ.haley_gmail.com: Unnecessary if the standard editline package is used. https://www.freebsd.org/cgi/man.cgi?
	LDFLAGS+= -lm -pthread
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions As per an email with Jan Beich: -pthread was inherited from https://svnweb.freebsd.org/changeset/ports/324286 which was probably fixed by https://svnweb.freebsd.org/changeset/base/276630 How do I test this? russ.haley_gmail.com: As per an email with Jan Beich: -pthread was inherited from https://svnweb.freebsd.
	BUILD_WRKSRC= ${WRKSRC}/src			BUILD_WRKSRC= ${WRKSRC}/src
	MAKE_ARGS+= MYCFLAGS="${CFLAGS} ${CPPFLAGS} -DLUA_USE_LINUX" \
				# Source, destination, and filenames to copy for the DOCS option
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions These variable have been added to standardize with lua.mk and hopefully other packages if I have time. russ.haley_gmail.com: These variable have been added to standardize with lua.mk and hopefully other packages if I…
				# (automatically added to pkg-plist if DOCS is set)
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions No. Linking lua53 with pthread might be defensible (though I personally don't think it is), but linking liblua.so against pthread is not on. andrew_tao173.riddles.org.uk: No. Linking lua53 with pthread might be defensible (though I personally don't think it is), but…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions I was unable to find a definitive test to indicate if Lua requires linking pthread. As I had seen mention of it in luaossl, I built Lua with and without linking to pthread and created a public key. In both tests I "required" luaossl and successfully created a public key using 1.0.2k. I emailed the luaossl maintainer (actually, I emailed the author wahern who directed me to the current maintainer duarnimator). Duarnimator indicated that openssl pre 1.1.0 needs pthreads and he pointed me to the sources: https://github.com/wahern/luaossl/blob/357a7f6da9e6ae442b3c3b9e43396b3cf2e1a91d/src/openssl.c#L11127 At this juncture I have assumed my tests were faulty and added -pthread back in. If you can indicate some tests I could try on any package that would prove this one way or the other (or confirm that my original test was valid) I would like to remove it entirely. To keep all the information together, here is the previous comment on that topic. As per an email with Jan Beich: -pthread was inherited from https://svnweb.freebsd.org/changeset/ports/324286 which was probably fixed by https://svnweb.freebsd.org/changeset/base/276630 russ.haley_gmail.com: I was unable to find a definitive test to indicate if Lua requires linking pthread. As I had…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions For reference on the luaossl requirement, see http://25thandclement.com/~william/projects/luaossl.pdf section 1.2.3 russ.haley_gmail.com: For reference on the luaossl requirement, see http://25thandclement.
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions I think you're missing the point about pthreads. Lua itself has no interaction with threads at all (unless you explicitly modify it to lock the interpreter, which the port doesn't do). Therefore, it's inappropriate for lublua.so (which will never call any pthread function) to force libthr into the process. (Remember that liblua.so might be being loaded because of a reference from a dlopen'd module - this is actually not uncommon) The bug fix you reference (base/276630) is specifically about loading libthr via dlopen, so without that fix, linking lublua.so against libthr actually makes things worse, since any dynamic load of a lua interpreter would trigger the bug even if no pthread-using module was ever used from Lua. If some extension that you want to load from Lua needs to pull in pthreads, then there are two possibilities: either it's enough for the extension .so to reference libthr to pull it in, or if there's an unfixed bug of the same kind as base/276630, then it's not enough for liblua.so to reference libthr, but rather the main executable must do so. andrew_tao173.riddles.org.uk: I think you're missing the point about pthreads. Lua itself has no interaction with threads at…
				russ.haley_gmail.comAuthorUnsubmitted Done Inline Actions I'm struggling to understand if/why libmath is required for the shared object at all but I don't currently have any code that uses liblua.so. I'll postulate that we should do a second exp run with -lm removed to see if anything breaks? russ.haley_gmail.com: I'm struggling to understand if/why libmath is required for the shared object at all but I…
				andrew_tao173.riddles.org.ukUnsubmitted Done Inline Actions Lua calls functions from libm. If you try and load liblua.so into a main program that doesn't export the libm functions, it'll fail unless liblua.so pulls in libm itself. So it's always correct for liblua.so to be linked against libm. andrew_tao173.riddles.org.uk: Lua calls functions from libm. If you try and load liblua.so into a main program that doesn't…
				# We override DOCSDIR to get a per-version subdir.
				# We put the docs for Lua proper in a lua/ subdir of the version subdir
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions Ken Sasaki (lua-stdlib-normalize / lua-stdlib-debug maintainer) suggested in a bugzilla thread that perhaps modules should be installing docs under doc/lua5N/port-name, so perhaps we should consider installing the docs for Lua proper under doc/lua5N/lua to allow that without creating a mess? andrew_tao173.riddles.org.uk: Ken Sasaki (lua-stdlib-normalize / lua-stdlib-debug maintainer) suggested in a bugzilla thread…
				# so that ports for Lua modules can use the version subdir too without
				# making a mess.
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions This is the standard make target for freebsd in lua. russ.haley_gmail.com: This is the standard make target for freebsd in lua.
				DOCSDIR= ${PREFIX}/share/doc/lua${PKGNAMESUFFIX}/lua
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions I would like to remove the renaming of the lua build output and postpone it until the install step, or a preinstall rename. Input appreciated. russ.haley_gmail.com: I would like to remove the renaming of the lua build output and postpone it until the install…
				PORTDOCS= *
				BUILD_WRKDOC= ${WRKSRC}/doc

				LUA_PREFIX= ${PREFIX}

				# 2018-03-17: AG - These should match lua.mk, but we can't include that here
				LUA_CMD= lua${PKGNAMESUFFIX}
				LUAC_CMD= luac${PKGNAMESUFFIX}
				LUA_INCDIR= ${LUA_PREFIX}/include/lua${PKGNAMESUFFIX}
				LUA_LIBDIR= ${LUA_PREFIX}/lib

				LUA_LIB_STATIC= liblua-${LUA_VER}.a
				LUA_LIB_SHARED= liblua-${LUA_VER}.so
				LUA_PC_FILE= lua-${LUA_VER}.pc

				# using the "bsd" target rather than "freebsd" saves patching out the
				# assumption of using base libedit in order to make it configurable. "bsd"
				# is "generic" plus the POSIX and DLOPEN options, plus -Wl,-E at link time;
				# it doesn't set CC either, which makes it easier for us to control that too.
				ALL_TARGET=bsd
				matUnsubmitted Not Done Inline Actions Why `+=`? mat: Why `+=`?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions I probably cargo-culted that in from some example when adding options to the lua54 port, and russ got it from me. No reason not to change it to just = andrew_tao173.riddles.org.uk: I probably cargo-culted that in from some example when adding options to the lua54 port, and…

				# Options

				OPTIONS_DEFAULT=LIBEDIT_DL DOCS

				OPTIONS_GROUP= DOCSGRP DEBUGGRP
				OPTIONS_SINGLE= EDITGRP

				OPTIONS_GROUP_DOCSGRP= DOCS
				OPTIONS_GROUP_DEBUGGRP= ASSERT APICHECK

				OPTIONS_SINGLE_EDITGRP= EDITNONE LIBEDIT_DL LIBEDIT READLINE

				# Option descriptions

				DEBUGGRP_DESC= Debugging options
				ASSERT_DESC= Enable interpreter assertions
				APICHECK_DESC= Enable API checks

				DOCSGRP_DESC= Documentation options
				DOCS_DESC= Install language and API reference (HTML, ~400kB)
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions Well, this sucks: qa.sh doesn't allow this and demands that you use the port instead. The problem with using the port libedit is that it links against the wrong libncurses, leading to compatibility problems when you try and use the lua curses module. Same problem exists with readline. I was hoping to avoid that problem this way, but if linking to base libedit isn't an option then we're going to need a much more involved solution, such as installing an extra lua binary without editing support. andrew_tao173.riddles.org.uk: Well, this sucks: qa.sh doesn't allow this and demands that you use the port instead. The…

				EDITGRP_DESC= Interactive command-line editing
				matUnsubmitted Not Done Inline Actions extra white space before `=`. mat: extra white space before `=`.
				EDITNONE_DESC= No command-line editing
				LIBEDIT_DL_DESC=Use dynamically loaded libedit (recommended)
				matUnsubmitted Not Done Inline Actions Please restore the header. mat: Please restore the header.
				LIBEDIT_DESC= Use libedit (breaks lcurses)
				READLINE_DESC= Use GNU Readline (breaks lcurses)

				# Option implementations

				ASSERT_EXTRA_PATCHES= ${PATCHDIR}/extra-patch-assert

				APICHECK_CPPFLAGS= -DLUA_USE_APICHECK

				# EDITNONE currently requires no settings

				matUnsubmitted Not Done Inline Actions To silence what exactly? Do not add inactive code because a third party lint tool gives you warnings. Also, what happens if libedit or libreadline is installed, and one selects this option? mat: To silence what exactly? Do not add inactive code because a third party lint tool gives you…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions portlint, which is prominently mentioned in the porters manual, counts as a third-party tool? Without that line or something logically equivalent, portlint reports: WARN: Makefile: EDITNONE is listed in OPTIONS_DEFINE, but no PORT_OPTIONS:MEDITNONE appears. Obviously that can just be ignored, which I did for a while, but I figured that it cost nothing to suppress the warning. If one selects EDITNONE, then regardless of what is or is not installed, the lua53 binary will not do command-line editing, when running interactively it'll just fgets from stdin. I thought the description of that was clear enough. No dependency on libedit or readline will be generated and no library other than libc and libm will be linked. andrew_tao173.riddles.org.uk: portlint, which is prominently mentioned in the porters manual, counts as a third-party tool?
				matUnsubmitted Not Done Inline Actions Mmm, if the option does nothing then do not add it. And instead of using an OPTIONS_SINGLE, use OPTIONS_RADIO. https://www.freebsd.org/doc/en/books/porters-handbook/makefile-options.html mat: Mmm, if the option does nothing then do not add it. And instead of using an OPTIONS_SINGLE…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions From a user perspective it seemed much clearer to have an explicit option for it (which could have a description). Without it, it's not at all clear that no editing is even an available option. andrew_tao173.riddles.org.uk: From a user perspective it seemed much clearer to have an explicit option for it (which could…
				matUnsubmitted Not Done Inline Actions The reason we have SINGLE (1) and RADIO (0,1) is to handle those case. You can add a few words to `EDITGRP_DESC` to say that having none is ok, or add a pkg-help file to be more verbose. But do not add a non functionnal variable only to please portlint. mat: The reason we have SINGLE (1) and RADIO (0,1) is to handle those case. You can add a few words…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions I'm OK with taking the variable out and just ignoring the warning, but changing the UI appearance just based on the fact that we don't actually need any special option processing to implement EDITNONE seems to me to be putting the cart before the horse. andrew_tao173.riddles.org.uk: I'm OK with taking the variable out and just ignoring the warning, but changing the UI…
				LIBEDIT_DL_USES= libedit
				LIBEDIT_DL_CPPFLAGS= -DLUA_USE_READLINE_DL

				LIBEDIT_USES= libedit
				LIBEDIT_CPPFLAGS= -DLUA_USE_READLINE
				matUnsubmitted Not Done Inline Actions missing tab after `=`. mat: missing tab after `=`.
				LIBEDIT_LIBS= -ledit

				READLINE_USES= readline
				READLINE_CPPFLAGS= -DLUA_USE_READLINE
				READLINE_LIBS= -lreadline

				matUnsubmitted Not Done Inline Actions This is not used anywhere, what is it for? mat: This is not used anywhere, what is it for?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions It's the only way to stop bsd.port.mk from adding -fno-strict-aliasing to CFLAGS. Lua does not require this flag. andrew_tao173.riddles.org.uk: It's the only way to stop bsd.port.mk from adding -fno-strict-aliasing to CFLAGS. Lua does not…
				matUnsubmitted Not Done Inline Actions But is it broken with it? mat: But is it broken with it?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions -fno-strict-aliasing only reduces optimization, so absent compiler bugs it can't "break" anything. However since Lua is an actively maintained piece of code which is tested with modern compilers, for which performance is a factor, I think it best to follow the upstream's selection of compile options in the absence of an overriding reason to do otherwise. andrew_tao173.riddles.org.uk: -fno-strict-aliasing only reduces optimization, so absent compiler bugs it can't "break"…
				# end of option vars

				CFLAGS+= -fPIC

				WITHOUT_NO_STRICT_ALIASING=yes

				MAKE_ARGS+= CC="${CC}" \
				MYCFLAGS="${CPPFLAGS} ${CFLAGS}" \
	MYLDFLAGS="${LDFLAGS}" \			MYLDFLAGS="${LDFLAGS}" \
	MYLIBS="-Wl,-E -L${LOCALBASE}/lib -ledit" \			MYLIBS="${LIBS}" \
	CC="${CC}" \			LUA_T=${LUA_CMD} \
	LUA_T=lua53 \			LUAC_T=${LUAC_CMD} \
	LUAC_T=luac53 \			LUA_A=${LUA_LIB_STATIC} \
	LUA_A=liblua-${LUA_VER}.a \			LUA_SO=${LUA_LIB_SHARED} \
	LUA_SO=liblua-${LUA_VER}.so \			LUA_SONAME=${LUA_LIB_SHARED} \
	LUA_SONAME=liblua-${LUA_VER}.so \			TO_BIN="${LUA_CMD} ${LUAC_CMD}" \
	TO_BIN="lua53 luac53" \			TO_LIB="${LUA_LIB_SHARED} ${LUA_LIB_STATIC}" \
	TO_LIB="liblua-${LUA_VER}.a liblua-${LUA_VER}.so" \
	INSTALL_TOP=${STAGEDIR}${PREFIX} \			INSTALL_TOP=${STAGEDIR}${PREFIX} \
	INSTALL_INC=${STAGEDIR}${PREFIX}/include/lua53 \			INSTALL_INC=${STAGEDIR}${LUA_INCDIR} \
	INSTALL_EXEC="${INSTALL_PROGRAM}"			INSTALL_EXEC="${INSTALL_PROGRAM}"

	# Cope with the lack of support for Lua 5.2 in bsd.lua.mk. These			SUB_FILES= ${LUA_PC_FILE}
	# overrides, which are required below, should be removed once bsd.lua.mk
	# understands this lua version.
	LUA_PREFIX?= ${PREFIX}
	LUA_SUBDIR?= lua${PKGNAMESUFFIX}
	LUA_INCDIR?= ${LUA_PREFIX}/include/${LUA_SUBDIR}
	LUA_LIBDIR?= ${LUA_PREFIX}/lib

	SUB_FILES= lua-${LUA_VER}.pc
	SUB_LIST= version=${PORTVERSION} \			SUB_LIST= version=${PORTVERSION} \
	includedir=${LUA_INCDIR} \			includedir=${LUA_INCDIR} \
	libdir=${LUA_LIBDIR} \			libdir=${LUA_LIBDIR} \
	soname=lua-${LUA_VER}			soname=lua-${LUA_VER}
				matUnsubmitted Done Inline Actions Why? mat: Why?
				russ.haley_gmail.comAuthorUnsubmitted Done Inline Actions I'm not sure I understand the question @mat? I'll assume the question is "Why use variables" and say, I was trying to remove the hard coded 'lua' and 'lua53' strings to make it more consistent and usable for the upcoming 5.4 port. To be more accurate, this is a revision of the 5.4 port Makefile 'backported' to 5.3 russ.haley_gmail.com: I'm not sure I understand the question @mat? I'll assume the question is "Why use variables"…
				andrew_tao173.riddles.org.ukUnsubmitted Done Inline Actions the problem here is that soname= and LUA_LIB_SHARED don't match if PORTNAME is changed. Either both names should be based on PORTNAME or neither should. andrew_tao173.riddles.org.uk: the problem here is that soname= and LUA_LIB_SHARED don't match if PORTNAME is changed. Either…
				matUnsubmitted Not Done Inline Actions Yes, why remove `lua`? This will never change, so, there is no point of having it as a variable. (Well, unless the language is renamed, but I don't see that happening.) mat: Yes, why remove `lua`? This will never change, so, there is no point of having it as a…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions Yes, why remove lua? This will never change, so, there is no point of having it as a variable. (Well, unless the language is renamed, but I don't see that happening.) I suppose the reason is two fold: 1) I'm learning as I go and it seemed like something to clean up and 2) my "OCD" made me cringe when I looked at it. I can change it back if it offends, as I am largely indifferent. russ.haley_gmail.com: > Yes, why remove lua? This will never change, so, there is no point of having it as a variable.
				matUnsubmitted Not Done Inline Actions It would be better to keep `lua` as it was before, using a 11 characters of variable for a 3 letter constant is a bit overboard. mat: It would be better to keep `lua` as it was before, using a 11 characters of variable for a 3…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions I am grateful for you taking the time to review my work. Please let me know what else you wish to see amended. russ.haley_gmail.com: I am grateful for you taking the time to review my work. Please let me know what else you wish…
				andrew_tao173.riddles.org.ukUnsubmitted Done Inline Actions Wrong value for soname= there. LUA_LUB_SHARED is liblua-5.3.so, but soname= needs to be lua-5.3.so without the 'lib' prefix. andrew_tao173.riddles.org.uk: Wrong value for soname= there. LUA_LUB_SHARED is liblua-5.3.so, but soname= needs to be lua-5.3.
				andrew_tao173.riddles.org.ukUnsubmitted Done Inline Actions uh, I mean soname needs to be lua-5.3 without either the 'lib' prefix or the '.so' suffix. andrew_tao173.riddles.org.uk: uh, I mean soname needs to be lua-5.3 without either the 'lib' prefix or the '.so' suffix.

	CFLAGS+= -fPIC
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions Added to the base Makefile russ.haley_gmail.com: Added to the base Makefile

	post-patch:			post-patch:
	@${REINPLACE_CMD} -e 's,rand *(,random(,g' \			@${REINPLACE_CMD} -e "/LUA_ROOT/s,/usr/local,${LUA_PREFIX}," \
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions The code that this patches is not reachable due to the USE_POSIX. http://lua-users.org/lists/lua-l/2017-09/msg00089.html From lmathlib.c #if !defined(l_rand) /* { / #if defined(LUA_USE_POSIX) #define l_rand() random() #define l_srand(x) srandom(x) #define L_RANDMAX 2147483647 / (2^31 - 1), following POSIX / #else #define l_rand() rand() #define l_srand(x) srand(x) #define L_RANDMAX RAND_MAX #endif #endif / } / from luaconf.h #if defined(LUA_USE_LINUX) #define LUA_USE_POSIX #define LUA_USE_DLOPEN / needs an extra library: -ldl / #define LUA_USE_READLINE / needs some extra libraries / #endif russ.haley_gmail.com:* The code that this patches is not reachable due to the USE_POSIX. http://lua-users.
	${WRKSRC}/src/lmathlib.c			${WRKSRC}/src/luaconf.h
	@${REINPLACE_CMD} -e "/LUA_ROOT/s\|/usr/local\|${LUA_PREFIX}\| ; \
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions luaconf.h contains no readline reference and I instead created a patch for lua.c. This makes the code changes in one place (patch files) and the changes required are easily visible (in the patch file). russ.haley_gmail.com: luaconf.h contains no readline reference and I instead created a patch for lua.c. This makes…
	andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions This removal isn't quite right because the point of editing luaconf.h here is not to deal with readline, but rather to fix LUA_ROOT to ensure it matches ${PREFIX}. By default these are both /usr/local, so it's not obvious if this step is missed, but if ${PREFIX} is set to something else it's important that LUA_ROOT in luaconf.h be updated to match. andrew_tao173.riddles.org.uk: This removal isn't quite right because the point of editing luaconf.h here is not to deal with…
	s,readline/,editline/,g ; \
	/history\.h/d" \
	${WRKSRC}/src/luaconf.h ${WRKSRC}/src/lua.c

				post-patch-LIBEDIT-on:
				@${REINPLACE_CMD} -e "s,readline/,editline/,g ; \
				/history\.h/d" ${WRKSRC}/src/lua.c

				post-patch-LIBEDIT_DL-on:
				@${REINPLACE_CMD} \
				-e "/^#def.*LUA_READLINE_LIBPATH/s,/usr/local,${LOCALBASE}," \
				${WRKSRC}/src/lua.c

	post-install:			post-install:
	@${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/liblua-${LUA_VER}.so			${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/${LUA_LIB_SHARED}
	@${MV} ${STAGEDIR}${PREFIX}/man/man1/lua.1 \			${MV} ${STAGEDIR}${PREFIX}/man/man1/lua.1 \
	${STAGEDIR}${PREFIX}/man/man1/lua53.1			${STAGEDIR}${PREFIX}/man/man1/${LUA_CMD}.1
	@${MV} ${STAGEDIR}${PREFIX}/man/man1/luac.1 \			${MV} ${STAGEDIR}${PREFIX}/man/man1/luac.1 \
	${STAGEDIR}${PREFIX}/man/man1/luac53.1			${STAGEDIR}${PREFIX}/man/man1/${LUAC_CMD}.1
	${INSTALL_DATA} ${WRKDIR}/lua-${LUA_VER}.pc \			${INSTALL_DATA} ${WRKDIR}/${LUA_PC_FILE} \
	${STAGEDIR}${PREFIX}/libdata/pkgconfig			${STAGEDIR}${PREFIX}/libdata/pkgconfig

				post-install-DOCS-on:
				${MKDIR} ${STAGEDIR}${DOCSDIR}
				(cd ${BUILD_WRKDOC} && \
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions make check-orphans doesn't like this, I'll fix in the next patch andrew_tao173.riddles.org.uk: make check-orphans doesn't like this, I'll fix in the next patch
				${COPYTREE_SHARE} . ${STAGEDIR}${DOCSDIR} '-not -name *\.1')

	.include <bsd.port.mk>			.include <bsd.port.mk>
				matUnsubmitted Not Done Inline Actions Any reason not to simply COPYTREE_SHARE all that directory in DOCSDIR? mat: Any reason not to simply COPYTREE_SHARE all that directory in DOCSDIR?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions BUILD_WRKDOC also has the lua.1 and luac.1 files in it that are installed as manpages rather than docs. In a previous version I had it copying those files anyway, but just not including them in PORTDOCS so they didn't get installed. But check-plist objects to that. andrew_tao173.riddles.org.uk: BUILD_WRKDOC also has the lua.1 and luac.1 files in it that are installed as manpages rather…
				matUnsubmitted Not Done Inline Actions This does not really say why you cannot use COPYTREE_SHARE. cd ${BUILD_WRKDOC} && ${COPYTREE_SHARE} . ${STAGEDIR}${DOCSDIR} '-not -name ".1"' mat:* This does not really say why you cannot use COPYTREE_SHARE. ``` cd ${BUILD_WRKDOC} &&…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions I just tried that, it doesn't work as given (it copies lua.1 and luac.1 anyway). Looks like COPYTREE_SHARE doesn't actually work with wildcards in the third arg, due to issues of shell quoting. "-not -name lua.1 -not -name luac.1" works, but now it's starting to look like not so much of an improvement over the previous form. andrew_tao173.riddles.org.uk: I just tried that, it doesn't work as given (it copies lua.1 and luac.1 anyway). Looks like…
				matUnsubmitted Not Done Inline Actions Mmmm, wildcards are supported, maybe you need to reverse the `"` and `'` order, like `"-not -name '.1'"`. Or write it as `'-not -name \.1'` mat: Mmmm, wildcards are supported, maybe you need to reverse the `"` and `'` order, like `"-not…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions None of those work. andrew_tao173.riddles.org.uk: None of those work.
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions Apparently the magic incantation is to escape with \ some part of the filename pattern other than the wildcard characters; this works because of an odd interaction between shell and find(1) related to the fact that find(1) does an extra layer of unescaping for itself, while the escape character prevents the pattern from matching any files in the shell (assuming there are no files with \ in the names). i.e. '-not -name \.1' works this is ... not at all well documented, while there is an example in bsd.port.mk it completely fails to point out the important aspect, and the ports handbook doesn't mention it at all. It also seems rather fragile to me. andrew_tao173.riddles.org.uk:* Apparently the magic incantation is to escape with \ some part of the filename pattern //other…
				matUnsubmitted Not Done Inline Actions Damn, I knew there was something strange happening. One day I'll try to figure out what really happens and why, and document it properly. mat: Damn, I knew there was something strange happening. One day I'll try to figure out what really…

View Options

files/lua-5.3.pc.in

	# Created by: GreenDog <fiziologus@gmail.com>			# Created by: GreenDog <fiziologus@gmail.com>
	# $FreeBSD$			# $FreeBSD$
				matUnsubmitted Done Inline Actions The credit will alreay be present in the commit message, please do not add more in the Makefile. mat: The credit will alreay be present in the commit message, please do not add more in the Makefile.
				matUnsubmitted Not Done Inline Actions Please, DO NOT CHANGE the header. mat: Please, DO NOT CHANGE the header.

	PORTNAME= lua			PORTNAME= lua
	PORTVERSION= 5.3.4			DISTVERSION= 5.3.5
	PORTREVISION= 2
	CATEGORIES= lang			CATEGORIES= lang
				matUnsubmitted Done Inline Actions This should be resetted when updating the version. mat: This should be resetted when updating the version.
				matUnsubmitted Not Done Inline Actions This was not done. Please remove PORTREVISION, or set it to 0. mat: This was not done. Please remove PORTREVISION, or set it to 0.
	MASTER_SITES= http://www.lua.org/ftp/			MASTER_SITES= https://www.lua.org/ftp/
	PKGNAMESUFFIX= 53			PKGNAMESUFFIX= 53

	MAINTAINER= russ.haley@gmail.com			MAINTAINER= russ.haley@gmail.com
	COMMENT= Small, compilable scripting language providing easy access to C code			COMMENT= Powerful, efficient, lightweight, embeddable scripting language
				matUnsubmitted Not Done Inline Actions Most scripting languages are embeddables, is lua not compilable any more ? mat: Most scripting languages are embeddables, is lua not compilable any more ?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions What does "compilable" mean? There is a bytecode compiler, which is useful for syntax checking and faster code loading, but has no effect whatsoever on execution speed (since code loaded as text is compiled to the same bytecode before execution anyway). Bytecode compilation is also of limited usefulness since the bytecode is version and platform dependent. I think most people would interpret "compilable" as implying faster execution, or execution of machine instructions rather than interpreted code, which is not the case here. andrew_tao173.riddles.org.uk: What does "compilable" mean? There is a bytecode compiler, which is useful for syntax checking…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions @andrew_tao173.riddles.org.uk is correct, that's why I changed it. I finally decided on the current phrasing because 'compilable' is not in the official description and I was too cowardly to change it entirely. I will change it to the official description on Lua.org: Lua is a powerful, efficient, lightweight, embeddable scripting language. russ.haley_gmail.com: @andrew_tao173.riddles.org.uk is correct, that's why I changed it. I finally decided on the…

	LICENSE= MIT			LICENSE= MIT

	USES= libedit
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions This is simply handled in the code patch to lua.c. As far as I can tell, editline is a standard package in FreeBSD 4.4? https://www.freebsd.org/cgi/man.cgi?editline russ.haley_gmail.com: This is simply handled in the code patch to lua.c. As far as I can tell, editline is a standard…
	LUA_VER= 5.3			LUA_VER= 5.3
	USE_LDCONFIG= yes			USE_LDCONFIG= yes

	# Overriding __MAKE_CONF makes sure that we don't re-parse			# Overriding __MAKE_CONF makes sure that we don't re-parse
	# /etc/make.conf during do-build, which would jeopardize the build			# /etc/make.conf during do-build, which would jeopardize the build
	# if, for instance, the user set CFLAGS=mumble			# if, for instance, the user set CFLAGS=mumble
	# NOTE: /etc/make.conf is read BEFORE Makefile, so we already			# NOTE: /etc/make.conf is read BEFORE Makefile, so we already
	# have its settings when we get here.			# have its settings when we get here.
	# See http://wiki.freebsd.org/MatthiasAndree/LuaLessonsLearnt			# See http://wiki.freebsd.org/MatthiasAndree/LuaLessonsLearnt
	MAKE_ARGS= __MAKE_CONF=${NONEXISTENT}			MAKE_ARGS= __MAKE_CONF=${NONEXISTENT}
	# liblua.so requires libm, so make sure it has an explicit dependency
	# so that applications need not second-guess lua's dependencies.
	CPPFLAGS+= -I${LOCALBASE}/include
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions Unnecessary if the standard editline package is used. https://www.freebsd.org/cgi/man.cgi?editline russ.haley_gmail.com: Unnecessary if the standard editline package is used. https://www.freebsd.org/cgi/man.cgi?
	LDFLAGS+= -lm -pthread
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions As per an email with Jan Beich: -pthread was inherited from https://svnweb.freebsd.org/changeset/ports/324286 which was probably fixed by https://svnweb.freebsd.org/changeset/base/276630 How do I test this? russ.haley_gmail.com: As per an email with Jan Beich: -pthread was inherited from https://svnweb.freebsd.
	BUILD_WRKSRC= ${WRKSRC}/src			BUILD_WRKSRC= ${WRKSRC}/src
	MAKE_ARGS+= MYCFLAGS="${CFLAGS} ${CPPFLAGS} -DLUA_USE_LINUX" \
				# Source, destination, and filenames to copy for the DOCS option
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions These variable have been added to standardize with lua.mk and hopefully other packages if I have time. russ.haley_gmail.com: These variable have been added to standardize with lua.mk and hopefully other packages if I…
				# (automatically added to pkg-plist if DOCS is set)
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions No. Linking lua53 with pthread might be defensible (though I personally don't think it is), but linking liblua.so against pthread is not on. andrew_tao173.riddles.org.uk: No. Linking lua53 with pthread might be defensible (though I personally don't think it is), but…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions I was unable to find a definitive test to indicate if Lua requires linking pthread. As I had seen mention of it in luaossl, I built Lua with and without linking to pthread and created a public key. In both tests I "required" luaossl and successfully created a public key using 1.0.2k. I emailed the luaossl maintainer (actually, I emailed the author wahern who directed me to the current maintainer duarnimator). Duarnimator indicated that openssl pre 1.1.0 needs pthreads and he pointed me to the sources: https://github.com/wahern/luaossl/blob/357a7f6da9e6ae442b3c3b9e43396b3cf2e1a91d/src/openssl.c#L11127 At this juncture I have assumed my tests were faulty and added -pthread back in. If you can indicate some tests I could try on any package that would prove this one way or the other (or confirm that my original test was valid) I would like to remove it entirely. To keep all the information together, here is the previous comment on that topic. As per an email with Jan Beich: -pthread was inherited from https://svnweb.freebsd.org/changeset/ports/324286 which was probably fixed by https://svnweb.freebsd.org/changeset/base/276630 russ.haley_gmail.com: I was unable to find a definitive test to indicate if Lua requires linking pthread. As I had…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions For reference on the luaossl requirement, see http://25thandclement.com/~william/projects/luaossl.pdf section 1.2.3 russ.haley_gmail.com: For reference on the luaossl requirement, see http://25thandclement.
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions I think you're missing the point about pthreads. Lua itself has no interaction with threads at all (unless you explicitly modify it to lock the interpreter, which the port doesn't do). Therefore, it's inappropriate for lublua.so (which will never call any pthread function) to force libthr into the process. (Remember that liblua.so might be being loaded because of a reference from a dlopen'd module - this is actually not uncommon) The bug fix you reference (base/276630) is specifically about loading libthr via dlopen, so without that fix, linking lublua.so against libthr actually makes things worse, since any dynamic load of a lua interpreter would trigger the bug even if no pthread-using module was ever used from Lua. If some extension that you want to load from Lua needs to pull in pthreads, then there are two possibilities: either it's enough for the extension .so to reference libthr to pull it in, or if there's an unfixed bug of the same kind as base/276630, then it's not enough for liblua.so to reference libthr, but rather the main executable must do so. andrew_tao173.riddles.org.uk: I think you're missing the point about pthreads. Lua itself has no interaction with threads at…
				russ.haley_gmail.comAuthorUnsubmitted Done Inline Actions I'm struggling to understand if/why libmath is required for the shared object at all but I don't currently have any code that uses liblua.so. I'll postulate that we should do a second exp run with -lm removed to see if anything breaks? russ.haley_gmail.com: I'm struggling to understand if/why libmath is required for the shared object at all but I…
				andrew_tao173.riddles.org.ukUnsubmitted Done Inline Actions Lua calls functions from libm. If you try and load liblua.so into a main program that doesn't export the libm functions, it'll fail unless liblua.so pulls in libm itself. So it's always correct for liblua.so to be linked against libm. andrew_tao173.riddles.org.uk: Lua calls functions from libm. If you try and load liblua.so into a main program that doesn't…
				# We override DOCSDIR to get a per-version subdir.
				# We put the docs for Lua proper in a lua/ subdir of the version subdir
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions Ken Sasaki (lua-stdlib-normalize / lua-stdlib-debug maintainer) suggested in a bugzilla thread that perhaps modules should be installing docs under doc/lua5N/port-name, so perhaps we should consider installing the docs for Lua proper under doc/lua5N/lua to allow that without creating a mess? andrew_tao173.riddles.org.uk: Ken Sasaki (lua-stdlib-normalize / lua-stdlib-debug maintainer) suggested in a bugzilla thread…
				# so that ports for Lua modules can use the version subdir too without
				# making a mess.
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions This is the standard make target for freebsd in lua. russ.haley_gmail.com: This is the standard make target for freebsd in lua.
				DOCSDIR= ${PREFIX}/share/doc/lua${PKGNAMESUFFIX}/lua
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions I would like to remove the renaming of the lua build output and postpone it until the install step, or a preinstall rename. Input appreciated. russ.haley_gmail.com: I would like to remove the renaming of the lua build output and postpone it until the install…
				PORTDOCS= *
				BUILD_WRKDOC= ${WRKSRC}/doc

				LUA_PREFIX= ${PREFIX}

				# 2018-03-17: AG - These should match lua.mk, but we can't include that here
				LUA_CMD= lua${PKGNAMESUFFIX}
				LUAC_CMD= luac${PKGNAMESUFFIX}
				LUA_INCDIR= ${LUA_PREFIX}/include/lua${PKGNAMESUFFIX}
				LUA_LIBDIR= ${LUA_PREFIX}/lib

				LUA_LIB_STATIC= liblua-${LUA_VER}.a
				LUA_LIB_SHARED= liblua-${LUA_VER}.so
				LUA_PC_FILE= lua-${LUA_VER}.pc

				# using the "bsd" target rather than "freebsd" saves patching out the
				# assumption of using base libedit in order to make it configurable. "bsd"
				# is "generic" plus the POSIX and DLOPEN options, plus -Wl,-E at link time;
				# it doesn't set CC either, which makes it easier for us to control that too.
				ALL_TARGET=bsd
				matUnsubmitted Not Done Inline Actions Why `+=`? mat: Why `+=`?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions I probably cargo-culted that in from some example when adding options to the lua54 port, and russ got it from me. No reason not to change it to just = andrew_tao173.riddles.org.uk: I probably cargo-culted that in from some example when adding options to the lua54 port, and…

				# Options

				OPTIONS_DEFAULT=LIBEDIT_DL DOCS

				OPTIONS_GROUP= DOCSGRP DEBUGGRP
				OPTIONS_SINGLE= EDITGRP

				OPTIONS_GROUP_DOCSGRP= DOCS
				OPTIONS_GROUP_DEBUGGRP= ASSERT APICHECK

				OPTIONS_SINGLE_EDITGRP= EDITNONE LIBEDIT_DL LIBEDIT READLINE

				# Option descriptions

				DEBUGGRP_DESC= Debugging options
				ASSERT_DESC= Enable interpreter assertions
				APICHECK_DESC= Enable API checks

				DOCSGRP_DESC= Documentation options
				DOCS_DESC= Install language and API reference (HTML, ~400kB)
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions Well, this sucks: qa.sh doesn't allow this and demands that you use the port instead. The problem with using the port libedit is that it links against the wrong libncurses, leading to compatibility problems when you try and use the lua curses module. Same problem exists with readline. I was hoping to avoid that problem this way, but if linking to base libedit isn't an option then we're going to need a much more involved solution, such as installing an extra lua binary without editing support. andrew_tao173.riddles.org.uk: Well, this sucks: qa.sh doesn't allow this and demands that you use the port instead. The…

				EDITGRP_DESC= Interactive command-line editing
				matUnsubmitted Not Done Inline Actions extra white space before `=`. mat: extra white space before `=`.
				EDITNONE_DESC= No command-line editing
				LIBEDIT_DL_DESC=Use dynamically loaded libedit (recommended)
				matUnsubmitted Not Done Inline Actions Please restore the header. mat: Please restore the header.
				LIBEDIT_DESC= Use libedit (breaks lcurses)
				READLINE_DESC= Use GNU Readline (breaks lcurses)

				# Option implementations

				ASSERT_EXTRA_PATCHES= ${PATCHDIR}/extra-patch-assert

				APICHECK_CPPFLAGS= -DLUA_USE_APICHECK

				# EDITNONE currently requires no settings

				matUnsubmitted Not Done Inline Actions To silence what exactly? Do not add inactive code because a third party lint tool gives you warnings. Also, what happens if libedit or libreadline is installed, and one selects this option? mat: To silence what exactly? Do not add inactive code because a third party lint tool gives you…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions portlint, which is prominently mentioned in the porters manual, counts as a third-party tool? Without that line or something logically equivalent, portlint reports: WARN: Makefile: EDITNONE is listed in OPTIONS_DEFINE, but no PORT_OPTIONS:MEDITNONE appears. Obviously that can just be ignored, which I did for a while, but I figured that it cost nothing to suppress the warning. If one selects EDITNONE, then regardless of what is or is not installed, the lua53 binary will not do command-line editing, when running interactively it'll just fgets from stdin. I thought the description of that was clear enough. No dependency on libedit or readline will be generated and no library other than libc and libm will be linked. andrew_tao173.riddles.org.uk: portlint, which is prominently mentioned in the porters manual, counts as a third-party tool?
				matUnsubmitted Not Done Inline Actions Mmm, if the option does nothing then do not add it. And instead of using an OPTIONS_SINGLE, use OPTIONS_RADIO. https://www.freebsd.org/doc/en/books/porters-handbook/makefile-options.html mat: Mmm, if the option does nothing then do not add it. And instead of using an OPTIONS_SINGLE…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions From a user perspective it seemed much clearer to have an explicit option for it (which could have a description). Without it, it's not at all clear that no editing is even an available option. andrew_tao173.riddles.org.uk: From a user perspective it seemed much clearer to have an explicit option for it (which could…
				matUnsubmitted Not Done Inline Actions The reason we have SINGLE (1) and RADIO (0,1) is to handle those case. You can add a few words to `EDITGRP_DESC` to say that having none is ok, or add a pkg-help file to be more verbose. But do not add a non functionnal variable only to please portlint. mat: The reason we have SINGLE (1) and RADIO (0,1) is to handle those case. You can add a few words…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions I'm OK with taking the variable out and just ignoring the warning, but changing the UI appearance just based on the fact that we don't actually need any special option processing to implement EDITNONE seems to me to be putting the cart before the horse. andrew_tao173.riddles.org.uk: I'm OK with taking the variable out and just ignoring the warning, but changing the UI…
				LIBEDIT_DL_USES= libedit
				LIBEDIT_DL_CPPFLAGS= -DLUA_USE_READLINE_DL

				LIBEDIT_USES= libedit
				LIBEDIT_CPPFLAGS= -DLUA_USE_READLINE
				matUnsubmitted Not Done Inline Actions missing tab after `=`. mat: missing tab after `=`.
				LIBEDIT_LIBS= -ledit

				READLINE_USES= readline
				READLINE_CPPFLAGS= -DLUA_USE_READLINE
				READLINE_LIBS= -lreadline

				matUnsubmitted Not Done Inline Actions This is not used anywhere, what is it for? mat: This is not used anywhere, what is it for?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions It's the only way to stop bsd.port.mk from adding -fno-strict-aliasing to CFLAGS. Lua does not require this flag. andrew_tao173.riddles.org.uk: It's the only way to stop bsd.port.mk from adding -fno-strict-aliasing to CFLAGS. Lua does not…
				matUnsubmitted Not Done Inline Actions But is it broken with it? mat: But is it broken with it?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions -fno-strict-aliasing only reduces optimization, so absent compiler bugs it can't "break" anything. However since Lua is an actively maintained piece of code which is tested with modern compilers, for which performance is a factor, I think it best to follow the upstream's selection of compile options in the absence of an overriding reason to do otherwise. andrew_tao173.riddles.org.uk: -fno-strict-aliasing only reduces optimization, so absent compiler bugs it can't "break"…
				# end of option vars

				CFLAGS+= -fPIC

				WITHOUT_NO_STRICT_ALIASING=yes

				MAKE_ARGS+= CC="${CC}" \
				MYCFLAGS="${CPPFLAGS} ${CFLAGS}" \
	MYLDFLAGS="${LDFLAGS}" \			MYLDFLAGS="${LDFLAGS}" \
	MYLIBS="-Wl,-E -L${LOCALBASE}/lib -ledit" \			MYLIBS="${LIBS}" \
	CC="${CC}" \			LUA_T=${LUA_CMD} \
	LUA_T=lua53 \			LUAC_T=${LUAC_CMD} \
	LUAC_T=luac53 \			LUA_A=${LUA_LIB_STATIC} \
	LUA_A=liblua-${LUA_VER}.a \			LUA_SO=${LUA_LIB_SHARED} \
	LUA_SO=liblua-${LUA_VER}.so \			LUA_SONAME=${LUA_LIB_SHARED} \
	LUA_SONAME=liblua-${LUA_VER}.so \			TO_BIN="${LUA_CMD} ${LUAC_CMD}" \
	TO_BIN="lua53 luac53" \			TO_LIB="${LUA_LIB_SHARED} ${LUA_LIB_STATIC}" \
	TO_LIB="liblua-${LUA_VER}.a liblua-${LUA_VER}.so" \
	INSTALL_TOP=${STAGEDIR}${PREFIX} \			INSTALL_TOP=${STAGEDIR}${PREFIX} \
	INSTALL_INC=${STAGEDIR}${PREFIX}/include/lua53 \			INSTALL_INC=${STAGEDIR}${LUA_INCDIR} \
	INSTALL_EXEC="${INSTALL_PROGRAM}"			INSTALL_EXEC="${INSTALL_PROGRAM}"

	# Cope with the lack of support for Lua 5.2 in bsd.lua.mk. These			SUB_FILES= ${LUA_PC_FILE}
	# overrides, which are required below, should be removed once bsd.lua.mk
	# understands this lua version.
	LUA_PREFIX?= ${PREFIX}
	LUA_SUBDIR?= lua${PKGNAMESUFFIX}
	LUA_INCDIR?= ${LUA_PREFIX}/include/${LUA_SUBDIR}
	LUA_LIBDIR?= ${LUA_PREFIX}/lib

	SUB_FILES= lua-${LUA_VER}.pc
	SUB_LIST= version=${PORTVERSION} \			SUB_LIST= version=${PORTVERSION} \
	includedir=${LUA_INCDIR} \			includedir=${LUA_INCDIR} \
	libdir=${LUA_LIBDIR} \			libdir=${LUA_LIBDIR} \
	soname=lua-${LUA_VER}			soname=lua-${LUA_VER}
				matUnsubmitted Done Inline Actions Why? mat: Why?
				russ.haley_gmail.comAuthorUnsubmitted Done Inline Actions I'm not sure I understand the question @mat? I'll assume the question is "Why use variables" and say, I was trying to remove the hard coded 'lua' and 'lua53' strings to make it more consistent and usable for the upcoming 5.4 port. To be more accurate, this is a revision of the 5.4 port Makefile 'backported' to 5.3 russ.haley_gmail.com: I'm not sure I understand the question @mat? I'll assume the question is "Why use variables"…
				andrew_tao173.riddles.org.ukUnsubmitted Done Inline Actions the problem here is that soname= and LUA_LIB_SHARED don't match if PORTNAME is changed. Either both names should be based on PORTNAME or neither should. andrew_tao173.riddles.org.uk: the problem here is that soname= and LUA_LIB_SHARED don't match if PORTNAME is changed. Either…
				matUnsubmitted Not Done Inline Actions Yes, why remove `lua`? This will never change, so, there is no point of having it as a variable. (Well, unless the language is renamed, but I don't see that happening.) mat: Yes, why remove `lua`? This will never change, so, there is no point of having it as a…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions Yes, why remove lua? This will never change, so, there is no point of having it as a variable. (Well, unless the language is renamed, but I don't see that happening.) I suppose the reason is two fold: 1) I'm learning as I go and it seemed like something to clean up and 2) my "OCD" made me cringe when I looked at it. I can change it back if it offends, as I am largely indifferent. russ.haley_gmail.com: > Yes, why remove lua? This will never change, so, there is no point of having it as a variable.
				matUnsubmitted Not Done Inline Actions It would be better to keep `lua` as it was before, using a 11 characters of variable for a 3 letter constant is a bit overboard. mat: It would be better to keep `lua` as it was before, using a 11 characters of variable for a 3…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions I am grateful for you taking the time to review my work. Please let me know what else you wish to see amended. russ.haley_gmail.com: I am grateful for you taking the time to review my work. Please let me know what else you wish…
				andrew_tao173.riddles.org.ukUnsubmitted Done Inline Actions Wrong value for soname= there. LUA_LUB_SHARED is liblua-5.3.so, but soname= needs to be lua-5.3.so without the 'lib' prefix. andrew_tao173.riddles.org.uk: Wrong value for soname= there. LUA_LUB_SHARED is liblua-5.3.so, but soname= needs to be lua-5.3.
				andrew_tao173.riddles.org.ukUnsubmitted Done Inline Actions uh, I mean soname needs to be lua-5.3 without either the 'lib' prefix or the '.so' suffix. andrew_tao173.riddles.org.uk: uh, I mean soname needs to be lua-5.3 without either the 'lib' prefix or the '.so' suffix.

	CFLAGS+= -fPIC
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions Added to the base Makefile russ.haley_gmail.com: Added to the base Makefile

	post-patch:			post-patch:
	@${REINPLACE_CMD} -e 's,rand *(,random(,g' \			@${REINPLACE_CMD} -e "/LUA_ROOT/s,/usr/local,${LUA_PREFIX}," \
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions The code that this patches is not reachable due to the USE_POSIX. http://lua-users.org/lists/lua-l/2017-09/msg00089.html From lmathlib.c #if !defined(l_rand) /* { / #if defined(LUA_USE_POSIX) #define l_rand() random() #define l_srand(x) srandom(x) #define L_RANDMAX 2147483647 / (2^31 - 1), following POSIX / #else #define l_rand() rand() #define l_srand(x) srand(x) #define L_RANDMAX RAND_MAX #endif #endif / } / from luaconf.h #if defined(LUA_USE_LINUX) #define LUA_USE_POSIX #define LUA_USE_DLOPEN / needs an extra library: -ldl / #define LUA_USE_READLINE / needs some extra libraries / #endif russ.haley_gmail.com:* The code that this patches is not reachable due to the USE_POSIX. http://lua-users.
	${WRKSRC}/src/lmathlib.c			${WRKSRC}/src/luaconf.h
	@${REINPLACE_CMD} -e "/LUA_ROOT/s\|/usr/local\|${LUA_PREFIX}\| ; \
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions luaconf.h contains no readline reference and I instead created a patch for lua.c. This makes the code changes in one place (patch files) and the changes required are easily visible (in the patch file). russ.haley_gmail.com: luaconf.h contains no readline reference and I instead created a patch for lua.c. This makes…
	andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions This removal isn't quite right because the point of editing luaconf.h here is not to deal with readline, but rather to fix LUA_ROOT to ensure it matches ${PREFIX}. By default these are both /usr/local, so it's not obvious if this step is missed, but if ${PREFIX} is set to something else it's important that LUA_ROOT in luaconf.h be updated to match. andrew_tao173.riddles.org.uk: This removal isn't quite right because the point of editing luaconf.h here is not to deal with…
	s,readline/,editline/,g ; \
	/history\.h/d" \
	${WRKSRC}/src/luaconf.h ${WRKSRC}/src/lua.c

				post-patch-LIBEDIT-on:
				@${REINPLACE_CMD} -e "s,readline/,editline/,g ; \
				/history\.h/d" ${WRKSRC}/src/lua.c

				post-patch-LIBEDIT_DL-on:
				@${REINPLACE_CMD} \
				-e "/^#def.*LUA_READLINE_LIBPATH/s,/usr/local,${LOCALBASE}," \
				${WRKSRC}/src/lua.c

	post-install:			post-install:
	@${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/liblua-${LUA_VER}.so			${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/${LUA_LIB_SHARED}
	@${MV} ${STAGEDIR}${PREFIX}/man/man1/lua.1 \			${MV} ${STAGEDIR}${PREFIX}/man/man1/lua.1 \
	${STAGEDIR}${PREFIX}/man/man1/lua53.1			${STAGEDIR}${PREFIX}/man/man1/${LUA_CMD}.1
	@${MV} ${STAGEDIR}${PREFIX}/man/man1/luac.1 \			${MV} ${STAGEDIR}${PREFIX}/man/man1/luac.1 \
	${STAGEDIR}${PREFIX}/man/man1/luac53.1			${STAGEDIR}${PREFIX}/man/man1/${LUAC_CMD}.1
	${INSTALL_DATA} ${WRKDIR}/lua-${LUA_VER}.pc \			${INSTALL_DATA} ${WRKDIR}/${LUA_PC_FILE} \
	${STAGEDIR}${PREFIX}/libdata/pkgconfig			${STAGEDIR}${PREFIX}/libdata/pkgconfig

				post-install-DOCS-on:
				${MKDIR} ${STAGEDIR}${DOCSDIR}
				(cd ${BUILD_WRKDOC} && \
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions make check-orphans doesn't like this, I'll fix in the next patch andrew_tao173.riddles.org.uk: make check-orphans doesn't like this, I'll fix in the next patch
				${COPYTREE_SHARE} . ${STAGEDIR}${DOCSDIR} '-not -name *\.1')

	.include <bsd.port.mk>			.include <bsd.port.mk>
				matUnsubmitted Not Done Inline Actions Any reason not to simply COPYTREE_SHARE all that directory in DOCSDIR? mat: Any reason not to simply COPYTREE_SHARE all that directory in DOCSDIR?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions BUILD_WRKDOC also has the lua.1 and luac.1 files in it that are installed as manpages rather than docs. In a previous version I had it copying those files anyway, but just not including them in PORTDOCS so they didn't get installed. But check-plist objects to that. andrew_tao173.riddles.org.uk: BUILD_WRKDOC also has the lua.1 and luac.1 files in it that are installed as manpages rather…
				matUnsubmitted Not Done Inline Actions This does not really say why you cannot use COPYTREE_SHARE. cd ${BUILD_WRKDOC} && ${COPYTREE_SHARE} . ${STAGEDIR}${DOCSDIR} '-not -name ".1"' mat:* This does not really say why you cannot use COPYTREE_SHARE. ``` cd ${BUILD_WRKDOC} &&…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions I just tried that, it doesn't work as given (it copies lua.1 and luac.1 anyway). Looks like COPYTREE_SHARE doesn't actually work with wildcards in the third arg, due to issues of shell quoting. "-not -name lua.1 -not -name luac.1" works, but now it's starting to look like not so much of an improvement over the previous form. andrew_tao173.riddles.org.uk: I just tried that, it doesn't work as given (it copies lua.1 and luac.1 anyway). Looks like…
				matUnsubmitted Not Done Inline Actions Mmmm, wildcards are supported, maybe you need to reverse the `"` and `'` order, like `"-not -name '.1'"`. Or write it as `'-not -name \.1'` mat: Mmmm, wildcards are supported, maybe you need to reverse the `"` and `'` order, like `"-not…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions None of those work. andrew_tao173.riddles.org.uk: None of those work.
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions Apparently the magic incantation is to escape with \ some part of the filename pattern other than the wildcard characters; this works because of an odd interaction between shell and find(1) related to the fact that find(1) does an extra layer of unescaping for itself, while the escape character prevents the pattern from matching any files in the shell (assuming there are no files with \ in the names). i.e. '-not -name \.1' works this is ... not at all well documented, while there is an example in bsd.port.mk it completely fails to point out the important aspect, and the ports handbook doesn't mention it at all. It also seems rather fragile to me. andrew_tao173.riddles.org.uk:* Apparently the magic incantation is to escape with \ some part of the filename pattern //other…
				matUnsubmitted Not Done Inline Actions Damn, I knew there was something strange happening. One day I'll try to figure out what really happens and why, and document it properly. mat: Damn, I knew there was something strange happening. One day I'll try to figure out what really…

View Options

files/lua-5.4.pc.in

	# Created by: GreenDog <fiziologus@gmail.com>			# Created by: GreenDog <fiziologus@gmail.com>
	# $FreeBSD$			# $FreeBSD$
				matUnsubmitted Done Inline Actions The credit will alreay be present in the commit message, please do not add more in the Makefile. mat: The credit will alreay be present in the commit message, please do not add more in the Makefile.
				matUnsubmitted Not Done Inline Actions Please, DO NOT CHANGE the header. mat: Please, DO NOT CHANGE the header.

	PORTNAME= lua			PORTNAME= lua
	PORTVERSION= 5.3.4			DISTVERSION= 5.3.5
	PORTREVISION= 2
	CATEGORIES= lang			CATEGORIES= lang
				matUnsubmitted Done Inline Actions This should be resetted when updating the version. mat: This should be resetted when updating the version.
				matUnsubmitted Not Done Inline Actions This was not done. Please remove PORTREVISION, or set it to 0. mat: This was not done. Please remove PORTREVISION, or set it to 0.
	MASTER_SITES= http://www.lua.org/ftp/			MASTER_SITES= https://www.lua.org/ftp/
	PKGNAMESUFFIX= 53			PKGNAMESUFFIX= 53

	MAINTAINER= russ.haley@gmail.com			MAINTAINER= russ.haley@gmail.com
	COMMENT= Small, compilable scripting language providing easy access to C code			COMMENT= Powerful, efficient, lightweight, embeddable scripting language
				matUnsubmitted Not Done Inline Actions Most scripting languages are embeddables, is lua not compilable any more ? mat: Most scripting languages are embeddables, is lua not compilable any more ?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions What does "compilable" mean? There is a bytecode compiler, which is useful for syntax checking and faster code loading, but has no effect whatsoever on execution speed (since code loaded as text is compiled to the same bytecode before execution anyway). Bytecode compilation is also of limited usefulness since the bytecode is version and platform dependent. I think most people would interpret "compilable" as implying faster execution, or execution of machine instructions rather than interpreted code, which is not the case here. andrew_tao173.riddles.org.uk: What does "compilable" mean? There is a bytecode compiler, which is useful for syntax checking…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions @andrew_tao173.riddles.org.uk is correct, that's why I changed it. I finally decided on the current phrasing because 'compilable' is not in the official description and I was too cowardly to change it entirely. I will change it to the official description on Lua.org: Lua is a powerful, efficient, lightweight, embeddable scripting language. russ.haley_gmail.com: @andrew_tao173.riddles.org.uk is correct, that's why I changed it. I finally decided on the…

	LICENSE= MIT			LICENSE= MIT

	USES= libedit
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions This is simply handled in the code patch to lua.c. As far as I can tell, editline is a standard package in FreeBSD 4.4? https://www.freebsd.org/cgi/man.cgi?editline russ.haley_gmail.com: This is simply handled in the code patch to lua.c. As far as I can tell, editline is a standard…
	LUA_VER= 5.3			LUA_VER= 5.3
	USE_LDCONFIG= yes			USE_LDCONFIG= yes

	# Overriding __MAKE_CONF makes sure that we don't re-parse			# Overriding __MAKE_CONF makes sure that we don't re-parse
	# /etc/make.conf during do-build, which would jeopardize the build			# /etc/make.conf during do-build, which would jeopardize the build
	# if, for instance, the user set CFLAGS=mumble			# if, for instance, the user set CFLAGS=mumble
	# NOTE: /etc/make.conf is read BEFORE Makefile, so we already			# NOTE: /etc/make.conf is read BEFORE Makefile, so we already
	# have its settings when we get here.			# have its settings when we get here.
	# See http://wiki.freebsd.org/MatthiasAndree/LuaLessonsLearnt			# See http://wiki.freebsd.org/MatthiasAndree/LuaLessonsLearnt
	MAKE_ARGS= __MAKE_CONF=${NONEXISTENT}			MAKE_ARGS= __MAKE_CONF=${NONEXISTENT}
	# liblua.so requires libm, so make sure it has an explicit dependency
	# so that applications need not second-guess lua's dependencies.
	CPPFLAGS+= -I${LOCALBASE}/include
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions Unnecessary if the standard editline package is used. https://www.freebsd.org/cgi/man.cgi?editline russ.haley_gmail.com: Unnecessary if the standard editline package is used. https://www.freebsd.org/cgi/man.cgi?
	LDFLAGS+= -lm -pthread
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions As per an email with Jan Beich: -pthread was inherited from https://svnweb.freebsd.org/changeset/ports/324286 which was probably fixed by https://svnweb.freebsd.org/changeset/base/276630 How do I test this? russ.haley_gmail.com: As per an email with Jan Beich: -pthread was inherited from https://svnweb.freebsd.
	BUILD_WRKSRC= ${WRKSRC}/src			BUILD_WRKSRC= ${WRKSRC}/src
	MAKE_ARGS+= MYCFLAGS="${CFLAGS} ${CPPFLAGS} -DLUA_USE_LINUX" \
				# Source, destination, and filenames to copy for the DOCS option
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions These variable have been added to standardize with lua.mk and hopefully other packages if I have time. russ.haley_gmail.com: These variable have been added to standardize with lua.mk and hopefully other packages if I…
				# (automatically added to pkg-plist if DOCS is set)
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions No. Linking lua53 with pthread might be defensible (though I personally don't think it is), but linking liblua.so against pthread is not on. andrew_tao173.riddles.org.uk: No. Linking lua53 with pthread might be defensible (though I personally don't think it is), but…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions I was unable to find a definitive test to indicate if Lua requires linking pthread. As I had seen mention of it in luaossl, I built Lua with and without linking to pthread and created a public key. In both tests I "required" luaossl and successfully created a public key using 1.0.2k. I emailed the luaossl maintainer (actually, I emailed the author wahern who directed me to the current maintainer duarnimator). Duarnimator indicated that openssl pre 1.1.0 needs pthreads and he pointed me to the sources: https://github.com/wahern/luaossl/blob/357a7f6da9e6ae442b3c3b9e43396b3cf2e1a91d/src/openssl.c#L11127 At this juncture I have assumed my tests were faulty and added -pthread back in. If you can indicate some tests I could try on any package that would prove this one way or the other (or confirm that my original test was valid) I would like to remove it entirely. To keep all the information together, here is the previous comment on that topic. As per an email with Jan Beich: -pthread was inherited from https://svnweb.freebsd.org/changeset/ports/324286 which was probably fixed by https://svnweb.freebsd.org/changeset/base/276630 russ.haley_gmail.com: I was unable to find a definitive test to indicate if Lua requires linking pthread. As I had…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions For reference on the luaossl requirement, see http://25thandclement.com/~william/projects/luaossl.pdf section 1.2.3 russ.haley_gmail.com: For reference on the luaossl requirement, see http://25thandclement.
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions I think you're missing the point about pthreads. Lua itself has no interaction with threads at all (unless you explicitly modify it to lock the interpreter, which the port doesn't do). Therefore, it's inappropriate for lublua.so (which will never call any pthread function) to force libthr into the process. (Remember that liblua.so might be being loaded because of a reference from a dlopen'd module - this is actually not uncommon) The bug fix you reference (base/276630) is specifically about loading libthr via dlopen, so without that fix, linking lublua.so against libthr actually makes things worse, since any dynamic load of a lua interpreter would trigger the bug even if no pthread-using module was ever used from Lua. If some extension that you want to load from Lua needs to pull in pthreads, then there are two possibilities: either it's enough for the extension .so to reference libthr to pull it in, or if there's an unfixed bug of the same kind as base/276630, then it's not enough for liblua.so to reference libthr, but rather the main executable must do so. andrew_tao173.riddles.org.uk: I think you're missing the point about pthreads. Lua itself has no interaction with threads at…
				russ.haley_gmail.comAuthorUnsubmitted Done Inline Actions I'm struggling to understand if/why libmath is required for the shared object at all but I don't currently have any code that uses liblua.so. I'll postulate that we should do a second exp run with -lm removed to see if anything breaks? russ.haley_gmail.com: I'm struggling to understand if/why libmath is required for the shared object at all but I…
				andrew_tao173.riddles.org.ukUnsubmitted Done Inline Actions Lua calls functions from libm. If you try and load liblua.so into a main program that doesn't export the libm functions, it'll fail unless liblua.so pulls in libm itself. So it's always correct for liblua.so to be linked against libm. andrew_tao173.riddles.org.uk: Lua calls functions from libm. If you try and load liblua.so into a main program that doesn't…
				# We override DOCSDIR to get a per-version subdir.
				# We put the docs for Lua proper in a lua/ subdir of the version subdir
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions Ken Sasaki (lua-stdlib-normalize / lua-stdlib-debug maintainer) suggested in a bugzilla thread that perhaps modules should be installing docs under doc/lua5N/port-name, so perhaps we should consider installing the docs for Lua proper under doc/lua5N/lua to allow that without creating a mess? andrew_tao173.riddles.org.uk: Ken Sasaki (lua-stdlib-normalize / lua-stdlib-debug maintainer) suggested in a bugzilla thread…
				# so that ports for Lua modules can use the version subdir too without
				# making a mess.
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions This is the standard make target for freebsd in lua. russ.haley_gmail.com: This is the standard make target for freebsd in lua.
				DOCSDIR= ${PREFIX}/share/doc/lua${PKGNAMESUFFIX}/lua
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions I would like to remove the renaming of the lua build output and postpone it until the install step, or a preinstall rename. Input appreciated. russ.haley_gmail.com: I would like to remove the renaming of the lua build output and postpone it until the install…
				PORTDOCS= *
				BUILD_WRKDOC= ${WRKSRC}/doc

				LUA_PREFIX= ${PREFIX}

				# 2018-03-17: AG - These should match lua.mk, but we can't include that here
				LUA_CMD= lua${PKGNAMESUFFIX}
				LUAC_CMD= luac${PKGNAMESUFFIX}
				LUA_INCDIR= ${LUA_PREFIX}/include/lua${PKGNAMESUFFIX}
				LUA_LIBDIR= ${LUA_PREFIX}/lib

				LUA_LIB_STATIC= liblua-${LUA_VER}.a
				LUA_LIB_SHARED= liblua-${LUA_VER}.so
				LUA_PC_FILE= lua-${LUA_VER}.pc

				# using the "bsd" target rather than "freebsd" saves patching out the
				# assumption of using base libedit in order to make it configurable. "bsd"
				# is "generic" plus the POSIX and DLOPEN options, plus -Wl,-E at link time;
				# it doesn't set CC either, which makes it easier for us to control that too.
				ALL_TARGET=bsd
				matUnsubmitted Not Done Inline Actions Why `+=`? mat: Why `+=`?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions I probably cargo-culted that in from some example when adding options to the lua54 port, and russ got it from me. No reason not to change it to just = andrew_tao173.riddles.org.uk: I probably cargo-culted that in from some example when adding options to the lua54 port, and…

				# Options

				OPTIONS_DEFAULT=LIBEDIT_DL DOCS

				OPTIONS_GROUP= DOCSGRP DEBUGGRP
				OPTIONS_SINGLE= EDITGRP

				OPTIONS_GROUP_DOCSGRP= DOCS
				OPTIONS_GROUP_DEBUGGRP= ASSERT APICHECK

				OPTIONS_SINGLE_EDITGRP= EDITNONE LIBEDIT_DL LIBEDIT READLINE

				# Option descriptions

				DEBUGGRP_DESC= Debugging options
				ASSERT_DESC= Enable interpreter assertions
				APICHECK_DESC= Enable API checks

				DOCSGRP_DESC= Documentation options
				DOCS_DESC= Install language and API reference (HTML, ~400kB)
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions Well, this sucks: qa.sh doesn't allow this and demands that you use the port instead. The problem with using the port libedit is that it links against the wrong libncurses, leading to compatibility problems when you try and use the lua curses module. Same problem exists with readline. I was hoping to avoid that problem this way, but if linking to base libedit isn't an option then we're going to need a much more involved solution, such as installing an extra lua binary without editing support. andrew_tao173.riddles.org.uk: Well, this sucks: qa.sh doesn't allow this and demands that you use the port instead. The…

				EDITGRP_DESC= Interactive command-line editing
				matUnsubmitted Not Done Inline Actions extra white space before `=`. mat: extra white space before `=`.
				EDITNONE_DESC= No command-line editing
				LIBEDIT_DL_DESC=Use dynamically loaded libedit (recommended)
				matUnsubmitted Not Done Inline Actions Please restore the header. mat: Please restore the header.
				LIBEDIT_DESC= Use libedit (breaks lcurses)
				READLINE_DESC= Use GNU Readline (breaks lcurses)

				# Option implementations

				ASSERT_EXTRA_PATCHES= ${PATCHDIR}/extra-patch-assert

				APICHECK_CPPFLAGS= -DLUA_USE_APICHECK

				# EDITNONE currently requires no settings

				matUnsubmitted Not Done Inline Actions To silence what exactly? Do not add inactive code because a third party lint tool gives you warnings. Also, what happens if libedit or libreadline is installed, and one selects this option? mat: To silence what exactly? Do not add inactive code because a third party lint tool gives you…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions portlint, which is prominently mentioned in the porters manual, counts as a third-party tool? Without that line or something logically equivalent, portlint reports: WARN: Makefile: EDITNONE is listed in OPTIONS_DEFINE, but no PORT_OPTIONS:MEDITNONE appears. Obviously that can just be ignored, which I did for a while, but I figured that it cost nothing to suppress the warning. If one selects EDITNONE, then regardless of what is or is not installed, the lua53 binary will not do command-line editing, when running interactively it'll just fgets from stdin. I thought the description of that was clear enough. No dependency on libedit or readline will be generated and no library other than libc and libm will be linked. andrew_tao173.riddles.org.uk: portlint, which is prominently mentioned in the porters manual, counts as a third-party tool?
				matUnsubmitted Not Done Inline Actions Mmm, if the option does nothing then do not add it. And instead of using an OPTIONS_SINGLE, use OPTIONS_RADIO. https://www.freebsd.org/doc/en/books/porters-handbook/makefile-options.html mat: Mmm, if the option does nothing then do not add it. And instead of using an OPTIONS_SINGLE…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions From a user perspective it seemed much clearer to have an explicit option for it (which could have a description). Without it, it's not at all clear that no editing is even an available option. andrew_tao173.riddles.org.uk: From a user perspective it seemed much clearer to have an explicit option for it (which could…
				matUnsubmitted Not Done Inline Actions The reason we have SINGLE (1) and RADIO (0,1) is to handle those case. You can add a few words to `EDITGRP_DESC` to say that having none is ok, or add a pkg-help file to be more verbose. But do not add a non functionnal variable only to please portlint. mat: The reason we have SINGLE (1) and RADIO (0,1) is to handle those case. You can add a few words…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions I'm OK with taking the variable out and just ignoring the warning, but changing the UI appearance just based on the fact that we don't actually need any special option processing to implement EDITNONE seems to me to be putting the cart before the horse. andrew_tao173.riddles.org.uk: I'm OK with taking the variable out and just ignoring the warning, but changing the UI…
				LIBEDIT_DL_USES= libedit
				LIBEDIT_DL_CPPFLAGS= -DLUA_USE_READLINE_DL

				LIBEDIT_USES= libedit
				LIBEDIT_CPPFLAGS= -DLUA_USE_READLINE
				matUnsubmitted Not Done Inline Actions missing tab after `=`. mat: missing tab after `=`.
				LIBEDIT_LIBS= -ledit

				READLINE_USES= readline
				READLINE_CPPFLAGS= -DLUA_USE_READLINE
				READLINE_LIBS= -lreadline

				matUnsubmitted Not Done Inline Actions This is not used anywhere, what is it for? mat: This is not used anywhere, what is it for?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions It's the only way to stop bsd.port.mk from adding -fno-strict-aliasing to CFLAGS. Lua does not require this flag. andrew_tao173.riddles.org.uk: It's the only way to stop bsd.port.mk from adding -fno-strict-aliasing to CFLAGS. Lua does not…
				matUnsubmitted Not Done Inline Actions But is it broken with it? mat: But is it broken with it?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions -fno-strict-aliasing only reduces optimization, so absent compiler bugs it can't "break" anything. However since Lua is an actively maintained piece of code which is tested with modern compilers, for which performance is a factor, I think it best to follow the upstream's selection of compile options in the absence of an overriding reason to do otherwise. andrew_tao173.riddles.org.uk: -fno-strict-aliasing only reduces optimization, so absent compiler bugs it can't "break"…
				# end of option vars

				CFLAGS+= -fPIC

				WITHOUT_NO_STRICT_ALIASING=yes

				MAKE_ARGS+= CC="${CC}" \
				MYCFLAGS="${CPPFLAGS} ${CFLAGS}" \
	MYLDFLAGS="${LDFLAGS}" \			MYLDFLAGS="${LDFLAGS}" \
	MYLIBS="-Wl,-E -L${LOCALBASE}/lib -ledit" \			MYLIBS="${LIBS}" \
	CC="${CC}" \			LUA_T=${LUA_CMD} \
	LUA_T=lua53 \			LUAC_T=${LUAC_CMD} \
	LUAC_T=luac53 \			LUA_A=${LUA_LIB_STATIC} \
	LUA_A=liblua-${LUA_VER}.a \			LUA_SO=${LUA_LIB_SHARED} \
	LUA_SO=liblua-${LUA_VER}.so \			LUA_SONAME=${LUA_LIB_SHARED} \
	LUA_SONAME=liblua-${LUA_VER}.so \			TO_BIN="${LUA_CMD} ${LUAC_CMD}" \
	TO_BIN="lua53 luac53" \			TO_LIB="${LUA_LIB_SHARED} ${LUA_LIB_STATIC}" \
	TO_LIB="liblua-${LUA_VER}.a liblua-${LUA_VER}.so" \
	INSTALL_TOP=${STAGEDIR}${PREFIX} \			INSTALL_TOP=${STAGEDIR}${PREFIX} \
	INSTALL_INC=${STAGEDIR}${PREFIX}/include/lua53 \			INSTALL_INC=${STAGEDIR}${LUA_INCDIR} \
	INSTALL_EXEC="${INSTALL_PROGRAM}"			INSTALL_EXEC="${INSTALL_PROGRAM}"

	# Cope with the lack of support for Lua 5.2 in bsd.lua.mk. These			SUB_FILES= ${LUA_PC_FILE}
	# overrides, which are required below, should be removed once bsd.lua.mk
	# understands this lua version.
	LUA_PREFIX?= ${PREFIX}
	LUA_SUBDIR?= lua${PKGNAMESUFFIX}
	LUA_INCDIR?= ${LUA_PREFIX}/include/${LUA_SUBDIR}
	LUA_LIBDIR?= ${LUA_PREFIX}/lib

	SUB_FILES= lua-${LUA_VER}.pc
	SUB_LIST= version=${PORTVERSION} \			SUB_LIST= version=${PORTVERSION} \
	includedir=${LUA_INCDIR} \			includedir=${LUA_INCDIR} \
	libdir=${LUA_LIBDIR} \			libdir=${LUA_LIBDIR} \
	soname=lua-${LUA_VER}			soname=lua-${LUA_VER}
				matUnsubmitted Done Inline Actions Why? mat: Why?
				russ.haley_gmail.comAuthorUnsubmitted Done Inline Actions I'm not sure I understand the question @mat? I'll assume the question is "Why use variables" and say, I was trying to remove the hard coded 'lua' and 'lua53' strings to make it more consistent and usable for the upcoming 5.4 port. To be more accurate, this is a revision of the 5.4 port Makefile 'backported' to 5.3 russ.haley_gmail.com: I'm not sure I understand the question @mat? I'll assume the question is "Why use variables"…
				andrew_tao173.riddles.org.ukUnsubmitted Done Inline Actions the problem here is that soname= and LUA_LIB_SHARED don't match if PORTNAME is changed. Either both names should be based on PORTNAME or neither should. andrew_tao173.riddles.org.uk: the problem here is that soname= and LUA_LIB_SHARED don't match if PORTNAME is changed. Either…
				matUnsubmitted Not Done Inline Actions Yes, why remove `lua`? This will never change, so, there is no point of having it as a variable. (Well, unless the language is renamed, but I don't see that happening.) mat: Yes, why remove `lua`? This will never change, so, there is no point of having it as a…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions Yes, why remove lua? This will never change, so, there is no point of having it as a variable. (Well, unless the language is renamed, but I don't see that happening.) I suppose the reason is two fold: 1) I'm learning as I go and it seemed like something to clean up and 2) my "OCD" made me cringe when I looked at it. I can change it back if it offends, as I am largely indifferent. russ.haley_gmail.com: > Yes, why remove lua? This will never change, so, there is no point of having it as a variable.
				matUnsubmitted Not Done Inline Actions It would be better to keep `lua` as it was before, using a 11 characters of variable for a 3 letter constant is a bit overboard. mat: It would be better to keep `lua` as it was before, using a 11 characters of variable for a 3…
				russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions I am grateful for you taking the time to review my work. Please let me know what else you wish to see amended. russ.haley_gmail.com: I am grateful for you taking the time to review my work. Please let me know what else you wish…
				andrew_tao173.riddles.org.ukUnsubmitted Done Inline Actions Wrong value for soname= there. LUA_LUB_SHARED is liblua-5.3.so, but soname= needs to be lua-5.3.so without the 'lib' prefix. andrew_tao173.riddles.org.uk: Wrong value for soname= there. LUA_LUB_SHARED is liblua-5.3.so, but soname= needs to be lua-5.3.
				andrew_tao173.riddles.org.ukUnsubmitted Done Inline Actions uh, I mean soname needs to be lua-5.3 without either the 'lib' prefix or the '.so' suffix. andrew_tao173.riddles.org.uk: uh, I mean soname needs to be lua-5.3 without either the 'lib' prefix or the '.so' suffix.

	CFLAGS+= -fPIC
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions Added to the base Makefile russ.haley_gmail.com: Added to the base Makefile

	post-patch:			post-patch:
	@${REINPLACE_CMD} -e 's,rand *(,random(,g' \			@${REINPLACE_CMD} -e "/LUA_ROOT/s,/usr/local,${LUA_PREFIX}," \
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions The code that this patches is not reachable due to the USE_POSIX. http://lua-users.org/lists/lua-l/2017-09/msg00089.html From lmathlib.c #if !defined(l_rand) /* { / #if defined(LUA_USE_POSIX) #define l_rand() random() #define l_srand(x) srandom(x) #define L_RANDMAX 2147483647 / (2^31 - 1), following POSIX / #else #define l_rand() rand() #define l_srand(x) srand(x) #define L_RANDMAX RAND_MAX #endif #endif / } / from luaconf.h #if defined(LUA_USE_LINUX) #define LUA_USE_POSIX #define LUA_USE_DLOPEN / needs an extra library: -ldl / #define LUA_USE_READLINE / needs some extra libraries / #endif russ.haley_gmail.com:* The code that this patches is not reachable due to the USE_POSIX. http://lua-users.
	${WRKSRC}/src/lmathlib.c			${WRKSRC}/src/luaconf.h
	@${REINPLACE_CMD} -e "/LUA_ROOT/s\|/usr/local\|${LUA_PREFIX}\| ; \
	russ.haley_gmail.comAuthorUnsubmitted Not Done Inline Actions luaconf.h contains no readline reference and I instead created a patch for lua.c. This makes the code changes in one place (patch files) and the changes required are easily visible (in the patch file). russ.haley_gmail.com: luaconf.h contains no readline reference and I instead created a patch for lua.c. This makes…
	andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions This removal isn't quite right because the point of editing luaconf.h here is not to deal with readline, but rather to fix LUA_ROOT to ensure it matches ${PREFIX}. By default these are both /usr/local, so it's not obvious if this step is missed, but if ${PREFIX} is set to something else it's important that LUA_ROOT in luaconf.h be updated to match. andrew_tao173.riddles.org.uk: This removal isn't quite right because the point of editing luaconf.h here is not to deal with…
	s,readline/,editline/,g ; \
	/history\.h/d" \
	${WRKSRC}/src/luaconf.h ${WRKSRC}/src/lua.c

				post-patch-LIBEDIT-on:
				@${REINPLACE_CMD} -e "s,readline/,editline/,g ; \
				/history\.h/d" ${WRKSRC}/src/lua.c

				post-patch-LIBEDIT_DL-on:
				@${REINPLACE_CMD} \
				-e "/^#def.*LUA_READLINE_LIBPATH/s,/usr/local,${LOCALBASE}," \
				${WRKSRC}/src/lua.c

	post-install:			post-install:
	@${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/liblua-${LUA_VER}.so			${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/${LUA_LIB_SHARED}
	@${MV} ${STAGEDIR}${PREFIX}/man/man1/lua.1 \			${MV} ${STAGEDIR}${PREFIX}/man/man1/lua.1 \
	${STAGEDIR}${PREFIX}/man/man1/lua53.1			${STAGEDIR}${PREFIX}/man/man1/${LUA_CMD}.1
	@${MV} ${STAGEDIR}${PREFIX}/man/man1/luac.1 \			${MV} ${STAGEDIR}${PREFIX}/man/man1/luac.1 \
	${STAGEDIR}${PREFIX}/man/man1/luac53.1			${STAGEDIR}${PREFIX}/man/man1/${LUAC_CMD}.1
	${INSTALL_DATA} ${WRKDIR}/lua-${LUA_VER}.pc \			${INSTALL_DATA} ${WRKDIR}/${LUA_PC_FILE} \
	${STAGEDIR}${PREFIX}/libdata/pkgconfig			${STAGEDIR}${PREFIX}/libdata/pkgconfig

				post-install-DOCS-on:
				${MKDIR} ${STAGEDIR}${DOCSDIR}
				(cd ${BUILD_WRKDOC} && \
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions make check-orphans doesn't like this, I'll fix in the next patch andrew_tao173.riddles.org.uk: make check-orphans doesn't like this, I'll fix in the next patch
				${COPYTREE_SHARE} . ${STAGEDIR}${DOCSDIR} '-not -name *\.1')

	.include <bsd.port.mk>			.include <bsd.port.mk>
				matUnsubmitted Not Done Inline Actions Any reason not to simply COPYTREE_SHARE all that directory in DOCSDIR? mat: Any reason not to simply COPYTREE_SHARE all that directory in DOCSDIR?
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions BUILD_WRKDOC also has the lua.1 and luac.1 files in it that are installed as manpages rather than docs. In a previous version I had it copying those files anyway, but just not including them in PORTDOCS so they didn't get installed. But check-plist objects to that. andrew_tao173.riddles.org.uk: BUILD_WRKDOC also has the lua.1 and luac.1 files in it that are installed as manpages rather…
				matUnsubmitted Not Done Inline Actions This does not really say why you cannot use COPYTREE_SHARE. cd ${BUILD_WRKDOC} && ${COPYTREE_SHARE} . ${STAGEDIR}${DOCSDIR} '-not -name ".1"' mat:* This does not really say why you cannot use COPYTREE_SHARE. ``` cd ${BUILD_WRKDOC} &&…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions I just tried that, it doesn't work as given (it copies lua.1 and luac.1 anyway). Looks like COPYTREE_SHARE doesn't actually work with wildcards in the third arg, due to issues of shell quoting. "-not -name lua.1 -not -name luac.1" works, but now it's starting to look like not so much of an improvement over the previous form. andrew_tao173.riddles.org.uk: I just tried that, it doesn't work as given (it copies lua.1 and luac.1 anyway). Looks like…
				matUnsubmitted Not Done Inline Actions Mmmm, wildcards are supported, maybe you need to reverse the `"` and `'` order, like `"-not -name '.1'"`. Or write it as `'-not -name \.1'` mat: Mmmm, wildcards are supported, maybe you need to reverse the `"` and `'` order, like `"-not…
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions None of those work. andrew_tao173.riddles.org.uk: None of those work.
				andrew_tao173.riddles.org.ukUnsubmitted Not Done Inline Actions Apparently the magic incantation is to escape with \ some part of the filename pattern other than the wildcard characters; this works because of an odd interaction between shell and find(1) related to the fact that find(1) does an extra layer of unescaping for itself, while the escape character prevents the pattern from matching any files in the shell (assuming there are no files with \ in the names). i.e. '-not -name \.1' works this is ... not at all well documented, while there is an example in bsd.port.mk it completely fails to point out the important aspect, and the ports handbook doesn't mention it at all. It also seems rather fragile to me. andrew_tao173.riddles.org.uk:* Apparently the magic incantation is to escape with \ some part of the filename pattern //other…
				matUnsubmitted Not Done Inline Actions Damn, I knew there was something strange happening. One day I'll try to figure out what really happens and why, and document it properly. mat: Damn, I knew there was something strange happening. One day I'll try to figure out what really…