On 20 Mar 2021, at 10:49, Frederik Seiffert <[email protected]> wrote: >> If you look at the build for libobjc2 on Windows, because we're using a >> CMake version that predates official support for either Objective-C or using >> the gcc-compatible driver, we have the same problem with /TP being added. >> We work around this with an undocumented feature of clang where you can >> provide an environment variable that removes flags from the command line. >> You can probably set that in your Visual Studio build. Setting this strips >> the TC and TP flags from clang invocations: >> >> CCC_OVERRIDE_OPTIONS=x-TC x-TP x/TC x/TP > > Good idea using CCC_OVERRIDE_OPTIONS, that should probably work fine. > Ultimately I’m hoping that we can come up with something more integrated like > a custom build tool spec in VS, so .m and .mm files automatically get all the > right flags.
It’s definitely not the *right* solution, but it should work for now. VS Code now has really good CMake support and I think it’s reasonable in VS as well. I’d love to see GNUstep adopt CMake - with the last release, it officially supports Objective-C and using clang with the gcc-like driver on Windows, so it would give us the ability to generate XCode projects, Visual Studio projects, and something that VS Code supports natively. >> It would be great at some point to remove the pthread-w32 dependency. >> SRWLocks and ConditionVariables on Windows seem to provide everything we >> need for NSLock* and be a fairly small amount of code. > > Yeah absolutely, I just wanted to make sure we could actually get this > working before spending time on improvements. I also expect to spend a lot of > time on fixes while integrating the toolchain in our project. The SRWLock APIs were introduced with Windows 7, as I recall. Last time I looked at this, there were enough XP machines that folks cared about that it didn’t make sense to use them, but now Windows 7 is effectively out of support so is a reasonable baseline. David
