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

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

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

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.

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 =

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.

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

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.

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.

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.

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

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.

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.

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.

This does not really say why you cannot use COPYTREE_SHARE.

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

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.

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

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.

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

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

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

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.

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 =

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.

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

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.

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.

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.

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

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.

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.

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.

This does not really say why you cannot use COPYTREE_SHARE.

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

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.

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

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.

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

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

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

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.

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 =