Mentions légales du service

Skip to content
Snippets Groups Projects

Add the certivibe-test repository as a submodule, add a test runner project

Created by: jlegeny

This PR adds the certivibe-test repository as a submodule of certivibe

Several CMake projects are added to facilitate running tests from the 'master' CMake

test-run-cmake test-run-build test-run

Note that the project is called test-run because the name 'test' is forbidden for some reason

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
1 project(openvibe-test)
  • Created by: cgcert

    I would keep the openvibe prefix for this target as weel. Just for consistency. Not because I like it...

  • Jussi Lindgren
    Jussi Lindgren @jlindgre started a thread on commit 085da179
  • 1 project(openvibe-test)
    2
    3 add_custom_target(${PROJECT_NAME}-cmake
    4 COMMAND cmake "${CMAKE_SOURCE_DIR}/test"
    • Created by: cgcert

      Here there are some user-defined variable to set: OVT_LOG_DIR & OVT_TEST_DATA_DIR. What I suggest is:

      • Create an option at certivibe project level BUILD_TESTING
      • If set to yes:
        • create cache variable OV_TEST_LOG_DIR & OV_TEST_DATA_DIR that will be used to generate test project (this is a kind of bridge so hopefully we won't have many test configuration variables)
        • add subdir test-runner
  • Jussi Lindgren
    Jussi Lindgren @jlindgre started a thread on commit 085da179
  • 1 project(openvibe-test)
    2
    3 add_custom_target(${PROJECT_NAME}-cmake
    4 COMMAND cmake "${CMAKE_SOURCE_DIR}/test"
  • Jussi Lindgren
    Jussi Lindgren @jlindgre started a thread on commit 085da179
  • 1 project(openvibe-test)
    2
    3 add_custom_target(${PROJECT_NAME}-cmake
    4 COMMAND cmake "${CMAKE_SOURCE_DIR}/test"
    5 "-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}"
    6 "-DOV_ROOT_DIR=${CMAKE_INSTALL_PREFIX}"
    7 "-GNinja"
    8 "-DOVT_LOG_DIR=${OVT_LOG_DIR}"
    9 "-DOVT_TEST_DATA_DIR=${OVT_TEST_DATA_DIR}"
    10 WORKING_DIRECTORY "${CMAKE_BINARY_DIR}/test"
  • Created by: cgcert

    First pass done. Tests with data fail on Linux.

  • Jussi Lindgren
    Jussi Lindgren @jlindgre started a thread on commit 085da179
  • 1 project(openvibe-test)
    • Created by: jlegeny

      openvibe-test then? I like the non-openvibe prefix as it makes the project stand out but we can do that.

  • Jussi Lindgren
    Jussi Lindgren @jlindgre started a thread on commit 085da179
  • 1 project(openvibe-test)
    2
    3 add_custom_target(${PROJECT_NAME}-cmake
    4 COMMAND cmake "${CMAKE_SOURCE_DIR}/test"
    • Created by: jlegeny

      Why use make? The thing is that using Ninja makes this consistent on Windows and Linux whereas otherwise CMake would generate a VS project on Windows and a Makefile project on Linux. Is there any reason to continue supporting Makefiles?

  • Jussi Lindgren
    Jussi Lindgren @jlindgre started a thread on commit 085da179
  • 1 project(openvibe-test)
    2
    3 add_custom_target(${PROJECT_NAME}-cmake
    4 COMMAND cmake "${CMAKE_SOURCE_DIR}/test"
    • Created by: jlindgre

      Might depend on your toolchain and practices. If everybody is comfortable over there working on whatever Ninja turns out, ok. Personally I dev/debug with the VS IDE and for that I need the VS project.

      Le 29-Jun-16 à 11:34 AM, Jozef Legény a écrit :

      @@ -0,0 +1,28 @@ +project(test-run) + +add_custom_target(${PROJECT_NAME}-cmake

      • COMMAND cmake "{CMAKE_SOURCE_DIR}/test" "-DCMAKE_BUILD_TYPE={CMAKE_BUILD_TYPE}" "-DOV_ROOT_DIR=${CMAKE_INSTALL_PREFIX}" "-GNinja" Why use make? The thing is that using Ninja makes this consistent on Windows and Linux whereas otherwise CMake would generate a VS project on Windows and a Makefile project on Linux. Is there any reason to continue supporting Makefiles?

      You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/mensiatech/certivibe/pull/33/files/0ff620da163e3aed43616b91a162a32895a4b037#r68914532

  • Jussi Lindgren
    Jussi Lindgren @jlindgre started a thread on commit 085da179
  • 1 project(openvibe-test)
  • Jussi Lindgren
    Jussi Lindgren @jlindgre started a thread on commit 085da179
  • 1 project(openvibe-test)
    2
    3 add_custom_target(${PROJECT_NAME}-cmake
    4 COMMAND cmake "${CMAKE_SOURCE_DIR}/test"
    • Created by: jlegeny

      This particular project would present itself as a VS project that when built, runs a cmake toolchain and runs the tests. This is not a code level project, basically we just run a program that runs the tests. As it happens the program is cmake, then ninja, then the test runner.

  • Jussi Lindgren
    Jussi Lindgren @jlindgre started a thread on commit 085da179
  • 1 project(openvibe-test)
    2
    3 add_custom_target(${PROJECT_NAME}-cmake
    4 COMMAND cmake "${CMAKE_SOURCE_DIR}/test"
    • Created by: jlegeny

      Also note that this does not have any impact on the debugging and building toolchain for either certivibe code or certivibe tests. It is strictly done to run this particular tests from the main certivibe toolchain which can be whatever (be it make, vs or ninja).

      As for running this "by hand" it works the same way as before. You can still run cmake make and everything manually. But I really do not see a point to add a ton of customisation to a simple run script. In my opinion this would be strictly equivalent to give option whether one wants to copy files in cmake using either cmake, cmd or python with all three implementations doing strictly the same thing.

  • Jussi Lindgren
    Jussi Lindgren @jlindgre started a thread on commit 085da179
  • 1 project(openvibe-test)
    2
    3 add_custom_target(${PROJECT_NAME}-cmake
    4 COMMAND cmake "${CMAKE_SOURCE_DIR}/test"
  • Jussi Lindgren
    Jussi Lindgren @jlindgre started a thread on commit 085da179
  • Unable to load the diff
    • Created by: cgcert

      Actually, I was more thinking of a cache variables for both of them: SET(OVT_TEST_DATA_DIR ${PROJECT_BINARY_DIR}/data/input/ CACHE PATH "Path to big test data")

      Typically, I would like to define these variables with cmake -Dvar=value or cmake-gui to point towards my data directory. Moreover, I would not choose a default path in the source directory. Binary directory is better as it avoids messing up with git & co.

  • Jussi Lindgren
    Jussi Lindgren @jlindgre started a thread on commit 085da179
  • Unable to load the diff
    • Created by: cgcert

      I would add a BUILD_TESTING option to the project and add test related directories (test-runner) and variables (OVT_XXXX) only if the option is on. This can be useful to remove test related stuff from generated targets.

  • Jussi Lindgren
    Jussi Lindgren @jlindgre started a thread on commit 085da179
  • Unable to load the diff
    • Created by: jlegeny

      Ok for cache variables. I did not know how they worked before. As for the default path, dependencies folder is already there on Windows so it seemed like a good place. It can be changed though. Binary directory is a bit awkward as it can be deleted quite often (if one wants to rebuild all from scratch)

  • Jussi Lindgren
    Jussi Lindgren @jlindgre started a thread on commit 085da179
  • Unable to load the diff
  • Created by: cgcert

    OK for merge

  • Please register or sign in to reply
    Loading