Discussion Orbiter: Lua 5.4 Upgrade: Community Input

[Kozak]

How about we solve it going forward then? We have definite code "owners" for some areas - e.g. Jarmonik for D3D9Client, dbeachy for XRSound, myself for CMake magic and/or GH actions stuff - how about we add a CODEOWNERS file to the repo so that specific people are called in to review?

About code owners - GitHub Docs

You can use a CODEOWNERS file to define individuals or teams that are responsible for code in a repository.

docs.github.com

As for build failing with particular flags being off, I agree, this is annoying. This is the downside of having too many flags - you never know they work unless you check. We can add a build without optional features & build it alongside main. Again, I'm happy to take a look

As for lua 5.4, I am afraid there isn't enough horsepower in dev community right now to both develop lua features and playing catch-up updating it all to 5.4, branches would diverge too much too quick. We need to either rip the band-aid and switch, or commit to having 5.1 for foreseeable future.

EDIT: Or, as a matter of fact, we can postpone the decision, but it would be worse of both worlds - as we continue to pile up 5.1 debt, increasing work it will take later

P.S. Here's a proposed PR for CODEOWNERS: https://github.com/orbitersim/orbiter/pull/552

 

[Gondos]

A reset did help. I managed to compile exactly once. It downloaded a bunch of stuff through vcpkg, but ultimately failed during install because for whatever reason it tries to install in c:/program files/
I used my usual workaround of deleting CMakePresets.json for it to install where I want but now the cmake cache won't regenerate. Restoring the file does not help.

1> CMake generation started for configuration: 'x64-Debug'.
1> Command line: "C:\Windows\system32\cmd.exe" /c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe"  -G "Ninja"  -DCMAKE_BUILD_TYPE:STRING="Release" -DCMAKE_INSTALL_PREFIX:PATH="C:\github\openorbiter\out\install\x64-Debug" -DCMAKE_C_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx86/x64/cl.exe" -DCMAKE_CXX_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx86/x64/cl.exe"  -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "C:\github\openorbiter" 2>&1"
1> Working directory: C:\github\openorbiter\out\build\x64-Debug
1> [CMake] CMake Error at C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.20/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
1> [CMake]   Could NOT find Lua (missing: LUA_LIBRARIES LUA_INCLUDE_DIR)
1> [CMake] Call Stack (most recent call first):
1> [CMake]   C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.20/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
1> [CMake]   C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.20/Modules/FindLua.cmake:233 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
1> [CMake]   CMakeLists.txt:284 (find_package)
1> [CMake] -- Configuring incomplete, errors occurred!
1> [CMake] See also "C:/github/openorbiter/out/build/x64-Debug/CMakeFiles/CMakeOutput.log".
1> 'C:\Windows\system32\cmd.exe' '/c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe"  -G "Ninja"  -DCMAKE_BUILD_TYPE:STRING="Release" -DCMAKE_INSTALL_PREFIX:PATH="C:\github\openorbiter\out\install\x64-Debug" -DCMAKE_C_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx86/x64/cl.exe" -DCMAKE_CXX_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx86/x64/cl.exe"  -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "C:\github\openorbiter" 2>&1"' execution failed with error: ''C:\Windows\system32\cmd.exe' '/c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe"  -G "Ninja"  -DCMAKE_BUILD_TYPE:STRING="Release" -DCMAKE_INSTALL_PREFIX:PATH="C:\github\openorbiter\out\install\x64-Debug" -DCMAKE_C_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx86/x64/cl.exe" -DCMAKE_CXX_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx86/x64/cl.exe"  -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "C:\github\openorbiter" 2>&1"' returned with exit code: 1'.

no more time to play with that crap for today

 

[jarmonik]

Out of curiosity I tried to compile this branch and got nowhere.

Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.22631.
The C compiler identification is MSVC 19.29.30153.0
The CXX compiler identification is MSVC 19.29.30153.0
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x86/cl.exe - skipped
Detecting C compile features
Detecting C compile features - done
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x86/cl.exe - skipped
Detecting CXX compile features
Detecting CXX compile features - done
Found LATEX: C:/Program Files/MiKTeX/miktex/bin/x64/latex.exe   
Looking for MFC
Looking for MFC - found
CMake Error at C:/Program Files/CMake/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find Lua (missing: LUA_LIBRARIES LUA_INCLUDE_DIR)
Call Stack (most recent call first):
  C:/Program Files/CMake/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
  C:/Program Files/CMake/share/cmake-3.21/Modules/FindLua.cmake:233 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:284 (find_package)


Configuring incomplete, errors occurred!
See also "C:/Software/VS-RepoMainClean/CMakeFiles/CMakeOutput.log".

 

[CaptainSwag101]

I was successfully able to build this experimental branch, but initially got an error similar to the folks above. However, my Visual Studio gave me a banner (which I regrettably did not take a screenshot of) telling me that my CMake toolchain needed to be regenerated because it was out of date. When I chose to do so, it triggered vcpkg to download all the packages and I was able to then generate my CMake cache and build without any problems. For additional context, I have already been able to successfully build Orbiter from source for a few years, and I simply changed my git branch over to this new one. I don't know if that makes a difference compared to a fresh clone of the repository, etc.

 

[jarmonik]

After downloading and installing LUA 5.4.2 and manually providing a path to LUA library and includes. Previous step passed, now it wants ZLIB and I can't find a place where to enter the paths.

Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.22631.
Found Lua: C:/Software/LUA/lua54.lib (found version "5.4.2")
CMake Error at C:/Program Files/CMake/share/cmake-3.31/Modules/FindPackageHandleStandardArgs.cmake:233 (message):
  Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)
Call Stack (most recent call first):
  C:/Program Files/CMake/share/cmake-3.31/Modules/FindPackageHandleStandardArgs.cmake:603 (_FPHSA_FAILURE_MESSAGE)
  C:/Program Files/CMake/share/cmake-3.31/Modules/FindZLIB.cmake:202 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:285 (find_package)


Configuring incomplete, errors occurred!

Could there be a configuration file of some kind that could contain the paths ? So that there's no need to type the paths every time when changing a branch or doing something else requiring a re-configuration. But for now keep the "main" clean of vcpkg until it's in a working condition what ever that supposed to be.

 

[Kozak]

It is in working condition - vcpkg packages work correctly without additional input if vcpkg is installed and CMakePresets.json is used (or vcpkg toolchain is specified, if ignoring CMakePresets)

However, if the developers don't want to use new tools, then it's obvious there is no place for new tools. Disregard the question asked in the original post of this topic.

 

[Gondos]

I don't see a vcpkg module in the VS2019 Tools & Features, is it only available in later versions?
I need to git clone vcpkg and manually specify C:/github/vcpkg/scripts/buildsystems/vcpkg.cmake as my CMake toolchain file for it to work.
Using the provided CMakePresets.json always end up the same :

[539/540] Install the project...
  -- Install configuration: "Debug"
  -- Installing: C:/Program Files (x86)/Orbiter/Orbiter/Scenarios
  CMake Error at cmake_install.cmake:36 (file):
    file INSTALL cannot make directory "C:/Program Files
    (x86)/Orbiter/Orbiter/Scenarios": No such file or directory.
 
 
  FAILED: CMakeFiles/install.util
  cmd.exe /C "cd /D C:\github\openorbiter\out\build\windows-x64-asan && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -P cmake_install.cmake"
  ninja: build stopped: subcommand failed.
Install succeeded.

Removing it now installs successfully in ${projectDir}/out/install but when launching the exe, it complains about a missing zlib1.dll file.

 

[Gondos]

Lua 5.1 is about 20 years old. So, an update is something what should be considered. But then again, DX9 is more than 20 years old and upgrade has been on mind many times but the truth is that DX12 or Vulkan only offers 2 or 3 features that would be useful to us and none of them been important enough to go through it, more important things has taken the priority.

I guess that LUA 5.4 could be developed in a separate branch and when the functionality matches the functionality of 5.1 it could be merged.

We don't tell JPL to stop using SPICE because it's coded in Fortran77...
I'm not worried about functionality but about loosing the possibility to switch to LuaJIT for a non negligible performance improvement. It's maintained and supported on Windows, linux and Mac, on x86 and x64.
Sadly so far I haven't managed to build the 5.4 version to see how it performs in comparison. Personnally I don't care about the new features introduced since 5.1, YMMV.

 

[Urwumpe]

We don't tell JPL to stop using SPICE because it's coded in Fortran77...
I'm not worried about functionality but about loosing the possibility to switch to LuaJIT for a non negligible performance improvement. It's maintained and supported on Windows, linux and Mac, on x86 and x64.
Sadly so far I haven't managed to build the 5.4 version to see how it performs in comparison. Personnally I don't care about the new features introduced since 5.1, YMMV.

LuaJIT is restricted to 5.1 because their main developer does not like 5.4. I really wish we could get over this kindergarten. Also, I really care about constants being constants and not being accidentially globally overwritten by a typo in an add-on, causing a moloch of bugs that is really terrible to debug.

What is IMHO pretty important, bad Lua code can cause quite some damage to Orbiter, so error handling and error isolation should be important principles. And 5.4 is way better in that context compared to the older 5.1 language standard. Also I don't get a "We use 5.1 because we always used 5.1 before" argumentation*, especially since Lua on Orbiter just lately became more interesting and we have the chance now to define what kind of scripting language will be used for the future before we have a large user base for Lua in Orbiter.

Also, in that context: Forget performance. Bad code with high performance only means we can crash Orbiter faster. Not get better add-ons. Also, we have the option to port performance critical Lua code to C++ code in Orbiters Lua environment. We have no urgent performance problem at all. Its all open source, add-on/vessel specific extensions are possible, so why are we even mucking about the need for a JIT compiler to make bad software almost as fast as good software?

I am pretty sure, its even already possible to provide generic C++ extensions of Lua in Orbiter, which could also mitigate multi-platform problems if we get a proper SDK toolset to support native Lua and Windows versions of modules.


* And the same argumentation made people stick to IE and Java 1.6 in really security critical applications despite both being a security nightmare for many years. Or still use a CATIA R6 version that even Dassault does not want to know about anymore.

 

[GLS]

Building the docs requires so-many additional tools that build must work without it.

The last time I built the docs in the main, before the release, the documentation was actually "OFF" and the rest was building fine. The only issue I remember was lua requiring XRSound, but that seems to have been fixed.

I guess that LUA 5.4 could be developed in a separate branch and when the functionality matches the functionality of 5.1 it could be merged.

Agree, freeeze lua development in the main (i.e., don't merge any lua PRs into there) and work the new lua in a branch. If the new stuff doesn't work, the main will still have 5.1.

 

[Lucy]

Yes, all the 5.4 work has been isolated to a separated branch to keep the mainline stable where it is in this regard. I don't really have particularly strong feelings one way or the other from the perspective of using 5.1 or 5.4; my concerns around this are pretty limited to what's easier to package, deploy, and ultimately build on non-windows systems. This is the end-goal that's driven us down the path of asking the question anyway, because the actual desired end result is introducing VCPKG and using it to handle the dependencies. It seems like that's causing some issues of its own, though, which doesn't spark much joy.

 

[jarmonik]

I got the VCPKG to work finally. I don't know what was the problem initially.

1) I cloned the CVPKG repository from the Git and declared env variables VCPKG_ROOT="C:\path\to\vcpkg"
2) Build "preset" was changed from "<custom>" to "x86 Release" This has never been issue before. Looks like it fails if I set it back to "<custom>" so this appears to be critical.

• Looks like the stuff needed to build XRSound is not included in vcpkg
• Build is very slow because multi-core build is disabled in this branch and main. There is PR to fix it.

103>C:\Software\OrbiterRepositories\OrbiterMain\Sound\XRSound\src\XRSoundEngine.h(28,10): fatal error C1083: Cannot open include file: 'irrKlang.h': No such file or directory

Here's the log.

Running vcpkg install
Fetching registry information from https://github.com/microsoft/vcpkg (HEAD)...

Detecting compiler hash for triplet x64-windows...

A suitable version of powershell-core was not found (required v7.2.24).

Downloading PowerShell-7.2.24-win-x64.zip

Successfully downloaded PowerShell-7.2.24-win-x64.zip.
Extracting powershell-core...

A suitable version of 7zip was not found (required v24.9.0).
Downloading 7z2409.7z.exe

Successfully downloaded 7z2409.7z.exe.
Extracting 7zip...

A suitable version of 7zr was not found (required v24.9.0).
Downloading 44d8504a-7zr.exe

Successfully downloaded 44d8504a-7zr.exe.

Compiler found: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe

Detecting compiler hash for triplet x86-windows...

Compiler found: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x86/cl.exe

The following packages will be built and installed:
    catch2:[email protected] -- C:\Users\jnikk\AppData\Local\vcpkg\registries\git-trees\f61acaeefdf6127fa878f7192fc109fa8e1a0135
    lua[core,tools]:[email protected] -- C:\Users\jnikk\AppData\Local\vcpkg\registries\git-trees\a25521a101ee330fd29139a6d4f377be3d814326
    luafilesystem:[email protected]#6 -- C:\Users\jnikk\AppData\Local\vcpkg\registries\git-trees\4b474bdcc3f49eef949ba79ad3294556e39af778
  * vcpkg-cmake:x64-windows@2024-04-18 -- C:\Users\jnikk\AppData\Local\vcpkg\registries\git-trees\a10a94e8d0071ed4804d40d0f0f0c5e4e7180afd
  * vcpkg-cmake-config:x64-windows@2024-05-23 -- C:\Users\jnikk\AppData\Local\vcpkg\registries\git-trees\97a63e4bc1a17422ffe4eff71da53b4b561a7841
    zlib:[email protected] -- C:\Users\jnikk\AppData\Local\vcpkg\registries\git-trees\3f05e04b9aededb96786a911a16193cdb711f0c9
Additional packages (*) will be modified to complete this operation.

Restored 0 package(s) from C:\Users\jnikk\AppData\Local\vcpkg\archives in 221 us. Use --debug to see more details.

Installing 1/6 vcpkg-cmake-config:x64-windows@2024-05-23...
Building vcpkg-cmake-config:x64-windows@2024-05-23...
C:\Users\jnikk\AppData\Local\vcpkg\registries\git-trees\97a63e4bc1a17422ffe4eff71da53b4b561a7841: info: installing overlay port from here

-- Installing: C:/Software/VCPKG/packages/vcpkg-cmake-config_x64-windows/share/vcpkg-cmake-config/vcpkg_cmake_config_fixup.cmake

-- Installing: C:/Software/VCPKG/packages/vcpkg-cmake-config_x64-windows/share/vcpkg-cmake-config/vcpkg-port-config.cmake

-- Installing: C:/Software/VCPKG/packages/vcpkg-cmake-config_x64-windows/share/vcpkg-cmake-config/copyright

-- Skipping post-build validation due to VCPKG_POLICY_EMPTY_PACKAGE

Stored binaries in 1 destinations in 43.5 ms.
Elapsed time to handle vcpkg-cmake-config:x64-windows: 117 ms
vcpkg-cmake-config:x64-windows package ABI: 44935fdfbef2fb5efc8c1926d743b1bb9f3c3cd9c37b1f1b376f03906cbe8e60
Installing 2/6 vcpkg-cmake:x64-windows@2024-04-18...

Building vcpkg-cmake:x64-windows@2024-04-18...
C:\Users\jnikk\AppData\Local\vcpkg\registries\git-trees\a10a94e8d0071ed4804d40d0f0f0c5e4e7180afd: info: installing overlay port from here

-- Installing: C:/Software/VCPKG/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/vcpkg_cmake_configure.cmake

-- Installing: C:/Software/VCPKG/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/vcpkg_cmake_build.cmake

-- Installing: C:/Software/VCPKG/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/vcpkg_cmake_install.cmake

-- Installing: C:/Software/VCPKG/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/vcpkg-port-config.cmake

-- Installing: C:/Software/VCPKG/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/copyright

-- Performing post-build validation

Stored binaries in 1 destinations in 32.8 ms.
Elapsed time to handle vcpkg-cmake:x64-windows: 118 ms
vcpkg-cmake:x64-windows package ABI: 63de85fc5f558d60084d44d627794895aa2ede1d9f72eabf38c3cb191824ba19
Installing 3/6 catch2:[email protected]...
Building catch2:[email protected]...

C:\Users\jnikk\AppData\Local\vcpkg\registries\git-trees\f61acaeefdf6127fa878f7192fc109fa8e1a0135: info: installing overlay port from here

-- Note: catch2 only supports static library linkage. Building static library.

Downloading catchorg-Catch2-v3.6.0.tar.gz

Successfully downloaded catchorg-Catch2-v3.6.0.tar.gz.

-- Extracting source C:/Software/VCPKG/downloads/catchorg-Catch2-v3.6.0.tar.gz

-- Applying patch fix-install-path.patch

-- Using source at C:/Software/VCPKG/buildtrees/catch2/src/v3.6.0-67626b634e.clean

-- Configuring x86-windows

-- Building x86-windows-dbg

-- Building x86-windows-rel

-- Fixing pkgconfig file: C:/Software/VCPKG/packages/catch2_x86-windows/lib/pkgconfig/catch2-with-main.pc

-- Fixing pkgconfig file: C:/Software/VCPKG/packages/catch2_x86-windows/lib/pkgconfig/catch2.pc

Downloading msys2-mingw-w64-x86_64-pkgconf-1~2.3.0-1-any.pkg.tar.zst

Successfully downloaded msys2-mingw-w64-x86_64-pkgconf-1~2.3.0-1-any.pkg.tar.zst.

Downloading msys2-msys2-runtime-3.5.4-2-x86_64.pkg.tar.zst

Successfully downloaded msys2-msys2-runtime-3.5.4-2-x86_64.pkg.tar.zst.

-- Using msys root at C:/Software/VCPKG/downloads/tools/msys2/21caed2f81ec917b

-- Fixing pkgconfig file: C:/Software/VCPKG/packages/catch2_x86-windows/debug/lib/pkgconfig/catch2-with-main.pc

-- Fixing pkgconfig file: C:/Software/VCPKG/packages/catch2_x86-windows/debug/lib/pkgconfig/catch2.pc

-- Installing: C:/Software/VCPKG/packages/catch2_x86-windows/share/catch2/copyright

-- Performing post-build validation

Stored binaries in 1 destinations in 5.3 s.
Elapsed time to handle catch2:x86-windows: 29 s
catch2:x86-windows package ABI: d95522ee24f18b501dca5a5d29bf12c0ea35361ca878dda18b0512326d860146
Installing 4/6 lua[core,tools]:[email protected]...
Building lua[core,tools]:[email protected]...
C:\Users\jnikk\AppData\Local\vcpkg\registries\git-trees\a25521a101ee330fd29139a6d4f377be3d814326: info: installing overlay port from here

Downloading lua-5.4.6.tar.gz

Successfully downloaded lua-5.4.6.tar.gz.

-- Extracting source C:/Software/VCPKG/downloads/lua-5.4.6.tar.gz

-- Applying patch vs2015-impl-c99.patch

-- Applying patch fix-ios-system.patch

-- Using source at C:/Software/VCPKG/buildtrees/lua/src/lua-5-3c3fafab78.clean

-- Installing: C:/Software/VCPKG/buildtrees/lua/src/lua-5-3c3fafab78.clean/cpp/CMakeLists.txt

-- Configuring x86-windows

-- Building x86-windows-dbg

-- Building x86-windows-rel

-- Installing: C:/Software/VCPKG/packages/lua_x86-windows/share/lua/usage

-- Installing: C:/Software/VCPKG/packages/lua_x86-windows/share/lua/copyright

-- Performing post-build validation

Stored binaries in 1 destinations in 246 ms.
Elapsed time to handle lua:x86-windows: 9.5 s
lua:x86-windows package ABI: 797342d8a171a0f919723878f336d54371237d1c18ed5ea9702cacfbacb5d3fe
Installing 5/6 luafilesystem:[email protected]#6...

Building luafilesystem:[email protected]#6...
C:\Users\jnikk\AppData\Local\vcpkg\registries\git-trees\4b474bdcc3f49eef949ba79ad3294556e39af778: info: installing overlay port from here

Downloading keplerproject-luafilesystem-v1_8_0.tar.gz

Successfully downloaded keplerproject-luafilesystem-v1_8_0.tar.gz.

-- Extracting source C:/Software/VCPKG/downloads/keplerproject-luafilesystem-v1_8_0.tar.gz

-- Using source at C:/Software/VCPKG/buildtrees/luafilesystem/src/v1_8_0-c1862256cf.clean

-- Configuring x86-windows

-- Building x86-windows-dbg

-- Building x86-windows-rel

-- Installing: C:/Software/VCPKG/packages/luafilesystem_x86-windows/share/luafilesystem/copyright

-- Installing: C:/Software/VCPKG/packages/luafilesystem_x86-windows/share/luafilesystem/usage

-- Performing post-build validation

Stored binaries in 1 destinations in 104 ms.
Elapsed time to handle luafilesystem:x86-windows: 4.2 s
luafilesystem:x86-windows package ABI: d9dd12845bdf81a87685f9c7ec8455c9932f3d6eccfc048a7dad9f65100025e8
Installing 6/6 zlib:[email protected]...
Building zlib:[email protected]...
C:\Users\jnikk\AppData\Local\vcpkg\registries\git-trees\3f05e04b9aededb96786a911a16193cdb711f0c9: info: installing overlay port from here

Downloading madler-zlib-v1.3.1.tar.gz

Successfully downloaded madler-zlib-v1.3.1.tar.gz.

-- Extracting source C:/Software/VCPKG/downloads/madler-zlib-v1.3.1.tar.gz

-- Applying patch 0001-Prevent-invalid-inclusions-when-HAVE_-is-set-to-0.patch

-- Applying patch 0002-build-static-or-shared-not-both.patch

-- Applying patch 0003-android-and-mingw-fixes.patch

-- Using source at C:/Software/VCPKG/buildtrees/zlib/src/v1.3.1-2e5db616bf.clean

-- Configuring x86-windows

-- Building x86-windows-dbg

-- Building x86-windows-rel

-- Installing: C:/Software/VCPKG/packages/zlib_x86-windows/share/zlib/vcpkg-cmake-wrapper.cmake

-- Fixing pkgconfig file: C:/Software/VCPKG/packages/zlib_x86-windows/lib/pkgconfig/zlib.pc

-- Using cached msys2-mingw-w64-x86_64-pkgconf-1~2.3.0-1-any.pkg.tar.zst.

-- Using cached msys2-msys2-runtime-3.5.4-2-x86_64.pkg.tar.zst.

-- Using msys root at C:/Software/VCPKG/downloads/tools/msys2/21caed2f81ec917b

-- Fixing pkgconfig file: C:/Software/VCPKG/packages/zlib_x86-windows/debug/lib/pkgconfig/zlib.pc

-- Installing: C:/Software/VCPKG/packages/zlib_x86-windows/share/zlib/copyright

-- Performing post-build validation

Stored binaries in 1 destinations in 120 ms.
Elapsed time to handle zlib:x86-windows: 6 s
zlib:x86-windows package ABI: 260296a8a7c6c1374cb3eb4d4976d63244d9ff8dd1bb709ffe187c80a043839c

Total install time: 48 s

catch2 provides CMake targets:

  # this is heuristically generated, and may not be correct
  find_package(Catch2 CONFIG REQUIRED)
  target_link_libraries(main PRIVATE Catch2::Catch2 Catch2::Catch2WithMain)

catch2 provides pkg-config modules:

  # A modern, C++-native test framework for C++14 and above (links in default main)
  catch2-with-main

  # A modern, C++-native, test framework for C++14 and above
  catch2


Use this package via the module FindLua that comes with CMake. To use in your CMakeLists.txt:

    find_package(Lua REQUIRED)
    target_include_directories(main PRIVATE ${LUA_INCLUDE_DIR})
    target_link_libraries(main PRIVATE ${LUA_LIBRARIES})


luafilesystem provides CMake targets:
 
  find_package(unofficial-luafilesystem CONFIG REQUIRED)
  target_link_libraries(main PRIVATE unofficial::luafilesystem::lfs)


The package zlib is compatible with built-in CMake targets:

    find_package(ZLIB REQUIRED)
    target_link_libraries(main PRIVATE ZLIB::ZLIB)


Running vcpkg install - done
Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.22631.
The C compiler identification is MSVC 19.29.30153.0
The CXX compiler identification is MSVC 19.29.30153.0
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x86/cl.exe - skipped
Detecting C compile features
Detecting C compile features - done
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x86/cl.exe - skipped
Detecting CXX compile features
Detecting CXX compile features - done
Found LATEX: C:/Program Files/MiKTeX/miktex/bin/x64/latex.exe
Looking for MFC
Looking for MFC - found
Found ZLIB: optimized;C:/Software/VS-RepoMainClean/vcpkg_installed/x86-windows/lib/zlib.lib;debug;C:/Software/VS-RepoMainClean/vcpkg_installed/x86-windows/debug/lib/zlibd.lib (found version "1.3.1")
CMake Warning (dev) at Src/Module/LuaScript/LuaInterpreter/CMakeLists.txt:57 (add_custom_command):
  The following keywords are not supported when using
  add_custom_command(OUTPUT): POST_BUILD.

  Policy CMP0175 is not set: add_custom_command() rejects invalid arguments.
  Run "cmake --help-policy CMP0175" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at Src/Module/LuaScript/LuaInterpreter/CMakeLists.txt:70 (add_custom_command):
  The following keywords are not supported when using
  add_custom_command(OUTPUT): POST_BUILD.

  Policy CMP0175 is not set: add_custom_command() rejects invalid arguments.
  Run "cmake --help-policy CMP0175" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.
This warning is for project developers.  Use -Wno-dev to suppress it.

Found existing irrKlang at C:/Software/OrbiterRepositories/OrbiterMain/Extern/irrKlang/x86
Configuring done (130.9s)

 

[DaveS]

to what's easier to package, deploy, and ultimately build on non-windows systems.

In this case, I would propose putting the various methods through a simple, yet effective test: Create a bunch of VMs that do not have anything beyond what the O/S itself provides and then see how fast you can get the proper binaries outputted. By doing this test, you will eventually parry things down to the very best and fastest ones. Remember that simplicity is key here! Any time you spend in the set up phase is to be counted against the method, not for it. So basically, download, build and go that is what should be the objective here, not the fanciest and most modern and most popular or even your own preference!

When you're done with this test, reset everything and see if you can't build things starting from zero. Place yourself in the position of someone who has never encountered Orbiter before, so zero experience. Keep at it until you hit the goal of having your own built Orbiter in no more than 15 minutes starting from scratch with zero build errors with the sources from Main.

This will lead to success.

 

[Gondos]

LuaJIT is restricted to 5.1 because their main developer does not like 5.4. I really wish we could get over this kindergarten. Also, I really care about constants being constants and not being accidentially globally overwritten by a typo in an add-on, causing a moloch of bugs that is really terrible to debug.

What is IMHO pretty important, bad Lua code can cause quite some damage to Orbiter, so error handling and error isolation should be important principles. And 5.4 is way better in that context compared to the older 5.1 language standard. Also I don't get a "We use 5.1 because we always used 5.1 before" argumentation*, especially since Lua on Orbiter just lately became more interesting and we have the chance now to define what kind of scripting language will be used for the future before we have a large user base for Lua in Orbiter.

Also, in that context: Forget performance. Bad code with high performance only means we can crash Orbiter faster. Not get better add-ons. Also, we have the option to port performance critical Lua code to C++ code in Orbiters Lua environment. We have no urgent performance problem at all. Its all open source, add-on/vessel specific extensions are possible, so why are we even mucking about the need for a JIT compiler to make bad software almost as fast as good software?

I am pretty sure, its even already possible to provide generic C++ extensions of Lua in Orbiter, which could also mitigate multi-platform problems if we get a proper SDK toolset to support native Lua and Windows versions of modules.


* And the same argumentation made people stick to IE and Java 1.6 in really security critical applications despite both being a security nightmare for many years. Or still use a CATIA R6 version that even Dassault does not want to know about anymore.

I pushed to have the Lua stuff available before the 2024 release so that devs can make addons for OO2024 that have a shot at staying compatible with a future 64bit version or for other platforms without recompilation. Every suggestion you make of using C++ goes contrary to that objective. If devs need to set up a C++ environment just to make a C++ version of one operation that is too slow to run with the interpreter, they might as well stay with C++. Their content will also probably be for one platform only.
Being able to create an addon without having to setup Visual Studio is appealing for some.
Your argument about performance meaning only to crash faster is the stupidest thing I have ever heard in 25 years of software engineering. Never had a const save the day either. I fight BS like that at work already, I'm not going to also spend energy here.

 

[Urwumpe]

Your argument about performance meaning only to crash faster is the stupidest thing I have ever heard in 25 years of software engineering. Never had a const save the day either. I fight BS like that at work already, I'm not going to also spend energy here.

Fine for you. In my 25 years (++), I had lots of senseless optimizers, who disappeared from the team (often with the backing of our then-CEO) for days only to come back with some microseconds saved once per month or who customers who complained about 5 minutes more run-time for a 12 hour job or discussed g/day differences in math. Thus also the "Crash faster" - nothing is as stupid as going on optimizations when the specs are still bad and much about to change. Or worse: When the baseline algorithm isn't yet tested in production yet (but that doesn't apply to Orbiter). This only gets you fast bugs, not a gain for the customer. Also, it is pretty anti-agile, since you hinder change with it.

And if "const" does not save your day or the lack of a const does not make problems: Be glad to be in such a protected safe environment. I have worked with people who would even change the communication protocol between web services unilaterally. Or who copied the definition for this communication into any service using them, instead of refering to a common definition. Thats my environment. Where your composite team members can be your worst enemies at the same time, since they have a different employer and their own set of goals. Programming defensively is a pretty sane choice then.

Also, maybe thats my HPC past, but delegating math heavy stuff to kernels is no heresy for me. Same for refactoring a complex script to push more work to Java or even C functions and make the script easier to maintain or change. Especially since not even a JIT compiler can compete with low-level code written by somebody, that knows where the seams are.

But know what? Do your stuff, I'll do mine.

 

[jarmonik]

The build was successful with the vcpkg using vs-generator how ever the ninja approach by following these https://www.orbiter-forum.com/threads/guide-orbiter-development-in-visual-studio-2019.40144/ instructions doesn't work at all, no sign of vcpkg getting enabled or doing any work there and configuration fails to LUA.

1> [CMake] CMake Error at C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.20/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
1> [CMake]   Could NOT find Lua (missing: LUA_LIBRARIES LUA_INCLUDE_DIR)
1> [CMake] Call Stack (most recent call first):
1> [CMake]   C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.20/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
1> [CMake]   C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.20/Modules/FindLua.cmake:233 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
1> [CMake]   CMakeLists.txt:284 (find_package)
1> [CMake] -- Configuring incomplete, errors occurred!

 

[Gondos]

Fine for you. In my 25 years (++), I had lots of senseless optimizers, who disappeared from the team (often with the backing of our then-CEO) for days only to come back with some microseconds saved once per month or who customers who complained about 5 minutes more run-time for a 12 hour job or discussed g/day differences in math. Thus also the "Crash faster" - nothing is as stupid as going on optimizations when the specs are still bad and much about to change. Or worse: When the baseline algorithm isn't yet tested in production yet (but that doesn't apply to Orbiter). This only gets you fast bugs, not a gain for the customer. Also, it is pretty anti-agile, since you hinder change with it.

And if "const" does not save your day or the lack of a const does not make problems: Be glad to be in such a protected safe environment. I have worked with people who would even change the communication protocol between web services unilaterally. Or who copied the definition for this communication into any service using them, instead of refering to a common definition. Thats my environment. Where your composite team members can be your worst enemies at the same time, since they have a different employer and their own set of goals. Programming defensively is a pretty sane choice then.

Also, maybe thats my HPC past, but delegating math heavy stuff to kernels is no heresy for me. Same for refactoring a complex script to push more work to Java or even C functions and make the script easier to maintain or change. Especially since not even a JIT compiler can compete with low-level code written by somebody, that knows where the seams are.

But know what? Do your stuff, I'll do mine.

You talk much yet contribute little. I'm working on a concrete porkshop plot MFD prototype to get representative performance results, not pulling some microseconds per month numbers out of my ass. Don't think that I'm not aware of the caveats of dynamically typed languages. There are better things than Lua 5.4 to help with that. For example there is Teal that is a typed Lua dialect (with support for <const> mind you) that can Transpile to Lua from version 5.1 to 5.4. It may be worth checking into that.
I see no urgency to switch to LuaJIT but keeping with 5.1 gives us options, switching to 5.4 will just closes the door.
Please don't be like that guy and const_cast<Brain *>(yourBrain).

 

[Urwumpe]

@Gondos: As I said earlier: Do your thing, I'll do mine.

I might not be the brightest candle on the cake, but I came around like Forest Gump.