Building Windows Binaries

[efroemling]

Hey folks,
I've finally gotten Windows builds wired up here so that its possible to compile them from source code instead of only using prefab binaries. (similar to the CMake Linux/Mac builds that have been available for a while).

See the docs here, but the basic idea is that you can type make windows-debug or make windows-release from a WSL command line and end up with a freshly compiled running game.

I'm hopeful this will allow people to help debug down some of the weird Windows issues that I can't reproduce such as this and will also allow people to play around with the low level physics/ui/etc. layers.

If anyone running Windows wants to give this a try, please post here how it goes or if you run into problems or if any instructions are confusing. I'd like to have this work 'out of the box' in as many cases as possible and want to add helpful tips or error messages for any problems people run into.

[TheMikirog]

Have been waiting for this for a while.
Now people won't let you sleep until you can make Android binaries.

[TheMikirog]

@efroemling After following the installation process, I've got two errors when I tried to make a debug build of Windows.

Then this appeared when I added sudo.

I thought all dependencies were installed with the tools/pcommand install_pip_reqs. How do I deal with this?
EDIT: Also I can confirm Python 3.9 is indeed installed, set as default and all requirements are satisfied, but for some reason the make file doesn't acknowledge it at all.

[Dliwk]

Though it could be a weird WSL thing too with something failing when it tries to run on a native windows dir.

This one. tar can't write timestamps to NTFS's files and emits this error (at least this is stated on several forums).

[TheMikirog]

Somehow I managed to get past that issue, but then another one appeared that prevents me from building anything.
Here's me running sudo make windows-debug. I have Visual Studio 2019 installed.

[efroemling]

Somehow I managed to get past that issue

Are you still getting the 'utime' error if you run it without sudo? Its always best to avoid sudo if possible, so I would hope there'd be another way we could get it working.

The build scripts basically just tell Visual Studio to build the project, so if its dying on that part it might be worth trying to open the project directly in visual studio and building or cleaning or fiddling with things from in there and see if you can get any different results. I'm not sure what the .props file is that it is referring to; I assume some internal Visual Studio thing.

[TheMikirog]

Are you still getting the 'utime' error if you run it without sudo?

make windows-debug? Nope. It just goes into building and gets stuck at the Visual Studio thing.

if its dying on that part it might be worth trying to open the project directly in visual studio and building or cleaning or fiddling with things from in there and see if you can get any different results.

I have no idea how Visual Studio even works, but I did use it at work just to press "compile", but alas, this button seems to be hidden or disabled if I open VS in the ballistica folder. The entire project either seems to not exist or is completely blank.

Am I even doing it right? Is there a project file hidden somewhere I can open and mess around with? If so, it wasn't mentioned in the documentation.

[brostosjoined]

Somehow I managed to get past that issue, but then another one appeared that prevents me from building anything. Here's me running sudo make windows-debug. I have Visual Studio 2019 installed.

HOW TO FIX

Simply download this files from the individual component on the visual studio installer

[efroemling]

It takes a bit of digging, but the last comment on the Building With Visual Studio section mentions checking out what the CI scripts here on GitHub do; they do some very basic setup and then run python tools/pcommand win_ci_binary_build, which lives in tools/batools/pcommand.py. Looking at that you should see a raw MSBuild command you could run or the path to the .vcxproj you could open in Visual Studio to do basically the same thing by hand. Hope that helps.

[efroemling]

so the extracted command you could run directly in windows would be something like:

"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\MSBuild.exe" ballisticacore-windows\Generic\BallisticaCoreGeneric.vcxproj -target:Build -property:Configuration=Debug -property:Platform=Win32 -property:VisualStudioVersion=16

[TheMikirog]

There is definitely some weird permissions stuff happening. Do things work correctly if you blow away the build dir and do a fresh build?

I went one step further and deleted the repo and did all the setup again while avoiding sudo. That didn't work, so I tried giving permissions to the build folder and project folder with chmod u+rwx. Didn't work.

I was wondering if moving to a Linux filesystem would be a fine move or would that just break Visual Studio more. Does VS need access to a Windows filesystem when working with files?

[efroemling]

I was wondering if moving to a Linux filesystem would be a fine move or would that just break Visual Studio more. Does VS need access to a Windows filesystem when working with files?

I would suggest giving it a try. Just clone the repo right under your home dir in WSL or whatnot. I saw that you had tried that before and ran into a warning before where it won't let you build if it appears that the repo is living in the Linux filesystem. But it also lists an environment variable you can set to disable that warning, so you should be able to at least try it. The reason I put that warning in was because the case-sensitivity of the linux filesystem was causing issues with visual studio trying to build there, but perhaps that has since been fixed. I think it would be great if we could do full builds in the linux filesystem since I imagine it would reduce weird permissions stuff that might come up with accessing the windows filesystem from WSL.

It also could be worth trying WSL2 if you're currently on WSL1 or vice versa.
And also, if you are able to get builds working through raw MSBuild commands or directly in Visual Studio, it should be possible to combine that with assets from a pre-built package or built through a prefab command or whatnot. Though I think just being able to use the 'golden path' build commands would be best since you'd get asset rebuilds and all that automatically.

In general that build path is pretty new so any bumps you can help find or smooth out is appreciated. I'm using it for all my windows builds, but it'd be great to have it work as well as possible for other people out of the box.

[TheMikirog]

I think it got worse. Now Visual Studio is not recognised at all despite everything I've done previously.

[TheNotEasy]

Then I got tons of "permission denied 13" errors when building.

Although this reply was a long time ago, but I will still write solutions for other people who also faced this problem.

Try change _sync_standard_game_data function to this in line 333

def _sync_standard_game_data(cfg: Config) -> None:
    import time
    import multiprocessing
    import shutil

    assert cfg.dst is not None
    _run('mkdir -p "' + cfg.dst + '/ba_data"')

    dst = os.path.join(cfg.dst, 'ba_data')
    start_time = time.monotonic()

    use_multiprocessing = True

    def copy():
        path = root.split("/")
        if not path:
            path = cfg.src + '/ba_data/'
        elif 'ba_data' in path:
            path = '/'.join(path[path.index('ba_data') + 1:len(path)])
        for folder in dirs:
            os.makedirs(os.path.join(dst, path), exist_ok=True)
        for file in files:
            shutil.copyfile(f"{root}/{file}", os.path.join(dst, path, file))

    last_process = None

    for root, dirs, files in os.walk(cfg.src + '/ba_data'):
        if use_multiprocessing:
            last_process = multiprocessing.Process(target=copy)
            last_process.start()
        elif not use_multiprocessing:
            copy()

    if last_process is not None:
        last_process.join()

    if __debug__:
        end_time = time.monotonic()
        print(f"End {end_time - start_time}")

You can change use_multiprocessing value depending on whether you want to use multiprocessing

[brostosjoined]

so the extracted command you could run directly in windows would be something like:
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\MSBuild.exe" ballisticacore-windows\Generic\BallisticaCoreGeneric.vcxproj -target:Build -property:Configuration=Debug -property:Platform=Win32 -property:VisualStudioVersion=16

The path says windows studio enterprise what about the community and professional