Stride Sandbox: Difference between revisions
Line 24: | Line 24: | ||
====Linux/FreeBSD==== | ====Linux/FreeBSD==== | ||
<ol> | <ol> | ||
<li>Build the test app | <li>Build the test app using GNU make | ||
<source lang="bash"> | <source lang="bash"> | ||
cd $STRIDE_DIR/SDK/Posix/src | cd $STRIDE_DIR/SDK/Posix/src |
Revision as of 23:28, 25 November 2014
Overview
Stride's cross-platform capabilities make it possible to use Stride in a host-only configuration called the Sandbox. This environment facilitates self-training, evaluations, and trying stuff. It frees you from external hardware dependencies and provides for a rapid edit-build-test cycle.
The Sandbox utilizes the framework's SDK that can be built and executed on the host system. When using the SDK Makefile a simulated target native application is generated, which we call a Test Application (TestApp). The Stride Runner application executes on the same host and communicates with the TestApp process over a TCP/IP connection.
The Sandbox requires the Stride framework package to be setup on your desktop. Refer to the Framework Setup article for more information. It also requires that your desktop contains one of the following compilers:
- For Windows, Microsoft Visual Studio 2008 or later is required. If you don't already have Visual Studio, the free Visual C++ Express can be used (download here). In case you have Cygwin installed, the GNU Compiler Collection could be used as an alternative.
- For Linux and FreeBSD, the GNU Compiler Collection (included by default in almost all distros) is required.
Building
SDK Makefile
The SDK Makefile is set up by default so that all .c .cpp and .h files found in the directory SDK\Windows\sample_src (or SDK/Posix/sample_src for Linux) are included in the compile and link of the testapp target.
Further--as a pre-compilation step--any .h files found in sample_src are submitted to the STRIDE Build Tools. This will result in
- the detection of test pragmas used to declare Test Units in these .h files
- the detection of function pragmas used to declare remoting of functions also found in .h files
- the inclusion of metadata into the sidb file created
- the generation of an Intercept Module required for executing tests
Build Steps
To begin, be sure that TestApp is not running then perform the following steps:
Linux/FreeBSD
- Build the test app using GNU make
cd $STRIDE_DIR/SDK/Posix/src make testapp
- Note that the following artifacts are produced by the build:
- $STRIDE_DIR/SDK/Posix/out/bin/TestApp
- the test application
- $STRIDE_DIR/SDK/Posix/out/TestApp.sidb
- the STRIDE interface database file which contains metadata describing the interfaces remoted by the test app (along with other data)
Windows
NOTE: In case you have Cygwin and GNU Compiler Collection installed and prefer to use it, please follow the build steps for Linux (see previous section) and ignore the one in here.
- If using Microsoft Visual Studio, open a Visual Studio Command Prompt to ensure that the compiler and linker are on your PATH.
- Build the test app using the supplied GNU make. (You will get Makefile errors if you use the default make.)
cd %STRIDE_DIR%\SDK\Windows\src ..\bin\make testapp
- Note that the following artifacts are produced by the build:
- %STRIDE_DIR%\SDK\Windows\out\bin\TestApp.exe
- the test application
- %STRIDE_DIR%\SDK\Windows\out\TestApp.sidb
- the STRIDE interface database file which contains metadata describing the interfaces remoted by the test app (along with other data)
Running
The test app we just built does not have any user tests in it. At this point it provides a starting point for test that we will subsequently add.
However, a set of diagnostic tests that verify operation of the STRIDE runtime itself are always built into the generated TestApp executable. If desired (we recommend you to do so) you could run them by doing the following:
- Invoke the TestApp. In order to see TestApp's output, we recommend that you manually run in a console window (or Windows equivalent):
- Linux
$STRIDE_DIR/SDK/Posix/out/bin/TestApp
- Windows
%STRIDE_DIR%\SDK\Windows\out\bin\TestApp
(...or launch from the file explorer)
- Note TestApp's output upon startup.
-------------------------------------------------- STRIDE Test Console Application. Enter 'Ctrl+C' to Quit. -------------------------------------------------- Listening on TCP port 8000 starting up... "_srThread" thread started. "stride" thread started.
- From a second console window, invoke stride as follows, to verify connectivity with the test app and STRIDE runtime operation:
- Linux
stride --diagnostics --database="$STRIDE_DIR/SDK/Posix/out/TestApp.sidb" --device=TCP:localhost:8000 --run="*"
- Windows
stride --diagnostics --database="%STRIDE_DIR%\SDK\Windows\out\TestApp.sidb" --device=TCP:localhost:8000 --run="*"
As the tests run you will see output in both the TestApp (target) and stride (host) console windows.
The host console window output is shown here:
Executing diagnostics... Connecting to device (TCP:localhost:8000)... runtime version: 5.0.xy test suite "/Link" Loopback .......... Payload Fragmentation Stub-Proxy Deadlock Target Characteristics > 4 passed, 0 failed, 0 in progress, 0 unknown, 0 not in use, 777.77 ms. test suite "/Stat" > 2 passed, 0 failed, 0 in progress, 0 unknown, 0 not in use, 74.98 ms. test suite "/Time" > 2 passed, 0 failed, 0 in progress, 0 unknown, 0 not in use, 2559.23 ms. Disconnecting from device... --------------------------------------------------------------------- Summary: 8 passed, 0 failed, 0 in progress, 0 unknown, 0 not in use, 3411.98 ms.
- Note the Summary results shown in the host output; all in use tests should pass.
- To exit TestApp, give the target window focus and enter Ctrl-C (or 'q' under Windows).
Build Problems
This page describes several common problems encountered when building a STRIDE TestApp using the Sandbox and suggested solutions.
Make Error 1
- Symptom
On Windows, when attempting to build the testapp from the command line, you encounter an error indicating that:
‘cl’ is not recognized as an internal or external command, operable program or batch file.
For example:
C:\STRIDE\SDK\Windows\src>..\bin\make.exe testapp cl -c -nologo -W4 -D_UNICODE -DUNICODE -DWIN32 -D_CONSOLE -DUNDER_NT -I”.” -I”../../Runtime” -I”../../SLAP” -I”../../GRS” -I”../o ut/src” -I”../sample_src” -GS -Zi -DNDEBUG -MD -O2 -D_LIB -DSTRIDE_STATIC -Fd”../out/desktop-Windows_NT-obj//cl.pdb” -Fo”../out/desktop-Windows_NT-o bj/srapi.o” ”../../Runtime/srapi.c” ‘cl’ is not recognized as an internal or external command, operable program or batch file. make: *** [../out/desktop-Windows_NT-obj/srapi.o] Error 1
- Cause
Microsoft Visual Studio 2008 or later is not installed or you are not building from a Visual Studio Command Prompt.
- Soultion
Make sure you have Microsoft Visual Studio 2008 or later installed.
To ensures that the compiler and linker are on your PATH open a Visual Studio Command prompt:
- Click the Start button, point to All Programs, Microsoft Visual Studio 20XX, Visual Studio Tools, and then click Visual Studio 20XX Command Prompt.
Make Error 2
- Symptom
On Windows, when attempting to build the testapp from the command line the following errors are observed:
syntax error near unexpected token `(' syntax error near unexpected token `(' syntax error: unexpected end of file
For example:
C:\stride\SDK\Windows\src>..\bin\make testapp /bin/sh: -c: line 0: syntax error near unexpected token `(' /bin/sh: -c: line 0: `IF EXIST ../out. (IF NOT EXIST ../out/src mkdir "../out/src") ELSE mkdir "../out" && mkdir "../out/src".' /bin/sh: -c: line 0: syntax error near unexpected token `(' /bin/sh: -c: line 0: `IF EXIST ../out. (IF NOT EXIST ../out/src mkdir "../out/src") ELSE mkdir "../out" && mkdir "../out/src".' /bin/sh: -c: line 1: syntax error: unexpected end of file make: *** [cleanapp] Error 258
- Cause
This error occurs because gnu make on Windows will search for an Unix shell (sh, bash or csh) anywhere in your PATH when executing shell commands and only default to DOS shell (cmd.exe) when no Unix shell is found. The sandbox Makefile uses DOS shell syntax, so when a Unix shell is found on your PATH, this results to errors like above.
Most commonly, this problem is caused by an installation of Cygwin, though it can also be caused by an installation of the QNX Software Development Platform.
- Solution
Explicitly specify the DOS shell by invoking make like:
..\bin\make SHELL=%ComSpec% testapp
Note: the value of %ComSpec% should be C:\Windows\system32\cmd.exe
An alternative is to remove any directories from your PATH that contain an Unix shell executable or otherwise prevent such from being found. (e.g. rename its parent directory).
Make Error 3
- Symptom
On Linux, when attempting to build the testapp from the command line, the following error is observed:
g++: command not found
For example:
# make testapp g++ -c -I”.” -I”../../Runtime” -I”../../SLAP” -I”../../GRS” -I”../out/src” -I”../sample_src” -fPIC -D_DEBUG -O0 -g3 -Wall -o ”../out/i386-Linux-obj/srtestpp.obj” ”../../Runtime/srtestpp.cpp” /bin/sh: g++: command not found make: *** [../out/i386-Linux-obj/srtestpp.obj] Error 127
- Cause
The C++ compiler, g++ can't be found on your PATH.
Most commonly, this problem is caused by not having a complete installation of GNU Compiler Collection.
- Solution
Make sure you have a compele GNU Compiler Collection installed.
Make Error 4
- Symptom
When building the testapp from the command line, you see the following compiler errors:
../out/src/strideIM.cpp(50) : error C3861: '_srTestResultCountReset': identifier not found ../out/src/strideIM.cpp(54) : error C3861: '_srTestSendFinalStatus': identifier not found ../out/src/strideIM.cpp(56) : error C3861: '_srTestAddToTotal': identifier not found ../out/src/strideIM.cpp(56) : error C3861: '_srTestResultGetTotals': identifier not found ... ... ...
- Cause
You are using an outdated version of the STRIDE build tools.
You can see which version of the tools were used to generate your STRIDE sources by looking at the top of the strideIM.cpp source file. The comment block at the top of the file shows this version.
- Solution
Remove the old tools and/or change your path so that the current tools are used.