How to publish a header only module and how to refer to it again as a dependency? AFAIK, there are only two ways to call out dependencies either ‘api’ or ‘implementation’. api doesn’t work for applications and implementation requires a library. Typical examples of this use case are rapidxml, rapidjson, jasmine json, boost, and many many more.
How to publish multiple libraries and single set of headers. Here’s an use case with Qt -
Qt comes with many (around 50 or so) prebuilt binaries. Most project will not use all or in fact many of them. Publishing each library as a separate library opens door for cases where one library version may not play well with other library version. Plus, the headers might also be different. Plus more intricate issues like order of header includes will start to matter. The ideal scenario is to package all headers and libraries into a single package but with the ability to dictate what sub-library from it to use as a dependency. This is something similar to what current qmake (build system for Qt) does.
qt += core
qt += gui
qt += network
core, gui and network are sub modules of the bigger qt module. Each submodule in itself has defined publicHeaders, libraries and macros. Assuming a root folder named ‘include’ and ‘lib’
core module =>
includes => include/, include/QtCore/ <== Note two folders here
libs => lib/QtCore/QtCore.lib
gui module =>
includes => include/QtGui/
libs => lib/QtGui/QtGui.lib
network module =>
includes => include/QtNetwork/
libs => lib/QtNetwork/QtNetwork.lib
application {
dependencies {
implementation ‘com.xyz:qt:1.2.3.4’ {
include core
include gui
include network
}
}
}
Is there any examples in the current samples or existing plugins that I can model for something like this. Also, what would the input for something like this look when defining the artifacts?
Hi @Shahji, there are several ways QT dependencies can be solved today.
The easiest solution to centralize all QT module version is to use a property. Often, this property would be placed inside the gradle.properties file of your project. This is how Kotlin ensure a single version is used. For example, your dependencies would look like this:
Your solution is making an assumption that each qt module is released independently. We would prefer not to go that route, if possible. Currently we release the whole of QT i.e. all modules as a single versioned package. Projects has the option to selectively add dependencies on individual module.
BTW, Qt is only an example but this problem does exist for multiple different projects. For example, OpenSSL has similar problem. It has two libraries and they go hand-in-hand. Splitting them is not a sustainable option for the long term - both in maintenance and usuability. Qt will be even bigger problem in long term maintenance with its nearly 50+ modules.
On the other front, there are other libraries which are very small and splitting them as header and libraries as separate packages seems a hammer solution. We have projects with a single header and single implementation file. Ideally, these tiny packages will be published with the header, implementation and the prebuilt library, all in a single package.
Is there a webpage or some way to see what’s in development and coming down the pipe? Anyway to influence what and how features get prioritized?
Your solution is making an assumption that each qt module is released independently. We would prefer not to go that route, if possible.
I will ask for a Gradle engineer with more experience than me with the dependency engine to comment on this.
Is there a webpage or some way to see what’s in development and coming down the pipe? Anyway to influence what and how features get prioritized?
These development have lots of consideration to take into account which makes it hard to pre-announce them. Some of those features are driven internally others are driven by sponsorship. The best way to get a feel of what features is coming in Gradle is to look at the samples repositories and the commit logs. You can also look at the pull requests been opened by members. If you can spare a bit more wait, you can look at the release note of RCs and GA. As you can see, we don’t have a formal process to announce features, especially when it’s not ready for public users.
Without sounding too salesy, Gradle is always ready to consider sponsorship for high-value features for enterprise wanting to bump those features at a higher priority. Without sponsorship, the Gradle team choose what is the most pressing for the community and the direction we, as a company, want to take. As an example, the original native support was a sponsorship initiative that I lead in my previous job with Gradle.