Is there a mechanism to define an API dependency on a separate NativeLibrarySpec in an assembler sourceset for a NativeLibrarySpec or NativeExecutableSpec? Similar to the c/cpp lib dependency mechanism.
I have a scenario where I have a set of c/cpp header files in a NativeLibrarySpec(LibA). In a separate NativeLibrarySpec(LibB) I have a set of c/cpp and asm files. LibB is set to have a header/api linkage dependency on LibA for both the c and cpp sourcesets. This works perfectly, however, I am unable to find a way to do the same for the assembler source set.
One of the assembler source files contains a #include to a C header, with the current setup, it fails as the header is not in the include path.
As a temporary work around I have manually defined the include path in the assembler args but this is not a clean solution, where i would like this to resolve automatically in the same fashion as the c/cpp header sets.
Thinking more generally it would be useful for the same NativeLibrarySpec to be able to internally reference c/cpp headers defined in its c/cppsourceset within the assembler sourceset. Is that possible too?
Any guidance would be appreciated.