I have just started out with Gradle and am looking at migrating from “Make” to “Gradle” for my Embedded C project. I am using the C plugin. My structure has a main project and many sub-projects within it. With Make, I usually build partially linked object files of all source sets within my sub-projects and then employ a second phase of link on these partially linked objects to build my complete software. I would like to replicate the same using Gradle.
As part of linker.args within my Native Gradle model, I have passed the arguments -r --warn-common . However, the name of the object file in the $buildDir/exe/{$component.name} location is just component_name and not component_name.o like how it was in case of Make. Am I to believe that Gradle has somehow understood what I needed it to do or has it built an executable in some other way?
Thanks for your question. In Gradle, we usually specify what work you want to do as oppose to how you want to do the work. Partially linked objects were not part of the original scope for the development of the native support. However, that doesn’t mean it’s not possible. It will simply require more work than your typical scenario.
Gradle works with conventions. That means, for an NativeExecutableSpec the output will be, by convention, in $buildDir/exe/${component.name} and, depending on which OS you are targeting, the file extension will vary. On *nix system, there usually aren’t any extension for the executable which differs for Windows system where .exe is used. For NativeExecutableBinarySpec and SharedLibraryBinarySpec binaries, the linker ld (for Gcc/Clang and link for Visual C++) is used.
Those are all convention regarding what you want to do. Specifying the arguments -r --warn-common should have done your partial linking. However, due to the convention in place, the output file doesn’t have the .o extension. This is where the confusion starts happening. It will be a bit difficult to use this object file through the dependency management in the native support. The fastest way is to use linker.args where you want to use it.
The cleanest solution would be to model what you are trying to achieve by extending the native software model to create a convention that you can apply everywhere else. I would suggest opening a feature request through Github issue so we can prioritize and work on the limitation. There are several ways we can improve this scenario, but we would be grateful is you could share a real world scenario with us.