Opened 11 years ago
Closed 3 months ago
#40228 closed enhancement (wontfix)
cmake: add FindLua52.cmake
| Reported by: | mojca (Mojca Miklavec) | Owned by: | macports-tickets@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | |
| Keywords: | Cc: | afb@…, cooljeanius (Eric Gallager) | |
| Port: | cmake wxLua |
Description
This needs to be reported upstream, but it might take a while before they do anything and release a new version. wxLua needs FindLua52.cmake in order to compile with external dependency (otherwise it can still use the built-in lua, but not the external one).
Attachments (1)
Change History (8)
Changed 11 years ago by mojca (Mojca Miklavec)
| Attachment: | FindLua52.cmake added |
|---|
comment:1 follow-up: 5 Changed 11 years ago by cssdev
The upstream bug for this is http://www.cmake.org/Bug/view.php?id=14224 and it looks like the implementation may be somewhat different. I would prefer to wait for the upstream 2.8.12 release.
That is, unless the generalized version-agnostic FindLua.cmake works with 2.8.11. Could one of you who uses Lua see if it does?
comment:2 Changed 11 years ago by cssdev
| Status: | new → assigned |
|---|
comment:3 Changed 11 years ago by mojca (Mojca Miklavec)
Waiting for 2.8.12 sounds perfectly fine (even though I have a hard time believing that this patch would be included in 2.8.12 given that RC3 is already out; if I was the developer I wouldn't dare changing the name of the module from RC3 to main release).
In any case fixing this in 2.8.11/12 only makes sense if the solution will be the same as in the to-be-released version. It's pointless to add one file now and realize that a completely different solution will be used in the released version.
Probably the main problem is that upstream software (like wxLua) expects the module to have a specific name (wxLua looks for FindLua52.cmake for example). I totally agree that it makes more sense to have version-agnostic FindLua.cmake rather than a separate module for each version. This FindLua52.cmake was just my quick-and-dirty solution to make the compilation work in the first place (lacking the experience to write a version-independent one).
Meanwhile I will try to open a ticket in the tracker for wxLua.
comment:4 Changed 8 years ago by kurthindenburg (Kurt Hindenburg)
| Owner: | changed from css@… to macports-tickets@… |
|---|---|
| Status: | assigned → new |
comment:5 Changed 2 years ago by cooljeanius (Eric Gallager)
Replying to cssdev:
The upstream bug for this is http://www.cmake.org/Bug/view.php?id=14224 and it looks like the implementation may be somewhat different. I would prefer to wait for the upstream 2.8.12 release.
The upstream bug has been closed; does that mean that this can be closed, too, now?
comment:6 Changed 2 years ago by cooljeanius (Eric Gallager)
| Cc: | cooljeanius added |
|---|
comment:7 Changed 3 months ago by ryandesign (Ryan Carsten Schmidt)
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
Well, the original upstream bug was closed when a bot migrated the issue to a new bug tracking system:
https://gitlab.kitware.com/cmake/cmake/-/issues/14224
The bot then closed that issue a few years later with no comment.
Today's CMake 3.28.1 still has no FindLua52.cmake file. It does have FindLua51.cmake, FindLua50.cmake, and FindLua.cmake files, and the latter supports up to Lua 5.4.
So I think this has to be closed as wontfix. We shouldn't add nonstandard Find*.cmake files to our cmake distribution. wxLua needs to use cmake's FindLua.cmake or if that's not sufficient for their needs then they need to bundle their own Find*.cmake files and they can be responsible for working with the developers of cmake to get those new or changed files accepted into the cmake distribution if they want to do that.
FindLua51.cmake with 5.1 replaced by 5.2