Stride Sandbox

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/FreeBSD) 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 Suites in these .h files
• the generation of a database (.sidb) file required for executing tests
• 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:

NOTE: If you experience any build problem please make sure to read Troubleshooting Build Problems for possible resolution.

Linux/FreeBSD

1. Build the test app using GNU make

   make -C "$STRIDE_DIR/SDK/Posix/src" testapp
   

2. 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.

1. If using Microsoft Visual Studio, open a Visual Studio Command Prompt to ensure that the compiler and linker are on your PATH.
2. Build the test app using the supplied GNU make. (You will get Makefile errors if you use the default make.)

   "%STRIDE_DIR%\SDK\Windows\bin\make" -C "%STRIDE_DIR%\SDK\Windows\src" testapp
   

3. 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:

1. Invoke the TestApp. In order to see TestApp's output, we recommend that you manually run in a console window (or Windows equivalent):

   Linux/FreeBSD

   $STRIDE_DIR/SDK/Posix/out/bin/TestApp
   

   Windows

   %STRIDE_DIR%\SDK\Windows\out\bin\TestApp
   

   (...or launch from the file explorer)

2. 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.
   

3. From a second console window, invoke stride as follows, to verify connectivity with the test app and STRIDE runtime operation:
   

   Linux/FreeBSD

   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.
   

4. Note the Summary results shown in the host output; all in use tests should pass.
5. To exit TestApp, give the target window focus and enter Ctrl-C.

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.

Solution

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 complete 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.