HP Integrity NonStop J-Series - Manual (Page 44)

Building with make on Windows
To build with make on Windows, either Cygwin or Msys must be installed. Both are available on
the NSDEE installation media. The path to the bin directory containing the make program must
be part of your PATH environment variable. A Cygwin or Msys bin directory can be added to
PATH
either outside of NSDEE (for example, by adding bin to your Windows PATH) or by NSDEE
prepending a bin path to PATH when builds are launched. For more information on NSDEE
prepending a bin path to PATH, see
“NSDEE_CONN_PORT, nsdee-auth, and Deploy.jar” (page 48) .
SQL managed builds
NSDEE's managed builds support both SQL/MX and SQL/MP. To create a project with managed
builds that support SQL/MX or SQL/MP, you must select the SQL/MX or SQL/MP radio button
on the Initial Build Settings dialog of the new project wizard. When you create a project that
supports SQL/MX or SQL/MP, NSDEE adds SQL tools to the tool chain for your project. For more
information, see
“Tool chains” (page 56) .
SQL builds require access to a NonStop system to process SQL statements during object builds
and for final SQL compilation. This access requires that compilers and linkers authenticate your
credentials during builds. NSDEE provides the program nsdee-auth that obtains your password
from NSDEE and passes it to compilers and linkers during builds. For details, see
“NSDEE_CONN_PORT, nsdee-auth, and Deploy.jar” (page 48) .
IMPORTANT: If you build an SQL/MP project behind a Windows firewall, the firewall will block
Portmapper.exe . To prevent this block, create a new firewall rule to allow Portmapper.exe
for both TCP and UDP.
The SQL/MX preprocessor, managed build, and header files
Managed builds run the SQL/MX preprocessor on SQL/MX preprocessor files as a separate step
from source file compilation, which results in each preprocessor run creating a source file. Because
the source file is derived, it is written to the output directory for the build and not the source directory
where the preprocessor file resides. For C and C++ sources, this means relative paths to header
files are different for preprocessor files and the source files derived from them.
Environment variables and build variables
For local projects, NSDEE sets a number of environment variables and build variables on your
behalf. Build variables are internal to Eclipse and are evaluated prior to creating makefiles and
launching a build. Environment variables, on the other hand, are passed to the shell in which a
build is launched and are evaluated when discovered by make in makefiles.
Build variables and environment variables look similar. Build variables are enclosed in curly braces:
for example, ${VARNAME}; whereas environment variables are enclosed in parentheses: for
example, $(VARNAME). The following sections describe each of the build variables and environment
variables defined by NSDEE.
Table 3 (page 45) provides an overview of build variables and
environment variables and for which types of projects NSDEE sets these variables.
When an environment variable is added, the variable is set along with its origin type, BUILD
SYSTEM
or USER: CONFIG.
BUILD SYSTEM
If an environment variable, COMP_ROOT for example, is added as part of Project creation or
project property modification where the variable is defined, the origin is set to BUILD SYSTEM.
The variable is set to BUILD SYSTEM when NSDEE sets the variable.
USER: CONFIG
When a user adds or overrides an environment variable, then the variable is added with its
origin marked as USER: CONFIG. When the value of a variable such as COMP_ROOT (which
was set during project creation and hence marked as a BUILD SYSTEM) is updated by the
44 Concepts