I would like to know if there are some example of model migration from the cpp plugin to the cpp-application plugin?
We are facing cache issues with cpp plugin and there is this simple project I could try to migrate to test the benefits of the new plugin. The thing is that it is not me that wrote the cpp model and before I ask the developpers to migrate, I would like to know the gain we can achieve with new plugin.
Is there a way to do that without learning both cpp and cpp-application plugins?
Sorry for the late reply, I’m usually more active in the #native Slack channel over on the Gradle Community Slack or under Nokee (GitHub - nokeedev/gradle-native: The home of anything about Gradle support for natively compiled languages). A incremental migration between the cpp and cpp-application is possible but would require some work to expose the artifacts generated by the cpp plugin to the cpp-application plugin. Depending on how you use the cpp plugin it may be quite trivial. Also it’s best to first convert consumer project vs producer project. Converting producer project first can be a bit more challenging as you would have to handle dependencies in the software model.
I have worked on both the software model (cpp) and current model (cpp-application) plugins. Now I’m the owner and maintainer of the Nokee plugins which provide everything around native support. They are very similar to the cpp-application plugin. I can answer questions on any of those plugins.
Ok thanks Daniel for the reply. Our model is quite complex using the cpp plugin. I attached one of our model so you can see by yourself the size of it. My problems are:
1- The time it takes to build seems long (compared to cmake)
2- The way the cache is used is not clear (The time it takes to validate the cache takes longer than recompiling for some projects)
3- Changing few lines of code will often rebuild a lot more code than it should for unknown reason
I know gradle is more java oriented, I have the feeling cpp will always be second class citizen in gradle am I right?
If I do the migration to get the same kind of behaviour I prefer not to try it.
From looking online it seems to me the new cpp-application has lot less support and help than cpp plugin. Most of what I find is related to the cpp plugin.
I am now considering calling cmake from gradle to have better control on my cpp building.
In theory, you should be able to improve on all the issues mentioned without any kind of migration. Nokee still has some small feature set missing to be on part with the cpp plugin and cpp-application is built on top of the core under the cpp plugin.
From the symptom you mentioned, it seems like Gradle is reaching too far in which files it considers for each component. It’s a common misconfiguration. There may be other issues, but I would start with that first. My guess is with the includes. There is a known issue around macro includes #include MACRO which can throw off the include tree parsing and revert back to snapshotting all headers. For some dependencies, that can be a significant overhead.
Let me look at the model.gradle and get back to you shortly.
There is nothing that stands out. If I’m not mistaking, for the issue I pointed out previously, you should look for an info log similar to this one. If you run your build using -i you should be able to see if any macro includes are detected.
Is there any information available on migrating from cpp to cpp-application and cpp-library, or examples? We have complex c++ native application and I don’t see from what I have found for documentation that it would be supported under the new plugins. We have multiple sub-project folders, each with many libraries and executables (I don’t see how to specify naming of libraries (or support for such in a single build.gradle)). Our top level build.gradle is also very complex and not sure what and how everything is supported under new plugins. We have flavors, buildTypes, 16 platforms, 16ish toolchains, we use cppCompiler.withArguments, linker.withArguments, cppCompiler.define, linker.args, cppCompiler.args, (based on platforms, targets, buildType, etc.
In the build.gradles in subprojects, we define many libraries and executables, dependencies within and outside the project, with linkages of api or static.
Basically we push the limits of what native c++ was made for.