Hello @Daniel_L,
Appreciate the response and apologies for the lack of communication on my part. There was a little too much to digest from your last response and took a little longer. 
QtMockGeneratorTask is supposed to run only on files that have changed. If not depend on CppCompile then how do I achieve this relation?
This is a serious limitation, especially when porting existing big codebases. We have lots of small modules that generate multiple smaller libraries and also generate one big shared library or application. The internal smaller modules (which are usually static libraries) can be used as external dependencies. A simple example is like a plugin architecture - the headers defining the interface for writing plugin is used by our own plugins but also build as a separate library for anyone else to use it.
We have a whole slew of library dependencies. We have extensive variety in what’s “prebuilt”. In fact, we wish to publish everything we do also as prebuilt libraries. Depending on the platform and where the library comes from the tool used to build itself can be different. We have some built using make, some Nant, cmake, visual studio, xcode packages, waf, ninja, .Net assemblies, and may be more. Many of these we don’t ever intend to build. Some of these we have don’t even have source code. These are prebuilt, prepackaged third party libraries. I don’t think we should focus on where or how these are built. That’s a deep rabbit hole. Focus should be we have cases where we need to package and publish any combination of headers, libs and dlls. And I mean any permutation of these - including only headers (rapidxml, rapidjson, boost), only libs (testing frameworks, partial libs), and only dlls (directx runtime).
P.S. I will open a separate discussion to discuss publication pipeline. Will include specific examples wherever possible.
Inline implementation of functions are typically (not a standard but a good practice) in a separate file which gets included at the end of the header file explicitly. The extension used is typically ‘.inl’. Regardless there are other third party libraries we use which use .hpp and .hxx when they want to call out private headers which are still included from the public headers but are not intended to be used outside the package itself. We have other use cases as well with library specific file extensions with proprietary implementation.
Attaching code I wrangled together using the referenced project to post prebuilt library. Comments/corrections are welcome
Prebuilt.zip (4.2 KB)
I tried to support the case of “headers only” scenario which I managed to publish but failed to resolved dependencies when referenced.
More questions below -
- How to refer to “headers only” dependency in other projects - using api or implementation or something else? I got it working with using api for libraries projects but the same won’t work for applications For application, use of api dependency throws errors.
library {
dependencies {
api “com.xyz:rapidxml:dev” // This works
}
}
application {
dependencies {
api “com.xyz:rapidxml:dev” // This doesn’t work
}
}
- Are macros exported from libraries, for both prebuilt and built? When a library is built there are certain macros which are public and are required to be included by everybody who references the library as a dependency. Is this something that’s supported and if not how can I workaround to get this working? Note that the dependency can be a published package and so these public macros will have to be somehow be included in the generated manifest or something. This should be part of transitive dependency support.
- Any option to publish project source as a package?
- Current publication pipeline publishes 3 binaries for each module - headers , debug and release (or in future, headers and a binary for each variant). Any reason to split these into so many pieces. Why not just publish a single binary with all in it. In an ideal world, I would like to define what the published binary should include.
- For transitive dependencies, how do I add additional include paths. For instance, for the following hierarchy -
include
MyModule
PlatformA
MyModule
PlatformAHeader.h
MyModuleHeader.h
I declare the include folder as ‘publicHeaders’ and that would resolve dependencies like “MyModule/MyModuleHeader.h” but not “MyModule/PlatformAHeader.h”. The files however are there in the folder since calling put include (the root) as the publicHeader would include everything below. How do I include include/MyModule/PlatformA as another exported header path without actually having a second copy of the files in the packaged archive.
One approach is to exclude the folder from the root and explicitly include the subfolder. That basically flattens the hierarchy. I would rather not do that because there is a risk of overwriting files in that scenario if the subfolder names happen to be the same.
- More in detailed question to follow in a new thread in context to publishing.