I took a look at gradle design docs and found the following:
design-docs/continuous-delivery-for-c-plus-plus.md
at line 1165 # Open issues
at line 1183 * Publishing and resolving RPM/DEB/NuGet/pkg-config/ etc.
It is very interesting to get pkg-config support implemented.
Also I would like to be able to export compiler/linker’s flags to dependent componetns (it is pretty close to what pkg-config does)
So I probably could contribute some code to this feature…
I actually took a look at source code and see that there is a good point to start:
./subprojects/platform-native/src/main/groovy/org/gradle/nativeplatform/NativeDependencySet.java
… @Incubating
public interface NativeDependencySet {
…
/**
* Returns the files to use at runtime.
*/
FileCollection getRuntimeFiles();
**/****
* **It would be great to add here something like this:**
***/**
**String getMyGreatCompilerAndLinkerFlagsIWantToExportToDependentNativeBinary(); // It is pretty much the same what pgk-config does**
}
…
It would be interesting to know what Founding Fathers of Gradle think about this feature.
Is it a good idea to export flags to dependent native components or not? Or maybe it is a wrong idea, and such change will never be accepted?
We definitely want to publish more metadata about a native library when we produce it. So as well as publishing the header files and binary files in a structured format, we’ll publish information about the dependencies of this binary, the platform it was build for, etc.
It seems like the pkg-config data model includes Requires and Requires.private for structured dependencies, but also allows the publishing of arbitrary compiler and linker flags. Before we decide to do something similar, I think we’ll want to determine the actual use cases for this. In general, we prefer to model the underlying problem domain rather than providing opaque configuration options.
Is your primary goal to produce packages that are compatible with pkg-config? For a native binary built with Gradle, what do you see as the main use cases for exported compile and link flags?
I certainly want to use preinstalled pkg-config packages, and create compatible packages
But the main idea is what exporing only -I -L and -l flags (or theirs analogs) is not suffisient for every project
For example, then using google mock framework, it is needed to compile project with -DGTEST_LINKED_AS_SHARED_LIBRARY=1 flag
In this case, the macro logically comes from the dependency from google mock framework rather than from toolchain settings
And I need to create prebuild library which exports this flag
The another example could be creating work around for bugs like https://svn.boost.org/trac/boost/ticket/6785
In this case, it is needed to create native prebulit library which represetns boost headers and exports -std=c++98 flag
Of course, creating workarounds like this is not a prinary goal of exporting compiler flags, but in this case it is useful to export (and propogate) them
I can now see why we might need to allow a library to ‘export’ compiler and linker flags in addition to the header files and link-time dependencies. For now, it would up to the consumer of the library to specify these flags, which would need to be documented with the library: not very convenient.
In many cases, we’d like to be able to model the actual requirements instead of simply exporting compiler/linker args. For example, it could be that for the Boost example the library could declare that it requires languageRuntime >= C++98. But for the google mock example, it seems like a simple case of a required compiler argument.
If you’re interested in taking this further, I would suggest starting a discussion on the Gradle Development mailing list (gradle-dev@googlegroups.com). That list is monitored by the actual “founding fathers” of Gradle, rather than just their lackeys like me .
.