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
24 @top Ocera Make System
31 @chapter Overview of OMK
34 OMK is an advanced make system written entirely in GNU make. Compiling
35 software using OMK requires only GNU make binary and standard UNIX
36 utilities installed. OMK aims to be developer friendly; to use OMK,
37 you do not need to understand (sometiles) cryptic syntax of makefile
43 OMK was originally written by Pavel Pisa as a solution to have one
44 common make system for OCERA project, where we needed to compile
45 user-space programs, Linux kernel modules and RT Linux modules in one
46 package. Although this system was not accepted for the whole OCERA
47 project. Several individual developers (mostly from Czech Technical
48 University) liked it and started to use it.
50 As number of users grew it was necessary to modularize the make system
51 to support more ``targets''. Michal Sojka took care about the process
54 @chapter Original README
56 @b{Important notice:} This make system uses features found in recent
57 versions of GNU Make program. If you encounter problems with package
58 building, check, that you use correct version of Make program. The
59 Make older than version 3.80, could not be used. Even Make version
60 3.80 has annoying bug which causes building fail with misleading
61 message "virtual memory exhausted". Please, upgrade at least to
62 version 3.81 of GNU Make.
64 There is list of features which we want to solve with our make system:
67 Central @file{Makefile.rules} for most of components of a bigger project.
69 FIXME (our CAN framework includes more libraries common with our other
70 projects, we need to separate some utility libraries etc.)
72 The rules in more spread Makefiles are way to the hell (update for
73 different kernel, RT-Linux etc would be nightmare in other case).
75 Make system should allow to freely move cross-dependant components in
76 directory structure without need to update users of moved component (I
77 hate somethink like @option{-I../../sched/rtlshwq/include} in CAN makefiles for
78 example. If a component is renamed or version is added to then name,
79 all Makefiles in CAN will require update).
81 Make system should be able to compile mutually cross-dependant
82 libraries and should ensure, that change in one component sources or
83 headers would result in relink or rebuild in components linked against
84 that library or including modified header file.
86 Make system has to enable compilation out of OCERA full source tree
87 (we would lost many users of particular components in other case).
89 Compile should be able to do all above work without need to install
90 any files before successful finish of build.
92 Because we use some libraries for RT-Linux build and user-space build,
93 we need to solve how to compile from same sources to both targets.
95 The build system should allow to call make for particular source
96 subdirectory. Time of recursive make through all subdirectories is
99 Make system should enable to build out of sources tree (else clean or
100 working with CVS sandbox gets fussy and simultaneous multiple targets
103 It would be good, if there is a possibility to call make from
104 read-only media sources.
106 Make system should store results of build in some separate directory
107 structure to simple install and testing.
109 Makefiles in sources directories should be simple.
112 There is probably only one alternative fully supporting above requirements
113 and it is GNU Autoheader...Automake...Autoconf... system.
114 But it is complicated and requires big amount of support files.
115 It would be acceptable if it could be easily used for OCERA framework.
116 But there are important show stoppers for that system:
119 It would require deep revision of all OCERA CVS contents and agreement
120 on this would be problematic
122 This system is not well prepared for dual compilation for Linux and
123 RT-Linux sub-targets. It would mean many changes in default autoconf
124 setup to support this. Probably simplest way would be to rebuild GCC
125 tool chain for something like i586-elf-rtlinux. This would require
126 even more space for OCERA development.
129 The problem calls for same solution, which would have minimal impact
130 on other components and would be elegant and would be maintainable
131 and small, because our main goal is components development and not
132 make systems development.
134 There is result of our trial. It is OMK make system.
135 The @file{Makefile} and @file{Makefile.omk} files should be in all source
136 directories. Common @file{Makefile.rules} file is required in the toplevel
137 sources directory. Alternatively this file could be moved
138 to link tree pointing into readonly media or can be anywhere
139 else if @code{MAKERULES_DIR} and @code{SOURCES_DIR} are specified.
141 Syntax of Makefile.omk files is for usual cases compatible
142 to Automake's Makefile.am descriptions. There are specific targets
143 for RT-Linux and Linux kernel related stuff
145 Makefile.omk user defined variables
148 list of subdirectories intended for make from actual directory
150 list of the user-space libraries
151 @item shared_LIBRARIES
152 list of the user-space shared libraries
153 @item kernel_LIBRARIES
154 list of the kernel-space libraries
155 @item rtlinux_LIBRARIES
156 list of the RT-Linux kernel-space libraries
157 @item include_HEADERS
158 list of the user-space header files
159 @item nobase_include_HEADERS
160 headers copied even with directory part
162 list of the kernel-space header files
163 @item rtlinux_HEADERS
164 list of the RT-Linux kernel-space header files
166 list of the require binary programs
168 list of the development utility programs
170 list of the kernel side modules/applications
171 @item rtlinux_MODULES
172 list of RT-Linux the kernel side modules/applications
174 list of specific target sources
176 additional include directories and defines for user-space
177 @item kernel_INCLUDES
178 additional include directories and defines for kernel-space
179 @item rtlinux_INCLUDES
180 additional include directories and defines for RT-Linux
182 list of default config assignments CONFIG_XXX=y/n ...
185 The Makefile is same for all sources directories and is only 14 lines
186 long. It is there only for convenience reasons to enable call "make"
187 from local directory. It contains code which locates
188 @file{Makefile.rules} in actual or any parent directory. With standard
189 BASH environment it works such way, that if you get into sources
190 directory over symbolic links, it is able to unwind yours steps back
191 => you can make links to readonly media component directories, copy
192 @file{Makefile.rules}, Makefile and toplevel Makefile.omk, adjust
193 Makefile.omk to contain only required components and then call make in
194 top or even directories after crossing from your tree to readonly
197 The system compiles all files out of source directories. The actual
198 version of system is adapted even for OCERA tree mode if
199 @code{OCERA_DIR} variable is defined in @file{Makefile.rules}
201 There are next predefined directory name components, which can be
205 @item BUILD_DIR_NAME = _build
206 prefix of directory, where temporary build files are stored
207 @item COMPILED_DIR_NAME = _compiled
208 prefix of directory, where final compilation results are stored
209 @item GROUP_DIR_NAME = yyy
210 this is used for separation of build sub-trees in OCERA environment
211 where more @file{Makefile.rules} is spread in the tree
214 Next directories are used:
217 @item KERN_BUILD_DIR := $(MAKERULES_DIR)/$(BUILD_DIR_NAME)/kern
218 directory to store intermediate files for kernel-space targets
219 @item USER_BUILD_DIR := $(MAKERULES_DIR)/$(BUILD_DIR_NAME)/user
220 directory to store intermediate files for user-space targets
222 @item USER_INCLUDE_DIR := $(MAKERULES_DIR)/$(COMPILED_DIR_NAME)/include
223 directory to store exported include files which should be installed later
224 on user-space include path
225 @item USER_LIB_DIR := $(MAKERULES_DIR)/$(COMPILED_DIR_NAME)/lib
226 same for user-pace libraries
227 @item USER_UTILS_DIR := $(MAKERULES_DIR)/$(COMPILED_DIR_NAME)/bin-utils
228 utilities for testing, which would not probably be installed
229 @item USER_BIN_DIR := $(MAKERULES_DIR)/$(COMPILED_DIR_NAME)/bin
230 binaries, which should go into directory on standard system PATH
231 (/usr/local/bin, /usr/bin or $(prefix)/bin)
233 @item KERN_INCLUDE_DIR := $(MAKERULES_DIR)/$(COMPILED_DIR_NAME)/include-kern
234 directory to store exported include files which should be installed later
235 on kernel-space include path
236 @item KERN_LIB_DIR := $(MAKERULES_DIR)/$(COMPILED_DIR_NAME)/lib-kern
237 same for kernel-pace libraries
238 @item KERN_MODULES_DIR := $(MAKERULES_DIR)/$(COMPILED_DIR_NAME)/modules
239 builded modules for Linux kernel or RT-Linux system
242 There is more recursive passes through directories to enable
243 mutual dependant libraries and binaries to compile.
244 Next passes are defined
248 generates @file{config.omk-default} or xxx-default (FIXME) configuration file
250 checks and creates required build directories
252 copies header files to @code{USER_INCLUDE_DIR} and @code{KERN_INCLUDE_DIR}
254 builds objects in USER_BUILD_DIR/@var{relative path} and creates libraries
256 @item binary-pass and utils-pass
257 links respective binaries in USER_@{BIN,UTILS@}_DIR directory. If some
258 object file is missing it compiles it in USER_BUILD_DIR/@var{relative path}
259 @item kernel-lib-pass
260 builds libraries for kernel space targets
262 builds kernel modules
265 The amount of passes is relatively high and consumes some time. But
266 only other way to support all required features is to assemble one big
267 toplevel Makefile, which would contain all components and targets
270 Drawbacks of designed make system
273 the system is not as fast as we would like
275 it lacks Autoconf and configure extensive support for many systems
276 from UNIX to DOS and WINDOWS
278 it does not contain support for checking existence of target
279 libraries and functionalities as GNU Autoconf
281 it is heavily dependant on GNU MAKE program. But it would not be big
282 problem, because even many commercial applications distribute GNU MAKE
283 with them to be able to work in non-friendly systems
285 the key drawback is dependence on recent MAKE version 3.80 and better
286 and even version 3.80 of MAKE has important bug, which has been
287 corrected in newer sources (FIXME)
290 The last point is critical. I have not noticed it first, because
291 I use Slackware-9.2 and it contains latest released version
292 of MAKE (version 3.80).
293 The problem appears when I have tried to build bigger libraries.
294 There is bug in version 3.80, which results in misleading
295 error "Virtual memory exhausted". It is known bug with ID 1517
298 * long prerequisite inside eval(call()) => vm exhausted, Paul D. Smith
302 I have optimized some rules to not push memory to the edge,
303 but there could be still issues with 3.80 version.
305 I have downloaded latest MAKE CVS sources. The compilation required
306 separate lookup and download for .po files and full Autoheader... cycle.
307 I have put together package similar to release. Only ./configure --prefix=...
308 and make is required. CVS sources contains version 3.81beta1.
309 You can download prepared sources archive from
310 @indicateurl{http://paulandlesley.org/make/make-3.81beta1.tar.bz2}
311 Or you can get our local copy from
312 @indicateurl{http://cmp.felk.cvut.cz/~pisa/can/make-3.81beta1.tar.gz}
314 The archive contains even "make" binary build by me, which should work
315 on other Linux distributions as well. Older version of MAKE (3.79.x
316 released about year 2000) found on Mandrake and RedHat are not
317 sufficient and do not support eval feature. I do not expect, that
318 Debian would be more up-to-date or contain fixes to MAKE vm exhausted
321 The local CTU archive with our CAN components prepared for inclusion
322 into OCERA SF CVS could be found in my "can" directory
324 @indicateurl{http://cmp.felk.cvut.cz/~pisa/can/ocera-can-031212.tar.gz}
326 The code should build for user-space with new make on most of Linux distros
327 when make is updated.
329 If you want to test compile for RT-Linux targets, line
332 #RTL_DIR := /home/cvs/ocera/ocera-build/kernel/rtlinux
335 in @file{Makefile.rules} has to be activated and updated
336 to point RT-Linux directory containing "rtl.mk".
337 There is only one library ("ulutrtl") and test utility compiled for RT-Linux
338 (@file{can/utils/ulut/ul_rtlchk.c}).
340 The next line, if enabled, controls compilation in OCERA project tree
343 #OCERA_DIR := $(shell ( cd -L $(MAKERULES_DIR)/../../.. ; pwd -L ) )
346 The LinCAN driver has been updated to compile out of source directories.
348 Please, check, if you could compile CAN package and help us with integration
349 into OCERA SF CVS. Send your comments and objections.
351 The OMK system has been adapted to support actual OCERA configuration process.
352 I am not happy with ocera.mk mix of defines and poor two or three rules,
353 but OMK is able to overcome that.
355 The OMK system has integrated rules (default-config) to build default
356 configuration file. The file is named @file{config.omk-default} for
357 the stand-alone compilation. The name corresponds to OCERA config +
358 "-default" if OCERA_DIR is defined. This file contains statements
359 from all @code{default_CONFIG} lines in all @file{Makefile.omk}. The
360 file should be used for building of own @file{config.omk} file, or as
361 list for all options if Kconfig is used.
365 @section Basic Concepts
367 @section Compiling Simple Programs
371 @section Configuration and Conditional Compilation
374 @chapter OMK Development
379 @unnumbered Variable Index
384 @unnumbered Concept Index