Detailed explanation of mke file

The old version of MicroStation supports cross-platform development, so its development architecture does not follow the Microsoft system but uses a Unix/Linux like development system, which uses production files rather than registry entries to control the entire project generation process. If you have developed with GCC under Unix or Linux, I believe that this system will have a familiar feel. The following figure is a complete process of generating ma and dll.

The shaded blocks are the source code (with header files, resource files, type files, and C ++ files), which we need to write by hand; rectangular blocks are some executables, including resource compilers, type generators, and MDL library wrappers, C ++ source file compiler, target object linker, etc. Other blocks are generated intermediate files or final files.

The resources in the MDL program are divided into command table resources, dialog resource, message resource, type resource, etc. They are all finally generated into the file ma (ma is the abbreviation of MicroStation Application). These are unique to Bentley, and these resource files must be written in accordance with the prescribed syntax. The process of generating C ++ source files to dynamic link libraries in MDL is the same as the compilation and linking process of ordinary C ++ files which is to invoke the compiler cl.exe under Microsoft VS to generate the obj file and then link the obj file (maybe multiple) into a dll file by invoking the linker link.exe. The almost independent processes of these two parts are controlled by a single mke file.

Below we use the mke file from the previous chapter as a basis to explain in detail the syntax of this production file.

• Comments: Lines that begin with # are comment lines. These lines are ignored by the bmake command while processing the mke file. 
• Macro definition: Such as appName = HelloWorld. appName is called the macro name and HelloWorld is called the value of the macro. 
• Macro expansion: Expressed as $(macro name). If $(appName)$(oext) is expanded to cpp.
• Dependency: For example, $(o)$(appName) .rsc: $(baseDir) $(appName) .r, the former depends on the latter. When the latter is modified, the former needs to be regenerated. Otherwise, such lines are ignored. The purpose of this is to speed up the generation of the entire project and only generate the target file for the modified content.
• Rules: such as

$(mdlapps) $(appName).ma: $(appRscs) 
    $(msg) 
    >$(o) make.opt 
    -o $ @ 
    $ (appRscs) 
    < 
$ (RLibCmd) @ $ (o) make.opt 
    ~ time 

When $(appName).ma is generated from $(appRscs), there are no default rules in all mki (header files for making files). Here are the explicit rules. The final call is the command $(RLibCmd) to package multiple rsc files into a single ma file. $ (RLibCmd) is actually rlib.exe under the bin folder in the SDK. 

• Statements: such as %include or %ifdef, etc. that begin with %. Either perform an include action or perform some conditional branch functions. The detailed mke file syntax can be found in creating a Makefile and Using the bmake Utility section of the SDK help document MicroStationApi.chm. For a deeper understanding of mke files, you also need to read the system's mki files, which define many of the system's built-in macro definitions and rules. 

Next, we summarize a few points you need to care about in practice. As long as you grasp these points, you can basically create new mke files and modify mke files in the future.

• appName defines the project name. When you want to create a new project, you need to copy a folder, modify the file names, and modify the value of the appName macro in the mke file to the name of your new project.
• Each additional .cpp file needs to modify the definition of appObjs and add a line to generate obj. Note that the backslash symbol at the end of a line is a line continuation character. There must be no spaces after the line continuation character.

$ (o)XXX $(oext) : $ (baseDir)XXX.cpp $ (baseDir)XXX.h

• If a function in another library is called, the library file name containing the function needs to be added to the LINKER_LIBRARIES macro definition.
• If you reference header files from another directory, you need to set dirToSearch to point to the folder where the new header files are located, and then include mki.
• Depending on the project, it may contain command list resource files, dialog resource files, and so on. Each resource file needs to be defined in the appRscs macro, similar to a cpp file. Each time you add a resource source file .r will add a line from. r generates the definition of .rsc. The command-line processing line has been defined in mke, you only need to cancel the comment symbol # at the beginning of the line.

Learn More about the Bmake Utility here : Creating a Makefile and Using the bmake Utility