Linking `userenv` is failing

[fire]

I have no idea why. https://github.com/V-Sekai/godot/actions/runs/4897415488/jobs/8745444818

userenv is failing.

https://user-images.githubusercontent.com/32321/236567536-dd3a5a1c-d9e0-4c7d-81cf-4cd23b9dde88.png

[fire]

elif env["platform"] == "windows":
    env["LIBWASMERSUFFIX"] = ".a" if env.get("use_mingw") else ".dll.lib"
    if env.get("use_mingw"):
        env.Append(LIBS=["userenv"])
    else:
        env.Append(LIBS=["Userenv"])

Maybe fixes this?

[ashtonmeuser]

I'll dig out my dusty old Windows machine and investigate this. Haven't even taken a look but if you've got the time, try using the libraries used in SConstruct.

[fire]

'userenv.windows.template_release.x86_64.lib' is not a valid library name from Microsoft

[ashtonmeuser]

Sounds like it's using the library suffix inherited from Godot when it shouldn't be. Can we define it explicitly with env.File()?

The only reason this lib was included is this comment. What happens if we just drop it for MSVC builds?

[fire]

I won't be able to use godot-wasm then because our builds use llvm-mingw.

Oh you mean like block msvc, worth a try?

Like

if env.msvc:
  pass

[ashtonmeuser]

Sorry still out and about so just spitballing here. I'll take a closer look shortly. I'm definitely not saying we drop your use case! We'll figure it out!

[fire]

I think your suggestion worked, when https://github.com/V-Sekai/godot/actions/runs/4899298148/jobs/8749165531 finishes I 'll try to pr.

[fire]

Oh no. Apparently wasmer uses a .dll. Will have to investigate making it a static link later

[ashtonmeuser]

Amazing! Thanks for doing the legwork here. Feel free to open a similar PR against master for that long overdue contributor credit. Otherwise, I'll cherrypick.

[fire]

Closing because issue is resolved.

[ashtonmeuser]

Likely related to https://github.com/godotengine/godot/issues/23687. The same issue doesn't affect GDNative/GDExtension addons because I'm overwriting env["LIBSUFFIX"] in SConstruct. Hesitant to do the same thing in SCsub as it would be applied to the engine's env. Looking into this further.

[ashtonmeuser]

This seems like a deficiency of Godot and possibly Scons. Godot changing LIBSUFFIX seems pretty heavy handed and basically precludes modules from using Windows SDK libs.

That said, I've got an idea for a workaround involving Scons AddPreAction. This is run after compilation but before linking. Should be able to parse the auto-generated _LIBFLAGS and edit Windows SDK lib names.

[ashtonmeuser]

I went with the Ugly Fuck It Solution™ and added the Windows SDK libs directly to LINKFLAGS for MSVC builds which is explicitly recommended against by SCons. This seems to be a begrudgingly-accepted solution here: https://github.com/godotengine/godot/issues/23687. I'm sure there's a really clever workaround here but this'll do. This is well into the territory of a kludgy Godot idiosyncrasy.

@fire Give it a shot! I've also created #33 to eventually remove dependence on your Godot fork (which has been super helpful ❤️) and provide the engine with Godot Wasm baked in as a module.

[fire]

Testing now. Wait an hour :'(

[ashtonmeuser]

I'd love to know why Godot 4 builds so much slower.

[fire]

Cache doesn't work well when the build never succeeds because it starts from the last cache. (which is empty)

[fire]

Hype! The game template passed. Pending game editor.

[fire]

Passed. 🎉

[ashtonmeuser]

Cache doesn't work well when the build never succeeds because it starts from the last cache.

Great point! Woooooooooooo I see green 🎉🎉🎉 Next builds should be a little faster! Thanks so much for all your help with this!