# Building eXtremeDB Libraries on Unix-Linux

> As explained in the Building and running SDK Samples page, makefiles are provided in the eXtremeDB root directory and all sample (project) directories. If it is necessary to rebuild the eXtremeDB libraries, the build system is a process of running the GNU make utility with a combination of cascade makefiles, project files and possible additional third-party products as described in the following sections.

> The instructions in the sections below use the following terms:

> - The product: McObject's eXtremeDB DBMS (DataBase Management System)
> - Build system: A computer system used to convert the eXtremeDB source code to executable binary code for host and target systems
> - Target system: A computer system where the eXtremeDB code will to be executed
> - Host system: A computer system used to develop applications for the target system
> - Third-party software: Software developed outside of McObject used in eXtremeDB code
> - Make: the GNU make utility (v 3.81 and later) used to build eXtremeDB code
> - Toolchain: A set of programs used to produce executable code out of source code (compiler, linker, etc)
> - Compiler family: A number of toolchains with similar behavior. Compiler family defines compiler/linker executable names, the way to pass control switches to the compiler, parameter conventions and other details on how to make the compiler produce binary code.

> # Build systems entry-points

> The build system supports the following entry points:

> > ### all

> > Build all binaries

> >         make … all …

> > ### clean

> > Clean the tree. This command removes only intermediate files leaving the final products and build-logs intact.

> >         make … clean …

> > ### distclean

> > Total cleanup. This command removes all the intermediate files and directories; the final files and the build logs will be purged out of the directory tree.

> >         make … distclean …

> > Also, the following old-fashion targets (from eXtremeDB releases prior to version 8.0) are left for compatibility:

> > ### host

> > Builds only the host-side executables.

> > ### target

> > Builds only the target-side utilities and libraries.

> > ### tools

> > This is the logical combination `host + target`

> > ### samples

> > Builds the samples only.

> # Make systems tips

> Following are some tips for using the build system:

> - Run make with the `-j` command line option to enable a parallel build. The option has parameter "`-j X`" where `X` is the number of CPUs allowed to use. The specification `-j 1` runs make on a single CPU which is good for build issue investigations. Running `-j` with no limitation will use all available CPUs in the build system.
> - In some cases running the build procedure on many CPUs may exhaust the system resources or reach user limitations (quotas). If, during the build process, the system become unresponsive or reports an insufficiency of file or process handles, try to adjust the limits or decrease the number of CPUs used.
> - Be courteous to other users on your build system if you share one. Do not consume the full machine power at once. A parallel build on a server may affect other users and services on the system.

> For MacOS systems:

> > Make sure your `JAVA_HOME` environment variable has a valid value. The typical way to initialize the variable is in the `~/.profile`. Add following line into the file:

> >         export JAVA_HOME=$(/usr/libexec/java_home)

> > Make sure your user has enough resources available. Increase the "number of processes per user" limit using:

> >         sudo sysctl -w kern.maxprocperuid=4096

> ## Templates

> Following are some templates for files of the build system, ready for copy-paste. You need to make a unique name for your project and substitute `<project-name>` with this name.

> ### Sub-directory or Project-directory level makefile

> Do not forget to change `<offset-path-to-the-root-directory>` with your offset path.

>         MCO_ROOT=$(abspath <offset-path-to-the-root-directory>)
>         include $(MCO_ROOT)/include/settings.makefile
>         include $(if $(findstring yes,$(MCO_QUICK_BUILD))$(findstring on,$(MCO_QUICK_BUILD)),,
>             $(MCO_ROOT)/)makefile.cascade
>         include $(MCO_ROOT)/include/rules.makefile

> ### Sub-directory level makefile.cascade

> Substitute `<directory1>…<directoryN>` with the names of your directories. If some of the directories are optional put "`-`" before the `include` directive.

>         include $(call mco_makefile_file, \
>             <directory1>/makefile.cascade \
>             ...
>             <directoryN>/makefile.cascade \
>         )

> ### Project-directory level makefile.cascade

> Do not forget to change `<project-name>` with the unique name of your project. If you have several projects in the same directory and some of them are optional (i.e. the existence of the project depends on features included into the package), then "`-`" may be specified in front of the `include` directive.

>         MCO_FILE_DIR:=$(dir $(lastword $(MAKEFILE_LIST)))
>         include $(MCO_FILE_DIR)makefile.project.<project-name-1>
>         ...
>         include $(MCO_FILE_DIR)makefile.project.<project-name-N>

> ### Project-directory level makefile.project.<project-name> for a sample program

> Do not forget to change `<project-name>` with the unique name of your project.

>         MCO_PRJ_LIST += <project-name>
>         PRJ_TARGET_EXECUTABLE_DPTR += <project-name>
>         PRJ_TARGET_EXECUTABLE_OFFS += <project-name>
>         PRJ_<project-name>_TAGS:=<project-name> sample core
>         PRJ_<project-name>_DIR:=$(call mco_project_dir)
>         PRJ_<project-name>_SRC:=$(call mco_project_file,main.c) $(MCO_SAMPLES_COMMON_DIR)/common.c
>         PRJ_<project-name>_SCHEMAS:=$(call mco_project_file,schema.mco)
>         PRJ_<project-name>_DATABASES:=<database-name>
>         PRJ_<project-name>_RUNTIME:=YES
>         PRJ_<project-name>_MEMDEV:=PRIVATE
>         PRJ_<project-name>_STORAGE:=TRANSIENT
>         PRJ_<project-name>_SYNC:=AUTO
>         PRJ_<project-name>_TRANSMGR:=MURSIW

> ### Project-directory level makefile.project.<project-name> for a library

> Do not forget to change `<project-name>` with the unique name of your project.

>         MCO_PRJ_LIST += <project-name>
>         PRJ_TARGET_LIBRARY_DPTR_STATIC  += <project-name>
>         PRJ_TARGET_LIBRARY_DPTR_DYNAMIC += <project-name>
>         PRJ_TARGET_LIBRARY_OFFS_STATIC  += <project-name>
>         PRJ_TARGET_LIBRARY_OFFS_DYNAMIC += <project-name>
>         PRJ_<project-name>_TAGS:=<project-name> target core
>         PRJ_<project-name>_DIR :=$(call mco_project_dir)
>         PRJ_<project-name>_SRC :=$(call mco_project_file, mcosrc1.c … mcosrcN.cpp)

> # Issues and diagnostics

> In most cases, build issues come from the incompatibility of third-party products installed in the build system and eXtremeDB requirements. Sometimes the versions of the products are different from those required. Sometimes the build system lacks the development headers of the products.

> Usually, the process of issue detecting is specific for every case, but a good approach is to:

> 1. Use `MCO_EXPLAIN=python,openssl` to see why and how the build script decided to use the third-party components:

>         $ make qqq MCO_EXPLAIN=openssl,python
>         Analyzing build environment...
>         MCO_FORCE_PYTHON=auto
>         MCO_BUILD_PYTHON=/usr/bin/python
>         [X] - OpenSSL 1.1.1 exists on the build system
>         [ ] - Forced to use MCO_OPENSSL_INCLUDE_PATH env. variable
>         [ ] - Forced to use build system OpenSSL installation
>         [ ] - Forced to build and use own OpenSSL installation
>         [ ] - auto-detection enabled, MCO_OPENSSL_INCLUDE_PATH env. variable is
>             set and development headers are present
>         [ ] - auto-detection enabled, the build system match to the target system
>             and there are usable development headers in the local OpenSSL installation
>         [X] - auto-detection enabled, build and use own OpenSSL installation if all above failed
>         [ ] - Invalid value of MCO_FORCE_OPENSSL detected, build and use own OpenSSL installation
>         MCO_TARGET_OPENSSL_INCLUDE=/home/x/t1219/eXtremeDB/target/sal/net/openssl-Linux-x86_64/include

>         [X] Python does exist on the build system
>         [X] Target and build-system arch. signatures are the same [+] or Build system is x86_64
>             and the target is x86 [+] (python is runnable and good for the target usage)
>         [X] DBus width match (otherwise not good for target usage)
>         [X] Build python is 2.7.x (otherwise not good for target/cross usage)
>         [ ] Dev. headers are present (otherwise not good for target usage)
>         BUILD_PYTHON =/usr/bin/python
>         CROSS_PYTHON =/home/x/t1219/eXtremeDB/target/python/Python-2.7.14-Linux-x86_64/bin/python2.7
>         TARGET_PYTHON=/home/x/t1219/eXtremeDB/target/python/Python-2.7.14-Linux-x86_64/bin/python2.7

>         Loading cascade make system...
>         Setting up the build procedure...
>         Processing...
>         make: *** No rule to make target 'qqq'.  Stop.

> 2. Run make with explanations enabled and gather it's output log and internal database:

>         $ make MCO_EXPLAIN=openssl,python all -p>issue-log 2>&1

> 3. For investigation of any compilation, it is good to disable parallel building and enable detailed logging (no `-j` make option!)

>         make MCO_BUILD_LOG=full all

> # The make utility

> The eXtremeDB build system utilizes the GNU make utility to build the product's source code into a set of executables and libraries used during development of end-user applications. To do its job, the make utility maintains products and source files dependency information in the form of a dependency tree where the top-level node (target in make's terminology) that depends on several sub-targets, then sub-sub-targets and so on down to the terminal nodes which are the source files. The make utility is able to track source file modifications using the file systems timestamps and file "exist" functions. Thus, make is able to track changes in the dependency chains and update all affected targets that depend on the modified source file.

> The build system includes two sub-systems: one is an array of project files that describe each of the eXtremeDB components as projects, defines the properties of the project and its dependencies; the other is a set of cascade make files that delivers the project information to the make utility in order to maintain the full dependency tree of all components, source code, headers, and eXtremeDB utilities. This full dependency tree gives the make utility the ability to trace and build (and re-build if necessary) any part of eXtremeDB. The build operations can be run as a series of build actions one-step-at-a-time or in parallel to utilize the full multi-CPU power of the build system.

> ## The cascade part of the build system

> The cascade makefile system is a set of `makefile.cascade` files located in all major directories of the product. The cascade makefile defines the hierarchy of directories and includes other downstream `makefile.cascade` files and project makefiles.

> ## The build system's project files

> Each component of the product is described by a project makefile for the build system. The project makefile defines what the component is, how it is to be built, it's source code files, flags, and properties. There are several types of project in the product: executables (for the host and the target separately), libraries (static and dynamic), JAVA class and jar files, Python modules and third-party modules used in the product.

> # Implementation of the build system

> The product build system is a set of interconnected makefiles. Among all these build systems files, there are some that are special: the top-level makefile, the include/settings.makefile and the include/rules.makefile.

> The top-level makefile initiates the build process. First, it includes the include/settings.makefile. This file contains all start-up settings for the build system and the required auto-detection heuristic. A user can override the settings externally or put necessary tunings into the include/settings.makefile. Then, the top-level makefile includes the top-level cascade file which runs (using the cascade inclusion technique) through the all the product's source tree and gathers other cascade and project makefiles. This step delivers the project properties of all the components and samples into the make system. Finally, the top-level makefile includes the include/rules.makefile. This file instructs the make utility how to build all the product files and all necessary intermediate files. This includes the dependency information that instructs the make utility what depends on what. Also, it generates the top-level target for the make command that initiates the build process.

> All other sub-directory makefiles (those with no extension) are necessary to be able to initiate the build procedure for this sub-directory and downstream directories. Internally the sub-directory makefiles define the current and top-level directory, and include the top-level makefile. This gives the build system the ability to check and, if necessary, rebuild not only the files in the current directory but even those in another parallel (from the source tree's point of view) directories in order to maintain correctness of the build process when one or several of the components was/were modified.

> The auto-detection heuristic implemented in the include/settings.makefile does the following:

> > 1. Detects the build platforms environment: Hardware architecture and OS.

> > 2. Sets the build utilities (such as echo, copy, make, etc.) used in the build process. (This setting depends on the build system.)

> > 3. Sets the build system's compiler family. The same compiler family is set for both host and target systems if no override is given in form of command line options `HOST_COMPILER_FAMILY` and `TARGET_COMPILER_FAMILY` (see section Make system overrides below).

> > 4. Using the compiler family information, the script detects the hardware and OS definition for host and target systems.

> > 5. Defines the default setting for eXtremeDB components such as: default memory drivers, synchronization primitives wrapper, file system drivers, etc.

> > 6. Defines the libraries and feature switches for the command generation for compilation and linking, depending on the project properties (for example the libraries that need to be linked into a program to support SQL functionality; or what needs to be given to the source code to make it aware of "Sequences" support).

> > 7. Finally, the script checks the existence of third-party products in the system and decides if it is possible to use the existing installations or if it is required to build its own. (See the detail below on the test and decision-making procedure.)

> The dependency-generation code is located in the include/rules.makefile. This code makes the dependency tree for the make utility using the project properties gathered by the cascade sub-system. Each of the projects has a unique name and the set of properties associated with that name. All project properties are defined using make variables, such as `PRJ_<project-name>_XXXX:=YYYY`, where `XXXX` is a property identifier and `YYYY` is a value. Also, there are several special variables named "lists" that contain the project names as references.

> The project needs to be linked into the `MCO_PRJ_LIST` list (i.e. its name needs to be added there as `MCO_PRJ_LIST += <project-name>`) and at least into one of the following lists:

> - `PRJ_HOST_EXECUTABLE` - the list of executable files for the host system. (MCOCOMP, SQL2MCO and etc. are included here.)
> - `PRJ_TARGET_EXECUTABLE_DPTR` - the list of executable files for the target system built for the `DPTR` variant of the eXtremeDB runtime. (For example, all of the `DPTR`-samples are included here.)
> - `PRJ_TARGET_EXECUTABLE_OFFS` - the list of executable files for the target system built for the `OFFS` variant of the eXtremeDB runtime. (For example, all the `OFFS`-samples are included here.)
> - `PRJ_TARGET_LIBRARY_DPTR_STATIC` - the list of the static `DPTR` libraries for the product
> - `PRJ_TARGET_LIBRARY_DPTR_DYNAMIC` - the list of the dynamic `DPTR` libraries for the product
> - `PRJ_TARGET_LIBRARY_OFFS_STATIC` - the list of the static `OFFS` libraries for the product
> - `PRJ_TARGET_LIBRARY_OFFS_DYNAMIC` - the list of the dynamic `OFFS` libraries for the product
> - `PRJ_TARGET_JAR` - the list of the Java JARs
> - `PRJ_TARGET_CLASS` - the list of the Java programs for the product
> - `PRJ_CUSTOM` - the list of the third-party components that need to be built for the product

> A project can be added to several suitable `PRJ`* lists (eg. C/C++ projects are good for libraries and executables, Java-projects - for Classes and Jars). For example, the `mcovtmem` project is included into the `PRJ_TARGET_LIBRARY_DPTR_STATIC` and `PRJ_TARGET_LIBRARY_DPTR_DYNAMIC` lists only, while the `mcovtdsk` library is present in all four `PRJ_TARGET_LIBRARY_*` lists. The build system sets up a special build procedure for every project based on these lists.

> The build script maintains global scope make targets, such as `build all` and `clean all`, using the `MCO_PRJ_LIST` list. The build all action is run from the command line `make all`, and produces all of the product binary files. The `clean all` action is run from the command line `make clean`, and removes all of the intermediate files but leaves the final binaries and build logs. The `make distclean` command line cleans everything. Also, it is possible to build each of the binary files (executables, the libraries, classes, and jars) separately using a command line like `make <binary-location-and-name>` (for example `make /home/user/eXtremeDB/target/bin/08-benchmarks-perf`).

> Note that the build system uses full file names to avoid "process current directory"-related disambiguate issues for parallel building.

> The build system includes a mechanism that allows the user to include or exclude selective components of eXtremeDB into or out of the build process. The filter is tag-based. Each of the project files defines a set of tags for each of the components and the `MCO_ENABLE` / `MCO_DISABLE` controls (see section Make system controls below) let the user determine the way to enumerate which of the target components need to be enabled or disabled. This mechanism not only excludes the named components from the build process, but also makes all of the other components aware of the status of the enabled / disabled components, and updates them accordingly. For example, `MCO_DISABLE=openssl` will exclude OpenSSL from the build procedure as well as the references to OpenSSL from the eXtremeDB crypto-driver and OpenSSL-specific examples.

> ## Third-party products in the eXtremeDB build system

> eXtremeDBuses some third-party software components (such as LUA, Java, Python, and OpenSSL) in its code. The use of these components is pretty version-sensitive: eXtremeDB code relies on the components' API and build-procedures. This is why the build script needs to make sure that the pre-installed version of the components located on the build system is suitable (i.e. that the version matches eXtremeDB requirements, the required hardware is supported, the development headers are present and so on). To achieve this, there are special precautions implemented in the build script:

> - LUA: This component does not require much. eXtremeDB has its full source code (+patches) in its source tree. The only thing is the cross-build procedure. The build system needs to build LUA code for every target platform separately.
> - Java: The build system always uses the build platform java installation. It is required to define the `JAVA_HOME` environment variable for the current build system.
> - Python: eXtremeDB works with Python 2.7.x only. It has the Python 2.7.14 source code package in its source tree. The build script tests the build system Python installation for the version number and development headers. Also, the target platform needs to match the build platform. If any of these conditions fail, the build script will build a target-specific Python installation and will use it to produce the eXtremeDB Python module. In some cases, the build script will need to build a cross-python - a python installation matching with data bus with to the target system and able to be executed on the build system.
> - OpenSSL: eXtremeDB is sensitive to the version of the OpenSSL component. The build system matches the version of the installed OpenSSL, its hardware platform and checks for development headers. If any of these conditions fail, the script builds the target-specific installation of the OpenSSL software out of the source code package existing in the eXtremeDB source tree.

> Note: it is possible to override the auto-detection for Python and OpenSSL using the `MCO_FORCE_OPENSSL` and `MCO_FORCE_PYTHON` controls. (See section Make system overrides below.)

> # Structure of the makefiles

> This section explains the internal structure of different kinds of makefiles used in the build system.

> ## root-level and sub-directory makefiles

> The root-level makefile defines the location of the eXtremeDB installation as an absolute path in the `MCO_ROOT` variable, includes the required parts of the build system and activates the cascade sub-system and the build process:

>         MCO_ROOT=$(abspath .)
>         include $(MCO_ROOT)/include/settings.makefile
>         include $(if $(findstring yes,$(MCO_QUICK_BUILD))
>             $(findstring on,$(MCO_QUICK_BUILD)),,$(MCO_ROOT)/)makefile.cascade
>         include $(MCO_ROOT)/include/rules.makefile

> The only difference for a sub-directory makefile is in the way to define `MCO_ROOT`. It converts an offset path to the root directory to its absolute representation:

>         MCO_ROOT=$(abspath ..)
>         include $(MCO_ROOT)/include/settings.makefile
>         include $(if $(findstring yes,$(MCO_QUICK_BUILD))
>             $(findstring on,$(MCO_QUICK_BUILD)),,$(MCO_ROOT)/)makefile.cascade
>         include $(MCO_ROOT)/include/rules.makefile

> In most cases, it is enough to copy an existing sub-directory makefile into a new directory and adjust the `MCO_ROOT` variable to produce a new sub-directory makefile.

> Note that the makefiles have some logic that work according to the `MCO_QUICK_BUILD` control. (See section Make system controls below for details.)

> ## makefile.cascade

> Typical sub-directory makefile.cascade files include all cascade files from the sub-directories below its level:

>         -include $(call mco_makefile_file, \
>             crypt/makefile.cascade \
>             mcobackup/makefile.cascade \
>             ...
>             python/makefile.cascade \
>             feedhandler/makefile.cascade \
>         )

> The project-level makefile.cascade file includes the project files and delivers the project properties into the make utility:

>         MCO_FILE_DIR:=$(dir $(lastword $(MAKEFILE_LIST)))
>         include $(MCO_FILE_DIR)makefile.project.mcolib

> The simplest way to create a new sub-directory or project makefile.cascade file is to copy an existing one and adjust the inclusion of the downstream cascade and project files.

> Note that very few cascade files contain logic that includes downstream projects depending on settings from the `include/settings.makefile`. For example

>         target/sal/sync/makefile.cascade: include $(call mco_makefile_file,

>             $(addprefix makefile.project.mcos,$(MCO_TARGET_SYNC_IMPLEMENTATIONS)))

> Note that some cascade files have a dash ("-") in front of the "include" directive. This construct of the make utility language defines optional inclusion, which is good for cases when a sub-level makefile.cascade needs to be included (may be or may be not present) in the source tree depending on the features included in a package.

> ## makefile.project.XXXX

> A typical project makefile defines the name of the project, its properties (such as source code files, databases, eXtremeDB features used etc.) and ties the project to appropriate lists to cause the build system to generate build procedures for the project.

> Following is a sample of a library-project makefile:

>         MCO_PRJ_LIST += mcosql
>         PRJ_TARGET_LIBRARY_DPTR_STATIC  += mcosql
>         PRJ_TARGET_LIBRARY_DPTR_DYNAMIC += mcosql
>         PRJ_TARGET_LIBRARY_OFFS_STATIC  += mcosql
>         PRJ_TARGET_LIBRARY_OFFS_DYNAMIC += mcosql
>         PRJ_mcosql_TAGS:=target sql malloc
>         PRJ_mcosql_DIR :=$(call mco_project_dir)
>         PRJ_mcosql_SRC :=$(call mco_project_file, dbapi.cpp compiler.cpp
>             sqlc.cpp operators.cpp optimizer.cpp nodes.cpp schema.cpp
>             sql.cpp utils.cpp exceptions.cpp stub.cpp value.cpp hash.cpp
>             multisql.cpp mcoapi.cpp mcosql.cpp mcoseq.cpp mcoapic.cpp)

> Following is a sample of an executable-project makefile:

>         MCO_PRJ_LIST += hasimple-master
>         PRJ_TARGET_EXECUTABLE_DPTR +=
>         PRJ_TARGET_EXECUTABLE_OFFS += hasimple-master
>         PRJ_hasimple-master_TAGS:=sample ha
>         PRJ_hasimple-master_DIR:=$(call mco_project_dir)
>         PRJ_hasimple-master_SRC:=$(call mco_project_file, master.c)
>             $(MCO_SAMPLES_COMMON_DIR)/common.c $(MCO_SAMPLES_COMMON_DIR)/commonha.c
>         PRJ_hasimple-master_SCHEMAS:=$(call mco_project_file,schema.mco)
>         PRJ_hasimple-master_DATABASES:=simplemstdb
>         PRJ_hasimple-master_RUNTIME:=YES
>         PRJ_hasimple-master_MEMDEV:=PRIVATE
>         PRJ_hasimple-master_STORAGE:=TRANSIENT
>         PRJ_hasimple-master_SYNC:=AUTO
>         PRJ_hasimple-master_TRANSMGR:=MURSIW
>         PRJ_hasimple-master_F_HA:=TCP

> Note that the project files add the projects to the corresponding build system lists and the defined project properties. For the meaning of the "properties" see section Project makefile flags below.

> ## Third-party makefiles

> The make system wraps the third-party make systems with special project files. A project file is "special" depending on the details of how the third-party product build process needs to be handled. These files are pretty complicated. For reference see: `target/sal/net/makefile.project.openssl` or `target/python/makefile.project.python`. The build procedure, products, build-logs and intermediate files are handled via the `PRJ_CUSTOM` list. (See section Project makefile flags below for details.)

> # Control switches and overrides

> Following is the full list of available control switches, overrides and project properties.

> ## Project makefile flags

> ### Build lists

> The following lists are common for all project makefiles. A project needs to be included into `MCO_PRJ_LIST` and into at least one of other `PRJ`_-lists depending on the meaning of the project. The project can be included in as many `PRJ_`-lists as required provided the project's code is suitable for it.

> Note that the "+=" operator is used for the inclusion.

> `MCO_PRJ_LIST`

> A project needs to be included into `MCO_PRJ_LIST` to make the build system aware of it. This list is used to generate global-scope operation code for the `build all` and `clean all` operations.

> Example:

>         MCO_PRJ_LIST += <project-name>

> `PRJ_HOST_EXECUTABLE`

> This list contains all the projects that generate host-side executable files including `mcocomp`, `sql2mc`o eXtremeDB host utilities.

> Example:

>         PRJ_HOST_EXECUTABLE += <project-name>

> `PRJ_TARGET_EXECUTABLE_DPTR`

> `PRJ_TARGET_EXECUTABLE_OFFS`

> These lists include target-side eXtremeDB executables such as the `regunlock` utility and xSQL. The project needs to be put in the `DPTR`-list or `OFFS`-list depending on its meaning, or possibly into both of them.

> Example:

>         PRJ_TARGET_EXECUTABLE_DPTR += <project-name>
>         PRJ_TARGET_EXECUTABLE_OFFS += <project-name>

> `PRJ_TARGET_LIBRARY_DPTR_DYNAMIC`

> `PRJ_TARGET_LIBRARY_OFFS_DYNAMIC`

> `PRJ_TARGET_LIBRARY_DPTR_STATIC`

> `PRJ_TARGET_LIBRARY_OFFS_STATIC`

> These lists include all target-side eXtremeDB library-projects. If a library is meant to be built as a static code container, it needs to be added to the `STATIC`-list, and to `DYNAMIC`-list for dynamic-loaded modules. The `DPTR`-lists and `OFFS`-lists separate `DPTR` and `OFFS` versions of the libraries. In most cases a library project would be included into all four of the lists but in some cases only a dynamic version is desired (for example feed handlers modules), or only the `OFFS` version makes sense (eg. the `mcovtdsk` library).

> Example:

>         PRJ_TARGET_LIBRARY_DPTR_DYNAMIC += <project-name>
>         PRJ_TARGET_LIBRARY_OFFS_DYNAMIC += <project-name>
>         PRJ_TARGET_LIBRARY_DPTR_STATIC += <project-name>
>         PRJ_TARGET_LIBRARY_OFFS_STATIC += <project-name>

> `PRJ_TARGET_CLASS`

> This list defines projects meant to be Java-classes. These projects are processed by the Java compiler into separate class-files.

> Example:

>         PRJ_TARGET_CLASS += <project-name>

> `PRJ_TARGET_JAR`

> The projects from this list produce Java code library JAR files. These projects are compiled using the Java compiler and are then put together with the jar utility.

> Example:

>         PRJ_TARGET_JAR += <project-name>

> `PRJ_TARGET_ANALYZE_ONLY`

> This is a quite special list. The build system processes the projects on the list, generates build properties out of the project properties, but does not generate code that produces the project products. The generated build properties may be used for some projects that need a special procedure to build its products.

> Example:

>         PRJ_TARGET_ANALYZE_ONLY += <project-name>

> `PRJ_CUSTOM`

> This is another special project list. The projects from this list need to be built using a special custom procedure defined in the project's makefile.

> Other `PRJ`-flags are required to be set for projects such as `PRJ_<project-name>_PRODUCTS`, `PRJ_<project-name>_PRODUCT_DIRS`, `PRJ_<project-name>_INTERMEDIATE_DIRS` and `PRJ_<project-name>_BUILD_LOGS`. In most cases, the project needs to add its build procedure to the `PRJ_GENERATE_CUSTOM_RULES` list.

> Example:

>         PRJ_CUSTOM += <project-name>
>         PRJ_GENERATE_CUSTOM_RULES += <project-name-build-proc>
>         PRJ_<project-name>_PRODUCTS         :=$(addprefix $(MCO_PRODUCT_ROOT)/target/bin/<dir>,
>             <project-name>.so <project-name>_debug.so)
>         PRJ_<project-name>_PRODUCT_DIRS     :=$(MCO_PRODUCT_ROOT)/target/bin/<dir>
>         PRJ_<project-name>_INTERMEDIATE_DIRS:=$(subst $(MCO_ROOT),$(MCO_BUILD_ROOT),
>             $(PRJ_<project-name>_DIR)/build-$(MCO_TARGET_ARCH_SFX))

> ### Common project flags

> The following flags define basic project properties and need to be included into every project file. Certainly, every project has to have a unique `<project-name>`; like "00-ddl" for instance.

> Note that the ":=" operator is used for value assignment. Other kinds of assignment mean value expansion for the make utility and need to be used very carefully due to the asynchronous nature of the build procedure. There is no way to predict the order of the values assignment.

> `PRJ_<project-name>_DIR:=$(call mco_project_dir)`

> This list defines the location of the project as an absolute path. All projects initialize this property via `$(call mco_project_dir)`. This construct calculates the path out of the `makefile.project-file` location.

> Example:

>         PRJ_00-ddl_DIR:=$(call mco_project_dir)

> `PRJ_<project-name>_TAGS`

> This list assigns tag(s) to the project (as a space-separated list). Using the tags it is possible to define logical groups within the project (by a feature, os-specific, etc). The build system is able to enable/disable the groups by user request or automatically.

> Example:

>         PRJ_00-ddl_TAGS:=sample core

> `PRJ_<project-name>_SRC`

> This list defines a set of project source code files (as a space-divided list). It may include C/C++ files and headers and Java files. Each of the files must be specified by its name and absolute filesystem path. The build system construct `$(call mco_project_file, <file1.c> <file2.cpp> ... <fileN.h>)` helps with the file location.

> Example:

>         PRJ_00-ddl_SRC:=$(call mco_project_file,oidsize.h main.c) $(MCO_SAMPLES_COMMON_DIR)/common.c

> ### Project-dependent flags

> The following flags are project-dependent and may or may not be specified depending on the meaning of the project.

> `PRJ_<project-name>_RUNTIME`

> Enables or disables the eXtremeDB runtime for the project.

> Possible values:

> - `<not set>` - do not add the eXtremeDB runtime into the project (good for non-eXtremeDB projects)
> - `YES` - add the runtime libraries into the project

> Example:

>         PRJ_00-ddl_RUNTIME:=YES

> `PRJ_<project-name>_STORAGE`

> Defines the type of database storage for the project

> Possible values:

> - `TRANSIENT` - Pure in-memory database, use the `mcovtmem` component
> - `PERSISTENT` - Persistent/hybrid database, use the `mcovtdsk` component

> Example:

>         PRJ_00-ddl_STORAGE:=TRANSIENT

> `PRJ_<project-name>_MEMDEV`

> Defines the memory device used for the project as the database memory storage

> Possible values:

> - `<not set>` - no memory driver on the linker line
> - `PRIVATE` - use the default private memory driver for current platform (defined in `include/settings.makefile`)
> - `SHARED` - use the default shared memory driver for current platform (defined in `include/settings.makefile`)
> - `<other>` - use a special memory drive, put the value to the linker line as the memory driver

> Example:

>         PRJ_00-ddl_MEMDEV:=PRIVATE

> `PRJ_<project-name>_STORAGEDEV`

> Defines the persistent storage driver for the project. This works for persistent and hybrid database based projects.

> Possible values:

> - `AUTO` - use the default persistent storage driver for the current platform (defined in `include/settings.makefile`)
> - `<not set>` - no storage driver
> - `<other>` - put the specified value to the linker line as the storage driver

> Example:

>         PRJ_02-open-disk_file_STORAGEDEV:=AUTO

> `PRJ_<project-name>_SYNC`

> Defines the synchronization implementation for the project. In the most cases, AUTO will serve the project well.

> Possible values:

> - `AUTO` - use the default synchronization implementation for the current platform depending on `PRJ_<project_name>_MEMDEV` setting.
> - `<not set>` - use no synchronization. implementation on the linker line
> - `<other>` - put the specified value to the linker line as the synchronization implementation library

> Example:

>         PRJ_00-ddl_SYNC:=AUTO

> `PRJ_<project-name>_TRANSMGR`

> Defines the transaction manager for the project.

> Possible values:

> - `MURSIW` - use the `MURSIW` TM implementation library
> - `MURSIW_READ` - use the Read-optimized `MURSIW` TM implementation library
> - `MVCC` - use the `MVCC` TM implementation library
> - `EXCLUSIVE` - use the `Exclusive` TM implementation library
> - `<not set>` - no TM library on the linker line

> Example:

>         PRJ_00-ddl_TRANSMGR:=MURSIW

> `PRJ_<project-name>_DATABASES`

> `PRJ_<project-name>_SCHEMAS`

> These two flags define the project databases (names) and the schema files. There can be several database names/schemas divided by spaces in the list. The number of items in the lists must match. The schema files must be represented by the file names with absolute path ( `$(call mco_project_file,<schema.mco>` helps here).

> Possible values:

> - `PRJ_<project-name>_SCHEMAS:=$(call mco_project_file,<schema1.mco> ... <schemaN.mco>)`
> - `PRJ_16-uda-udameta_DATABASES:=<database1-name> ... <databaseN-name>`

> Example:

>         PRJ_16-uda-udameta_SCHEMAS:=$(call mco_project_file,
>             uda1.mco uda2.mco uda3.mco uda4.mco uda5.mco)
>         PRJ_16-uda-udameta_DATABASES:=uda1 uda2 uda3 uda4 uda5

> `PRJ_<project-name>_F_BACKUP`

> Indicates that the project uses Inline Backup feature.

> Possible values:

> - `YES` - Enable the Incremental Backup feature (and the libraries) for the project.
> - `<not set>` - no support for Incremental Backup in the project.

> Example:

>         PRJ_18-backup-online_F_BACKUP:=YES

> `PRJ_<project-name>_F_CLUSTER`

> Enables the Cluster feature for the project.

> Possible values:

> - `TCP` - enable Cluster support and set TCP as the transport
> - `MPI` - enable Cluster support and set MPI as the transport
> - `<not set>` - do not enable the Cluster feature

> Example:

>         PRJ_cluster_attach_F_CLUSTER:=TCP

> Note: do not forget to put `PRJ_<project-name>_TRANSMGR:=MVCC` for Cluster-enabled projects.

> `PRJ_<project-name>_F_CPP`

> Instructs the build system to generate the C++ interface for the project's databases (equivalent to setting the `-hpp` flag for `mcocomp`).

> Possible values:

> - `YES` - enable C++ interface
> - `<not set>` - no C++ interface

> Example:

>         PRJ_20-languages-cpp_smartptr_F_CPP:=YES

> `PRJ_<project-name>_F_CRT`

> Defines whether to use the C Runtime Library CRT wrappers for the project.

> Possible values:

> - `<not set>` - automatically use `mcouwrt` if the eXtremeDB runtime is enabled or none otherwise
> - `WRT` - use `mcouwrt` (CRT implementation of utility routines) unconditionally
> - `NRT` - use `mcounrt` (own CRT-independent implementation of utility routines) unconditionally

> Example:

>         PRJ_fh_F_CRT:=YES

> `PRJ_<project-name>_F_CRYPT`

> Enables cryptography support for the project.

> Possible values:

> - `YES` - Adds the `mcocryptaes` library to the linkage
> - `<not set>` - automatically adds `mcocryptstub` for FeedHandler-enabled or eXtremeDB-enabled projects, or none otherwise

> Example:

>         PRJ_02-open-security-disk_cipher_F_CRYPT:=YES

> `PRJ_<project-name>_F_DBCALC`

> Enables the DBCALC feature for the project

> Possible values:

> - `YES` - adds the DBCALC library to the linkage
> - `<not set>` - does nothing

> Example:

>         PRJ_17-statistics-dbcalc-conv_F_DBCALC:=YES

> `PRJ_<project-name>_F_FHLIB`

> Enables FeedHandler support for the project

> Possible values:

> - `YE`s - the FeedHandler feature is enabled
> - `<not set>` - the FeedHandler feature is not enabled

> Example:

>         PRJ_fh_F_FHLIB:=YES

> `PRJ_<project-name>_F_HA`

> Enables High Availability feature support for the project

> Possible values:

> - `TCP` - enables High Availability and sets TCP as the transport channel. Adds the default socket library to the linkage.
> - `UDP` - enables High Availability and sets UDP as the transport channel. Adds the default socket library to the linkage.
> - `PIPES` - enables High Availability and sets PIPES as the transport channel. Adds the default socket library to the linkage.
> - `<not set>` - no High Availability support for the project

> Note: there can be multiple space-divided values for this setting.

> Example:

>         PRJ_hasimple-master_F_HA:=TCP
>         PRJ_hamultichan-master_F_HA:=TCP UDP

> `PRJ_<project-name>_F_HV`

> Enables HttpView feature support for the project

> Possible values:

> - `YES` - enable the HttpView feature support. Automatically adds SQL support if the SQL feature is enabled.
> - `<not set>` - no support for the HttpView feature

> Example:

>         PRJ_22-httpview-sql_F_HV:=YES

> `PRJ_<project-name>_F_IOT`

> Enables IoT feature support

> Possible values:

> - `YES` - enable the IoT feature support.
> - `<not set>` - no support for the IoT feature

> Example:

>         PRJ_iot_simple_dev_F_IOT:=YES

> `PRJ_<project-name>_F_LOG`

> Enable the Transaction Logging feature for the project

> Possible values:

> - `YES` - enable Transaction Logging feature support
> - `<not set>` - no support for the Transaction Logging feature

> Example:

>         PRJ_tlogbasic_F_LOG:=YES

> `PRJ_<project-name>_F_NATIVE`

> Force native fields ordering for the `mcocomp` utility (equivalent to setting the `-nosort` option).

> Possible values:

> - `YES` - Do not reorder fields in the database schema structs
> - `<not set>` - usual behavior

> Example:

>         PRJ_createdb_sniffer_F_NATIVE:=YES

> `PRJ_<project-name>_F_ODBC`

> Enable ODBC support for the project

> Possible values:

> - `YES` - enable ODBC support
> - `<not set>` - no support for ODBC

> Example:

>         PRJ_simpleodbc_F_ODBC:=YES

> `PRJ_<project-name>_F_PERFMON`

> Enable the Performance Monitor feature for the project

> Possible values:

> - `YES` - enable the Performance Monitor feature support
> - `<not set>` - no support for the Performance Monitor feature

> Example:

>         PRJ_25-perfmon_F_PERFMON:=YES

> `PRJ_<project-name>_F_REST`

> Enable REST interface feature support (for Web Services) for the project

> Possible values:

> - `YES` - enable the REST feature support
> - `<not set>` - no support for the REST feature

> Example:

>         PRJ_24-rest-mt_F_REST:=YES

> `PRJ_<project-name>_F_SEQUENCES`

> Enable Sequence calculations support for the project

> Possible values:

> - `YES` - enable the Sequence feature support
> - `RLE` - enable support of RLE compression version of the Sequence feature
> - `<not set>` - no support for the Sequence feature

> Example:

>         PRJ_sequences-basic_F_SEQUENCES:=RLE

> `PRJ_<project-name>_F_SERI`

> Enable serialization for the project

> Possible values:

> - `YES` - enable serialization support
> - `<not set>` - no support for serialization

> Example:

>         PRJ_18-backup-bse-conv_F_SERI:=YES

> `PRJ_<project-name>_F_SMARTPTR`

> Enable generation of the SmartPtr interface for the C++ interface to the projects database (equivalent to setting the `-smartptr` option for `mcocomp`)

> Possible values:

> - `YES` - enable SmartPtr support
> - `<not set>` - no support for SmartPtr

> Example:

>         PRJ_20-languages-cpp_smartptr_F_SMARTPTR:=YES

> `PRJ_<project-name>_F_SQL`

> Enable the SQL feature support for the project.

> Possible values:

> - `LOCAL` - support for the local SQL engine
> - `REMOTE` - support for the RSQL engine + default socket library for the platform
> - `REMOTE_STANDALONE` - support for the RSQL client engine only + default socket library for the platform
> - `<not set>` - no SQL feature on the linker line

> Example:

>         PRJ_api-sql-01-c-api-mursimul_F_SQL:=LOCAL
>         PRJ_tpcodbc_F_SQL:=REMOTE
>         PRJ_api-sql-10-rsql-client-standalone_F_SQL:=REMOTE_STANDALONE

> `PRJ_<project-name>_F_UDA`

> Enables UDA database interface feature for the project

> Possible values:

> - `YES` - enable the UDA support
> - `<not set>` - no support for UDA

> Example:

>         PRJ_16-uda-udaops_F_UDA:=YES

> `PRJ_<project-name>_F_XML`

> Enable the XML database serialization feature for the project (equivalent to setting the `-x` option for `mcocomp`)

> Possible values:

> - `YES` - enable the XML feature support
> - `<not set>` - no support for the XML feature

> Example:

>         PRJ_16-uda-udaopen_F_UDA:=YES

> ### Overrides

> The following flags override default build system behavior on the project level.

> `PRJ_<project-name>_DEFINES`

> Adds special defines for the project in the form `<define-name>[=<define-value>]`. The build script will add the necessary compiler declaration directives automatically.

> Example:

>         PRJ_mcoews_DEFINES:=MCOEWS_BUILD_RUNTIME MCO_HTTP_OVERRIDE_CONFIG
>             MCO_HTTP_CGI MCO_SECURITY_NONE MCO_HTTP_CONNECTION_USER_DATA

> `PRJ_<project-name>_INCLUDE`

> Additional include locations for the project as directory paths. The build script will add the necessary compiler include path declaration directives.

> Example:

>         PRJ_mcocomplib_INCLUDE:=$(MCO_ROOT)/host/mcocomp

> `PRJ_<project-name>_DEBUG`

> Force the project to be linked with the debug version of the eXtremeDB libraries.

> Possible values:

> - `YES` - set the debug libraries unconditionally
> - `<not set>` - normal behavior (equjvalent to setting the `MCO_DEBUG=on` command line option for debug libraries)

> Example:

>         PRJ_fhdbg_DEBUG:=YES

> `PRJ_<project-name>_F_USE_DYNAMIC_LIBRARIES`

> Force the project to be linked with the dynamic version of the eXtremeDB libraries.

> Possible values:

> - `YES` - set the dynamic libraries unconditionally
> - `<not set>` - normal behavior

> Example:

>         PRJ_fh_F_USE_DYNAMIC_LIBRARIES:=YES

> `PRJ_<project-name>_ADDITIONAL_LIBRARIES`

> Add special libraries to the linkage of the project. The script will add all necessary library directives for the compiler.

> Examples:

>         PRJ_mcoluaload_ADDITIONAL_LIBRARIES:=luajit

> `PRJ_<project-name>_SKIP_AUTO_BUILD`

> Exclude this project from the auto-build sequence. The project build procedure needs to be initiated by another project (specify the product of the project as a required file for another project).

> Possible values:

> - `YES` - exclude this project from the auto-build list
> - `<not set>` - normal behavior

> Examples:

>         PRJ_openssl_SKIP_AUTO_BUILD  :=YES

> `PRJ_<project-name>_BUILD_SFX`

> This defines a custom suffix for the products intermediate directory. Good for projects with custom build procedure.

> `PRJ_<project-name>_RESULT_NAME_BASE`

> Overrides the name of the product of the project. The build script will use this value instead of `<project-name>` during product file name generation. The script will add all necessary prefixes and suffixes according to the projects product nature.

> Example:

>         PRJ_mcocomplib_RESULT_NAME_BASE:=mcocomp

> ### Custom-build flags

> The following flags are good for custom-build projects only.

> `PRJ_<project-name>_PRODUCTS`

> The list of the products of the project.

> `PRJ_<project-name>_PRODUCT_DIRS`

> The list of directories where the products of the project will be created (if the location is not the default bin directory).

> `PRJ_<project-name>_BUILD_LOGS`

> The list of build logs for the project.

> `PRJ_<project-name>_INTERMEDIATE_DIRS`

> The list of directories where the intermediate files of the project will be created during the build procedure.

> `PRJ_<project-name>_MAKEFUNC`

> Defines the name of the custom build procedure that generates the build target for the project.

> ## Make system controls

> The following flags are defined to control the make system build process.

> `MCO_BUILD_ROOT`

> Defines the directory where the script will put all the build activities and intermediate files. It must be an absolute path to the directory. The default is the same directory as `MCO_ROOT`. Using this control it is possible to build eXtremeDB binaries out of the source tree.

> `MCO_PRODUCT_ROOT`

> Defines the directory where the build script will create products of the build process. It must be an absolute path to the directory. The default is `MCO_BUILD_ROOT`. Using this control it is possible to separate the final products from the intermediate files and the source code tree.

> `MCO_QUICK_BUILD`

> Values: on or yes. Disables the detailed dependency tracking mechanism but makes the build process faster overall. When the override is active, the script starts the cascade import not from the `MCO_ROOT` but from the current directory, so the build procedure will cover only the current and all downstream directories.

> `MCO_BUILD_LOG`

> Defines how to show the build process log. There are three settings: `on`, `off` and `full`. The default setting is `on` and it displays only brief progress information. The `off` setting makes the build script quiet (see the result code and the build logs for results). The `full` setting prints all of the output immediately and does not maintain build logs. For the `on` and `off` settings the build scrip puts all the commands and the output into the build log files located in the projects intermediate directories. Usually the build log is named the same as the project's product name with the "`.build-log`" extension. Also the build script produces separate build logs for object files naming them as `<object-file-name>.o.build-log`.

> Note that it is highly not recommended to use the `full` setting for a parallel build. The asynchronous nature of the process makes a mess in the output. It is very tricky to find the actual error message in this build log.

> `MCO_EXTRA_CHECKS`

> The `on` setting enables extra checks (equivalent to `-Wall` and `-pedantic` options) for gcc-based builds.

> `MCO_ENABLE_EVAL_BINARIES`

> The `yes` setting enables producing the evaluation version of eXtremeDB binaries in bin-directories with the "`.eval`" suffix.

> `MCO_DISABLE`

> This control switch allows the user to exclude groups of or specific projects / features out of the build process. The value of this control is a comma-separated or space-separated list of project tags that need to be disabled. Disabling a tag results not only in excluding the specified projects from the build process, but also disabling compilation defines indicating the presence of disabled features.

> Example:

>         MCO_DISABLE:=sequences
>         MCO_DISABLE:=java python lua
>         MCO_DISABLE:=net,fsystem

> `MCO_ENABLE`

> This control switch enables projects / features that are normally disabled.

> Example:

>         MCO_ENABLE :=wchar
>         MCO_ENABLE :=rtree

> ### Additional switches

> The following switch settings have the effect of setting other build system controls.

> `SHOW_BUILD_LOG=on`

> Uses `MCO_BUILD_LOG=full`.

> `x64=on|off`

> The build system detects the target databus width automatically (with the target compiler's help). It is necessary to specify `x64=off` to make the build script produce 32-bit code.

> `MCO_SKIP_PERFMON=yes`

> Skips the Performance Monitor (`perfmon`) build.

> `MCO_SKIP_SEQ_LIB=yes`

> Disables sequences support.

> `MCO_SKIP_LUA_UDF=yes`

> Disables UDF for Lua support.

> `MCO_SKIP_XSQL_BIN=yes`

> Skips the xSQL build.

> `JAVA=off`

> Skips Java-related code.

> `PYTHON=off`

> Skips Python-related code.

> `LUA=off`

> Skips Lua-related code.

> `FEEDHANDLER=off`

> Skip FeedHandler code.

> ## Make system overrides

> The following switches override the gcc/g++ compiler name for GCC-based toolchains. This makes it possible to use alternative compilers.

> `MCO_BUILD_GCC_OVERRIDE=<gcc-executable-name>`

> `MCO_BUILD_GXX_OVERRIDE=<g++-executable-name>`

> `MCO_HOST_GCC_OVERRIDE=<gcc-executable-name>`

> `MCO_HOST_GXX_OVERRIDE=<g++-executable-name>`

> `MCO_TARGET_GCC_OVERRIDE=<gcc-executable-name>`

> `MCO_TARGET_GXX_OVERRIDE=<g++-executable-name>`

> Example:

>         MCO_TARGET_GCC_OVERRIDE=gcc456
>         MCO_TARGET_GXX_OVERRIDE=g++456

> `MCO_FORCE_OPENSSL`

> Overrides auto-detection of the OpenSSL package.

> Possible values:

> - `MCO_FORCE_OPENSSL=auto` - (Default) Try to use an OpenSSL installation pointed to by the `MCO_OPENSSL_INCLUDE_PATH` environment variable if it is set; otherwise try to use the build system's OpenSSL headers if the build architecture is the same as the target and the build system has the necessary headers; finally, use the OpenSSL package from the source tree to build the OpenSSL installation for the target system and use it to build eXtremeDB
> - `MCO_FORCE_OPENSSL=envpath` - Unconditionally force the use of $(MCO_OPENSSL_INCLUDE_PATH) to look for OpenSSL headers for the target
> - `MCO_FORCE_OPENSSL=buildsys` - Unconditionally force the use of the build system's OpenSSL installation
> - `MCO_FORCE_OPENSSL=sourcetree` - Force building the target-specific OpenSSL package from the source code archive located in `target/sal/net`

> `MCO_FORCE_PYTHON`

> Overrides auto-detection of the Python package.

> Possible values:

> - `MCO_FORCE_PYTHON=auto` - (Default) try to use the Python installation pointed to by the `PYTHONBIN` environment variable if it is set; otherwise try to find the Python installation by the path. Next check if the Python version is sufficient, is runnable, that the architecture matches and it has the necessary header file. Otherwise, build Python from the package in the source tree.
> - `MCO_FORCE_PYTHON=envpath`- Unconditionally force the use of `$(PYTHONBIN)` to look for Python
> - `MCO_FORCE_PYTHON=buildsys` - Unconditionally force the use of the build system's Python installation
> - `MCO_FORCE_PYTHON=sourcetree` - Force building the Python package from the source code archive located in `target/python`

> `HOST_COMPILER_FAMILY`

> `TARGET_COMPILER_FAMILY`

> Overrides the auto-detected `host/target` compiler family. The auto-detection is based on the `host/target` platform OS.

> Example:

>         TARGET_COMPILER_FAMILY=gcc

> `HOST_ARCH`

> `TARGET_ARCH`

> Overrides the auto-detection of the `host/target` hardware architecture. The auto-detection is based on the host/target compilers information.

> Example:

>         TARGET_ARCH=aarch64

> `HOST_DBUS_WIDTH`

> `TARGET_DBUS_WIDTH`

> Overrides auto-detection of the `host/target` databus width. The auto-detection is based on the `host/target` compilers and architecture information.

> Possible values are `16`, `32` or `64`.

> Example:

>         TARGET_DBUS_WIDTH=32

> `HOST_FLAGS`

> `TARGET_FLAGS`

> Unconditionally adds arguments to the compiler/linker command line for HOST / TARGET code compilation. (Arguments are added exactly as they appear - no checks are applied.)

> Example:

>         TARGET_FLAGS="--sysroot=/opt/toolchains/arm-unknown-linux/"

> # Test Suite makefile.test compatibility notes

> The build system includes compatibility support for the Test Suite `run.py` script. Keep in mind that the `makefile.test` files are not good for parallel processing. Do not try to use `make -j` for them.

> There are two cases of possible usage of the build system from `run.py`:

> Method 1. Run `makefile.test` directly as a project makefile.

> Example of the makefile:

>         MCO_ROOT=$(abspath ../../..)
>         include $(MCO_ROOT)/include/settings.makefile
>         TEST_TAGS        = disk in-memory callback threads
>         TEST_COMMENT     = Allocation callback test. It checks callback
>             notification about exceded in-mamory or disk database space
>         TEST_TIMEOUT     = 300
>         MCO_ROOT        ?= ../../..
>         PRJ_TYPE         = APP
>         PRJ_SHOW_BUILD   = YES
>         PRJ_SIDE         = TARGET
>         PRJ_SOURCES      = main.c
>         PRJ_SCHEMAS      = schema.mco
>         PRJ_INTERFACES   =
>         PRJ_DBNAMES      = allocclbkdb
>         PRJ_STORAGE     ?= MEMORY
>         PRJ_MEMDEV      ?= CONV
>         PRJ_STORAGEDEV   = AUTO
>         PRJ_SYNC         = AUTO
>         PRJ_TRANSMGR    ?= MURSIW
>         PRJ_DIRECTPTR   ?= NO
>         PRJ_HA          ?= NONE
>         PRJ_RPC          = NONE
>         PRJ_F_CPP        = NO
>         PRJ_F_SQL        = NO
>         PRJ_F_LOG        = NO
>         PRJ_F_DBCALC     = NO
>         PRJ_F_UDA        = NO
>         PRJ_F_XML        = NO
>         PRJ_F_SERI       = NO
>         PRJ_F_HV         = NO
>         PRJ_F_CLUSTER    = NO
>         PRJ_RMFILES      =
>         PRJ_TITLE        = allocclbk_$(PRJ_SUFFIX)
>         THIS_MAKEFILE := $(lastword $(MAKEFILE_LIST))
>         # include $(MCO_ROOT)/include/header.mak
>         include $(MCO_ROOT)/include/rules.makefile

> The build system detects this kind of `makefile.test` files by the presence of `PTR_TYPE = APP` and `TEST_NAME`. For this kind of `makefile.test` the build system creates a virtual project makefile using `PRJ_TITLE` as the project name (`<project-name>` mentioned above) and sets all of the build properties as `PRJ_$(PRJ_TITLE)_XXXX` where `XXXX` is the property name. Project tags come from the `TEST_TAGS` variable. The eXtremeDB runtime is always enabled. The final executable name is set as the value of `PRJ_TITLE` because the value includes `PRJ_SUFFIX` already. `PRJ_DIRECTPTR` controls the inclusion into the `PRJ_TARGET_EXECUTABLE_`-list. All other build properties are set according to the rules of the old build system.

> Method 2. Run the normal build systems makefile from under `makefile.test` control.

> Example of the `makefile.test`:

>         TEST_NAME        = 08-benchmarks-perf-conv
>         TEST_TAGS        = samples fast perf
>         TEST_COMMENT     = 08-benchmarks perf sample
>         TEST_TIMEOUT     = 300
>         TEST_STORAGE     = MEMORY

>         MCO_ROOT        ?= ../../../../..

>         all:
>             $(MAKE) -C . $(MAKEFLAGS) $(MAKECMDGOALS) PRJ_TITLE=$(TEST_NAME)_$(PRJ_SUFFIX)

>         clean:
>             $(MAKE) -C . $(MAKEFLAGS) $(MAKECMDGOALS)

> The build system detects this kind of makefile.test by the presence of the `PRJ_TYPE` and `TEST_NAME` variables. As the `makefile.test` actually runs a typical makefile there is no need to create a virtual project. All the build properties come from the makefile and the script cares about the `PRJ_STORAGE`, `PRJ_MEMDEV`, `PRJ_TRANSMGR`, `PRJ_DIRECTPTR`, `PRJ_SUFFIX` and `TEST_TAGS` overrides only. `PRJ_DIRECTPTR` controls inclusion into the `PRJ_TARGET_EXECUTABLE_`-lists. Project tags comes from `TEST_TAGS`. The final executable name `PRJ_<project-name>_RESULT_NAME_BASE` is constructed from `<project-name>_$(PRJ_SUFFIX)`. The values of the `PRJ_STORAGE`, `PRJ_MEMDEV`, `PRJ_TRANSMGR` controls override normal values of the project build settings `PRJ_<project-name>_STORAGE`, `PRJ_<project-name>_F_MCOCOMP_FORCE`, `PRJ_<project-name>_STORAGEDEV`, `PRJ_<project-name>_MEMDEV`, `PRJ_<project-name>_TRANSMGS` and `PRJ_<project-name>_F_SEQUENCES` according to the rules described above (see section Common project flags above).