Daniel I just wanted to see if it is possible to feature request something for nokee. Add a way to include args both before and after the libraries, object files, and source files are added to a link or compile task. Just ran into a case where a customer need an arg before the link libraries. Turns out in the current gradle built in plugins, there is no way to do this. To make it more annoying, GCC and MSVC are different. MSVC puts args before link libraries, gcc puts them after. https://github.com/gradle/gradle/blob/master/subprojects/platform-native/src/main/[…]dle/nativeplatform/toolchain/internal/msvcpp/LinkExeLinker.java https://github.com/gradle/gradle/blob/master/subprojects/platform-native/src/main/[…]org/gradle/nativeplatform/toolchain/internal/gcc/GccLinker.java If I could access systemArgs I could make it work, but that is fully inaccessable.

That is definitely something that I want to do at some point. It’s basically controlling the argument ordering. There was a few idea that I floated around but the one that I believe would be the most powerful is deep modelling of the arguments. Instead of passing argument as string, arguments would be passed as opaque objects that each have different meaning. This would remove the need for special properties (macros, includes, libs, etc.) and focus on a way to declare all arguments in a single collection. The idea would be to allow toolchain to react to each model and provide the correct flags. For example, a user include vs system include would be different flag on GCC/Clang but may have a different ordering on MSVC. As for the ordering of the arguments, since each argument are models, we would could make them

Comparable

and allow for an ordering phase. Finally for per source file arguments, we can add flags that stipulate it only applies to certain files or a subset of files. With the ability to self-mutate Gradle properties (something that we may just support in Nokee types) we can remap the full arguments to include those repeating group (to support circular symbols dependencies). All this thinking was the main reason why the current compile and link task do not expose all the Gradle properties. However, I may just have to go through a deprecation cycle…. Feel free to open an issue, we can put some though into it and come up with a good model.

It's actually Linux I'm having the issue on, and specifically the linker. I can use the escape hatch for compiler args, but not linker args.

The fact that it's not fully wire up seems to be a bug in Gradle.

Yeah it probably is.

That's unfortunate, I really wish I had more time to complete the migration from core types in Nokee. 😥