I am attempting to use Gradle for a large C++ project with Boost Test unit test framework. While I am creating a Boost Test plugin to satisfy the need to use Boost Test I noticed that the default behavior of the NativeBinariesTestPlugin is to attach the sources of the NativeLibrary under test to the test binary. This is done by the @Finalize rule method attachTestedBinarySourcesToTestBinaries.
The result of this behavior seems to be that all sources will be compiled and linked directly with the test binary instead of having a static library linked with the test binary. In the GoogleTest plugin or the CUnit plugin this would result in two copies of the code getting compiled. With the approach I have to take for BOOST Test I find this to be unacceptable as there will be one test binary per test suite and that will create as many compilations of the sources as there are test suites. Even for the GoogleTest and CUnit cases I think the double compilation is unnecessary and unwarranted.
As a work around I am contemplating forking and fixing the NativeBinariesTestPlugin to make the problem go away but I wonder why this is done so? I cannot find a reason for this and it seems unnecessary IMHO.
This seems to be how it works even with the latest 2.7 release candidate.
I have successfully created a working BoostTest plugin that performs very well. I modeled it after the GoogleTest plugin but had to change some functionality to accommodate the BoostTest implementation details. I did not activate the NativeBinariesTestPlugin during the apply method invocation because I did not want the behaviors of the rules defined there.
Specifically I could not allow the assignment of the tested target sources to the tested binary. This causes the target library to be compiled as many times as there are unit tests. BoostTest typically uses a single executable per test suite instead of the one executable as the provided GoogleTest. The native project I am porting to Gradle has several libraries and each library has several unit tests. All total the number of unit test executables in the project is 1300 which would mean the total source code for the production libraries would be compiled 1300 times!
In my solution I assigned the produced library (shared in my case) to be a library dependency of the test binary. I also changed the behavior of the plugin to not use the Install task but create a wrapper script that sets the LD_LIBRARY_PATH correctly in Linux and the PATH for Windows. This made the solution work exactly as well as the original project CMake generated compilation as far as the compilation speed was concerned.
I am still testing the plugin but I am planning to contribute it back as soon as it is stable enough.