theCompiler 10.0
NHI1 -
theKernel -
theLink -
theConfig -
theSq3Lite -
theCompiler -
theBrain -
theGuard
|
COMPILE A native-library into a managed-object.
Basically, the alc-compiler is a tool for the programmer who is faced with the question of extracting information from a definition file, e.g. a c-header-file, in order to start various actions from it.
The libconfig can be found at: http://hyperrealm.github.io/libconfig/Libconfig is a simple library for processing structured configuration files. This file format is more compact and more readable than XML. And unlike XML, it is type-aware, so it is not necessary to do string parsing in application code.
libconfig is a native-library which means that the library itself, as downloaded from the internet, does not contain any managed-object information and is therefore completely independent of the alc-compiler project.
First it needs a framework for the managed-object library.
The basic framework consists of the class-definitions and the library-definition. The class-definitions are generated from a database containing the definitions of all classes and ultimately sort to ensure that the class-hierarchy is enforced.
A class is a managed-object and is defined by one or more struct in C. The class definition is replaced by cls_MqC
added to the header file.
The class definition database ClassDB
is very simple :
# ==================================================================================== # Define "LcConfig" classes define class MkObjectS LcConfigS { desc "LcConfigC class handle" Short Cfg header LcConfigC } define class MkObjectS LcSettingS { desc "LcSettingC class handle" Short Cfs header LcSettingC }
There will be one file per class ( LcConfigC_lc.h and LcSettingC_lc.h ) and one file as library-definition ( LibLcConfig_lc.h ).
And create the following code (example: LcConfigS) :
Example from LcConfigC_def_lc.h
→ class hierarchy
Example from LcConfigC_def_lc.h
→ class definition
Example from LibLcConfig_lc.h
→ class type definition
Example from LcConfigC_def_lc.h
→ class introspection
The meta-code is the most important file from the alc-compiler as near all tools use this file to extract the api-definition.
The config_lc.h
file is the wrapper needed only for compiling with c_Meta
to add __parser__
directives that ultimately adapt the native definitions in libconfig.h
to the managed-object structure. In addition to the native API, the classes generated using c_Class
are also compiled.
The c_Meta
write the meta-code into the package-directory because this file will be added into the release-management (git). By default the filenames gen/c_lcconfig.meta
and gen/nat_lcconfig.meta
are created and follow the project name LibLcConfig.
The following image shows the meta-code of the native function config_lookup_int64
:
grep '\<LcConfigLookupInt64\>' NHI1_HOME/theConfig/c/gen/nat_lcconfig.meta
The problem is that a native-library lacks all the functionality required to function properly as a managed-object
The c_Native
perform the following tasks:
The following image shows the translation of the native function config_lookup_int64
into the manged-object function LcConfigLookupInt64.
An "overload" is a function that adds an additional function with the same or a similar name to an existing function to represent a "function" that does not exist in the original API.
"C" requires an "overload" for :
The default-argument is implemented in "C" using the overload-language-extension to "C" that appends the postfix _X
(X=0,1,2,3,...) to the original function name to identify the number of arguments in the "overload".
void MyFunc(type1 arg1, type2 arg2 __parser_(default=xyz))
void MyFunc(type1 arg1, type2 arg2)
#define MyFunc_1(...) MyFunc(__VA_ARGS__,xyz)
The following image shows the "overload" using the verbose -v
mode :
The following image shows the "overload" of the manged-object function LcConfigLog :
The c_MqS exists for every programming language, where the "c" is replaced by the respective language abbreviation (e.g. tcl_MqS.tcl) and is used to declare the api.
A declaration can be an object (e.g. enum) or a function.
The X_MqS really shows its importance with the NONE-"C" language connection, where, for example, the interpreter interface is defined using X_MqS or a translation layer for data types (C#).
Usually the X_MqS does not write any code but only code references or code declarations, the code itself is written in X_MqC.
The following image shows the "declaration" of the manged-object callback for enum LcConfigFormatE :
The c_MqC exists for every programming language, whereby the "c"
is replaced by the respective language abbreviation (e.g. tcl_MqC.tcl
).
The c_MqC is used to write the wrapper source code.
The wrapper-source-code ultimately has the task of integrating the managed-object-api-function into the target-language so that the namespace of the managed-object is valid for input and the namespace for the target-language is valid for output.
The integration includes the data type or the type-cast as well as the error handling.
Usually the X_MqC write wrapper-source-code :
The following image shows the C-wrapper-source-code of the manged-object LcConfigLookupInt64 :
C#
api functionThe example in the alc-compiler C# backend shows the debugging of the MkBufferAppendSTR function.
This function is from the library LibMkKernel_mk.h or mk
for short and is a method of the class MkBufferC .