RADE

Why this kind of file?

Every module should be associated with a Imakefile.mk file before attempt to build with the CAA Workbench Code Builder mkmk.

The Imakefile.mk contains make-like macros which are used at compilation time and build time. So the Imakefile.mk syntax must comply to the global syntax of makefiles.

Like explained in mkmk paper, our environment proposes the same compiler for all operating systems where CNext can be run. This is a convenient way for developers to build their programs since they do not have to learn how to use different compilers and how to write (and keep up to date) makefiles. However all cannot be done by mkmk and users must explain at least what they want to generate.

Few samples

Here are the most basic samples of Imakefile.mk files you could have to write regarding the type of data to generate.

Location

How to build a shared library

The type of result is specified by a variable named BUILT_OBJECT_TYPE. The most basic Imakefile.mk contains just one line:

BUILT_OBJECT_TYPE=SHARED LIBRARY

Another type of library is the archive. It is less used than shared libraries but if you need to generate one, just replace the words "SHARED LIBRARY" by the word "ARCHIVE".

How to build an executable

A main program can be built by setting another value to the previous variable:

BUILT_OBJECT_TYPE=LOAD MODULE

Another thing that could be interesting to control is the name of the program: this is achieved using another variable, for instance:

PROGRAM_NAME=my_beautiful_program
BUILT_OBJECT_TYPE=LOAD MODULE

If no name is defined, default names will be chosen regarding the type of data to build.

How to Build a Java Module

To build a Java module, include:

PACKAGE_MODULE=my.package
BUILT_OBJECT_TYPE=JAVA

where my.package is the root of the packages that are to be included in the Java module.

Distinguish operating systems in Imakefile.mk

Even if the same Imakefile.mk file can be used on any (supported) operating systems, you may want to mark some differences regarding the current operating system. To do this, consult the declarative file preprocessor document.

How to use personal preprocessing variables

Preprocessing variables are often used in programs for different purposes:

• Debug: print messages to trace execution
• Variants of implementation: according to the current OS or for different levels of services

The Imakefile.mk syntax proposes a set of keyword (one per language) to add such variables, here is an example where we set a "DEBUG" variable for the compilation of C and C++ files and a "API3" variable for the compilation of C++ files (note the use of "$(...)" to reference the value of a variable):

LOCAL_CFLAGS=-DDEBUG
LOCAL_CCFLAGS=$(LOCAL_CFLAGS) -DAPI3
...

Syntax and variables

Syntax rules

1. A variable can be defined from a previously defined variable.

   VAR2=$(VAR1)

2. The makefile syntax does not allow to define a variable from itself. Definition such as the following ones are not allowed:

   VAR1=val1 val2
   VAR1=$(VAR1) val3

3. Lines beginning by the '#' character are comments or pragma.
4. Lines ending with a backslash '\' character continue on the next line.
5. space characters are ignored on both sides of a equal '=' character.
6. except if specified, the space character can be used as separator if a variable is set with several parameters

Variables interpreted by mkmk

Note: Variables following the flag "internal usage" are those used for special purpose and may not be used outside Dassault Systèmes.

mandatory

BUILT_OBJECT_TYPE= type of the module to build. Its value can be :

• LOAD MODULE to build a main program,
• SHARED LIBRARY to build a shared library or DLL,
• ARCHIVE to build an archive,
• EL LIBRARY for Explicitly Loaded, this kind of modules are explicitly loaded at run time. A shared library or DDL is built but it cannot be referenced by the other modules through the LINK_WITH macro
• JAVA to build a Java module.

mandatory for Java

PACKAGE_MODULE= root of the Java packages for the module to build, such as com.dev for a module containing the packages com.dev.view and com.dev.controller

internal usage

NONE is used to group small modules into a bigger module. The name of the small module must be included in an INCLUDED_MODULES macro in the big module. The container module can be a LOAD MODULE or a SHARED LIBRARY. The container and its contents must belong to the same framework.

optional

PROGRAM_NAME= name of the built module.

Default value is the module directory name with a prefix or a suffix depending of the module type (see BUILT_OBJECT_TYPE variable).

For example, if the module to build is in mymodule.m directory, the generated output name is:

BUILT_OBJECT_TYPE	Generated module name
LOAD MODULE	mymodule (UNIX) mymodule.exe (Windows)
SHARED LIBRARY	libmymodule.a (AIX) libmymodule.sl (HP-UX) libmymodule.so (SunOS) mymodule.dll (Windows) mymodule.lib (Windows)
ARCHIVE	libmymodule.a (UNIX) mymodule.lib (Windows)

The naming of modules concerns only load modules (BUILT_OBJECT_TYPE= LOAD MODULE) and is advised for transparency reasons.

mandatory

LINK_WITH = lib_1 lib_2 ... lib_n

list of modules (i.e. libraries) to be used at link-edition time of the current module. This option is mandatory. You must always at least include JS0GROUP in the list of load modules. The statement becomes:

LINK_WITH = JS0GROUP lib_2 ... lib_n

When link-editing a module, mkmk uses the subset of libraries which belong to the prerequisite frameworks of the embedding framework of the module. mkmk only makes available the subset of libraries in the prerequisites that LINK_WITH features. The library name to be used is either the one specified in the corresponding Imakefile.mk file or the default computed by mkmk (see PROGRAM_NAME keyword).

Do not forget to referenced the prerequisite frameworks in the identity card (IdentityCard.h file) of the framework to avoid an mkmk error (mkmk-WARNING: .....: Modules .... in LINK_WITH was found in component .... which is not directly referenced, ignored). For JS0GROUP, you must reference the System framework.

optional

INCLUDED_MODULES = mod_1 mod_2 ... mod_n

list of modules of the current framework whose objects must be included in this module. Note that the ".m" code module suffix is not written.

The type of the modules referenced in this macro must be NONE (BUILT_OBJECT_TYPE=NONE).

optional

COMDYN_MODULE=

module name which exports the CNext dynamic commons. Be careful the module name cannot be referenced in the LINK_WITH macro. This macro concerns only Fortran modules of course. If you need to share your own dynamic commons between sources, put the sources in the same module.

optional

IMPACT_ON_IMPORT= YES

to force the build of the modules which import this module.

This solves the incoherences at runtime due to the no rebuild of libraries. The problem does not exist with C++ programs because the dependencies between modules are indicated in header files. The impact is automatically computed and the rebuild is done. But with Fortran language this problem exists as shown in the following sample.

The m3 module in library3 has the m1 module from library1 as prerequisite. The s1 symbol moves from m1 (library1) to m2 (library2). So library3 must be rebuilt to be correct at the execution time.

This macro must be included always in Fortran modules and never in other modules for performance reasons. With C++ programs it is not necessary to force the rebuild.

optional

OPTIMIZATION_xxx=

xxx can be either C, CPP, or FORTRAN

This macro is used to define an optimization level for a language. The value is ignored if mkmk runs with -g or -dev option.

optional

CXX_EXCEPTION=

mkmk deactivates by default C++ native exceptions. If you need to use C++ native exceptions in your module, add this macro to reactivate them. Do not add any value after the equal sign. Pay attention not to nest V5 exceptions and C++ native exceptions.

optional

BUILD=NO

module won't be rebuilt by mkmk until this macro is removed.
Useful in OS-specific section.

optional

LOCAL_xxFLAGS=

additive compile-time options.

The following table lists the name of the macro corresponding to the language to compile.

Languages	Macro name
C++	LOCAL_CCFLAGS
C	LOCAL_CFLAGS
fortran	LOCAL_FFLAGS
assembler	LOCAL_ASFLAGS
express grammar	LOCAL_CKMFLAGS
yacc grammar (on UNIX only)	LOCAL_YFLAGS
lex grammar (on UNIX only)	LOCAL_LFLAGS

optional

LOCAL_LDFLAGS=

additive link-time options

optional

SYS_LIBPATH=

additive link-edit time system library directories (-L options)

optional

SYS_LIBS=

additive link-edit time system library directories (-l options)

[Top]

In Short

• Mkmk needs an Imakefile.mk file for every module.
• The minimum required is to specify what to built (cf macro BUILT_OBJECT_TYPE).
• You can expressed specific sections for all (supported) operating systems;
• You can add your own preprocessing variables as well as external libraries.

[Top

History

Copyright © 2000, Dassault Systèmes. All rights reserved.