Acrobatomatic Build System - generic make files and companion scripts

Make is a tool developed in 1977. It was design to help software developers build binaries from multiple source files in a more efficient way that using a static script to chain all the require compiler call. One major improvement of make is to be able to perform only the necessary operations to build the target files according the current intermediate files that may already be available. In its day to day job, the software developer only edit a few files and need to check its change by building the new software and it is useless to compile again unchanged source files. To enable such capability, make propose to defines rules instead of static action sequences. A rule is defined by three properties:

• the target file: this is the goal of the rule, the file that is expected to be done when applying the rule.
• the prerequisite: the list of files that are needed to build the target file.
• the transformation command: a shell command that generates the target file from the prerequisite files.

The rules inserted in a text file constitute a makefile, that is, a file to use as input script for the make command. When such file is named Makefile in the current directory, it is used as the default input by the make command.

Example: a make rule to generate concat.txt file by concatenating to text files a.txt and b.txt

                                    concat.txt: a.txt b.txt
	cat a.txt b.txt > concat.txt

                                

                                    CC=gcc

cmd: a.o b.o
	$(CC) -o cmd a.o b.o

.c.o:
	$(CC) -c $*.c
                                

                                    $ make
gcc -c a.c
gcc -c b.c
gcc -o cmd a.o b.o
                                

                                    $ make
gcc -c b.c
gcc -o cmd a.o b.o
                                

                                    TARGET=cmd
CC=gcc
SRCFILES:=$(wildcard src/*)
OBJFILES:=$(patsubst src/%.c,obj/%.o,$(SRCFILES))

$(TARGET): $(OBJFILES)
	$(CC) -o $@ $(OBJFILES)

obj/%.o: src/%.c
	$(CC) -o $@ -c $^
                                

                                    # include application specific parameters
include app.cfg
# include the main ABS makefile
include .abs/core/main.mk

# This rule enable to download, from a remote repository, the core ABS package providing 
# the .abs/core/main.mk makefile among others
.abs/%/main.mk:
	mkdir -p .abs
	wget $(patsubst .abs/%/main.mk,$(ABS_REPO)/abs-%.tar.gz,$@) -O - | tar xvzf - -C .abs --strip-components=1

                                

To let a generic build system works, some common conventions are still needed. The project shall have two level of directory:

• the application level, that is in fact the root level.
• the modules level, an application could be made of several module and each module is hosted in a specific subdirectory of the root directory. Of course a simple and small application may be composed of one single module.

At each level, that is into the root directory and into each module directory, the ABS feature are brought by:

• the abs bootstrap makefile named as Makefile to be selected as the default makefile when running the make command.
• a configuration file, named app.mk at application level and module.mk at module level.

The only directories where ABS shall create files are (with <prjroot> being your project's root directory):

• $HOME/.abs : to store the local copy of ABS itself.
• <prjroot>/build : all files generated by the build process.
• <prjroot>/dist : stores the distribution package archives.

Those three directories, since containing only outputs of the generation process should never be set under revision control.

Besides the output directories, the app.cfg and Makefile files, the project's root directory shall only contains directories: one for each module.

The GNU make include feature shall be used to:

• avoid any make code, rules and macro definition duplication, by using a common file to be included to store common definition.
• enable project and modules configuration adaptation, by defining specific rules and macros into dedicated file that are included only when needed.

The bootstrap makefile includes a single main core makefile that will itself include the current application, and module configuration, and then include the needed sub-makefile regarding the application and module's parameters.

ABS itself is split in several module. Each module is a set of makefile and companion scripts handling a specific set of tasks. The ABS modules are:

• core: ABS core features
• application, module configuration parameters handling
• programming language support: C/C++, java, python.
• unit tests management.
• operating system identification.
• doc: document processing features
• mstrans: matlab/simulink to SMP2 wrapping features
• jenkins: jenkins integration helper scripts.

Inside the ABS core module, the technical service and utility features are implemented into the following files:

• main.mk: detects whether the current directory is the application root or a module directory to include the appropriate file.
• app.mk: application level service.
• builds all modules
• run tests of all modules
• build distribution packages
• creation of new modules
• complete build, test, packaging and package publication triggered by the single target cint [ abs.cm.4 ].
• module.mk: module level service. Reads the module parameters to include the required specialized makefile according the module type and the specific needed features and extensions requested by the module configuration.
• module-absext.mk: defines mapping between module types and makefile to include name patterns
• module-extlib.mk: external library management.
• module-util.mk: provide additionnal features (create source files from template, run lua shell, display ABS variables values).

All module type specialized makefile shall provide target that are consistent with the main targets:

• all: default target that builds everything (unique to module.mk to avoid bugs on this target)
• all-impl: implementation of the all target that builds everything. The target all depends of this target.
• clean: remove all output files
• check, test, debugcheck, debugtest: run unit tests without or with debugger.
• run: launch the built software.

When any of the above target is not meaningful for the module or extension (for instance run is not relevant for a documentation module), the specific ABS scripts shall be tolerant to the use of the target anyway. That means using such target shall not fail in this case but only report nothing has to be done. Thus all modules, whatever the type, can be handled the same way at the highest level and the automation of module target calling sequence just by simple recursions is feasible.

Figure 1 - ABS interfaces and module types hierarchy

The above diagrams enumerates the minimal configuration parameters expected at application and module levels. The variable index in section 4.6 , provides the name and description of all variables including internal variables to be used by the module type specific makefiles.

C/C++ module support is brought by the core ABS module. A C/C++ module shall have only one "real" target: one library (shared object file) or one binary (standard executable file). The C/C++ features and related makefiles are included with the ABS core distribution, more specifically, the C/C++ features are provided by the following makefiles:

• modules-cheaders.mk: rules to publish headers. Related to the PUB_H module configuration parameters, introduced only to ease the integration of existing software as an ABS managed project.
• module-crules-var.mk: defines common variable for C/C++ handling.
• module.crules.mk: defines rules to go from source code to final binary.
• module-exe.mk: defines executable target for exe module type.
• module-library.mk: defines shared object target for library module type.
• module-test.mk: provides Unit test features based on cppunit.

For C/C++ the build process and related rules overview is the following:

• The list of object files is derived from the list of source files (files from module src directory having .c or .cpp extension).
• an object file is done from the corresponding C source file by running the C compiler.
• alternatively an object file is done from the corresponding C++ source file by running the C++ compiler
• the final target is made from all object file by running the linker command.

Some advanced rules are included to define dynamically dependencies to header files directly from source and ensure all needed source files are processed again when any header file is changed.

Additionally, there are some rule to generate intermediate source files, that will be themselves derived as object file and complete the list of objects to link in the final target:

• vinfo.c or vinfo.cpp: defines a static string containing meta data about the application and module, such as name, version, or build option. This string is used by the mastol logger to print a signature of each library when the software is started. It enables also to use the unix ident command to extract the information directly from the built binary file.
• resource C file: such file is done for each resource file found in the module's src/res directory. It defines a static buffer and set its value to the content of the corresponding resource file in src/res. This enable to define long static string from flat files, or any kind of resource (image, or any other) to be embed in the target library.

Java is handled slightly the same way than native compilation. Where native compilation is a two step process, building object file from source file, then linking all together in an executable or a library, the Java build is also a two step process: for each java source file, a .class file is build, then all .class files are compressed in a .jar file.

Python being a programming platform relying first on an interpretor, the python build process is more a file packaging process. The python files are copied into the build directory tree trying to comply to what's python expects when loading libraries.

Unit test management is defined in language dedicated makefiles of the core ABS package:

• module-test.mk: C/C++ unit test handling using cppunit.
• module-junit.mk: java unit test handling using JUnit.
• module-testpython.mk: python unit test handling

Each language use its own test runner and unit test library but all should be compliant to the xUnit general principles (see R2 ). From the ABS perspective, all test procedure are, first eventually complied (C/C++/java), then run sequentially. Of course, the test target has a dependency over the main module target to ensure the software to be checked is built before running tests. The test run progression is printed on the standard output and in a file for further post-analysis. On test run completion a report file is generated using the JUnit report XML format to enable processing of results with third party tools in general and within jenkins in particular. A summary is also printed on the standard output by XSLT processing of the XML report (see xunit2txt.xml in ABS core package).

The fileset module type is the ultimate generic module, but it finally performs almost no processing, it just copy files as-is from module's src directory to the application target directory. The only specific processing is to grant execution to files comming from module's src/bin if any. Since those files destination is the application's bin directory, we choose to apply the unix general rule to store there executable files only.

Document processing feature is brought when using the doc module type. It is implemented by a the dedicated ABS-doc package. Its main components are:

• main.mk: document file processing rules
• html directory: resource for generated html documents.
• style.xhtml.xls: heml transformation to html format
• tex directory: latex templates and macros
• style.tex.xsl: heml transformation to tex format.

This package uses external components :

• heml processor: enables converting the document input format using XSLT style sheets. It is used by ABS-doc to generate both tex and html files from a single source heml document.
• plantuml: generates graphic UML diagrams from textual object specifications.
• dia: inline export of dia diagrams to document embeddable png files.
• doxygen: reference documentation generation from the commented source code.

ABS enable cross copmilation where cross-compilers are available. The XARCH varaible is used to someway force the architecture identifier to the target architecture. It also includes also some standard cross compilation configration. Those configuration set specific value to many variable such as CC, CPPC, etc. Those variables define the command to use for many compilation tasks and of course needs specific value to use alternate compilers and linkers, that are in this case the cross compilers and linkers.

ABS is extensible. A pattern matching rule is defined in module.mk to let ABS itself to download additional package (mostly set of makefiles) for some specific module types (defined in the module configuration file module.cfg using MODTYPE package). The MODULE_TYPE_MAP defines the assignment of module type over ABS packages. Its initial value is defines in core/module.mk and can be extended.

A project using ABS can itself provide its own ABS extension. ABS extension management is handled by core/module-absext.mk that provide many helpers rules to manage the integration of the extension in the distributable package of the application through its embedded import.mk.

Master makefiles ( app.mk and module.mk include a generic help target to display some short user documentation. It is just a grep command to display all lines starting with "## " (two sharp, one space) of all included makefiles. To let this system display readable help messages, try to apply the following rules while developing and maintaining all ABS' makefiles:

• Start with a header giving a clear section break and short description of the scope of the makefile.
• introduce overloadable variables definition section
• in-line variable comment tells the role and the default value of the variable
• introduce the targets section
• in-line target comment tells the role of the target. Remember to mention variables expected on make invocation command line that are specifically used by the target.
• limit line length to 80 characters max to keep readable even on text console.

Those rules are summarized by the following template:

                                    ## --------------------------------------------------------------------
## Documented makefile template 
## Short introduction of the services provided by this makefile
## --------------------------------------------------------------------
## 
## Overloadable variables :
## 
##  - VAR1: variable 1 description, default value is value1
VAR1=value1
##  - VAR2: variable 2 description, default value is value2
VAR2=value2
## 
## Targets:
##   - tgt1 A=arg: target 1 description, A argument is ...
tgt1: 
	echo "A=$(A)"
##   - tgt2 [B=arg]: target 2 description, B optionnal argument is ...
tgt2:
	echo "B=[$(B)]"
                                

                                    INCTESTS:=$(findstring test,$(MAKECMDGOALS))$(findstring check,$(MAKECMDGOALS))$(findstring help,$(MAKECMDGOALS))
ifneq ($(INCTESTS),)
 ifneq ($(findstring library,$(MODTYPE))$(findstring exe,$(MODTYPE)),)
  $(info including module-test)
  include $(PRJROOT)/make/module-test.mk
 else ifeq ($(MODTYPE),jar)
  include $(PRJROOT)/make/module-junit.mk
 else ifeq ($(MODTYPE),python)
  include $(PRJROOT)/make/module-testpython.mk
 endif
endif
                                

Buildscripts expects one specific files and directories layout to be able to apply its generic rules and perform all needed actions to achieve to build according the current project state. The standard layout is:

• <project name>-X.Y/ : root directory for the project's X.Y branch workspace.
• _doc/ : documentation module
• <1st module name>/ : 1st module directory.
• <2nd module name>/ : 2nd module directory.
• ...
• <Nth module name>/ : Nth module directory.
• app.cfg : project configuration file
• Makefile : project's root makefile, copy of the ABS bootstrap makefile .
• build/ : root directory for all generated artifacts during the build process. Shall not be inserted into the version control system.
• local.cfg : optional workspace local configuration file. Shall not be inserted into the version control system.

This file hosts the application wide parameters. The mandatory definitions are:

• APPNAME=<application name> : name of the application. Caution: since this name is used to define some output files names, it shall not contain any space, the '-' character or any special characters that may not be supported in a file name.
• VERSION=X.Y.Z : version identifier. Must be initialized manually on project creation consistently with branch name set in the version control system. Then it is automatically maintained when branches are created from existing branch and when a branch is tagged.
• ABS_REPO:=<URL> : URL of the abs distribution repository.
• VABS:=X.Y : version of ABS to be used to build the application.

The optionals definitions are:

• COMPANY=<company name> : the name of the company or organization that owns the project.
• COPYRIGHT=<copyright declaration> : Copyright information. The standard format is the following: (c) <create date>[-<update date>] <copyright older name>
• EXPMOD=<mod name>* : list of modules to be exported. Any module that is a library to be used by another application should be exported.
• DOMAIN=<reversed domain name> : Java package name prefix.
• USELIB=<<libname>-X.Y.Z>* : list of external libraries directly used by the project.
• extra_import_defs=<any makefile content> : additional rules and macro definitions to be inserted into the import.mk file packaged with the product. This import.mk file is included in any user application that, through its own cnofiguration and USELIB value, makes reference to the product.

The internal file layout in modules is:

• <module name>
• include/<project name>/<module name> : public C/C++ header files
• src/ : implementation source files.
• test/ : unit tests source code.
• module.cfg : module's configuration file.
• Makefile : module's local makefile, copy of the ABS bootstrap makefile .

This file stores all the module specific configuration. The mandatory expected definition are:

• MODNAME=<module name> : the module's name. String without any special character is preferred, since this name will compose file names.
• MODTYPE=<module type> : the module's type. Use any of the following value
• exe : "native" (C/C++) executable.
• library : "native" (C/C++) library.
• jar : java package
• python : python package
• linuxmodule : linux kernel module
• doc : document set.

Additional definitions may be used:

• USEMOD=<module name>* : list of modules from the same project that are used by the current module.
• LINKLIB=<lib name>* : list of libraries to link with. Use short library name, that is, if abc is given, the expected shared object file name is libabc.so for Unix/Posix systems, or abc.dll for Windows systems.
• USEJAR=<pacakge name>* : list of java package needed by the current module (when module is itself a java package). Use only package/version name, that is if abc-1.2.10 is set, the file named abc-1.2.10.jar is included in the CLASSPATH .
• CFLAGS+=<CC argument>* : additional C/C++ compiler flags.
• LDFLAGS+=<LD argument>* : additional linker flags.
• MAINCLASS=<class name> : name of the class to be used as the main entry point class in a java package. This class must have a public static method named main and expecting one string array as parameter.

Buildscripts can handle the compilation of linux kernel modules. To integrate an existing linux kernel module source code in an ABS managed project, apply following steps:

• create a new buidlscript module in the project using _lkm as name suffix:

                                          make newmode M=<driver name>_lkm
                                      

• Edit module.cfg file to define it is a linux kernel module:

                                          MODTYPE=linuxmodule
                                      

• Copy all source files (including root directory containing original makefile) int src dir.
• When some imported source file should not be compiled (sometimes, obsolete files are remaining in public source code distributions of kernel modules), filter out those files by defining the DISABLE_SRC variable (do not include src/ in listed file names).

                                          DISABLE_SRC=file1.c file2.c ... fileN.c
                                      

• The header files to be included from user space applications or from other kernel modules will be published in include/<app>/<module> directory only when explicitely listed in module.cfg using the variable PUB_H . Specify file path from the src directory (do not include src/ itself.

                                          PUB_H=header1.h header2.h ... headerN.h
                                      

Buildscripts is just a set of makefiles, scripts and style sheets. There is no binary to install, the only task is to include in the root directory, the ABS bootstrap makefile as Makefile , and define the project's configuration file.

All packaged ABS version are available from the ABS distributions repository . Some mirror may have been created in other location that can't reach this public primary repository, check people that have provided you this document that may know about such mirror. This document first public issue as written while integration ABS version 3.0.

From the project root (where the make directory of ABS has been integrated):

• create app.cfg file and define at least the APPNAME , VERSION , VABS  and ABS_REPO variables.
• extract the file core/bootstrap.mk from the ABS core distribution archive (or fetch the reference version such as abs-3.0-bootstrap.mk ) into the project root directory and rename it Makefile .
• when some modules are already existing, for each one go to its directory, then:
• create module.cfg file en define at least the MODNAME and MODTYPE variables.
• copy the bootstrap makefile already integrated to the root directory as the module's Makefile file.

After that you are ready to build your project with ABS by calling make , and even create new modules by calling make newmod M=<module name> . Next sections details all services available through make targets and variables that can be used to configure your project and enclosed modules.

The project level main targets are:

• make all : default target, builds all modules, without unit tests.
• make testbuild : builds all modules including unit tests but without running the tests.
• make clean : deletes all built artifacts (deletes the build and dist directories.
• make newmod M=<module name> : creates a new module. Create the directory structure, module.cfg and Makefile files with default minimal configuration (default module type is library ).
• make branch : creates new branch from the current one. New branch identifier (X.Y) and comment including issue reference will be interactively requested during processing. Write access to the subversion repository is needed to proceed.
• make dist : builds distribuable binary "short" package. Such packaging is design to support publication to a build repository. The packages available on the build repository can be fetched by any project (see USELIB variable usage).
• make help : in-line help system. Show usage information about application level services.
• make doc : generate documentation from code. Doxygen is needed to process the source code and shall be available on your workstation to use this feature.
• make install [PREFIX=<install root>] : builds and installs the application. The default installation root is /opt/<app name>-<version> . All needed dependencies are also installed, so avoid using /usr or /usr/local as installation root to avoid any risk to overwrite some system libraries.
• make distinstall : generates an installation archive including the complete built application and its dependencies. The generated file is executable and handles, when later run, the installation process.
• when project contains in its root directory a file named extradist.sh , this script is run during the processing of the dist target. It receive the target build path (default is dist/<app>-<version> as first argument. You can put in this script any commands that copy/create/update files into the dist directory that will then be included in the built final archive file.
• using the extra dist feature, one can insert in the dist/<app>-<version>/bin directory a file named postinstall.sh . The in installation archive embedded script, at the end of the install process, looks at this file availability and if present run it with two arguments, the application name, and the application version. Caution: take care to set this postinstall.sh file the executable attribute in order to be invoked by the installation script.

Some utility and additional targets may be added according to ABS improvements. See in-line help for more complete reference.

The module level main targets are:

• make all : default target, builds the module. The build of other modules may be automatically triggered regarding the prerequisites definition (see USEMOD variable).
• make run [RUNARGS="[<arg>]*"] : builds and run the module. Applicable to executable modules or libraries found to include a lua_open function. In this second particular case, ABS attempts to launch the module from a lua shell and requires some feature from mastol. This target also ensure library search paths are consistent with dependencies definitions.
• make testbuild : builds the module and its unit tests but doesn't run the tests.
• make check [RUNARGS="+|-f <test name pattern>"] : builds the module and its unit tests, then run the tests.

  Test naming

  Cppunit that is used as the unit test engine for C/C++ modules, can use the symbol names as test identifier. To capture the symbol name, run once make check and see the right names to use to identify test on the test execution report.

                                                      $ make check
  [...]
  # ------------------------------------
  # Successful tests
  # ------------------------------------
  - N4test11TestExampleE::testCaseSuccess 1.4995e-05 s (0.014995 ms).
  [...]
  $ make check RUNARGS="+f N4test11TestExampleE"
  [...] only test from TestExample test class are done.
  $ make check RUNARGS="-f testCaseSuccess"
  [...] all test are done except methods named testCaseSuccess (whatever is the enclosing test class)
                                                  

• make debug : same as make run but inside a gdb session. Once gdb shell is ready, invoke runapp to start running the module in the debugger.
• make debugcheck : same as make check but inside a gdb session. Once gdb shell is ready, invoke runtests to start running the tests in the debugger.
• make test : see make check
• make debugtest : see make debugcheck
• make edebug : displays parameters required for debugging from Eclipse (applicable to executable modules only).
• make edebugtest : displays parameters required for debugging unit tests from Eclipse .
• make newclass C=<class name> : generate new empty class files (both implementation and headers for C++) complient to ABS rules.
• make newtest T=<name of class to test> : create source code file for a unit testing class.
• make help : in-line help system. Show usage information about per module available services.

the main build targets will use the following option (given as make command arguments) to specialize the build process:

• MODE=<debug|release> : compilation mode, with debug symbol and tracing activated or without debug symbol, tracing deactivated and some optimization flags. The default mode is debug .
• DEFINES="<symbol1> <symbol2> ..." : C/C++ preprocessor symbol definition. Implementation can provide alternate or special optional features and this argument enable the user to activate such. Any symbols provided in the list should match at least one #ifdef directive in C/C++ source code.

Official distributable packages should be built and published by the continuous integration system that includes many automated checks. However manual build of such package is possible through make targets (and the automated system use the same targets). The operations to be performed for the two step build and publish process are:

• use command make dist or make distinstall regarding the product is only a library or includes applications.
• copy the generated archive in dist to your web server hosting your binaries repository:

                                              scp dist/<product>-<version>.<arch>.tar.gz <login>@<webserver>:<DocumentRoot>/dist/<arch>
                                          

  Build and publish for every architecture

  This process shall be repeated for every supported architecture, that is, build the package on every compilation host required to cover all the needed processor classes and Operating Systems.

  To meet traceability requirements, only fresh checkout of tagged version of a product should be build and published to the repository. The continuous integration state is available through its web interface .

  Binaries identification.

  Buildscripts includes in the C/C++ binaries an identification string. The ident command can parse the binary to retrieve that string and restore the build and configuration context.

                                                      $ ident mastol_luad
  mastol_luad:
       $Attr: app.name=mastol $
       $Attr: app.version=1.1.10 $
       $Attr: app.revision=5817. $
       $Attr: app.file=mastol_luad $
       $Attr: company=Airbus Defence and Space $
       $Attr: copyright=(c) 2013-2017 Airbus Safran Launchers $
       $Attr: build.mode=release $
       $Attr: build.opts= $
       $Attr: build.date=mer. mai 10 10:10:21 CEST 2017 $
       $Attr: build.host=apollo $
       $Attr: build.user=m026258 $
       $Attr: build.id=null $
                                                  

  Some criteria to know the binary was produced through the validated process by continuous integration system are:

  • version has no d suffix.
  • revision has no M suffix.
  • build mode is release
  • build identifier is not null.

  Only tagged software should deployed onto integration, validation or production target hosts.

Aside the application configuration file app.cfg , some workspace local parameter definitions can be stored in a file named local.cfg . This file is dedicated to the handling or workaround of local workspace issues, such as using alternate binary repository. Please never add this file into the revision control system since it can overload the correct shared project configuration with values not applicable to every reference compilation hosts. Here are some examples of use:

                                        LIB_REPO:=/the/local/path,$(LIB_REPO)
                                    

                                        ARCH=RedHatEnterpriseWorkstation_6.3_x86_64
                                    

Let's have two applications:

• avionic inluding the mandatory module bus and the optional modules alpha and beta . Other dependencies are:
• All modules need the external library space-0.2.5
• beta needs alpha
• and beta also uses another external library star-1.0.0
• spaceship is an application using version 1.1.0 of avionic and has itself two modules:
• payload using only bus from avionic
• booster using optional module beta from avionic .

To link an application to external libraries, define the USELIB macro int the application configuration file app.cfg

                                    APPNAME=avionic
VERSION=1.1.0
USELIB=space-0.2.5 star-1.0.0
                                

                                    APPNAME=spaceship
VERSION=1.1.0
USELIB=avionic-1.0.0
                                

The module of an application to be reused by some other applications (typically the libraries) shall be explicitly declared to ensure the header files and other needed meta information are included in the published final package. Use the EXPMOD macro to list all the modules to be exported.

                                    APPNAME=avionic
VERSION=1.1.0
USELIB=space-0.2.5 star-1.0.0
EXPMOD=bus alpha beta
                                

Locally at the module level, all dependencies shall be defined: USEMOD lists the other modules of the same application that are used by the current module. LINKLIB lists the few external shared objects brought by external dependencies that the current module directly use.

For the three avionic 's modules:

                                    MODNAME=bus
MODTYPE=library
LINKLIB=space
                                

                                    MODNAME=alpha
MODTYPE=library
LINKLIB=space
                                

                                    MODNAME=beta
MODTYPE=library
USEMOD=alpha
LINKLIB=space star
                                

                                    MODNAME=payload
MODTYPE=library
LINKLIB=avionic_bus
                                

                                    MODNAME=booster
MODTYPE=library
LINKLIB=avionic_beta
                                

However, despite any effort to follow the rules presented above, dependencie management can become far complex. Since a project defines only its direct dependencies, it can't ensure any used external library will not itself use a library also linked directly to the project but with a different version. To support the user and at least identify the library mix issues, some checks are performed on the full USELIB defintion recursively computed from include to include. A warning is displayed during the build when different versions of a same lib is found. Invoking make checkdep displays a complete depedency graph.

Figure 2 - Real world example of a dependency graph with a version conflict

ABS Doc module permit the use of additional templates to generate documentation files. This is done using an absext module (see section 2.2.13 ).

                                    extra_import_defs=include $$(_absext_index_<project name>_<module name>)/main.mk
                                

                                    APPNAME=prjexample			
extra_import_defs=\
include $$(_absext_index_prjexample_extmodexample)/main.mk # this permit to load the main.mk at the load of external libraries.
                                

                                    MODNAME=extmodexample
MODTYPE=absext
                                

                                    <?xml version="1.0" encoding="iso-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:import href="style.tex.xsl"/> <!-- import the default style (in abs doc module) -->
</xsl:stylesheet>
                                

                                    TEXINPUTS+=$(_absext_index_prjexample_extmodexample)//
HEMLTOTEX_MAP+=<template name>:$(_absext_index_prjexample_extmodexample)/styleExt.tex.xsl
HEMLTOXHTML_MAP+=<template name>:$(_absext_index_prjexample_extmodexample)/styleExt.xhtml.xsl
HEMLTOXML_MAP+=<template name>:$(_absext_index_prjexample_extmodexample)/styleExt.xml.xsl