Taskranger really needs scons install. There's env.Install, but that unfortunately doesn't work well with virtualenv on Linux. Might need to get creative with this one :blobsweat:

This is a shared issue for all Windows-related issues up until the release. After the release (or at some arbitrary point), Windows-specific issues should be posted as separate issues.

("the release" refers to the first working version, and not necessarily 1.0.0. This will be labeled when we get that far)

This is pending documentation updates, because I have no clue how to migrate. May be done before or after v3.0.0 is properly released - I really don't care. They've hit the preview phase, which means it's almost stable, and that's good enough for me to start migrating - as long as there's docs on usage of V3 anyway.

I hate making issues purely for testing, but I forgot opening a PR wasn't enough :')

https://docs.microsoft.com/en-us/windows/console/setconsolemode?redirectedfrom=MSDN

here we go again...

SCons 4.0.0 was recently released, but in an issue in the SCons repo (3736), an update issue was pointed out that breaks the entirety of SCons, and by extension, Taskranger's build process. This is a Windows-only problem, because the filesystem is case-insensitive and doesn't allow SCons and scons. Linux and Mac remains unaffected.

The workaround is renaming the scons package folder to SCons. C:\python38\lib\site-packages\scons is one example of where it's found - this obviously depends on whether virtualenv is used or not, and what version of python, etc. Use some common sense when locating the directory.

I have no idea what consequences renaming has (if any), but the directory can always be purged manually if necessary.

I swear these <things have broken> issues are turning into "The beacons of CI have been lit!". On the bright side, it wasn't Windows' fault for once 😂

Conan is broken. Specifically, the SCons generator in Conan doesn't include system_libs, which breaks our fresh addition to the dependency list, icu.

I raised an issue upstream, but to save myself work, I'm just going to temporarily disable the build portion of the CI. I could manually add the libraries and blah blah blah, but I'm really not in the mood for hacking stuff together for something I get to remove next Conan release.

Conan has a frequent release schedule; this issue will be closed when a fix is implemented, and said fix is included in a release. Based on their previous release schedule, this shouldn't take more than a couple weeks. In the meanwhile, the debug builds work fine. If their general release schedule pointed to the next release being in several months, I'd be more inclined to add a workaround.

This issue should in theory only affect Linux and Windows when the build is in release mode. The Windows build might just break in general. Linux has been held together by the undefined behavior sanitizer (which conveniently linked -ldl -lpthread, hence why only debug mode worked), but I have no idea if anything else links in the system_lib used on Windows, so that might break entirely. The issues started appearing because of tests that used the date API. Not gonna lie, I'm surprised the CI built at all after I added the library, but I guess it's just a coincidence.

_{Just for fun, I decided to cross-reference with my other project based on the same build architecture as this project, and there were a few dependencies that conveniently held together the entire repo, purely by coincidence. It not breaking in the entire time I used it is pretty much a miracle}

Anyway, someone assigned themselves the issue and fixed it, so it's kinda done. Unfortunately, the effects won't be seen until the 1.28 release, which isn't gonna be tonight, for obvious reasons. There's gonna be a little while between it being merged and the fix becoming usable. In the meanwhile, stuff might compile, but there's a fairly decent chance some build configurations just won't compile. This doesn't mean support for anything is cut off, and I'll get back on track as soon as Conan gets an update. I'm gonna continue working on Taskranger in the meanwhile, which might accidentally break more stuff (I'm not exactly known for writing perfect code on the first go 😂). OS support will just be wobbly for a little while, and possibly broken, but I will fix that as soon as I can.

See #10 - running 10 builds (5 for push, 5 for pull_request) on PRs from develop does not work. I can't find any decent workarounds for this atm that doesn't mess with CI on develop.

Post-"fix" edit:

The specific bug referenced has been fixed with the help of a friend of mine. MSVC's JIT error popup in a headless CI bullshit remains unchanged. The CI will remain active until the next time this happens - MSVC will still screw over the CI the next time there's an error, and I can't bother someone who happens to run Windows every single time MSVC decides to resist exiting. Windows support is on an extremely thin thread until this issue gets addressed - the core issue with MSVC preventing program exit and preventing the error from showing up where I can see it is still real, and might risk killing off Windows support eventually.

Background

This has been triggered by 554d071

MSVC pushes some JIT debugging bullshit into GitHub actions. It being headless means the popup is not possible to control. In the event of an error, the tests will never succeed or fail.

There's currently a bug that makes the Windows tests fail. The JIT bullshit is preventing me from fixing it. Taskranger on Windows is effectively broken until the details get worked out. I have no idea what's wrong either, because the JIT debugging is preventing me from getting any information. I also don't have easy access to a MSVC Windows box to test on, so I won't.

I've asked around, but if I don't get an answer there by tomorrow, I'm going to stop trying, because pouring all my time and effort into MSVC isn't something I want to do. I hate MSVC. It's so backwards in so many ways, and working to maintain support to it when pretty much all solutions fail is something I can't do. There might be some easy way to solve this that I'm completely missing, but all my attempts have failed, and I can't keep spewing out more commits to run CI over and over For Science:tm:

This issue is written in the likely event my asking around leads nowhere, and no windows support is a legitimate concern.

Proposed solutions

Attempts:

• Delete JIT debugger: 0417b60
• Delete registry keys: d180724
• Try-catch: 1b59c08
• Windows API hackery: 45366b7

Proof of concept:

• Catching should work: b1e060c

Implications

Until this issue is closed, Windows will be disregarded.

if my questions lead nowhere, starting tomorrow (June 19th 2020), no more CI time will be allocated to Windows tests.

Until CI is back up and running, Taskranger on Windows is classified as broken. Windows support is still a goal, but if MSVC decides to continue to be an absolute fucking cunt, I can't work towards it. No automated testing on Windows can and should be interpreted as a sign that Taskranger doesn't work on Windows. A major part of the purpose behind running the CI is being able to debug issues. If the Windows CI fails to live up to that, it will be stopped.

Pull requests fixing Windows issues are still welcome. I want to be able to support Windows, but without access to or a desire to get access to a Windows box, I have nothing aside the CI to tell if Taskranger is broken. That's why MSVC breaking the CI classifies as Windows support being broken.

Finally, if anyone happens to know how to suppress the GUI popups or otherwise make the tests fail properly, a PR or a comment on this issue is more than welcome. Fundemental issues in the way MSVC is handled should be addressed in this repo instead (SConsStandard is a submodule in this repo used to cut down buildscript code)

Pretty much the title. It's nearly identical, but -lm -lstdc++ has been appended to the link phase. I have no idea why - I'm suspecting a change to GitHub actions is screwing me over again, but I have no idea where to start to debug that.

I swear I spend more time debugging GH actions than I do coding...