Skip to content
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

Build output map with empty war3map.j, on Raspberry Pi #978

Open
jmrico01 opened this issue Dec 8, 2020 · 9 comments
Open

Build output map with empty war3map.j, on Raspberry Pi #978

jmrico01 opened this issue Dec 8, 2020 · 9 comments
Labels

Comments

@jmrico01
Copy link
Contributor

jmrico01 commented Dec 8, 2020

Describe the bug

I recently got a Raspberry Pi 4, and decided it would be fun to use it as a CI runner for Wurst map builds. Since this is Java, it must simply work anywhere, right? Turns out, it almost works! However, it seems the output map has an empty war3map.j, even though the code is correctly compiled and saved in temp/output.j.

Environment is a Raspberry Pi 4 (ARM linux), with Java version:

openjdk 11.0.9.1 2020-11-04
OpenJDK Runtime Environment (build 11.0.9.1+1-post-Raspbian-1deb10u2)
OpenJDK Server VM (build 11.0.9.1+1-post-Raspbian-1deb10u2, mixed mode)

Starting only with my map project and WurstSetup.jar:

  1. java -jar WurstSetup.jar install wurstscript
  2. java -jar ~/.wurst/WurstSetup.jar install
  3. java -jar ~/.wurst/WurstSetup.jar build base.w3x -runcompiletimefunctions -injectobjects -stacktraces -noExtractMapScript -opt
  4. I move the output map in _build to a Windows machine and inspect with an MPQ editor. Everything looks good except war3map.j is 0 bytes. temp/output.j has all the code, though...

EDIT: I also tried replacing all java -jar ~/.wurst/WurstSetup.jar commands with the standard ~/.wurst/grill - same results.

compiler.log

Speculation

When I do a Windows build, compiler.log at first is similar/equal to the one in the Pi. After build is done, the previous logs get totally overwritten, and in the new ones, there is a final MPQ editing section with just Added file war3map.j and a few others. This suggests to me that there are 2 MPQ editing/packing passes in the Wurst build, # 1 with almost everything except the war3map.j, and # 2 with the rest. It's possible that the 2nd one just isn't running on the Pi. There is no Added file war3map.j log there.

EDIT: Just saw #937, not sure if that would address this. not relevant, nvm

@Frotty
Copy link
Member

Frotty commented Dec 8, 2020

You should use the package manager commands grill build etc. as described in the CI docker image https://hub.docker.com/r/frotty/wurstscript
#937 is only for the runmap command.

@jmrico01
Copy link
Contributor Author

jmrico01 commented Dec 8, 2020

Just tried ~/.wurst/grill build base.w3x, but it didn't seem to change anything. I also tried re-running the install step with grill, but still the same.

@Frotty
Copy link
Member

Frotty commented Dec 9, 2020

I misread the original post and thought u were calling wurstscript.jar instead of setup/grill. So except for some suspicious runargs it seems fine and should work. Can you check if grill build works correctly on your normal (windows?) machine to verify that it's a problem on the rasp only?

@jmrico01
Copy link
Contributor Author

Yep, been doing grill build base.w3x on my Windows machine, and everything works as expected. In the Pi, the war3map.j is 0 bytes but everything else is OK.

@Frotty
Copy link
Member

Frotty commented Dec 11, 2020

So it sounds like a jmpq issue since the output.j is correctly generated, but not inserted into the map?
Would probably need to investigate in that direction. The unit tests run on Linux, so it sounds like a more intricate problem.

@jmrico01
Copy link
Contributor Author

Yeah that sounds right. Weird because everything else gets inserted - I have an imports folder with a bunch of files, and those end up in the map no problem. My current workaround is to have a post-build step that inserts the temp/output.j into the built map as war3map.j.

@Frotty Frotty added the bug label Dec 15, 2020
@Frotty
Copy link
Member

Frotty commented Feb 11, 2021

any update on this?

@jmrico01
Copy link
Contributor Author

Not exactly the same environment, but I recently tried this on a new mac with an Apple silicon chip (ARM 64bit) and saw no issues. I also had to fix some pjass errors before the build fully worked, so now I'm wondering if it was those errors causing the issue to begin with. I can re-test on my raspberry pi in a few weeks.

@Frotty
Copy link
Member

Frotty commented Dec 28, 2023

Okay, might also have been fixed in the meantime. Some test case would be helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants