[Solved] lua 5.4.6 for TCL14 x86_64

[GNUser]

The logic would have to be refined, this approach does not give the expected results:

Code: [Select]

$ ls /usr/local/bin/lua*.*
/usr/local/bin/lua5.4        /usr/local/bin/luajit-2.0.5
/usr/local/bin/luac5.4
Something like this is what we need:

Code: [Select]

$ ls /usr/local/bin/lua* | grep -Eo '/usr/local/bin/lua[0-9]+\.[0-9]+' | sort -V
$ ls /usr/local/bin/lua* | grep -Eo '/usr/local/bin/luac[0-9]+\.[0-9]+' | sort -V

[GNUser]

I'm going to submit a third set of extensions. Will do it quick, like ripping off a bandaid.

[jazzbiker]

My only small objection is that lua.5.4 etc is a bit ugly and difficult to type. My vote is keep binary names as lua5.3, luac5.3, lua5.4, luac5.4, etc.

I think You don't need to bother about the names' ugliness because the tce.installed will hide all the ugliness behind the beautiful links.
I even see no trouble in lua-5.4 and luac-5.4 binaries. The one thing I want to ask is lua-5.4.pc, in order to the *.pc name will correspond with an extension name.

[GNUser]

I think You don't need to bother about the names' ugliness because the tce.installed will hide all the ugliness behind the beautiful links.

Not if you have multiple versions installed and are trying to use one of the older versions

Ok, I just submitted a third set of extensions of Lua 5.4 for TCL14 x86_64. Third time's the charm!

Note that in order for these new tce.installed scripts to work well, some changes are recommended in the Lua 5.3 extensions:
* lua-5.3.tcz: binaries should be renamed to lua5.3 and luac5.3
* lua-5.3-dev.tcz: /usr/local/lib/pkgconfig/lua.pc should be renamed /usr/local/lib/pkgconfig/lua-5.3.pc

P.S. Maybe in a future redo the hyphens could vanish from the extension names (to become lua5.4.tcz, for example--to match way python versions are packaged) and from the .pc file names (to lua5.3.pc, for example--to match the binary names). But that's something to consider some other time. I think we've done enough for now.

[Rich]

Hi GNUser

... * lua-5.3-dev.tcz: /usr/local/lib/pkgconfig/lua.pc should be renamed /usr/local/lib/pkgconfig/lua-5.3.pc ...

Doesn't that risk breaking any package that needs to call pkg-config for
lua-dev in order to build it? Possible examples:

Code: [Select]

14.x/x86/tcz/edje-dev.tcz.dep   lua-dev.tcz
14.x/x86/tcz/gegl-dev.tcz.dep   luajit-dev.tcz
14.x/x86/tcz/grilo-plugins-dev.tcz.dep  lua-dev.tcz
14.x/x86/tcz/vlc3-dev.tcz.dep   lua-dev.tcz
14.x/x86/tcz/wireshark-dev.tcz.dep      lua-dev.tcz

14.x/x86_64/tcz/grilo-plugins-dev.tcz.dep       lua-5.3-dev.tcz
14.x/x86_64/tcz/mpv-dev.tcz.dep luajit-dev.tcz
14.x/x86_64/tcz/vlc-dev.tcz.dep lua-5.3-dev.tcz
14.x/x86_64/tcz/wireshark-dev.tcz.dep   lua-5.3-dev.tcz

[GNUser]

Hi Rich. Yes it would. However, I think we should deprecate extensions called lua.tcz and lua-dev.tcz. Therefore, no packages should depend on lua.tcz or lua-dev.tcz.

The version number (for Lua x.y.z, version number is x.y and z is the bug fix release) should always be part of the extension name.

P.S. lua-x.y-dev.tcz would have a startup script that creates a link called lua.pc pointing to lua-x.y.pc. The lua-5.4-dev.tcz extension that I submitted today has a startup script that does just that.

[GNUser]

Hi Rich. Sorry, I just realized that what I said above was an unsatisfactory, partial response to your very legitimate concerns. I will try to give a (hopefully) complete response below, in four bullet points. If you catch a missing detail, please let me know.

* lua-dev.tcz should be renamed lua-5.3-dev.tcz
* in lua-5.3-dev.tcz: lua.pc file should be renamed lua-5.3.pc
* in lua-5.3-dev.tcz: the extension should have a startup file that looks like this:

Code: [Select]

#!/bin/sh

LUAPC_LATEST=$(ls /usr/local/lib/pkgconfig/lua* | grep -Eo '/usr/local/lib/pkgconfig/lua-[0-9]+\.[0-9]+\.pc' | sort -V | tail -n1)
ln -sf $(readlink $LUAPC_LATEST) /usr/local/lib/pkgconfig/lua.pc* .dep files that contain lua-dev.tcz should be updated to contain lua-5.3-dev.tcz

These proposals are based on jazzbiker's ideas and I agree that they are the best (only?) way to support multiple versions of Lua on the machine. jazzbiker's smart idea is to include startup scripts in every lua-x.y.tcz, lua-x.y-lib.tcz, and lua-x.y-dev.tcz extension. The startup script's job is to ensure that those few files that don't normally have the Lua version in their name (namely: lua.pc, lua, luac, liblua.so) are just symlinks pointing the the most recent version of the relevant file that's available on the machine.

P.S. The Lua 5.4 submissions for the TCL14 x86_64 repo, which I sent today, incorporate jazzbiker's naming suggestions and include the startup scripts.

[Rich]

Hi GNUser
The following is not limited to lua but extensions in general.

What I've seen being done in many (but not all) instances is:
When Y changes in version X.Y of extension.tcz, it gets replaced with a new extension.tcz.
When Y changes, backward compatibility is supposed to be maintained.

When X changes in version X.Y and backward compatibility is needed:
The old extension.tcz becomes extensionX.tcz where X is the old version number.
Sometimes the lib.so->lib.so.X link gets removed from the old extension.tcz.
The old extension-dev.tcz gets removed so nothing gets compiled against the old version.
Extensions that depend on the old extension.tcz need their .dep files updated to extensionX.tcz.
The new version becomes extension.tcz.

My concern is what issues get introduced if version numbers get added to extension names.
Checking all of the build/run dependencies to see if their extension names
need to be changed in build scripts.
The same might hold true for configure scripts and make files.
I'm sure .dep files get carried over in many cases when extensions get
updated, but version numbers all over the place would complicate that.

I see Juanito and andyj maintain a lot of extensions. Maybe they could
provide some input.

[jazzbiker]

Hi Rich and GNUser,

I want to remind one more scheme which was not yet mentioned.

lua-5.3.tcz includes lua-5.3, luac-5.3 and no tce.installed
lua-5.4.tcz includes lua-5.4, luac-5.4 and no tce.installed
lua.tcz has lua-5.4.tcz as the dependency and contains tce.installed linking lua -> lua-5.4 and luac -> luac-5.4.

[GNUser]

Hi GNUser
The following is not limited to lua but extensions in general.

What I've seen being done in many (but not all) instances is:
When Y changes in version X.Y of extension.tcz, it gets replaced with a new extension.tcz.
When Y changes, backward compatibility is supposed to be maintained.

When X changes in version X.Y and backward compatibility is needed:
The old extension.tcz becomes extensionX.tcz where X is the old version number.

Hi Rich. Not in Lua, where x.y is the major version.
x.(y+1) in Lua is a very big, ABI-incompatible change. See https://www.lua.org/versions.html

I agree with everything you said, but in Lua you have to adjust your thinking by a decimal place.

[GNUser]

Sometimes it helps to see how other projects have dealt with packaging conundrums.

In Devuan and Termux there is no binary named lua. In both projects, the lua interpreter is called lua5.3 or lua5.4 etc, depending on lua version(s) installed.

In Termux, interestingly, the package that provides Lua 5.3 is called lua53.deb (no decimal point in the package name). After installing the package, typing lua in the terminal results in "command not found" error. User must type lua5.3 to start the interactive interpreter.

In Devuan, /usr/bin/lua exists but is just a link:

Code: [Select]

Devuan$ which lua
/usr/bin/lua
Devuan$ ls -l /usr/bin/lua
lrwxrwxrwx 1 root root 33 Jul 17  2022 /usr/bin/lua -> /etc/alternatives/lua-interpreter
Devuan$ ls -l /etc/alternatives/lua-interpreter
lrwxrwxrwx 1 root root 15 Jul 17  2022 /etc/alternatives/lua-interpreter -> /usr/bin/lua5.4

[GNUser]

Hi jazzbiker and friends. Two more questions to consider.

1) Regarding the startup scripts, wouldn't it be better for it to link the unversioned file to the version in that extension? Like this:

* lua-5.3.tcz forcibly links /usr/local/bin/lua to /tmp/tcloop/lua-5.3/usr/local/bin/lua5.3
* lua-5.4.tcz forcibly links /usr/local/bin/lua to /tmp/tcloop/lua-5.4/usr/local/bin/lua5.4

Same idea for lua.pc and liblua.so.

The advantage of this method is that the user could easily choose which lua version should be the default simply by the order in which extensions are loaded. Last one loaded wins.

2) Does everybody else also prefer the simpler names without hyphens (lua5.3.tcz, lua5.4.tcz, lua5.3.pc, etc)? If so, maybe the time to fix it is now while we are at it

I don't mind recreating the extensions until we have a consensus and everybody is happy

[Rich]

Hi GNUser

... Not in Lua, where x.y is the major version. ...

Fair enough. 

[jazzbiker]

Hi GNUser,

Your extensions are in the x86_64 repo since yesterday morning, seems we are wasting time.

You can ask me, how I deal with Lua 5.4.
I built it in the separate directory, I use my own build scripts where I defined -I, -L and all necessary switches. I mean I don't use pkg-config for Lua. I link with static library. In the scripts I use shebang to point to the lua binary. My ~/.local/bin contains proper redirections to my lua and luac binaries.
All these preparations took quite small time. You know that Lua is built in a few moments.

I beg Your pardon for so much messing.

Happy hacking!

[GNUser]

Hi jazzbiker.

Those extensions were my first attempt--vanilla build without external libs, without pkgconfig, without any thought to concurrent versions.

Yes, I feel like now I'm making a mess, creating noise and more work for everybody. I think I'm doing a disservice to Lua.

After I finish this post I will create and submit one last set of 5.4 extensions for the x86_64 repo, with today's timestamp (2023/08/19). The set will have the -lib extension, pkgconfig, and simple startup scripts that use the last-loaded-wins idea I mentioned in reply #26. I will keep hyphens in extension names.

If this final set is considered to add value to TCL, I would be happy to see it accepted. If not, no hurt feelings.

Rich, please mark thread as solved.

Happy hacking!