Quick Nav
- Platform Makefile
- Windows Nmake
- Modifying Defaults
- Installing
- Cross Compiling
- Specifying a Tool chain
- Supporting OpenSSL
- Supporting Ejscript
- Building with Bit
- Building with an IDE
See Also
Building with Make or Nmake
This document describes the process to build the software from source using Make or Nmake on Windows. First make sure you have read Building from Source to prepare your build environment.
Platform Makefiles
Appweb provides a suite of generated, pre-configured Makefiles for common platforms. These are simple flat makefiles that build a default configuration of Appweb for a specific operating system. These makefiles are provided under the ./projects directory.
A top level Makefile is also provided that detects your operating system and CPU architecture and then invokes the appropriate project Makefile for your system. For example:
$ make make --no-print-directory -f projects/appweb-macosx-default.mk all ...
Windows Nmake
On Windows, a make.bat file is provided to to invoke nmake. The make.bat file first invokes projects/windows.bat which runs the Visual Studio vcvarsall.bat procedure to setup the necessary Visual Studio environment variables for compiling.
To build on Windows with nmake, type:
$ make nmake -f projects\appweb-windows.nmake ...
Modifying the Makefile Defaults
You do not use the configure program when building via Make, that is used only for building with Bit. Rather, you supply configuration options directly to Make. These options override default values defined by the projects/appweb-OS-default.mk makefile and by the projects/appweb-OS-debug-bit.h file. For example, to disable use of SQLite:
$ make BIT_PACK_SQLITE=0
Extension packs are enabled by setting their corresponing BIT_PACK_NAME option to 1. Disable by setting to zero. Some packs requires a path to locate libraries and headers. Use BIT_PACK_NAME_PATH to define the path to the extension pack.
By defining make variables such as CC and CFLAGS, you can modify the compiler options. This is the also the technique used when cross-compiling.
To see the list of configurable options, run:
$ make help usage: make [clean, compile, install, run, uninstall] The default configuration can be modified by setting make variables Set to 0 to disable and 1 to enable: PROFILE # Select default or static for static linking BIT_EJS_DB # Enable database support, ejs.db BIT_EJS_MAIL # Enable mail support, ejs.mail BIT_EJS_MAPPER # Enable database mapper support, ejs.mapper BIT_EJS_TAR # Enable tar support, ejs.tar BIT_EJS_TEMPLATE # Enable template support, ejs.template BIT_EJS_WEB # Enable web support, ejs.web BIT_EJS_ZLIB # Enable zlib support, ejs.zlib BIT_ESP_MDB # Enable ESP MDB database support BIT_ESP_SDB # Enable ESP SQLite database support BIT_MPR_LOGGING # Enable application logging BIT_MPR_TRACING # Enable debug tracing BIT_PACK_CGI # Enable the CGI handler BIT_PACK_DIR # Enable the directory listing handler BIT_PACK_EJSCRIPT # Enable the Ejscript handler BIT_PACK_ESP # Enable the ESP web framework BIT_PACK_EST # Enable the EST SSL stack BIT_PACK_MATRIXSSL # Enable the MatrixSSL SSL stack BIT_PACK_NANOSSL # Enable the Mocana NanoSSL stack BIT_PACK_OPENSSL # Enable the OpenSSL SSL stack BIT_PACK_PHP # Enable the PHP framework BIT_PACK_SQLITE # Enable the SQLite database BIT_ROM # Build for ROM without a file system For example, to disable CGI: make BIT_PACK_CGI=0 Other make variables: ARCH # CPU architecture (x86, x64, ppc, ...) OS # Operating system (linux, macosx, windows, vxworks) CC # Compiler to use LD # Linker to use DEBUG # Set to debug or release for debug or optimized builds CONFIG # Output directory for built items. CFLAGS # Add compiler options. For example: -Wall DFLAGS # Add compiler defines. For example: -DCOLOR=blue IFLAGS # Add compiler include directories. LDFLAGS # Add linker options LIBPATHS # Add linker library search directories. LIBS # Add linker libraries. For example: -lpthreads PROFILE # Build profile, used in output products directory name
By defining the make variables such as CC and CFLAGS, you can modify the compiler options. This is the technique used when cross-compiling. For more details, see Cross Compiling below.
Installing with Make
You can install the newly built software via:
sudo make install
You can remove by:
sudo make uninstall
Warning: Must Use Same Option
It is essential when invoking make install, that you provide the same make flags and options as you did when compiling. This is because the Makefile will conditionally install only the selected components for those options.
For example, to build and install PHP:
$ make BIT_PACK_PHP=1 BIT_PACK_PHP_PATH=/usr/src/php compile $ sudo make BIT_PACK_PHP=1 BIT_PACK_PHP_PATH=/usr/src/php install
Deploying
If you need to deploy to a different system or capture the build products, you can install to a specific directory via:
make deploy
This will install to the deploy directory under the output platform directory.
Cross Compiling with Make
Building a product for platform different to that of the local system is called cross compiling. Sometimes this compiling is just for a different instruction set (say x64 instead of x86). Other times, it is for a completely different operating system and/or CPU architecture. In such cases, a cross-compiler is typically required to build for the target platform.
Appweb supplies makefiles for Linux, Windows, FreeBSD, MAC OSX and VxWorks. To cross compile, you invoke the relevant project makefile and pass the required CPU architecture as a make variable. For example, to cross compile for VxWorks on ARM:
make -f projects/appweb-vxworks-default.mk ARCH=arm PROFILE=debug
When make runs, it places the output products (executables, libraries and objects) in a platform-specific output directory. This is named using the form: OS-ARCH-PROFILE. For example: vxworks-arm-debug. In this manner, make can be invoked multiple times, once for each target platform and the results will be captured in separate platform output directories. Some of the supported architectures for the ARCH field are: arm, mips, ppc, x64 and x86. The PROFILE is a descriptive name chosen by you for your configuration.
If there is not a makefile for your target operating system, copy the closest makefile and edit to suit your target platform.
Specifying the CPU
The build will generic CPU type within the specified architecture. To override the default choice and specify a CPU type within an architecture, use the CPU variable. For example:/p>
make OS=vxworks ARCH=arm CPU=arm7tdmi
Specifying a Tool Chain
You may need to specify where Make can locate your cross-compiler and other tools. You can supply these via the make variables: CC, CFLAGS, DFLAGS, IFLAGS, LD and LDFLAGS.
For example:
make CC=/opt/bin/ccarm.exe LD=/opt/bin/ccarm.exe ARCH=arm PROFILE=release -f projects/appweb-vxworks-default.mk
Supporting OpenSSL
If OpenSSL is required to provide SSL support, you must specify the path to the OpenSSL source directory. For example:
make BIT_PACK_OPENSSL=1 BIT_PACK_OPENSSL_PATH=/path/to/openssl compile
If you are using a binary OpenSSL distribution, provide the path where the OpenSSL libraries are located (typically /usr/lib).
make BIT_PACK_OPENSSL=1 BIT_PACK_OPENSSL_PATH=/usr/lib compile
Static Building
If you require a static build without the ability to dynamically load modules, use the static makefile profile. For example:
make PROFILE=static
Some web frameworks such as ESP and Ejscript may have reduced functionality in static builds.
Building for VxWorks
Before building for VxWorks, you must define the WIND_* environment variables via the wrenv.sh script provided with VxWorks. This defines the WIND_BASE, WIND_HOST_TYPE and other required environment variables.
The command below runs wrenv.sh and defines the WIND variables in the current shell's environment.
eval `/WindRiver/wrenv.sh -p vxworks-6.8 -o print_env -f sh`
Once defined, you can invoke make.
make OS=vxworks
If you require a static build, set the profile to "static".
make OS=vxworks PROFILE=static
Supporting Ejscript
If Ejscript is required, you must also build Appweb for the local system as the Ejscript compiler is a necessary tool when compiling the Ejscript library for the target. To do this, run make for the local development system first and then pass the binary output directory for the local system to the cross make. For example, if developing on a Linux X86 system:
make make LBIN=linux-x86-debug/bin -f projects/appweb-vxworks-default.mk
The first make will compile the software for the local development system. The second make will do the cross compilation using tools from the directory specified by the LBIN variable.