Closed dwang-hingehealth closed 1 year ago
I totally forgot that generators used a different build system, sorry.
It's a good suggestion. I'll start when I can.
Published version 1.2.0
cmake {
targets {
example_project {
cmakeLists.set(file('src/CMakeLists.txt'))
targetMachines.add(machines.host)
generator.set(generators.unixMakefiles)
cmakeArgs.add('arg1', 'arg2') // passed to cmake
generatorArgs..add('arg1', 'arg2') // passed to the underlaying build system (make, ninja, etc)
}
}
}
For custom generators, (ones with no built in support), you will need to add an implementation of com.github.tomtzook.gcmake.generator.CmakeGeneratorBuildTask
. Then add in your script:
generators.customGenerators.register("nameOfGenerator") {
it.buildTaskClass.set(GeneratorBuildTaskClassName)
}
And use the generator with generators.customGenerators.nameOfGenerator
.
Sorry it took so long, was pretty swamped with life stuff. Haven't had the chance to test the custom generators part. Again sorry. But you really are welcome to add code yourself.
Hi Tom,
Thank you for https://github.com/tomtzook/gradle-cmake/issues/1#issuecomment-1250539907. With this change, I was able to successfully cmake configure my project, but the cmake build step still fails now, due to the fact that
MakeBuildTask.java
is hard coded to usemake
. Would it be possible to change it in favour of the more genericcmake --build <dir> --target <target> --parallel <threads>
?Also, if it's not too much, would it be possible to add support for arbitrary CMake parameter definitions in the veins of
cmake -DMyVar=Value
?Thank you so much