Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support recompiling on test run #24

Open
thejezzi opened this issue Jun 24, 2024 · 3 comments
Open

Support recompiling on test run #24

thejezzi opened this issue Jun 24, 2024 · 3 comments

Comments

@thejezzi
Copy link

thejezzi commented Jun 24, 2024

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
Copy link
Owner

alfaix commented Jun 25, 2024

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
Copy link

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants