Fix win scons #359
Fix win scons #359
Conversation
SConstruct
Outdated
| elif platform == "win32" and subprocess.call(['where', '/Q', 'makensis']) == 0: | ||
| env.VariantDir("#build/pkg", "pkg/win") | ||
| SConscript("build/pkg/SConscript") | ||
| #elif platform == "win32" and subprocess.call(['where', '/Q', 'makensis']) == 0: |
There was a problem hiding this comment.
This needs to be uncommented or otherwise fixed before I can merge it.
There was a problem hiding this comment.
The installer part is having weird problems. I didn't want to deal with it because I think an auto-updating deployment target like Itch or Steam is preferable to having an installer at all.
There was a problem hiding this comment.
Putting it on Itch or Steam is fine, but we should support a standalone installer build as well for the benefit of people who don't like using services like Itch or Steam. What kind of weird problems was it having? Maybe there's an issue of using deprecated NSIS stuff or something…
| FLAC | ||
| bz2 | ||
| brotlidec | ||
| brotlicommon |
There was a problem hiding this comment.
Something seems to be wrong here. What on earth is "brotli", and why is bz2 being bundled when we don't use it?
I don't think we use vorbis/ogg/FLAC, either, though it wouldn't hurt to include it for use by mods someday. Including freetype is fine.
There was a problem hiding this comment.
I agree it seems wrong, but the Visual Studio build outputs all of those DLLs, and the scons build won't launch without them bundled.
There was a problem hiding this comment.
What do you mean it "outputs" all of those DLLs?
There was a problem hiding this comment.
They're all in the build directory Visual Studio outputs, and if you rename one of them to something else, the binary won't launch.
There was a problem hiding this comment.
So then the question is, what exactly is causing them to be required? They shouldn't be required, since we don't use them anywhere. Are they transitive dependencies of something else? If so, the something else should be built in a way that doesn't require them.
|
I can't get the 32-bit build to work locally despite quadruple-checking all the lib paths. The compiler isn't finding Zlib, but I'm 100% sure I have an x86 build of zlib installed where scons is checking for it. This is frustrating. I want to suggest separating out some concerns. Without the PR, we have these problems:
With the PR, the situation becomes:
I would suggest that we do this:
|
I'm not certain that it ever worked. When I built on Windows, I (almost?) always used MSVC 2013, not scons. I agree on points 1, 3, and 4. For point 2, I would like the installer generation uncommented, but it can be set to run only if explicitly requested (so, running |
|
I did all the things. |
|
Is it okay to squash all of this into a single commit? And if so, do you want to write up a summarized commit message? |
|
I'm pretty comfortable squashing all of this one without doing a summary. 🤷♀️ |
There's some messiness in this PR with trying things, reverting them, etc. It should probably all be squashed, but I can now make a build with scons on Windows that actually launches.