This message was deleted.

I’m aware some links are currently broken with Nokee documentation. It’s unfortunate and hoping to get them fix soon. With regards to native support in Gradle, the only continuous native development is Nokee. I’m hard at work 7 days a week on that. I may not have progress as much as I would have hoped but the current work is mostly focused on backend support to allow for all the complexity the native ecosystem brings to build management. Generally, build systems takes the easy way out which is managing a single variant at a time. Gradle historically manage all variant together which is most powerful. For that specific issue, Nokee may be affected as well given we still rely on Gradle core for toolchain discovery. We would love to move away, it’s a matter of figuring out what is the most pressing issue at the moment. I have noticed a recent change under Windows that I have to investigate. I will post back once I have more information. The MSVC discovery has some issues that I would love to improve. We want toolchain to be resolved the same way any dependencies are resolved which tied modernizing the MSVC discovery and 3rd party repository support (like Conan) together.

Thank you so much for your reply, Daniel. Kudos to you for your hard work on both Gradle and Nokee.dev. Just to be clear, the original issue I mentioned seems to only be a problem if I try to specify the MSVC toolchain install path using the model API. If I actually install MSVC2019 on the machine, it somehow miraculously works. However, the company I work for insist on maintaining third-party dependencies using source control to ensure 100% reproducible builds (i.e. using the same toolchain across the board). Some exceptions has been made w.r.t. android and others where it is controlled by the SDK or the OS itself. I suspect, we'd want to keep even those under revision control. The larger concern I have is Gradle's native development support is slowly becoming dated with almost little to no effort in keeping it up to date. While Nokee.dev seems like a viable alternative, and is kept up to date. It lacks the backing of Gradle, Inc. What would be very helpful is if there was a promise to yet again include Nokee.dev as a part of the standard distribution, or at least keep taking snapshot of the releases.

What your company is doing is actually a very good practice to reproduce build. We usually call this “toolchain provisioning”. We have this sample that works for Clang and GCC (https://github.com/gradle/native-samples/tree/lacasseio/improve-provisionable-toolchains/cpp/provisionable-tool-chains). The issue with MSVC is how to get a standalone “archive” of the installed MSVC. I think for legal reason, we can’t redistribute a self-contained, vetted, archive with just the compiler. In recent years, they allow installing only the compilers but Gradle checks some specific paths to “validate” the installation is “ok to use”. Unfortunately, that logic is quite annoying when doing toolchain provisioning. I would assume the MSVC dependency in your source control is missing one of those path. I may be just a matter of creating empty files to trick Gradle into thinking the installation is “ok to use”. When we take on the toolchain detection in Nokee, we want to make this process much more controllable in the sense that users should be able to express any toolchain easily. Easily is a big word here because there’s a lot of things that relate to a toolchain such as the standard C library, the target architecture, the host architecture, etc. Ideally, we should have a deeper understanding of the MSVC installation and treat that as a “remote repositories” to pull all the various tools and libraries as dependencies. The Gradle’s native development support may lack some maintenance but in general it’s still pretty good at supporting most native development scenario. What is lacking is conveniences to make the task much more painless. This is where Nokee steps in, we really want to create a painless environment to support native ecosystem. We are still addressing some debt most specifically a way to easily configure and compose complex native models. We provide basic models but those never quite cut it for complex native project. Instead, we want to provide the flexibility to compose native models that fully represent what you are building. Our general guideline is build complexity should be logarithmic not exponential. I agree Gradle should make a statement about their native support. Nokee’s statement is to provide a painless native support for Gradle. It would be great to include Nokee in Gradle in some shape or form but that may go against the general idea of reducing Gradle distribution and instead focus on modules. We released a plugin that tries its best to bridge the gap between Nokee and Gradle. We hope to add more capabilities for distribution management (especially for airgap environment).