Run under CTest about vscode-cmake-tools HOT 35 CLOSED

cmake already comes with all that is necessary to run CTest and CPack automagically.

There is no need for this extension to add more support for that.
Especially no additional parsing etc.pp. is necessary!

To declare a unittest inside your CMakeLists.txt files, do this:

(1)
enable unittest execution by
enable_testing()
You might want to make this conditional on some platforms,
and disable that for example when doing cross-compilations.

(2)
in your CMakeLists.txt file first create the test executable:
add_executable(mycooltest)

(3)
add a make target which allows running (not: building) that test:
add_test(run_mycooltest COMMAND mycooltest)
https://cmake.org/cmake/help/v3.0/command/add_test.html

(4)
just use the existing command of this extension: "CMake: Build a target..." and choose
the make target that your toolchain has generated for you during cmake configure.
For make the target to build is test, and for Visual Studio that is RUN_TESTS

from vscode-cmake-tools.

found the root of issue:
I've moved from vscode.cmd script most of paths to settings keys, including cmake:

"cmake.cmakePath": "C:/dev/tools/CMake/bin/cmake.exe",

after that, seems ctest.exe could not be found, because when I 've put the path to cmake bin folder back into .cmd. the button "CTest" (Status Bar) is now there

from vscode-cmake-tools.

I'm not quite sure what you mean. Could I get some clarification or examples?

from vscode-cmake-tools.

I've just analyzed my request one more time, not sure that can be easy to implement and enough clear to implement.
So I'm talking about unit testing. you know cmake kit contains a few parts: mostly know - cmake (build system), ctest - unit testing , and cpack - packaging and deploying.
If some target (in cmakelists) contains "enable_testing()" instruction and add_test, that means cmake will generate CTest instructions in addition to just executable. I suppose that a developer wrote this (enable_testing(), etc) that means that target should be ran under ctest.exe.

however there is a number of questions how to detect this target, enable_testing() can be invoked in any place of cmakelists, in root script or in any nested.
for me, the only ability to detect this, is to parse this:
add_test(NAME ""${CTestName}""
COMMAND ${TestTarget} ${Name} --durations yes --warn NoAssertions
--name "${TestTarget} ($ build)")

but you see - in most cases, developers are writing with a variable, not with a target name directly.
so you will need to get an active target in the context.

looks very complex, and feature (using CTest) is not so popular, not all who uses cmake, also uses ctest.

I suggest to close this

from vscode-cmake-tools.

Are you requesting tighter CTest integration? I like the idea of such a feature. I know that the Python extension recently added greater integration with Python's unit testing systems.

There are pretty simple ways to introspect information about CTest. For example, running ctest -N inside the build directory will print a list of tests that are available. I'd like to have something like what the Python extension does for CTest. I use CTest pretty frequently.

from vscode-cmake-tools.

seems you are familiar with that better than me :)
I'd glad to see this in the features of your extension.
and - yes, I was talking about ctest integration

from vscode-cmake-tools.

CPack integration works the same way.

You just have to write the corresponding packing instructions into your CMakeLists.txt file, for example:

if (NOT CPACK_GENERATOR)
   if (WIN32 OR ANDROID)
      set(CPACK_GENERATOR "ZIP")
   else()
      set(CPACK_GENERATOR "RPM")
   endif()
endif()

set(CPACK_PACKAGE_NAME "my_cool_project")
set(CPACK_PACKAGE_RELEASE 1)
set(CPACK_PACKAGE_CONTACT "Your Name")
set(CPACK_PACKAGE_VENDOR "Neusoft Company")
set(CPACK_PACKAGE_VERSION "put something here")
set(CPACK_PACKAGING_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX})
set(CPACK_PACKAGE_FILE_NAME "${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION}-${CPACK_PACKAGE_RELEASE}.${CMAKE_SYSTEM_NAME}.${CMAKE_SYSTEM_PROCESSOR}")

# RPM specific options
set(CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION /usr/etc /usr/lib/systemd /usr/lib/systemd/system)

# DEB specific options
set(CPACK_DEBIAN_PACKAGE_ARCHITECTURE ${CMAKE_SYSTEM_PROCESSOR})

include(CPack)

So nothing needs to be added to this extension to make this work.
Packing stuff into packages is "just another make target".

from vscode-cmake-tools.

please confirm how to run ctest(s) ?
I only know is to run ctests.exe (for WIn, the same for nix)

from vscode-cmake-tools.

I already expose a command CMake: Run tests which just runs CTest in the build directory. I'm wanting to have greater integration with CTest, much like the Python extension.

from vscode-cmake-tools.

sorry for my inattention ..
I was talking about Run tests.. only at this stage
let me look at Python extension

from vscode-cmake-tools.

can you drop the direct ctest invocation and instead just use the build backend?
i.e., let cmake run make test or let MSBuild "build" the "build" target named RUN_TESTS ?

from vscode-cmake-tools.

could you drop a link how to do this?
do I udnerstand you right - cmake, during the build process, should inkoke ctest indirectly?
how to do this ? enable_testing() is not enough, it doesn't run existing in the target tests

from vscode-cmake-tools.

enable_testing() just enables that the toolchain backend generates make targets for executing the tests.
In other words, when you don't do that, the call "add_test()" will be without effect.
However, enable_testing() just takes care of adding the necessary make targets,
it does NOT execute the tests! To execute them, you need to run your build backend again and have it "build" the build target which in fact does not really build something but instead run a test.
For make, that is make test, and for generator "Visual Studio 14 2015" that is "build the custom target RUN_TESTS"

from vscode-cmake-tools.

I already expose a command CMake: Run tests which just runs CTest in the build directory. [

this also doesn't work for me.
the only direct ctest running works.
from log, I see this command goes to the root of cmake_binary_dir. however, this target saved into subdirectory

vscode] Executing cmake command: cmake -E chdir c:/dev/workspace/algolist/build ctest -j4 --output-on-failure
Test project C:/dev/workspace/algolist/build
No tests were found!!!
[vscode] CMake exited with status 0

from vscode-cmake-tools.

I'm sticking with invoking CTest directly. It gives greater control over the CTest run (which I've needed in the past). I'm trying to stick with the most flexible solution I can.

I could even invoke a build using CTest (ctest -T build), and I believe that is how Kitware does it, but I don't plan on doing that because that's just getting really weird.

CTest can emit some useful files that are great for IDE/tooling integration (ie. ctest -T test emits a very detailed test report XML file in the build directory).

@amigo421, the docs for enable_testing require that the command is run in the root source directory. It emits a file called CTestTestfile.cmake which contains information about your tests.

from vscode-cmake-tools.

running CTest from VSCode should IMHO be a separate extension.

this extension is about CMake

from vscode-cmake-tools.

@vector-of-bool thank you very much. yo uare right, the enabling was in incorrect place!

from vscode-cmake-tools.

@MinnieTheMoocher, there's definitely been some scope creep. I've even thought about renaming the extension just to make it a bit clearer where this project is headed.

I want this extension to cover a greater end-to-end CMake-based workflow for native developers, which includes CTest and (eventually) CPack.

Unfortunately, the diversity of tools used by native developers is paradoxically a hindrance to greater developer tooling (reminds me of I HAVE NO TOOLS BECAUSE I’VE DESTROYED MY TOOLS WITH MY TOOLS). I'd like to have one canonical tool that supports a very fleshed-out and useful workflow based on CMake, which is a very powerful and capable tool, especially with its sibling projects, CTest, CPack, etc.

I look at the Python extension as a great example of what kind of workflow can be created for a language with a good set of well-integrated tools. I use that extension daily and have a great Python workflow going with it. I'm hoping to achieve a similarly smooth workflow with CMake Tools.

from vscode-cmake-tools.

nice. I would be happy to see commands like CTest: ... in addition to CMake: ...
I retract my point that a separate extension should be used for ctest.

from vscode-cmake-tools.

sorry for a question out of current scope.
guys how do you use vscode for c++ daily? I'm just trying to migrate on this, but a lot of issues there
it can resolve nothing from standard and my headers.
it also can't find the headers from standard library and others.
autocomplete works inside a single file only

from vscode-cmake-tools.

I'd need more information about your environment and platform. Windows? Linux? macOS? Clang? GCC? MSVC? Something else?

from vscode-cmake-tools.

Win10, vc19.
for me it looks unstable, sometimes it sees a one header. some other - no, even these are in the same folder.
from one cpp, the class can be resolved, from another one - can't, includes are absolutely equal.
also I see this message The C/Cpp Language Server server crashed 5 times in the last 3 minutes. The server will not be restarted. constantly

and of course - the project is built successfully, from vscode or from commandline, so the problem is a pure editor issue

from vscode-cmake-tools.

The language server crashing is related to the C/C++ extension from Microsoft.

Are you running VSCode from a dev command prompt? It's required, unfortunately, unless I could work out how to set the proper environment variables for cl.exe myself.

Note that if you already have a running instance of VSCode and start a new one from the dev command prompt, the new window will not actually be started from the command prompt, just spawned from the already existing process (and will subsequently not see the dev environment).

from vscode-cmake-tools.

yes, I'mrunning this using .cmd file with a various env variables, including vc vars, as I wrote in the discussion under your link.
as I said no issues with a building process.
do you know - vscode looks for a headers in INCLUDE env variable?

from vscode-cmake-tools.

Ah, you are seeing issues with the C/C++ extension? In that case, I can't be of help. The messages shown inline about missing headers is from that extension.

from vscode-cmake-tools.

yes, exactly, just asked you for the opinion from your experience. so okay.

from vscode-cmake-tools.

Although not exactly pertinent to the original request, 0.7.0 has greater CTest support! As such, I will close this issue.

from vscode-cmake-tools.

last version doesn't show CTest button again. have you any idea how to fix this?
enable_testing() and CTest* files are there, no changes in the configuration

from vscode-cmake-tools.

Which button are you looking for? The button on the statusbar?

from vscode-cmake-tools.

by the way, is it possible (seems currently it's not so) , to get a git path for ExternalProject git cloning not from environment but from setting firstly:

"git.path": "C:/dev/tools/git/cmd/git.exe",

regarding CTest - do you plan to add own key for the searching CTest.exe or parsing the path from CMake.exe setting?

from vscode-cmake-tools.

Hmm... I've never thought about such a feature. It seems a little too niche for this extension, though...

from vscode-cmake-tools.

1. git - agreed, that is not a critical .
2. CTest - just for sure, cmakePath should contain a path only? or with executable name combined? does it refer on bin of cmake instalation or on cmake.exe only

from vscode-cmake-tools.

cmakePath should include the executable filename as well as the directory.

from vscode-cmake-tools.

it's your project, I can't tell you how to do, but is it a useful idea to use this variable as a path only, without the application name? the place where to look for cmake.exe, ctest.exe and cpack.exe?

from vscode-cmake-tools.

Maybe... The default is to just use the command names like cmake, which will find it in the PATH variable. Simply adding the directory with those executables to PATH would be sufficient.

from vscode-cmake-tools.