Hi @Shahji and @matemoln,
Still stumbling into a lot of stuff that looks like isn’t just there yet.
The goal for the new native plugins is to behave similarly to the other language domain to allow for easy cross-domain build improvement from Gradle as well as 3rd party plugin. This will require new APIs which will take more times. Right now, we went the route of don’t the native work with the goal to replace the old plugin soonish. For example, integration with 3rd party plugin such as Artifactory Maven there are not tested and will most likely not work out-of-the-box. It will eventually work, but the focus isn’t on this now.
It is important to make the distinction between what doesn’t work with Gradle and what isn’t provided out-of-the-box. In general, there’s only a tiny fraction of things that doesn’t work with Gradle. Gradle’s richness allows pretty much anything to work, it may just be cumbersome to implement.
As an example, for a project, I was able to make the new native plugins cross-compile for bare metal ARM processors while provisioning both host and cross-compiler as shown in the samples. Some work had to be done, but as we move forward more and more will be handled by Gradle out of the box.
We use Qt in our project and one of the features it includes is autogenerating some connection logic code using a tool named moc.
I would advise against adding a dependency to your QtMocGeneratorTask from CppCompile. It’s too fragile. You should always prefer strongly modeling what you are trying to achieve. I suggest having a look at the source generation sample for an example on how to do this. Be advised there is a bug around consuming library with generated source files. You can inconveniently work around it by explicitly adding a task dependency on the source generated task in the producer project from the consumer project.
This is less useful at the moment without actually being able to define/differentiate between debug, release, profile, performance, etc.
I agree with you on this. We are lacking the concept of build type and are discussing how this should be migrated over from the old plugin. We want something more strongly modeled and haven’t achieved a consensus.
How do define multiple libraries/application outputs from single build.gradle subproject file?
As a design choice, the new plugins can only configure a single component per project. We may revisit this choice later but in a cross-cutting way with the JVM domain. That been said, it doesn’t mean you can’t share a single folder layout to constraint multiple libraries/applications. I suggest you have a look at the Swift package manager sample that share a single source folder across multiple projects thus creating multiple libraries/applications outputs from a single build.gradle.
The output libraries/dlls are named based on the project name, I guess. How do I change that? How would I do that for build files that generate multiple libraries/dlls?
By default, output file name is based on the subproject name. To change this, you need to set the component’s base name like this:
applications {
baseName = "some-app-name"
}
What’s the easiest way to globally change the output directory i.e. the “build” for all subprojects to be under one root? At the moment I am using this in each subproject but I would preferably like to do it in one place somewhere at the top level.
You can apply configuration to all projects using something like the following in your root build.gradle:
allproject {
buildDir = ...
}
I suggest you read the Authoring Multi-project Build chapter of the userguide.
How do I add a new tool chain?
The new plugins are still piggybacking on the software model configuration for the tool chains. See this section of the native chapter of the userguide.
Any examples of how to configure (path to exe, libraries to include, paths to system libraries, paths to system includes, etc) included tool chains?
There are several ways to achieve those specific configurations and configuring the tool chains may not always be solutions. I suggest having a look at the user guide section about the tool chains and tell us about your specific use case.
Any examples of using resource compiler for windows UI based binaries?
Unfortunately, this hasn’t been migrated over the new native plugin. It would need to be wired in like any source generation use case.
I have global macros defined for all macros in root project’s build.gradle so they are all in one place. I have an exception for one specific project where I have to remove the already defined macro. How do I remove from macros list?
At the moment, you would have to achieve this by reaching to the CppCompile tasks. However, this has lots of edge cases and is prone to have configuration order issues. It is best to model your macros as either 1) a separate extension or 2) opt-in configuration by calling methods. Option 1 may be overkill but would behave just like you are describing. The advantage is you can model what each macro means. Option 2 is a lightweight configuration scheme that each project opt-in. It’s more explicit and lacks the removing capability. Both options aren’t mutually exclusive.
Could you provide a few pointers on how to publish a package (includes headers and libraries) using pre-built binaries?
What you are looking is achieved inside the CMake library sample. More specifically, you would be looking at this part of the build wrapper plugin. The CMake build generate binaries that are considered as prebuilt libraries by Gradle. We have started the story around prebuilt libraries yet and would be curious to know more information about your use cases, more specifically:
- What library are you using?
- Are they built by 3rd party build tools? If yes, which build tools is used?
- Where do the binaries come from? Chocolatey, apt-get, conan.io, brew, plain installer, etc?
- Do you require only released binaries or do you expect to build the latest modification?
How do I include non .h includes in publicHeaders for publishing?
The publishing of the headers is handled by a Zip task. You would have to reach to that task and add your source files there. What use case do you have around adding non .h includes to be published? If those are “include” files to be ingested by another tool than the compiler, it would be better to publish them separately. The reason being this artifact will be able to be resolved independently of the headers which are especially important if the other tools don’t require the headers to function properly. For example, the protobuf .proto files should be published as another artifact.
What I came up with:
- define headers and binaries paths
- generate headers zip (zip task)
- generate module file
- publish headers, module file and libraries to maven repo (maven publish)
@matemoln This is a great, but fragile process of publishing prebuilt libraries. Although we document the module file format, manually generating it is bad practice. We always recommend modeling what you are trying to achieve through the Gradle public API. I suggest following a similar process as shown in the build wrapper plugin.
The problem I have is that I have to purge the gradle cache each time I update a package.
@matemoln Depending on how you publish/consume the library, you may be hitting the changing cache resolution strategy if you are using dynamic version range, or breaking the assumption that a released version should never change once published. Either way, you should be able to force the artifact to be fetched again by using the CLI flag --refresh-dependencies. Purging Gradle cache should be avoided as it’s location and implementation is internal to Gradle and may change (unlikely, but we don’t want users to purge the cache manually).
I would guess there would be a way to extend existing artifact.
The artifact publication is still quite internal, but we aim to provide some public APIs for extension through plugins.
I’ve asked around about creating the module metadata file via an api multiple times, but haven’t got an answer.
The module metadata is in full development which makes answering questions hard. We should have at least answer something and, for that, I’m sorry for not providing the right guidance. It will be documented better soon-ish.
Do you have an example that I can work off of? What’s needed is a ‘cpp-api’ plugin just like ‘cpp-library’ and ‘cpp-application’.
You should be able to find your answer in the samples referenced above.
Thanks for all those questions, we always welcome community feedback and we are open to all use cases you are using in your native build. Don’t hesitate to ask more questions,
Daniel
