Support recompiling on test run

[thejezzi]

Hi there,

would it be possible to execute a pre build step before a test run?
At the moment I always have to build my binary by hand and then use neotest, but it would make my life much easier if I could specify a prebuild task via the lets say ConfigureGtest command or a new ConfigureGtestBuild command or something, which could instead execute make or something similar and then the binary on every test run.

BTW: Thank you for this awesome plugin which makes my life already so much better :)

[alfaix]

Hey @thejezzi
I was hoping to do this as part of CMake support (so by default this hook would try to find the relevant target through CMake), but that proved to be a bit more difficult than I thought (see this issue).

I suppose as an intermediate step I can add a user hook.

Would adding something like recompile = function(file_path, project_root) to config be good enough for the time being?

[mjrogozinski]

I don't think this plugin should depend on CMake.

Callback should be enough. Building can be done by a task plugin e.g. overseer.
Consider adding binary as a parameter, so it could be passed to the build system to speed up building (build only the binary containing test).

Another idea would be to use compile_commands and bypass the build system altogether. Although it's probably not very wise.

[rocket-engineer]

Hi @mjrogozinski, @alfaix,

some time ago I started to implement two callbacks in my fork of neotest-gtest. One callback as "launch_settings_provider" and another one for a "build_callback". I want to use neotest-gtest in companion with cmake-tools.nvim, but I don't want to confine these callbacks to work with cmake-tools.nvim only. In my opinion we need these two callback in order to couple neotest-gtest with a building system in NeoVim.

The "launch_settings_provider" works reasonable well. I can pass the execution settings from the CMake plugin (using a new API). This API provides information for "cwd", "exe", "args" and "envs" (environment variables) of the current chosen CMake target (needs to be an executable target). neotest-gtest adds its additional "args" to select and run the respective tests. I had to introduce a hack in order to prevent the call to "ConfigureGtest" (only one executable is provided in this case).

I haven't worked quite much on the "build_callback" yet. I can call cmake-tools.nvim to (re-)build the current target, but I haven't achieved to wait unit the chosen target was built (either by polling for the result or using a synchronous call with a result value).

Currently, I'm renewing my entire config (switch to NeoVim 0.10.x and using lazy.nvim). I will also update and push everything to the mentioned forks. Afterwards, I want to come back and elaborate the "build_callback". One possible solution could be to switch from toggleterm to overseer in cmake-tools.nvim in order to gain control over the building process.

[alfaix]

Hey @rocket-engineer, sorry for the long wait.

I have a little more time on my hands now so if you could open a PR (even if half-working), I'd appreciate it. I think refactoring "ConfigureGtest" into a last resort matching provider if no build system is found will be the way to go. My experience with cmake-tools.nvim is a little uneven but I see no harm in adding it as an optional thing either way. I'll give a shot to direct cmake integration too (files API is not that complicated; moreover I only need a couple calls).

[rocket-engineer]

Hi @alfaix,

thx for the answer! I'm currently quite short on time, too. I'll compose a PR on this matter soon.

Recently, I lifted my setup to NeoVim 0.10.x and currently I'm working on the cmake-tools.nvim integration. I think refactoring "ConfigureGtest" to use it as a fallback option is a good approach! This part of the code was the hardest for me to understand;)
I haven't found a solution to support multiple executables yet. Therefore, for the time being, I'll stick to a single executable.