-
-
Notifications
You must be signed in to change notification settings - Fork 546
Upgrade janet to 1.27, add mingw workflow build #2155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
includes support for mingw builds, along with sandbox functionality needed to lock down io
After cloning and checking out an appropriate branch, I did something like the following (via an msys2 mingw64 terminal -- trying via an "ordinary" console arrangement ended in failure for me but using a msys2 mingw64 shell / terminal seemed to help):
That seemed to work here. Not sure if editing I also edited |
It didn't appear to be necessary. Removed the changes to Note that I already had what seemed to be the prerequisites listed in the build instructions from previous activities so I'm fuzzy on exactly what those bits are and how they got installed. I think many pieces were in place via scoop. Regarding |
ah good call on the janetconf.h, totally forgot about that. Ya Im not entirely what mingw does and where it sits.. I think its a windows implementation of common GNU library's, so you can build "as if" its on linux? If thats the case it would make intuitive sense that changes to the CMakeFiles.txt would not be necessary. I'll go through the janetconf and get that up to date |
I may also try my hand at adding a mingw build step to the github actions pipeline |
Hmm... I think a change to the config might be necessary after all, I still get an error when trying to build the Janet library while leaving the CMakelists.txt file "as is". |
Currently trying to build it on my end using mingw, should be possible on this branch with Janet being updated, sorry my laptop is not very fast. |
Possibly off-topic, but:
My confusion about this comes from statements such as:
I think what I've been using is the latter and the build instructions mention mingw-w64 (though in Quite confusing. |
@sogaiu That is what I am trying now. |
My understanding is that even if you have ming-w64 you still use the command |
Yeah, I agree. |
Looks like that did the trick! ################################
# Janet
################################
if(MINGW)
add_custom_command(
OUTPUT ${THIRDPARTY_DIR}/janet/build/c/janet.c
COMMAND mingw32-make build/c/janet.c
WORKING_DIRECTORY ${THIRDPARTY_DIR}/janet/
)
elseif(WIN32)
add_custom_command(
OUTPUT ${THIRDPARTY_DIR}/janet/build/c/janet.c
COMMAND ./build_win.bat
WORKING_DIRECTORY ${THIRDPARTY_DIR}/janet/
)
else()
add_custom_command(
OUTPUT ${THIRDPARTY_DIR}/janet/build/c/janet.c
COMMAND make build/c/janet.c
WORKING_DIRECTORY ${THIRDPARTY_DIR}/janet/
)
endif() |
So can confirm a change to the cmake file is necessary.
to
|
@NPO-197 Hmm, I thought it wasn't necessary here. I'll check again. |
Did you delete the libjanet.a file before rebuilding? |
I didn't verify, but I did run Ah you know, there is a |
Ahh, I don't have that must be why we are getting different errors. |
Then may be it's better to modify According to |
I got my distribution of mingw64 from the msys2 pakage which apparently doesn't have |
Yeah, I think "terminal" can definitely lead to problems. I'm not sure what would be good to replace it with. In my case I used MSYS2's MingW64 shell, but may be it's possible to end up with a MingW64 environment some other way? I gave up trying to find a way via https://www.mingw-w64.org/, but may be there is one. |
Oh but looks like the w64devkit one dose! So this would be on me for not using the distribution of mingw64 linked in the read me! |
Yeah It honestly might be better to just link to https://www.msys2.org/ in the readme instead of to https://www.mingw-w64.org/ and change the cmake for Janet to use |
I agree it is kind of vague as it stands. I haven't been following TIC-80 for very long and I don't know what else depends on |
for the readme wording, maybe we could say
|
Best idea so far :) |
any thoughts on whats going wrong with the workflow here? https://github.com/nesbox/TIC-80/actions/runs/4559234069/jobs/8042966444?pr=2155#step:5:36 I'll admit that I havent spun up a windows vm and tried building locally with mingw.. should probably try that, thought this seems like a ci/cd problem |
Puzzling. Is it correct that some of the output is a result of invoking A long shot, but perhaps output is intermingled by parallelization making interpretation harder? Possibly not using Also did a search for "cmake not able to compile a simple test program" and got hits, but not sure any were helpful. |
I looked at Possibly similar phenomena mentioned here: microsoft/LightGBM#3469 -- lots of theories in that issue. |
this seems pretty close to what im seeing https://stackoverflow.com/questions/59355908/mingw-c-compiler-not-able-to-compile-a-simple-test-program |
Chocolatey [1] was mentioned in the issue I linked above too. For your viewing pleasure, below is the C:\Program Files\MongoDB\Server\5.0\bin C:\aliyun-cli C:\vcpkg C:\cf-cli C:\Program Files (x86)\NSIS\ C:\tools\zstd C:\Program Files\Mercurial\ C:\hostedtoolcache\windows\stack\2.9.3\x64 C:\cabal\bin C:\\ghcup\bin C:\Program Files\dotnet C:\mysql\bin C:\Program Files\R\R-4.2.2\bin\x64 C:\SeleniumWebDrivers\GeckoDriver C:\Program Files (x86)\sbt\bin C:\Program Files (x86)\GitHub CLI C:\Program Files\Git\bin C:\Program Files (x86)\pipx_bin C:\npm\prefix C:\hostedtoolcache\windows\go\1.17.13\x64\bin C:\hostedtoolcache\windows\Python\3.7.9\x64\Scripts C:\hostedtoolcache\windows\Python\3.7.9\x64 C:\tools\kotlinc\bin C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\8.0.362-9\x64\bin C:\Program Files\ImageMagick-7.1.1-Q16-HDRI C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin C:\ProgramData\kind C:\Program Files\Eclipse Foundation\jdk-8.0.302.8-hotspot\bin C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0\ C:\Windows\System32\OpenSSH\ C:\ProgramData\Chocolatey\bin C:\Program Files\PowerShell\7\ C:\Program Files\Microsoft\Web Platform Installer\ C:\Program Files\Microsoft SQL Server\130\Tools\Binn\ C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\ C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\ C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\ C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\ C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\ C:\Program Files (x86)\Microsoft SQL Server\140\DTS\Binn\ C:\Program Files (x86)\Microsoft SQL Server\150\DTS\Binn\ C:\Program Files (x86)\Microsoft SQL Server\160\DTS\Binn\ C:\Program Files\OpenSSL\bin C:\Strawberry\c\bin C:\Strawberry\perl\site\bin C:\Strawberry\perl\bin C:\ProgramData\chocolatey\lib\pulumi\tools\Pulumi\bin C:\Program Files\TortoiseSVN\bin C:\Program Files\CMake\bin C:\ProgramData\chocolatey\lib\maven\apache-maven-3.8.7\bin C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code C:\Program Files\Microsoft SDKs\Service Fabric\Tools\ServiceFabricLocalClusterManager C:\Program Files\nodejs\ C:\Program Files\Git\cmd C:\Program Files\Git\mingw64\bin C:\Program Files\Git\usr\bin C:\Program Files\GitHub CLI\ c:\tools\php C:\Program Files (x86)\sbt\bin C:\SeleniumWebDrivers\ChromeDriver\ C:\SeleniumWebDrivers\EdgeDriver\ C:\Program Files\Amazon\AWSCLIV2\ C:\Program Files\Amazon\SessionManagerPlugin\bin\ C:\Program Files\Amazon\AWSSAMCLI\bin\ C:\Program Files (x86)\Google\Cloud SDK\google-cloud-sdk\bin C:\Program Files (x86)\Microsoft BizTalk Server\ C:\Program Files\LLVM\bin C:\Users\runneradmin\.dotnet\tools C:\Users\runneradmin\.cargo\bin C:\Users\runneradmin\AppData\Local\Microsoft\WindowsApps [1] Though it does have some things that scoop doesn't, I have felt the quality of Chocolatey stuff has been too variable for my taste and I have found scoop to have met my needs better. Perhaps there is no choice in this situation though? |
I noticed (lines 36-38):
I looked in the Windows environment I had success building with and I think there the path has |
OK! I've finally got what I think is the pipeline building using mingw, or at least mingw64 under msys2. This required way too many triggers of the pipeline, and stealing from the sdl2 github workflow config. The largest deviation is using the cmake msys makefiles generator instead of the mingw one.. though I think thats ok https://cmake.org/cmake/help/latest/generator/MSYS%20Makefiles.html#generator:MSYS%20Makefiles |
Includes support for mingw builds, however we may need to additionally make some edits to the CMakeList.txt.
Hopefully will address #2154