This should be resetted when updating the version.

Why?

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.

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

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

For reference on the luaossl requirement, see http://25thandclement.com/~william/projects/luaossl.pdf section 1.2.3

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?

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.

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.

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.

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.

uh, I mean soname needs to be lua-5.3 without either the 'lib' prefix or the '.so' suffix.

Please, DO NOT CHANGE the header.

This was not done. Please remove PORTREVISION, or set it to 0.

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

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.

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.

I am grateful for you taking the time to review my work. Please let me know what else you wish to see amended.

Please restore the header.

Most scripting languages are embeddables, is lua not compilable any more ?

Why +=?

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.

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 =

This isn't actually needed with the change to use the "bsd" target.

@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.

extra white space before =.

missing tab after =.

This is not used anywhere, what is it for?

It's the only way to stop bsd.port.mk from adding -fno-strict-aliasing to CFLAGS. Lua does not require this flag.

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.

But is it broken with it?

-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.

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?

make check-orphans doesn't like this, I'll fix in the next patch

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?

Any reason not to simply COPYTREE_SHARE all that directory in DOCSDIR?

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.

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.

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

This does not really say why you cannot use COPYTREE_SHARE.

cd ${BUILD_WRKDOC} && ${COPYTREE_SHARE} . ${STAGEDIR}${DOCSDIR} '-not -name "*.1"'

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.

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.

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.

Mmmm, wildcards are supported, maybe you need to reverse the " and ' order, like "-not -name '*.1'". Or write it as '-not -name \*.1'

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.

None of those work.

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.

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.