1 \input texinfo @c -*-texinfo-*-
4 @settitle Ocera Make System
8 Manual for Ocera Make System (OMK)
10 Copyright @copyright{} 2007 Michal Sojka, Pavel Pisa
14 @title Ocera Make System Manual
16 @vskip 0pt plus 1filll
23 @node Top, Overview of OMK, (dir), (dir)
24 @top Ocera Make System
38 @node Overview of OMK, OMK User's Manual, Top, Top
42 OMK is an advanced make system written entirely in GNU make. Compiling
43 software using OMK requires only GNU make binary and standard UNIX
44 utilities (@command{sh}, @command{sed}, @command{cmp} and
45 @command{tr}@footnote{@command{tr} is needed only for OMK to be
46 compatible with MinGW.}) installed. OMK aims to be developer friendly;
47 to use OMK, you do not need to understand (sometimes) cryptic syntax of
50 You can use OMK on all platforms where you can run GNU Make including
51 Cygwin and MinGW. MS DOS was not tested.
57 @c Easy to use for beginners.
59 @c Automatic handling of dependencies.
61 @c Supported host platforms: all Un*x operating system including Linux,
62 @c Cygwin, MS DOS and maybe others.
71 @node Why to Use OMK?, Quick Start, Overview of OMK, Overview of OMK
72 @section Why to Use OMK?
74 Here we list some of OMK features, which we think are important for
75 choosing of a make system.
80 Makefile in source directories are usually very @b{simple}.
82 There is only @b{one} @file{Makefile.rules} for most of components of
85 OMK greatly simplifies compilation of projects, where source files are
86 spread between @b{multiple directories}.
88 OMK handles properly @b{dependencies} of source files and libraries,
89 so it is not necessary to recompile the whole project if only several
92 OMK allows to freely @b{move} cross-dependant components @b{in
93 directory structure} without the need to update users of moved
94 component. I hate something like
95 @option{-I../../sched/rtlshwq/include} in makefiles for example. If a
96 component is renamed or version is added to the name, all Makefiles
97 in will require an update.
99 The above feature is very helpful in @b{combining components}
100 (libraries) from different projects/developers to a single project by
101 simply creating symbolic links to external components.
103 Compilation of an OMK based projects don't require to install any
104 files before successful finish of build.
106 OMK allows to call @command{make} for a particular subdirectory in the
109 Under OMK all products of compilation are stored @b{out of source
110 directories}. This simplifies work with version control systems and
111 helps when simultaneous compilation for multiple targets/platforms is
116 @node Quick Start, History, Why to Use OMK?, Overview of OMK
119 If you get some sources, which are distributed with OMK, usually the
120 following commands are sufficient to compile the whole project.
129 @noindent To use OMK in your own project, follow these steps:
133 Take appropriate @file{Makefile.rules}, put it together with leaf
134 @file{Makefile} to the root directory of your project.
136 Create @file{Makefile.omk} files in all directories you want to
137 compile something. Please refer to @ref{OMK User's Manual} to learn
138 what to write in @file{Makefile.omk} files.
140 Run @command{make omkize} in the root directory.
143 @noindent Your project is now ready to compile.
146 @node History, , Quick Start, Overview of OMK
149 OMK was originally written by Pavel Pisa as a solution to have one
150 common make system for OCERA project, where we needed to compile
151 user-space programs, Linux kernel modules and RT Linux modules in one
152 package. Although this system was not accepted for the whole OCERA
153 project. Several individual developers (mostly from Czech Technical
154 University) liked it and started to use it.
156 As a number of projects using OMK grew it was necessary to modularize
157 the make system to support more ``targets''. Michal Sojka took care
158 about the process of modularization.
160 @node OMK User's Manual, Original README, Overview of OMK, Top
161 @chapter OMK User's Manual
165 * Dependency Tracking::
166 * Compiling Programs::
168 * Multiple Directories::
169 * Configuration and Conditional Compilation::
170 * Running OMK under Windows OS::
171 * Interfacing OMK to popular IDEs::
175 @node Basic Concepts, Dependency Tracking, OMK User's Manual, OMK User's Manual
176 @section Basic Concepts
178 The main concept of OMK is very simple. In the root directory of the
179 projects resides a file called @file{Makefile.rules}. This file contains
180 all compilation rules needed for compilation of a particular
181 project. There are different @file{Makefile.rules} for different
182 platforms (Unix, RTEMS, system-less, ...). In every subdirectory a
183 @file{Makefile.omk} is stored. This file specifies what should be done
184 in this directory (e.g. compile a program from several source
185 files). Its syntax is very simple -- see the following sections.
187 Since make searches by default for a @file{Makefile} and not for
188 @file{Makefile.rules} or @file{Makefile.omk}, there must be a small
189 @file{Makefile} in every directory, whose task is only to find
190 @file{Makefile.rules} and include it. The @file{Makefile.rules} is
191 searched starting from the current directory and continuing to upper
194 The compilation process itself is comprised of several passes. Every
195 pass traverses the whole directory structure@footnote{In future, we are
196 planning some optimization that allows OMK to traverse the directories
197 only once and thus decrease compilation time.} and does a particular
198 task in every directory of the project. Typically, these passes are:
200 @anchor{include-pass}
202 This pass takes all include files marked for ``export'' and copies
203 (or links) them to the @file{include} directory under
204 @file{_compiled} directory. @xref{Header Files}.
206 Also, during this pass, automatically generated header file are
207 generated according to the current
208 configuration. @xref{Configuration and Conditional Compilation}.
210 During this pass, all include files are in place, so all libraries
213 Finally, programs can be compiled and linked against libraries
214 created in the previous pass.
217 The results of compilation are stored under the @file{_compiled}
218 directory. This directory is structured as a classical Unix file-system
219 (it contains directories like @file{bin}, @file{lib} and @file{include})
220 and can be directly copied to the target device or to some directory on
221 a host computer (e.g. @file{/usr/local}).
223 Besides @file{_compiled} directory, there in a @file{_build}
224 directory. Under this directory are stored some temporary files and
225 intermediate compilation products (object files, dependency files etc.).
227 @node Dependency Tracking, Compiling Programs, Basic Concepts, OMK User's Manual
228 @section Dependency Tracking
230 OMK automatically handles tracking of dependencies of files in compiled
231 projects. It uses gcc's @option{-M@var{x}} options to do this for object
232 files. This way, whenever you change some header file, OMK recompiles
233 only those files, where the changed header was really included.
235 Dependencies are also maintained for libraries and binaries. To find the
236 dependencies, OMK parses linker map files, so a change to some library
237 causes recompilation of all programs using that library.
240 * Compiling Programs::
241 * Configuration and Conditional Compilation::
244 @node Compiling Programs, Libraries, Dependency Tracking, OMK User's Manual
245 @section Compiling Programs
247 To tell OMK to compile a program, you need to set some variables in
248 @file{Makefile.omk} (usually) in the directory where program sources are
251 In the example bellow a program @command{test} will be compiled from
252 source @file{test.c}.
255 @verbatiminclude ../tests/programs/Makefile.omk
258 @noindent The variables are:
261 Contains a list of names (whitespace separated) of programs to be
262 compiled in this directory.
265 @defvar @var{program name}_SOURCES
266 For every program name in @code{bin_PROGRAMS}, this variable contains
267 a list of sources that are needed to compile the executable. OMK uses
268 an extension of the filename to determine the compiler to compile this
272 @defvar @var{program name}_LIBS
273 This variable contains a list of libraries the program @var{program
274 name} will be linked with.
282 This variable contains a list of libraries all programs in this
283 directory needs to be linked to.
287 Directives passed to the C or C++ compiler with additional directories
288 to be searched for header files. In most cases you need to specify an
289 absolute path. To specify a directory relative to the source
290 directory, you can use the @code{$(SOURCES_DIR)} variable, which
291 refers to the directory, where @file{Makefile.omk} is located. This
292 variable applies to all compilations invoked in the current directory.
295 INCLUDES = -I$(SOURCES_DIR)/my_include_dir
300 Directives passed to the C or C++ compiler with preprocessor macro
301 definitions. This variable applies to all compilations invoked in the
310 @c FIXME: INCLUDES variable should not be set by rtlinux rules.
312 @node Libraries, Multiple Directories, Compiling Programs, OMK User's Manual
316 With OMK, you can easily create statically or dynamically linked
317 libraries. The way of creating libraries is very similar to how programs
318 are created. @xref{Compiling Programs}.
320 In @file{Makefile.omk}, you specify several variables, which defines how
321 the libraries should be compiled. In the example below the library
322 @samp{mylib} is created from two sources @file{funca.c} and
323 @file{funcb.c}. Interface of this library is defined in
324 @file{myfunc.h}. Therfore, we export this header for use by other
328 @verbatiminclude ../tests/libraries/Makefile.omk
331 @noindent Variables for use with libraries are:
333 @defvar lib_LIBRARIES
334 Specifies a list of statically linked libraries to be compiled.
337 @defvar shared_LIBRARIES
338 Specifies a list of dynamically linked libraries to be compiled.
341 @defvar @var{library name}_SOURCES
342 For every library name in @code{lib_LIBRARIES} or
343 @code{shared_LIBRARIES}, this variable contains a list of sources that
344 are needed to compile the library. OMK uses an extension of the
345 filename to determine the compiler to compile this source.
352 @node Header Files, , Libraries, Libraries
353 @subsection Header Files
355 C and C++ libraries are not very useful without header files. OMK
356 provides several variables that specify activities on header files.
358 During compilation, header files are copied (or linked) from source
359 directories to the @file{_compiled} tree
360 (see @ref{include-pass}). Libraries and programs are then compiled against
363 @anchor{include_HEADERS}
364 @defvar include_HEADERS
365 Specifies the list of header files to be exported for use by other
366 libraries/programs. If the header file specified here contains a
367 directory prefix (see @file{periph/} in the example below), the header
368 is copied with the same prefix under @file{includes} directory in
369 @file{_compiled} tree.
372 include_HEADERS = regs.h periph/sci_regs.h
376 @defvar nobase_include_HEADERS
377 Similar to @ref{include_HEADERS}, but the directory prefix is always
378 stripped before coping the header file.
381 @defvar renamed_include_HEADERS
382 Exports the header files under different name. The form of the items
383 in this whitespace separated list is: @var{real name}@code{->}@var{new
387 renamed_include_HEADERS = orte_config_omk_win32.h->orte_config.h
392 This variable is very useful during library development. Most
393 @acronym{IDE}s, allows you to jump directly to the place, where an
394 error is reported by the compiler. If the error is in a header file,
395 IDE opens you the copy of the header file. If you correct the error
396 there, after the next compilation, your header file will be
397 overwritten by the old version from your source tree.
399 If this variable equals to @samp{y}, symbolic links to headers in
400 source directories are used in @file{_compiled} tree instead of
404 @node Multiple Directories, Configuration and Conditional Compilation, Libraries, OMK User's Manual
405 @section Multiple Directories
407 OMK is probably most useful in projects consisting of multiple
408 directories. For such projects, it is not easy to write Makefiles that
409 provides all the needed features, from scratch.
411 You can instruct OMK to descend to a (sub)directory by setting the
412 @code{SUBDIRS} variable in @file{Makefile.omk}.
415 This variable contains a list of directories, in which compilation
416 must be also invoked. Usually, names of subdirectories are used, but
417 you can use any path specification here.
419 Compilation is invoked in these directories before it is invoked in
420 the current directory.
422 @c TODO: Write tests for this.
424 @defvar ALL_OMK_SUBDIRS
425 This variable is set by OMK and can be used as the value of
426 @code{SUBDIRS} variable. It contains a list of all direct
427 subdirectories, which contain @file{Makefile.omk}. This is especially
428 useful if you are combining several projects or components
429 together. In the root directory of your project, you just create
430 symbolic links the components from other projects and all the linked
431 directories automatically appears as the value of this variable.
434 SUBDIRS = $(ALL_OMK_SUBDIRS)
438 @node Configuration and Conditional Compilation, Running OMK under Windows OS, Multiple Directories, OMK User's Manual
439 @section Configuration and Conditional Compilation
441 In many projects, it is necessary to configure a compilation process. By
442 this configuring we mean, setting some parameters that influence the
443 output of compilation process. In GNU projects, @command{configure}
444 script is usually responsible for configuration. User provides some
445 parameters to @command{configure}, which is run before compilation, and
446 this script does all steps needed to configure the sources and
447 make-system in the desired way.
449 OMK has its own configuration mechanism, which is described in this
450 section. For future releases, we plan that this mechanism can make use
451 of GNU autoconf, but currently there is no support for it.
453 In every directory you can specify some configuration parameters, which
454 can be modified by a user. Then, when @command{make default-config} is
455 run, all these parameters are found and together with their default
456 values are stored as makefile variables in
457 @file{config.omk-default}. This file is included during compilation, so
458 if you don't specify other values, these defaults are used. If you are
459 not satisfied with these defaults, you can override the values of
460 parameters in @file{config.omk}. This file is also included during
461 compilation and variables mentioned there takes precedence over those
462 specified in @file{config.omk-default}. Both @file{config.omk} and
463 @file{config.omk-default} have to be stored in the same directory as
464 @file{Makefile.rules}.
466 Besides overriding the default values of configuration parameters,
467 @file{config.omk} can also be used as a common place to store some
468 global settings that applies to the whole project, e.g. the compiler to
469 use or common compiler flags.
471 @subsection Specifying Configuration Parameters
473 To specify names and default values of configuration parameters use the
474 @code{default_CONFIG} variable in @file{Makefile.omk}.
476 @defvar default_CONFIG
477 This variable contains a list of configuration parameters and their
478 default values. The format of every item in this list is
479 @var{CONFIG_xxxx}=@var{value}. You can name the parameter as you want,
480 but it is good practice to start the name with @samp{CONFIG_} prefix.
482 OMK can automatically generate header files, with C preprocessor macro
483 definitions according to the OMK's configuration parameters. The
484 actual content of generated header files depends on the form of the
485 @var{value}. The possible forms are:
488 @item @samp{y} or @samp{n}
489 This defines boolean parameters. If the value of the parameter is
490 @samp{y}, the @samp{#define CONFIG_@var{xxx} 1} is generated, if it is
491 @samp{n}, no @code{#define} is generated.
493 Numeric parameters. The define looks like @samp{#define CONFIG_@var{xxx} @var{number}}
495 Text without quotes. The define looks like @samp{#define CONFIG_@var{xxx} @var{text}}
497 Text with quotes. The define looks like @samp{#define CONFIG_@var{xxx} "@var{text}"}
501 @noindent Example of using @code{default_CONFIG}. @file{Makefile.omk} reads like:
503 @verbatiminclude ../tests/config/default/Makefile.omk
505 @noindent and @file{subdir/Makefile.omk} like:
507 @verbatiminclude ../tests/config/default/subdir/Makefile.omk
510 @noindent After running @command{make default-config}, the content of
511 @file{config.omk-default} will be:
513 @verbatiminclude ../tests/config/default/config.omk-correct
516 @subsection Using Configuration Parameters
518 Configuration parameters can be used in two ways:
521 as variables in @file{Makefile.omk} and
523 as C/C++ preprocessor macros in OMK generated header files.
526 @noindent For the first use, your @file{Makefile.omk} may contain something like:
528 SUBDIRS = arch/$(CONFIG_ARCH)
530 ifeq ($(CONFIG_DEBUG),y)
531 DEFS += -DUSE_SIMULATOR
535 @noindent For the second use, there are several variables that control
536 the generation of header files with configuration values. These
537 variables are described here:
539 @anchor{LOCAL_CONFIG_H}
540 @defvar LOCAL_CONFIG_H
541 The value of this variable is the name of a header file, which will
542 contain all configuration parameters declared in the current directory
543 by @code{default_CONFIG}. This header file is accessible only by files
544 in the current directory and it should be included like @code{#include
547 In @file{Makefile.omk}, the use of this variable can look like this:
550 LOCAL_CONFIG_H = myconfig.h
554 @defvar config_include_HEADERS
555 This variable is similar to @code{LOCAL_CONFIG_H}. One difference is
556 that the generated header file is accessible to all files, not only to
557 files in the same directory (it is stored in @file{_compiled}
558 tree). The second difference is that you have to specify, which
559 configuration parameters you want to appear in the header file.
562 @defvar @var{xxx}_DEFINES
563 This variable determines the configuration parameters that should be
564 stored in a header file specified by
565 @code{config_include_HEADERS}. The @var{xxx} in the name of this
566 variable needs to be the same as the base name (without extension) of
570 @noindent Example of using @code{config_include_HEADERS}:
572 default_CONFIG = CONFIG_LINCAN=y CONFIG_LINCANRTL=n CONFIG_LINCANVME=n
573 config_include_HEADERS = global.h
574 global_DEFINES = CONFIG_OC_LINCAN CONFIG_OC_LINCANRTL
577 @noindent Here, we include only two out of the three configuration
578 parameters defined in the current @file{Makefile.omk}. It is also
579 possible to include configuration parameters defined in a different
582 @subsection Common Variables
584 It is common practice to use @file{config.omk} to store project-wide
585 settings. Here is the list of variables, which are commonly set here
586 (but they can also be set elsewhere, e.g. in @file{Makefile.omk}).
588 You can easily ``reconfigure'' your project by changing the
589 @file{config.omk} file. It is useful to have several configurations
590 stored in different files and let @file{config.omk} be a symbolic link
591 to the desired configuration.
595 The name of C compiler.
597 Command line options for C compiler.
599 The name of C++ compiler.
601 Additional parameters (besides @code{CFLAGS}) to by passed to C++
605 @node Running OMK under Windows OS, Interfacing OMK to popular IDEs, Configuration and Conditional Compilation, OMK User's Manual
606 @section Running OMK under Windows OS
608 @node Interfacing OMK to popular IDEs, Troubleshooting, Running OMK under Windows OS, OMK User's Manual
609 @section Interfacing OMK to popular IDEs
613 KDevelop has support for custom build systems. To use KDevelop to
614 develop projects using OMK follow these steps. These steps are valid for
615 version 3.5.0 of KDevelop, but for previous versions it doesn't differ
620 Import project to KDevelop (from menu choose @emph{Project---Import
621 existing project}). Select the type of project to @emph{Generic C
622 Application (Custom Buildsystem)}.
628 Then answer to following dialogs as you want.
633 @image{kdevelop3} @image{kdevelop4}
637 If you are working only on some small part of the bigger project, you
638 usually don't want to recompile the whole project every time. In
639 @emph{Project---Project Options}, you can specify the subdirectory where to
646 If you want to switch between several configurations easily (see also
647 @ref{Configuration and Conditional Compilation}), in the same dialog
648 you can add @option{-e} to make options. This makes environment variables
649 have higher precedence than those in @file{config.omk-default}. Then,
650 you can define several environments with different
651 @code{CONFIG_@var{xxx}} variables and their values.
657 You can easily switch the configurations from @emph{Build---Make
667 @subsection Emacs, VIM, etc.
669 Since OMK compilation is started by executing @command{make} command,
670 many common editors can work easily with OMK.
672 Under Emacs, you can use @command{compile} or @command{recompile}
673 commands as you are used to do.
675 @node Troubleshooting, , Interfacing OMK to popular IDEs, OMK User's Manual
676 @section Troubleshooting
678 Renaming of some file => dependency problems.
680 Manual compilation ... V=1
682 @node Original README, OMK Development, OMK User's Manual, Top
683 @chapter Original README
685 Since this manual still doesn't cover all aspects of OMK, we include
686 here a @file{README.rules} file, which was written for the first version
689 @b{Important notice:} This make system uses features found in recent
690 versions of GNU Make program. If you encounter problems with package
691 building, check, that you use correct version of Make program. The
692 Make older than version 3.80, could not be used. Even Make version
693 3.80 has annoying bug which causes building fail with misleading
694 message "virtual memory exhausted". Please, upgrade at least to
695 version 3.81 of GNU Make.
697 There is list of features which we want to solve with our make system:
700 Central @file{Makefile.rules} for most of components of a bigger project.
702 FIXME (our CAN framework includes more libraries common with our other
703 projects, we need to separate some utility libraries etc.)
705 The rules in more spread Makefiles are way to the hell (update for
706 different kernel, RT-Linux etc would be nightmare in other case).
708 Make system should allow to freely move cross-dependant components in
709 directory structure without need to update users of moved component (I
710 hate somethink like @option{-I../../sched/rtlshwq/include} in CAN makefiles for
711 example. If a component is renamed or version is added to then name,
712 all Makefiles in CAN will require update).
714 Make system should be able to compile mutually cross-dependant
715 libraries and should ensure, that change in one component sources or
716 headers would result in relink or rebuild in components linked against
717 that library or including modified header file.
719 Make system has to enable compilation out of OCERA full source tree
720 (we would lost many users of particular components in other case).
722 Compile should be able to do all above work without need to install
723 any files before successful finish of build.
725 Because we use some libraries for RT-Linux build and user-space build,
726 we need to solve how to compile from same sources to both targets.
728 The build system should allow to call make for particular source
729 subdirectory. Time of recursive make through all subdirectories is
732 Make system should enable to build out of sources tree (else clean or
733 working with CVS sandbox gets fussy and simultaneous multiple targets
736 It would be good, if there is a possibility to call make from
737 read-only media sources.
739 Make system should store results of build in some separate directory
740 structure to simple install and testing.
742 Makefiles in sources directories should be simple.
745 There is probably only one alternative fully supporting above requirements
746 and it is GNU Autoheader...Automake...Autoconf... system.
747 But it is complicated and requires big amount of support files.
748 It would be acceptable if it could be easily used for OCERA framework.
749 But there are important show stoppers for that system:
752 It would require deep revision of all OCERA CVS contents and agreement
753 on this would be problematic
755 This system is not well prepared for dual compilation for Linux and
756 RT-Linux sub-targets. It would mean many changes in default autoconf
757 setup to support this. Probably simplest way would be to rebuild GCC
758 tool chain for something like i586-elf-rtlinux. This would require
759 even more space for OCERA development.
762 The problem calls for same solution, which would have minimal impact
763 on other components and would be elegant and would be maintainable
764 and small, because our main goal is components development and not
765 make systems development.
767 There is result of our trial. It is OMK make system.
768 The @file{Makefile} and @file{Makefile.omk} files should be in all source
769 directories. Common @file{Makefile.rules} file is required in the toplevel
770 sources directory. Alternatively this file could be moved
771 to link tree pointing into readonly media or can be anywhere
772 else if @code{MAKERULES_DIR} and @code{SOURCES_DIR} are specified.
774 Syntax of Makefile.omk files is for usual cases compatible
775 to Automake's Makefile.am descriptions. There are specific targets
776 for RT-Linux and Linux kernel related stuff
778 Makefile.omk user defined variables
781 list of subdirectories intended for make from actual directory
783 list of the user-space libraries
784 @item shared_LIBRARIES
785 list of the user-space shared libraries
786 @item kernel_LIBRARIES
787 list of the kernel-space libraries
788 @item rtlinux_LIBRARIES
789 list of the RT-Linux kernel-space libraries
790 @item include_HEADERS
791 list of the user-space header files
792 @item nobase_include_HEADERS
793 headers copied even with directory part
795 list of the kernel-space header files
796 @item rtlinux_HEADERS
797 list of the RT-Linux kernel-space header files
799 list of the require binary programs
801 list of the development utility programs
803 list of the kernel side modules/applications
804 @item rtlinux_MODULES
805 list of RT-Linux the kernel side modules/applications
807 list of specific target sources
809 additional include directories and defines for user-space
810 @item kernel_INCLUDES
811 additional include directories and defines for kernel-space
812 @item rtlinux_INCLUDES
813 additional include directories and defines for RT-Linux
815 list of default config assignments CONFIG_XXX=y/n ...
818 The Makefile is same for all sources directories and is only 14 lines
819 long. It is there only for convenience reasons to enable call "make"
820 from local directory. It contains code which locates
821 @file{Makefile.rules} in actual or any parent directory. With standard
822 BASH environment it works such way, that if you get into sources
823 directory over symbolic links, it is able to unwind yours steps back
824 => you can make links to readonly media component directories, copy
825 @file{Makefile.rules}, Makefile and toplevel Makefile.omk, adjust
826 Makefile.omk to contain only required components and then call make in
827 top or even directories after crossing from your tree to readonly
830 The system compiles all files out of source directories. The actual
831 version of system is adapted even for OCERA tree mode if
832 @code{OCERA_DIR} variable is defined in @file{Makefile.rules}
834 There are next predefined directory name components, which can be
838 @item BUILD_DIR_NAME = _build
839 prefix of directory, where temporary build files are stored
840 @item COMPILED_DIR_NAME = _compiled
841 prefix of directory, where final compilation results are stored
842 @item GROUP_DIR_NAME = yyy
843 this is used for separation of build sub-trees in OCERA environment
844 where more @file{Makefile.rules} is spread in the tree
847 Next directories are used:
850 @item KERN_BUILD_DIR := $(MAKERULES_DIR)/$(BUILD_DIR_NAME)/kern
851 directory to store intermediate files for kernel-space targets
852 @item USER_BUILD_DIR := $(MAKERULES_DIR)/$(BUILD_DIR_NAME)/user
853 directory to store intermediate files for user-space targets
855 @item USER_INCLUDE_DIR := $(MAKERULES_DIR)/$(COMPILED_DIR_NAME)/include
856 directory to store exported include files which should be installed later
857 on user-space include path
858 @item USER_LIB_DIR := $(MAKERULES_DIR)/$(COMPILED_DIR_NAME)/lib
859 same for user-pace libraries
860 @item USER_UTILS_DIR := $(MAKERULES_DIR)/$(COMPILED_DIR_NAME)/bin-utils
861 utilities for testing, which would not probably be installed
862 @item USER_BIN_DIR := $(MAKERULES_DIR)/$(COMPILED_DIR_NAME)/bin
863 binaries, which should go into directory on standard system PATH
864 (/usr/local/bin, /usr/bin or $(prefix)/bin)
866 @item KERN_INCLUDE_DIR := $(MAKERULES_DIR)/$(COMPILED_DIR_NAME)/include-kern
867 directory to store exported include files which should be installed later
868 on kernel-space include path
869 @item KERN_LIB_DIR := $(MAKERULES_DIR)/$(COMPILED_DIR_NAME)/lib-kern
870 same for kernel-pace libraries
871 @item KERN_MODULES_DIR := $(MAKERULES_DIR)/$(COMPILED_DIR_NAME)/modules
872 builded modules for Linux kernel or RT-Linux system
875 There is more recursive passes through directories to enable
876 mutual dependant libraries and binaries to compile.
877 Next passes are defined
881 generates @file{config.omk-default} or xxx-default (FIXME) configuration file
883 checks and creates required build directories
885 copies header files to @code{USER_INCLUDE_DIR} and @code{KERN_INCLUDE_DIR}
887 builds objects in USER_BUILD_DIR/@var{relative path} and creates libraries
889 @item binary-pass and utils-pass
890 links respective binaries in USER_@{BIN,UTILS@}_DIR directory. If some
891 object file is missing it compiles it in USER_BUILD_DIR/@var{relative path}
892 @item kernel-lib-pass
893 builds libraries for kernel space targets
895 builds kernel modules
898 The amount of passes is relatively high and consumes some time. But
899 only other way to support all required features is to assemble one big
900 toplevel Makefile, which would contain all components and targets
903 Drawbacks of designed make system
906 the system is not as fast as we would like
908 it lacks Autoconf and configure extensive support for many systems
909 from UNIX to DOS and WINDOWS
911 it does not contain support for checking existence of target
912 libraries and functionalities as GNU Autoconf
914 it is heavily dependant on GNU MAKE program. But it would not be big
915 problem, because even many commercial applications distribute GNU MAKE
916 with them to be able to work in non-friendly systems
918 the key drawback is dependence on recent MAKE version 3.80 and better
919 and even version 3.80 of MAKE has important bug, which has been
920 corrected in newer sources (FIXME)
923 The last point is critical. I have not noticed it first, because
924 I use Slackware-9.2 and it contains latest released version
925 of MAKE (version 3.80).
926 The problem appears when I have tried to build bigger libraries.
927 There is bug in version 3.80, which results in misleading
928 error "Virtual memory exhausted". It is known bug with ID 1517
931 * long prerequisite inside eval(call()) => vm exhausted, Paul D. Smith
935 I have optimized some rules to not push memory to the edge,
936 but there could be still issues with 3.80 version.
938 I have downloaded latest MAKE CVS sources. The compilation required
939 separate lookup and download for .po files and full Autoheader... cycle.
940 I have put together package similar to release. Only ./configure --prefix=...
941 and make is required. CVS sources contains version 3.81beta1.
942 You can download prepared sources archive from
943 @indicateurl{http://paulandlesley.org/make/make-3.81beta1.tar.bz2}
944 Or you can get our local copy from
945 @indicateurl{http://cmp.felk.cvut.cz/~pisa/can/make-3.81beta1.tar.gz}
947 The archive contains even "make" binary build by me, which should work
948 on other Linux distributions as well. Older version of MAKE (3.79.x
949 released about year 2000) found on Mandrake and RedHat are not
950 sufficient and do not support eval feature. I do not expect, that
951 Debian would be more up-to-date or contain fixes to MAKE vm exhausted
954 The local CTU archive with our CAN components prepared for inclusion
955 into OCERA SF CVS could be found in my "can" directory
957 @indicateurl{http://cmp.felk.cvut.cz/~pisa/can/ocera-can-031212.tar.gz}
959 The code should build for user-space with new make on most of Linux distros
960 when make is updated.
962 If you want to test compile for RT-Linux targets, line
965 #RTL_DIR := /home/cvs/ocera/ocera-build/kernel/rtlinux
968 in @file{Makefile.rules} has to be activated and updated
969 to point RT-Linux directory containing "rtl.mk".
970 There is only one library ("ulutrtl") and test utility compiled for RT-Linux
971 (@file{can/utils/ulut/ul_rtlchk.c}).
973 The next line, if enabled, controls compilation in OCERA project tree
976 #OCERA_DIR := $(shell ( cd -L $(MAKERULES_DIR)/../../.. ; pwd -L ) )
979 The LinCAN driver has been updated to compile out of source directories.
981 Please, check, if you could compile CAN package and help us with integration
982 into OCERA SF CVS. Send your comments and objections.
984 The OMK system has been adapted to support actual OCERA configuration process.
985 I am not happy with ocera.mk mix of defines and poor two or three rules,
986 but OMK is able to overcome that.
988 The OMK system has integrated rules (default-config) to build default
989 configuration file. The file is named @file{config.omk-default} for
990 the stand-alone compilation. The name corresponds to OCERA config +
991 "-default" if OCERA_DIR is defined. This file contains statements
992 from all @code{default_CONFIG} lines in all @file{Makefile.omk}. The
993 file should be used for building of own @file{config.omk} file, or as
994 list for all options if Kconfig is used.
996 @c @chapter OMK Reference
998 @node OMK Development, Variable Index, Original README, Top
999 @chapter OMK Development
1003 @node Variable Index, , OMK Development, Top
1004 @unnumbered Variable Index
1008 @c @node Concept Index, , Variable Index, Top
1009 @c @unnumbered Concept Index