{"id":5779,"date":"2020-08-07T07:00:51","date_gmt":"2020-08-07T14:00:51","guid":{"rendered":"http:\/\/writeasync.net\/?p=5779"},"modified":"2020-08-06T11:07:11","modified_gmt":"2020-08-06T18:07:11","slug":"cross-platform-without-complexity-command-line","status":"publish","type":"post","link":"http:\/\/writeasync.net\/?p=5779","title":{"rendered":"Cross-platform without complexity: command line"},"content":{"rendered":"

At this point we have a Windows build<\/a> and remote Linux build<\/a> working from Windows in the Visual Studio IDE. This is all good and it’s hard to beat VS in terms of productivity while actively developing the code. However, there are still plenty of scenarios where command line is superior (e.g. when setting up build automation<\/a>).<\/p>\n

Unfortunately, it is not quite as easy as running cmake.exe<\/code> on the command line to get the same experience that VS has provided so far. There are actually three things that are happening when building and testing the project in VS:<\/p>\n

    \n
  1. Producing native build system files via a CMake generator<\/a><\/li>\n
  2. Executing the native build step<\/li>\n
  3. Discovering and executing the tests<\/li>\n<\/ol>\n

    The first step is where CMake comes in but it must be properly initialized. This requires understanding which generator and make program to use as well as some of the required paths. By observing how VS launches CMake (Sysinternals Process Monitor<\/a> FTW!), I was able to construct a command line that has identical behavior. It looks something like this:<\/p>\n

    \ncmake.exe -G Ninja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_COMPILER:FILEPATH=cl.exe -DCMAKE_INSTALL_PREFIX:PATH=”PROJ\\PATH\\out\\install\\x64-Debug” -DCMAKE_MAKE_PROGRAM=ninja.exe -DCMAKE_TOOLCHAIN_FILE=”VCPKG\/PATH\/scripts\/buildsystems\/vcpkg.cmake” “PROJ\\PATH”\n<\/p><\/blockquote>\n

    There are some paths to fill in based on the particular system and project, but this gives you a general idea. Also note that this command must be executed in the build output path, e.g. out\\build\\x64-Debug<\/code>.<\/p>\n

    Given that VS uses the Ninja generator<\/a> to produce build system files, we would need to invoke ninja.exe<\/code>. In this case, it is just a simple matter of launching the EXE — any other arguments are optional and would only be needed if you wanted to change output logging behavior, for example.<\/p>\n

    Testing is also just as easy. Since CMake and Ninja have already done all the hard work, we would launch ctest.exe<\/code> to execute tests.<\/p>\n

    Given the tedium of trying to stitch together all the required paths and setting up the right folders, these steps are just begging to be automated. So here is a batch file build.cmd<\/code> which does just that:<\/p>\n

    \r\n@echo off\r\nsetlocal\r\n\r\npushd %~dp0\r\nset ROOT_PATH=%CD%\r\n\r\nset EXIT_CODE=1\r\nif NOT DEFINED VSCMD_ARG_HOST_ARCH set ERR_MSG=%0 must be run from a VS command prompt.& goto :Quit\r\n\r\nset VCPKG_FILE=%LOCALAPPDATA%\\vcpkg\\vcpkg.path.txt\r\nif NOT EXIST "%VCPKG_FILE%" set ERR_MSG=Could not find vcpkg.& goto :Quit\r\nset \/p VCPKG_PATH=<%VCPKG_FILE%\r\n\r\nset CLEAN=0\r\nset NO_TEST=0\r\nset VERBOSE=0\r\nset BUILD_TYPE=Debug\r\nset ERR_MSG=Usage: %0 [--clean] [--no-test] [--verbose] [build_type]\r\n\r\n:NextArg\r\nset NEXT_ARG=%~1\r\nshift\r\nif NOT DEFINED NEXT_ARG goto :EndArg\r\nif \/i "%NEXT_ARG%" == "--clean" set CLEAN=1& goto :NextArg\r\nif \/i "%NEXT_ARG%" == "--no-test" set NO_TEST=1& goto :NextArg\r\nif \/i "%NEXT_ARG%" == "--verbose" set VERBOSE=1& goto :NextArg\r\nif "%NEXT_ARG:~0,1%" == "-" goto :Quit\r\nset BUILD_TYPE=%NEXT_ARG%\r\nif \/i "%BUILD_TYPE%" == "Debug" goto :NextArg\r\nif \/i "%BUILD_TYPE%" == "Release" goto :NextArg\r\ngoto :Quit\r\n:EndArg\r\n\r\nset BUILD_CONFIG=%VSCMD_ARG_HOST_ARCH%-%BUILD_TYPE%\r\necho == Build config '%BUILD_CONFIG%'\r\n\r\nif \/i "%BUILD_TYPE%" == "Release" set BUILD_TYPE=RelWithDebInfo\r\n\r\nset OUTPUT_PATH=%ROOT_PATH%\\out\r\nset BUILD_PATH=%OUTPUT_PATH%\\build\\%BUILD_CONFIG%\r\n\r\nif "%CLEAN%" == "0" goto :Make\r\necho == Remove %BUILD_PATH%\r\nif EXIST "%BUILD_PATH%" rd \/s \/q "%BUILD_PATH%"\r\n\r\n:Make\r\nif NOT EXIST "%BUILD_PATH%" md "%BUILD_PATH%"\r\ncd "%BUILD_PATH%"\r\n\r\nset CMAKE_ARGS=^\r\n  -G Ninja ^\r\n  -DCMAKE_BUILD_TYPE=%BUILD_TYPE% ^\r\n  -DCMAKE_CXX_COMPILER:FILEPATH=cl.exe ^\r\n  -DCMAKE_INSTALL_PREFIX:PATH="%OUTPUT_PATH%\\install\\%BUILD_CONFIG%" ^\r\n  -DCMAKE_MAKE_PROGRAM=ninja.exe ^\r\n  -DCMAKE_TOOLCHAIN_FILE="%VCPKG_PATH%\/scripts\/buildsystems\/vcpkg.cmake" ^\r\n  "%ROOT_PATH%"\r\n\r\nif "%VERBOSE%" == "1" set CMAKE_ARGS=%CMAKE_ARGS% --log-level=VERBOSE\r\n\r\necho == cmake.exe %CMAKE_ARGS%\r\ncmake.exe %CMAKE_ARGS%\r\nset EXIT_CODE=%ERRORLEVEL%\r\nset ERR_MSG=cmake.exe failed.\r\nif NOT "%EXIT_CODE%" == "0" goto :Quit\r\n\r\nset NINJA_ARGS=\r\n\r\nif "%VERBOSE%" == "1" set NINJA_ARGS=%NINJA_ARGS% -v\r\n\r\necho == ninja.exe %NINJA_ARGS%\r\nninja.exe %NINJA_ARGS%\r\nset EXIT_CODE=%ERRORLEVEL%\r\nset ERR_MSG=ninja.exe failed.\r\nif NOT "%EXIT_CODE%" == "0" goto :Quit\r\n\r\nif "%NO_TEST%" == "1" goto :Quit\r\n\r\nset CTEST_ARGS=\r\n\r\nif "%VERBOSE%" == "1" set CTEST_ARGS=%CTEST_ARGS% -V\r\n\r\necho == ctest.exe %CTEST_ARGS%\r\nctest.exe %CTEST_ARGS%\r\nset ERR_MSG=ctest.exe failed.\r\nset EXIT_CODE=%ERRORLEVEL%\r\n\r\n:Quit\r\npopd\r\nif NOT "%EXIT_CODE%" == "0" echo %ERR_MSG%\r\nexit \/b %EXIT_CODE%\r\n<\/pre>\n
    Note the additional functionality which can be enabled via command line options: --clean<\/code> to delete the previous output folder before starting, --no-test<\/code> to skip the testing step, and --verbose<\/code> to pass verbose flags to each of the tools. The default build target is Debug<\/code>, or you can say build Release<\/code> for, you guessed it, the release build. Since this assumes the same development environment as Visual Studio, it should be run from inside a VS developer command prompt<\/a>.<\/p>\n
    Running it for the first time or on any changes will generate all the binaries and run tests. Running it without any changes should quickly blaze past the generation\/compilation steps and just run tests:<\/p>\n
    \r\n== Build config 'x64-release'\r\n== cmake.exe   -G Ninja   -DCMAKE_BUILD_TYPE=RelWithDebInfo   -DCMAKE_CXX_COMPILER:FILEPATH=cl.exe   -DCMAKE_INSTALL_PREFIX:PATH="X:\\root\\CMakeSampleVS\\out\\install\\x64-release"   -DCMAKE_MAKE_PROGRAM=ninja.exe   -DCMAKE_TOOLCHAIN_FILE="X:\/root\/vcpkg\/scripts\/buildsystems\/vcpkg.cmake"   "X:\\root\\CMakeSampleVS"\r\nRe-run cmake no build system arguments\r\n-- Configuring done\r\n-- Generating done\r\n-- Build files have been written to: X:\/root\/CMakeSampleVS\/out\/build\/x64-release\r\n== ninja.exe\r\nninja: no work to do.\r\n== ctest.exe\r\nTest project X:\/root\/CMakeSampleVS\/out\/build\/x64-release\r\n    Start 1: SampleTest.GetName\r\n1\/3 Test #1: SampleTest.GetName ...............   Passed    0.11 sec\r\n    Start 2: sample-app-UsageError\r\n2\/3 Test #2: sample-app-UsageError ............   Passed    0.01 sec\r\n    Start 3: sample-app-HelloWorld\r\n3\/3 Test #3: sample-app-HelloWorld ............   Passed    0.01 sec\r\n\r\n100% tests passed, 0 tests failed out of 3\r\n\r\nTotal Test time (real) =   0.14 sec\r\n<\/pre>\n
    If Windows were our only concern, we would be done here. But I promised cross-platform, so we need to figure out the equivalent steps in a Linux environment. Luckily for us, in this case, the steps are very similar. We just need a Linux-native way to perform them, which means it’s time for Bash<\/a>! Here is build.sh<\/code>, a relatively faithful port of the above script using the all-around superior Bash constructs (conditionals, looping, functions, etc.):<\/p>\n
    \r\n#!\/bin\/bash\r\n\r\nquit() {\r\n    echo $1\r\n    popd > \/dev\/null \r\n    exit $2;\r\n}\r\n\r\npushd `dirname $0` > \/dev\/null\r\nROOT_PATH="${PWD}"\r\n\r\nCLEAN=0\r\nNO_TEST=0\r\nVERBOSE=0\r\nBUILD_TYPE="Debug"\r\n\r\nwhile [[ "$1" != "" ]] ; do\r\n  case $1 in\r\n    --clean)   CLEAN=1 ;;\r\n    --no-test) NO_TEST=1 ;;\r\n    --verbose) VERBOSE=1 ;;\r\n    debug)     BUILD_TYPE="Debug" ;;\r\n    release)   BUILD_TYPE="Release" ;;\r\n    *) quit "Usage: $0 [--clean] [--no-test] [--verbose] [build_type]" 1 ;;\r\n  esac\r\n\r\n  shift\r\ndone\r\n\r\nBUILD_CONFIG="Linux-Clang-${BUILD_TYPE}"\r\necho == Build config $BUILD_CONFIG\r\n\r\n[[ "${BUILD_TYPE}" = "Release" ]] && BUILD_TYPE="RelWithDebInfo"\r\n\r\nOUTPUT_PATH="${ROOT_PATH}\/out"\r\nBUILD_PATH="${OUTPUT_PATH}\/build\/${BUILD_CONFIG}"\r\n\r\nif [[ $CLEAN -eq 1 ]]; then\r\n  echo "== Remove ${BUILD_PATH}"\r\n  [[ -d "${BUILD_PATH}" ]] && rm -rf "${BUILD_PATH}"\r\nfi\r\n\r\n[[ ! -d "${BUILD_PATH}" ]] && mkdir "${BUILD_PATH}"\r\ncd "${BUILD_PATH}"\r\n\r\nCMAKE_ARGS="\r\n  -G Ninja\r\n  -DCMAKE_BUILD_TYPE=${BUILD_TYPE}\r\n  -DCMAKE_CXX_COMPILER:FILEPATH=clang++\r\n  -DCMAKE_INSTALL_PREFIX:PATH=${OUTPUT_PATH}\/install\/${BUILD_CONFIG}\r\n  -S ${ROOT_PATH}\r\n"\r\n\r\n[[ $VERBOSE -eq 1 ]] && CMAKE_ARGS="${CMAKE_ARGS} --log-level=VERBOSE"\r\n\r\necho == cmake $CMAKE_ARGS\r\ncmake $CMAKE_ARGS\r\nEXIT_CODE=$?\r\n[[ $EXIT_CODE -ne 0 ]] && quit 'cmake failed' $EXIT_CODE\r\n\r\nNINJA_ARGS=""\r\n\r\n[[ $VERBOSE -eq 1 ]] && NINJA_ARGS="${NINJA_ARGS} -v"\r\n\r\necho == ninja $NINJA_ARGS\r\nninja $NINJA_ARGS\r\nEXIT_CODE=$?\r\n[[ $EXIT_CODE -ne 0 ]] && quit 'ninja failed' $EXIT_CODE\r\n\r\n[[ $NO_TEST -eq 1 ]] && quit 'Done' 0\r\n\r\nCTEST_ARGS=""\r\n\r\n[[ $VERBOSE -eq 1 ]] && CTEST_ARGS="${CTEST_ARGS} -V"\r\n\r\necho == ctest $CTEST_ARGS\r\nctest $CTEST_ARGS\r\nEXIT_CODE=$?\r\n[[ $EXIT_CODE -ne 0 ]] && quit 'ctest failed' $EXIT_CODE\r\n\r\nquit 'Done' 0\r\n<\/pre>\n
    You might notice that the cmake arguments are slightly different here. For Linux, we don’t really need vcpkg and we choose the CLang compiler since MSVC (cl.exe<\/code>) wouldn’t make sense. I also found that it has trouble with quoted paths so I omitted them. Anyway, just as we had hoped, the Linux behavior is equivalent to Windows when launching the script from an already produced Release build:<\/p>\n
    \r\n== Build config Linux-Clang-Release\r\n== cmake -G Ninja -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_CXX_COMPILER:FILEPATH=clang++ -DCMAKE_INSTALL_PREFIX:PATH=\/mnt\/x\/root\/CMakeSampleVS\/out\/install\/Linux-Clang-Release -S \/mnt\/x\/root\/CMakeSampleVS\r\n-- Configuring done\r\n-- Generating done\r\n-- Build files have been written to: \/mnt\/x\/root\/CMakeSampleVS\/out\/build\/Linux-Clang-Release\r\n== ninja\r\nninja: no work to do.\r\n== ctest\r\nTest project \/mnt\/x\/root\/CMakeSampleVS\/out\/build\/Linux-Clang-Release\r\n    Start 1: SampleTest.GetName\r\n1\/3 Test #1: SampleTest.GetName ...............   Passed    0.01 sec\r\n    Start 2: sample-app-UsageError\r\n2\/3 Test #2: sample-app-UsageError ............   Passed    0.01 sec\r\n    Start 3: sample-app-HelloWorld\r\n3\/3 Test #3: sample-app-HelloWorld ............   Passed    0.01 sec\r\n\r\n100% tests passed, 0 tests failed out of 3\r\n\r\nTotal Test time (real) =   0.04 sec\r\nDone\r\n<\/pre>\n
    Here is the GitHub repo with the changes: CMakeSampleVS<\/a><\/p>\n
    Amazingly, we have achieved our original goals. We have a project structure which works with the VS IDE on Windows, produces platform-specific binaries for Windows and Linux, supports a command line build for both Windows and Linux, and has full unit test support on both platforms. What kinds of modern C++ software could we create with these newfound capabilities?<\/p>\n","protected":false},"excerpt":{"rendered":"
    At this point we have a Windows build and remote Linux build working from Windows in the Visual Studio IDE. This is all good and it’s hard to beat VS in terms of productivity while actively developing the code. However,… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[107,101],"tags":[],"class_list":["post-5779","post","type-post","status-publish","format-standard","hentry","category-cross-platform","category-native"],"_links":{"self":[{"href":"http:\/\/writeasync.net\/index.php?rest_route=\/wp\/v2\/posts\/5779","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/writeasync.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/writeasync.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/writeasync.net\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/writeasync.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=5779"}],"version-history":[{"count":5,"href":"http:\/\/writeasync.net\/index.php?rest_route=\/wp\/v2\/posts\/5779\/revisions"}],"predecessor-version":[{"id":5786,"href":"http:\/\/writeasync.net\/index.php?rest_route=\/wp\/v2\/posts\/5779\/revisions\/5786"}],"wp:attachment":[{"href":"http:\/\/writeasync.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=5779"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/writeasync.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=5779"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/writeasync.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=5779"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}