This message was deleted.

I don't know about M1 support, but you might want to have a look at https://nokee.dev/

Is the base plugin free?

I'm not aware it costs anything at all. As far as I know it is FOSS. What makes you think it costs?

just asking.

@daniel Nokee is not commercial, is it? Does it support M1 macs?

Basically, this commit gives gradle M1 support. So my question is can this be done manually within a version 6.0.1 build.gradle file: https://github.com/gradle/gradle/commit/35455d90c9bb16390cf10fef81e4b9da9f658c15

It's not possible to do without using a lot of internal API. Using internal API, there is almost always a way to hack something into Gradle. :) But it's quite complicated to wrap your head around it. Nokee usually doesn't help in cases of unsupported architectures/tool chains, as it also builds on top of what Gradle core provides in this area. I am in the process of creating a sample of how you can use the Tasks for native compilation without the whole toolchain setup around it. The goal is to use them for embedded development (cross-compile for other architectures). I don't know if it helps in your case, but maybe: https://github.com/jjohannes/plain-c

There is a lot to unpack here and I can see some misinformation around native support in Gradle as well as over simplification. First off Nokee is free. It’s the continuation of the native support in Gradle. I’m pretty much the reason native support exists in Gradle in the first place and Nokee is a continuation of this work.

Nokee usually doesn’t help in cases of unsupported architectures/tool chains, as it also builds on top of what Gradle core provides in this area.

As far as this comment, it’s not true that Nokee doesn’t help for unsupported architectures/tool chains. It may be “more complicated” than what it should be, but it’s definitely possible to build for M1 using the latest snapshot. Nokee fixed several issues with the “newer” native support (aka `cpp-library`/`cpp-application`) around architecture supports.

I am in the process of creating a sample of how you can use the Tasks for native compilation without the whole toolchain setup around it. The goal is to use them for embedded development (cross-compile for other architectures).

It’s an interesting idea, and I would be curious how this actually work in real life project. I done about 4-5 different modelling for native as part of Nokee to explore and question the “older” and “newer” core native support and a simple “per-task” approach usually hits a wall pretty early. The current Nokee modelling focus on the middle model (variant management). Recently, we worked on composition which would be more of the higher level but it’s not the main focus at the moment. Task-level will be tackled as some point but I doubt it will ever bit the main focus because of all the other modelling that users needs in order to create a functional native build. In general, the task level is what Nokee calls the source sets which include source/headers management, incoming compile dependencies, toolchain management (local, remote), source/target compatibility, and compile task. As we can see compiling sources requires quite a bit of elements to work together. This is not to say that it cannot be approximated, but then you hit the chance of having weaker up-to-date checking or requiring to have intimate knowledge of the tool to use for building which defeats the core idea of native support in Gradle.