A problem occurred configuring project ':CppUnit'.
> Exception thrown while executing model rule: model.components > withType()
> Could not get unknown property 'debug' for BuildType container.
* What went wrong:
A problem occurred configuring project ':CppUnit'.
> Exception thrown while executing model rule: model.components > withType()
> No such property: buildType for class: org.gradle.nativeplatform.NativeLibrarySpec
I see where you are coming from and the short answer is buildType is available at the binary level. Basically, a component is a grouping of binary. The binaries are the outputs of a component.
The longer answer have already been explored in great detail here. The solution is quite lengthy and an issue have been opened on Github to address this use case.
Thanks for you detailled explanations… I have another issue with gradle for building Poco. There is a need for a user’s defined output directory for NativeBinarySpec. Poco is using the following convention
the Poco’s project organization should be
Poco
--------bin
--------imp
--------lib\
where bin is the place to put all SharedLibraryBinarySpec and NativeExecutableSpec
where imp is the place to put all linking libs when using a dll (Windows concept is an import lib)
where lib is the place to put all StaticLibraryBinarySpec
Poco is using also the convention to suffix with a ‘d’ all components made with the debug buildtype, so that there is only one directory to put in PATH. A debug executable will use the proper debug dll while a release one will link with the released dll. that’s quite important because Poco is providing a portable and uniform API way to invoke dynamic link library both on Windows and Linux/Unix. The code is something like
Thanks for the great detail in the question. The BinaryNamingScheme is an internal API and I haven’t seen any discussion about making it public. The best step forward is really to use the answer I linked in my previous comment. The ground work is exposed there. The little missing detail is you should use the code inside a convention for your project. As the name say it’s a global configuration applied to all the project that need to follow a specific convention. The following code could be use to create a convention for all cpp project:
As we can see from this code, it will apply an action for allprojects that will only execute if the cpp plugin is applied. It will then proceed in adding the Debug and ReleasebuildTypes and configure NativeBinarySpec for all NativeComponentSpec. This is a convention as it will only do the work if specific condition are met for the entire project. The code is still a bit opinionated as it assume a Debug build type will be present. You could play around are remove this assumption in order to generalize event more the code. You can also only apply the convention on a subset of project by using subprojects or similar behavior.
Thank for opening a path to a solution to meet the poco requirment… I will try it. By the way, I would like to propose an extension that can abstract this issue. Why not using a target container as the sources one in the model/components. One could have something like
Your proposal answered to the point of making the name of the binary depending on the buildTypes, that’s ok. But there is another point to solve: the user’s defined outputDirectory for each binaries which are in my story fixed paths, and this not at install time but at build time (needed for unit testing the dll portable code)