@end table
@end defvar
-Example of using @code{default_CONFIG}. @file{Makefile.omk} reads like:
+@noindent Example of using @code{default_CONFIG}. @file{Makefile.omk} reads like:
@example
@verbatiminclude ../tests/config/default/Makefile.omk
@end example
-and @file{subdir/Makefile.omk} like:
+@noindent and @file{subdir/Makefile.omk} like:
@example
@verbatiminclude ../tests/config/default/subdir/Makefile.omk
@end example
-After running @command{make default-config}, the content of
+@noindent After running @command{make default-config}, the content of
@file{config.omk-default} will be:
@example
@verbatiminclude ../tests/config/default/config.omk-correct
@subsection Using Configuration Parameters
-Configuration parameters can be used by two ways:
+Configuration parameters can be used in two ways:
@enumerate
@item
as variables in @file{Makefile.omk} and
@item
- as C preprocessor macros in OMK generated header files.
+ as C/C++ preprocessor macros in OMK generated header files.
@end enumerate
-@noindent For the first use, you can have in @file{Makefile.omk} something like:
+@noindent For the first use, your @file{Makefile.omk} may contain something like:
@example
SUBDIRS = arch/$(CONFIG_ARCH)
ifeq ($(CONFIG_DEBUG),y)
DEFS += -DUSE_SIMULATOR
-endif
+end if
@end example
-For the second use, there are several variables that are described here:
+For the second use, there are several variables that control generation
+of header files with configuration values. These variables are described
+here:
+@anchor{LOCAL_CONFIG_H}
@defvar LOCAL_CONFIG_H
+ The value of this variable is the name of a header file, which will
+ contain all configuration parameters declared in the current directory
+ by @code{default_CONFIG}. This header file is accessible only by files
+ in current directory and it should be included like @code{#include
+ "@var{myconfig.h}"}.
+ In @file{Makefile.omk}, the use of this variable can look like this:
+
+@example
+LOCAL_CONFIG_H = myconfig.h
+@end example
@end defvar
@defvar config_include_HEADERS
-
+ This variable is similar to @code{LOCAL_CONFIG_H}. One difference is
+ that the generated header file is accessible to all files, not only to
+ files in the same directory. The second difference is that you have to
+ specify, which configuration parameters you want to appear in the
+ header file.
@end defvar
@defvar @var{xxx}_DEFINES
-
+ This variable determines the configuration parameters stored in a
+ header file generated by @code{config_include_HEADERS}. The @var{xxx}
+ in the name of this variable needs to be the same as the base name
+ (without extension) of the header file.
@end defvar
+@noindent Example of using @code{config_include_HEADERS}:
+@example
+default_CONFIG = CONFIG_LINCAN=y CONFIG_LINCANRTL=n CONFIG_LINCANVME=n
+config_include_HEADERS = global.h
+global_DEFINES = CONFIG_OC_LINCAN CONFIG_OC_LINCANRTL
+@end example
@subsection Common Variables
+It is common practice to use @file{config.omk} to store projects-wide
+settings. Here is the list of variables, which are commonly set here
+(but they can also be set elsewhere, e.g. in @file{Makefile.omk}).
+
+You can easily ``reconfigure'' your project by changing the
+@file{config.omk} file. It is useful to have several configurations
+stored in different files and let @file{config.omk} be a symbolic link
+to the desired configuration.
+
+@vtable @code
+@item CC
+ The name of C compiler.
+@item CFLAGS
+ Command line options for C compiler.
+@item CXX
+ The name of C++ compiler.
+@item CPPFLAGS
+ Additional parameters (besides @code{CFLAGS}) to by passed to C++
+ compiler.
+@end vtable
@section Running OMK under Windows @acronym{OS}
@section Interfacing OMK to popular @acronym{IDE}s
+@subsection KDevelop
+
+KDevelop has support for custom build systems. To use KDevelop to
+develop projects using OMK follow these steps. These steps are valid for
+version 3.5.0 of KDevelop, but for previous versions it doesn't differ
+much.
+
+@enumerate
+@item
+ Import project to KDevelop (from menu choose Project -> Import
+ existing project). Select the type of project to @samp{Generic C
+ Application (Custom Buildsystem)}
+@example
+ @image{kdevelop1}
+@end example
+
+@item
+ Then answer to following dialogs as you want.
+@example
+ @image{kdevelop2}
+@end example
+@example
+ @image{kdevelop3} @image{kdevelop4}
+@end example
+
+@item
+ If you are working only on some small part of the bigger project, you
+ usually don't want to recompile the whole project every time. In
+ Project -> Project Options, you can specify the subdirectory where to
+ run @command{make}.
+@example
+ @image{kdevelop5}
+@end example
+
+@item
+ If you want to switch between several configurations easily (see also
+ @ref{Configuration and Conditional Compilation}), in the same dialog
+ you can add @option{-e} to make options. This makes environment variables
+ have higher precedence than those in @file{config.omk-default}. Then,
+ you can define several environments with different
+ @code{CONFIG_@var{xxx}} variables and their values.
+@example
+ @image{kdevelop6}
+@end example
+
+@item
+ You can easily switch the configurations from Build -> Make
+ Environment.
+@example
+ @image{kdevelop7}
+@end example
+@end enumerate
+
+
@subsection Eclipse
-@subsection KDevelop
+@subsection Emacs, VIM, etc.
-@subsection Emacs
+Since OMK compilation is started by executing @command{make} command,
+many common editors can work easily with OMK.
-@subsection VIM
+Under Emacs, you can use @command{compile} or @command{recompile}
+commands as you are used to do.
@section Troubleshooting
-@chapter OMK Reference
+@c @chapter OMK Reference
@node OMK Development, Variable Index, Overview of OMK, Top
@chapter OMK Development
@printindex vr
-@node Concept Index, , Variable Index, Top
-@unnumbered Concept Index
-
-@printindex cp
+@c @node Concept Index, , Variable Index, Top
+@c @unnumbered Concept Index
+@c @printindex cp
@bye
projects / omk.git / commitdiff
