mk-configure

package: mk-configure

title: mk-configure(7)

text:
# mk-configure(7)

## NAME
mk-configure - lightweight replacement for GNU autotools

## DESCRIPTION
mk-configure is a collection of include files for bmake (portable version of NetBSD make) and a number of executables. It is intended to simplify crossplatform development and software building.

There are only a few top-level makefiles: mkc.init.mk, mkc.mk, mkc.configure.mk, mkc.minitest.mk. Everything else (mkc_imp.*.mk files) is included implicitely. Do not use mkc_imp.*.mk files directly! If you do, I cannot guarantee backward compatibility. mkc.configure.mk is included automatically by mkc.mk, but can be included explicitely. mkc.minitest.mk provides a trivial support for regression tests and should be included explicitely. Usually mk-c makefiles consist of variables assignments and inclusion of mkc.mk in the and. One can also use mkc.prog.mk, mkc.lib.mk, mkc.files.mk, mkc.subdir.mk and mkc.subprj.mk instead of mkc.mk. The latter activates mkc.lib.mk if variable LIB is set, mkc.prog.mk if variables PROG or PROGS are set, mkc.subprj.mk if variable SUBPRJ is set, mkc.subdir.mk if variable SUBDIR is set, and mkc.files.mk otherwise.

To get system-wide configuration parameters, mkc.init.mk loads "${MAKECONF}" file if it exists. Otherwise, it loads /etc/mkcmake.conf if it exists. If neither ${MAKECONF} nor /etc/mkcmake.conf exist, it tries to load /etc/mk.conf file. If "${SRCTOP}/Makefile.common" file exists it is also included by all subprojects. Unless SRCTOP variable is set, "../Makefile.inc" is also included if exists. These files may define any of the variables described below. Compiler-specific defaults are also loaded from "~/.mkcmake" or system directories. This compiler-specific defaults are determined at build time or with the help of mkc_compiler_settings utility.

Below in square brackets the default value for variables are specified. In triangle brackets -- typical way of use, where I means "Initialized by mk-configure", Iu means "Initialized by mk-configure but may be overriden by user", Im means "Initialized by mk-configure but may be set in Makefile", U means "Usually set by user", M means "May be set or changed in project's Makefile" and Mu means "May be set in project's Makefile but may be initialized or overriden by user".

### Targets
Mk-configure provides the following targets:

all

build everything.

clean

clean temporary files and directories with the help of ${CLEANFILES_CMD} and ${CLEANDIRS_CMD} commands.

cleandir

remove all of the files removed by the target clean, as well as cache files created by mkc.configure.mk.

installdirs

create target directories.

install

install programs, libraries, files, include files, manual pages etc. to the target directories with the help of ${INSTALL} program.

uninstall

remove installed files with the help of ${UNINSTALL} command.

configure

check for MKC_ERR_MSG variable and fails if it set printing an error message

depend

create .depend_${.CURDIR:T} file containing list of dependencies (see mkdep(1)).

filelist

output a list of destination files of the project, one per line, e.g.

```
  /usr/local/bin/hello

  /usr/local/man/man1/hello.1

```

obj

if MKOBJDIR is "yes", creates object directories (${.OBJDIR}) according to MAKEOBJDIR and MAKEOBJPREFIX variables. Current umask is used for this.

mkgen

See mkc_imp.foreign_autotools.mk.

bin_tar, bin_targz, bin_tarbz2, bin_zip, bin_deb

build software, install it to a temporary directory (using DESTDIR) and create .tar/.tar.gz/.tar.bz2/.zip/.deb archive containing all installed files. The target bin_deb expects debian control files in DEBIAN subdirectory, see examples/files for the sample.

NOTE: Commands associated with targets all, install, clean, cleandir, depend, test, installdirs, uninstall, configure and filelist in Makefile override the standard behaviour.

NOTE: All targets in this list have pre_*, do_* and post_* counterparts. See ALLTARGETS for details.

### mkc.init.mk
This file is included by mkc.mk and mkc.configure.mk automatically but can be used by users directly. mkc.init.mk uses the following variables.

AFLAGS

Options to ${CC} when compiling or linking .s or .S assembly source files. []

AR

Create, modify, and extract from archives. <Iu> [ar]

ARFLAGS

Options to ${AR}. <Iu> [rl]

AS

Assembler. <Iu> [as]

BINDIR

Target directory for utilities. <Iu Mu> [${PREFIX}/bin]

BMAKE_REQD

Minimal required version of bmake. If it is older, mkcmake exits with error. <Im>

BZIP2

bzip2 copression tool. <Iu> [bzip2]

CC

C compiler. <Iu> [cc]

CC_PREFIX

Prefix command for ${CC}, for example, distcc or ccache. <Iu> []

CC_TYPE

C compiler type. This variable is set by mk-configure and can be overriden by user. It can get the following values:

```
Value     Description
----------------------
gcc       GNU C/C++ compiler
pcc       Portable C compiler
icc       Intel C/C++ compiler
msc       Microsoft C/C++ compiler
armcc     ARM C/C++ compiler
hpc       HP-UX C/C++ compiler
sunpro    SUNWspro C/C++ compiler
ibmc      IBM C/C++ compiler (Visual Age for C/C++?)
bcc       Borland C/C++ compiler
watcom    Watcom C/C++ compiler
como      COMO C/C++ compiler
decc      DEC C
mipspro   MIPSpro C compiler

```

<Iu> [no]

CC_VERSION

C compiler version. <I>

CCSTD

Add C language standard command line option to the compiler. Supported options: c89, gnu89 (C89 with GNU extensions), c99, gnu99 (C99 with GNU extensions), c11, gnu11 (C89 with GNU extensions), c17, gnu17 (C17 with GNU extensions). If compiler is not known for mk-configure or does not support appropriate option, no additional options are applied. <M> []

CFLAGS

Additional flags to the compiler when creating C objects. <IM>

CFLAGS0

The same as CFLAGS but CFLAGS0 is passed to the compiler before CFLAGS. Normally, CFLAGS0 should be modified in makefiles and should not be set from environment by user. <M>

CFLAGS.check

Same as CFLAGS but every option is checked whether it is a valid one for C compiler. Double underline in the flag is considered as a single space character. <M> [unset]

CFLAGS.dflt.<cctype>, CXXFLAGS.dflt.<cxxtype>

Additional flags passed to C or C++ compilers according to their types (CC_TYPE and CXX_TYPE). <Iu>

CFLAGS.pic, CXXFLAGS.pic

Options for C and C++ compilers for generating position independent code. On some platforms it makes sense to override these variables (initialized by mk-configure) for better performance, for example, one may use -fpic instead of -fPIC with GNU C/C++ compilers. See SHLIB_MAJOR, MKPIE etc. variables for more information. <Iu>

CFLAGS.pie, CXXFLAGS.pie

Options for C and C++ compilers for generating position independent executables. On some platforms it makes sense to override these variables (initialized by mk-configure) for better performance, for example, one may use -fpic instead of -fPIC with GNU C/C++ compilers. See MKPIE variable for more information. <Iu>

CFLAGS.ssp, CXXFLAGS.ssp

Options for C and C++ compilers for generating stack protection code. See USE_SSP variable for more information. <Iu>

CFLAGS.warns.<cctype>.<warn-level>, CXXFLAGS.warns.<cxxtype>.<warn-level>

These variables are set by mk-configure and enable warning messages for C or C++ compilers according to their types (CC_TYPE and CXX_TYPE) and warning level (WARNS). <Iu>

CFLAGS_<project>

Similar to CFLAGS but for project ${PROJECTNAME}. <U>

CFLAGS_<source>

Similar to CFLAGS but for the specified source file. Basename of the source file is used. <Mu>

CLEANDIRS_CMD

Command for removing directories used by targets "clean" and "cleandir". <Iu> [${RM} -rf]

CLEANFILES_CMD

Command for removing files used by targets "clean" and "cleandir". <Iu> [${RM} -f]

COPTS

Additional flags to the compiler when creating C objects. <U>

COPTS_<project>

Similar to COPTS but for project ${PROJECTNAME}. <U>

CPP

C Pre-Processor. <Iu> [cpp]

CPPFLAGS

Additional flags to the C/C++ pre-processor. <Iu>

CPPFLAGS0

The same as CPPFLAGS but CPPFLAGS0 is passed to the compiler before CPPFLAGS. Normally, CPPFLAGS0 should be modified in makefiles and should not be set from environment by user. <M>

CPPFLAGS_<project>

Similar to CPPFLAGS but for project ${PROJECTNAME}. <U>

CPPFLAGS_<source>

Similar to CPPFLAGS but for the specified source file. Basename of the source file is used. <Mu>

CXX

C++ compiler. <Iu> [c++]

CXX_PREFIX

Prefix command for ${CXX}, for example, distcc or ccache. <Iu> []

CXX_TYPE

C++ compiler type. This variable is set by mk-configure and can be overriden by user. It can get the same values as CC_TYPE variable. <Iu>

CXX_VERSION

C++ compiler version. <I>

CXXFLAGS

Additional flags to the compiler when creating C++ objects. <Iu> []

CXXFLAGS0

The same as CXXFLAGS but CXXFLAGS0 is passed to the compiler before CXXFLAGS. Normally, CXXFLAGS0 should be modified in makefiles and should not be set from environment by user. <M>

CXXFLAGS.check

Same as CXXFLAGS but every option is checked whether it is a valid one for C++ compiler. <M> [unset]

CXXFLAGS_<project>

Similar to CXXFLAGS but for project ${PROJECTNAME}. <U>

CXXFLAGS_<source>

Similar to CXXFLAGS but for the specified source file. Basename of the source file is used. <Mu>

CXXOPTS

Additional flags to the compiler when creating C++ objects. <U>

CXXOPTS_<project>

Similar to CXXOPTS but for project ${PROJECTNAME}. <U>

CXXSTD

Add C++ language standard command line option to the compiler and linker. Supported options: c++98, gnu++98 (C++98 with GNU extensions), c++11, gnu++11 (C++11 with GNU extensions), c++14, gnu++14 (C++14 with GNU extensions), c++17, gnu++17 (C++17 with GNU extensions) If compiler is not known for mk-configure or does not support appropriate option, no additional options are applied. <M> []

DATADIR

Target directory for architecture-independent text files. <Iu> [${PREFIX}/share]

DESTDIR

Installation prefix. <U> []

GZIP

gzip copression tool. <Iu> [gzip]

INCSDIR

Target directory for header files. <Iu> [${PREFIX}/include]

INFODIR

Target directory for .info files. <Iu> [${PREFIX}/info]

INSTALL

install(1) command. <Iu> [install or mkc_install]

INSTALL_FLAGS

Flags passed to ${INSTALL} program. <Iu> [-c]

LD

Linker. <Iu> [ld]

LD_TYPE

Linker type. This variable is set by mk-configure and can be overriden by user. It can get the following values:

```
Value        Description
----------------------
aixld        AIX linker
darwinld     Darwin linker (MacOS-X)
gnuld        GNU linker
hpld         HP-UX linker
interixld    Interix linker
scold        SCO linker
sunld        SunOS linker
osf1ld       OSF1 linker (Tru64)
irixld       IRIX linker

```

<Iu>

LEX

Lexical analyzer. <Iu> [lex]

LEXLIB

Object file for lex. <Iu> [-ll]

LFLAGS

Options to ${LEX}. <Iu> []

LIBDIR

Target directory for libraries. <Iu> [${PREFIX}/lib]

LIBEXECDIR

Target directory for system utilities. <Iu> [${PREFIX}/libexec]

LN

ln(1) tool. <Iu> [ln]

LN_S

Tool equivalent to ln -s. <Iu> [${LN} -s]

LORDER

List dependencies for object files. <Iu> [lorder]

LPREFIX

Symbol prefix for ${LEX} (see -P option in lex(1)). <Iu> [yy] <Iu> [yy]

MAKE

bmake(1). [bmake or make on NetBSD]

MAKEDEPEND

makedepend(1) tool. <Iu>

MKC_ERR_MSG

If set, keep an error message. <I M> []

MKC_REQD

Minimal required version of mk-configure. If required version is not found, mkcmake fails. This variable should be set before mkc.init.mk is included, directly or indirectly. <M>

MKC_VERSION

Version of mk-configure. This variable is always set to non-empty value when mkc.*.mk include files are used, so you can use it to initialize mk-c variables in mk.conf. For example:

```
/etc/mk.conf:

   ...

   .ifdef MKC_VERSION

   COPTS?=      -O2 -Werror

   SHRTOUT=    yes

   .endif # MKC_VERSION

```

<I>

MKCOMPILERSETTINGS

At build time mk-configure detects some compilers capabilities and saves them to system-wide mkc_imp.cc_${CC_TYPE}-${CC_VERSION}.mk (for C compiler) and mkc_imp.cxx_${CXX_TYPE}-${CXX_VERSION}.mk (for C++ compiler) files. At run time mk-configure loads these files if necessary. If they are absent, that is, if you use compilers unknown to mk-configure, it exits with error. If order to fix this, you have to run mkc_compiler_setting(1) utility manually. This utility generates similar files in ${HOME}/.mkcmake directory. However, if MKCOMPILERSETTINGS variable is set to yes, mkc_compiler_setting(1) is run automaticlly and mk-configure loads the generated files. <Iu> [no]

MKDEP

mkdep(1) tool. <Iu>

MKDIR

mkdir(1) tool. <Iu> [mkdir]

MKINSTALL

If not "yes", build everything but do not install. This option is useful for e.g. internal libraries. <Mu> [yes]

MKINSTALLDIRS

If "yes", install target directories (target installdirs) before installing files (target install). <Iu> [yes]

MKOBJDIR

If "yes", the target "obj" creates object directories, if "auto", object directories are created automatically. Otherwise object directories are not created. <Iu> [auto]

NM

List symbols from object files. <Iu> [nm]

OBJCOPY

Copy and translate object files. <Iu> [objcopy]

OBJDUMP

Display information from object files. <Iu> [objdump]

OBJTOP

Top-level object directory which defaults to ${.OBJDIR} if ${.MAKE.LEVEL} is 0. <I>

PREFIX

Target directory. <U> [/usr/local]

PROJECTNAME

The name of a project. By default it is set to ${PROG}, ${LIB} or ${.CURDIR:T}. For a top-level project using either mkc.subdir.mk or mkc.subprj.mk it makes sense to set this variable explicitely in project's Makefile. This variable is initialized before including mk.conf, so you can use it to change build options, e.g. during development process.

```
/etc/mk.conf:

   ...

   .ifdef MKC_VERSION

   ...

   .if ${PROJECTNAME} == "foo"

   SHRTOUT=    yes

   PROG.gcc=   /usr/bin/gcc

   CC_TYPE=    gcc

   COPTS=      -O0 -g

   .endif

   .endif # MKC_VERSION

```

<Im>

RANLIB

Generate index to archive. <Iu> [ranlib]

RM

rm(1) tool. <Iu> [rm]

SBINDIR

Target directory for administration utilities. <Iu> [${PREFIX}/sbin]

SHAREDSTATEDIR

Target directory for modifiable architecture-independent data files. <Iu> [${PREFIX}/com]

SHRTOUT

If not "no", output messages about compiling, linking and creating libraries are shortened and formatted. <Iu> [no]

SIZE

List section sizes and total size. <Iu> [size]

SRC_PATHADD

List of directories added to .PATH. <Im> []

SRCTOP

Top-level project's directory which defaults to ${.CURDIR} if ${.MAKE.LEVEL} is 0. If set, "../Makefile.inc" is not included. Also, the following command

mkcmake -C subproject target

will be translated to

cd ${SRCTOP}; mkcmake target-subproject <Iu>

STRIP

Discard symbols from object files. <Iu> [strip]

STRIPFLAG

The flag passed to the install program to cause the binary to be stripped. <Iu>

SYSCONFDIR

Target directory for configuration files. <Iu> [${PREFIX}/etc]

TAR

tar archiver. <Iu> [tar]

TSORT

Topological sort of a directed graph. <Iu> [tsort -q]

UNINSTALL

Command for removing files used by target "uninstall". <Iu> [${RM} -f]

USE_SSP

If "yes", enables stack protection code, which detects stack overflows and aborts the program. This enhances security but imposes some performance penalty. <U>

VARDIR

Target directory for modifiable single-machine data files. <Iu> [${PREFIX}/var]

WARNERR

If "yes", force warnings to be reported as errors. At the moment this is supported for GCC, clang, Intel C/C++ and Sun's C/C++ compilers. <Iu> [yes if WARNS=4, no otherwise ]

WARNS

Crank up warning options; the distinct levels are (the higher the more strict):

```
    WARNS=0

    WARNS=1

    WARNS=2

    WARNS=3

    WARNS=4

```

At the moment WARNS is supported for GCC and HP-UX C/C++ only. WARNS=0 means disabling all warnings if such feature is provided by compiler and mk-configure. <Mu> [0]

YACC

LALR(1) parser generator. <Iu> [yacc]

YFLAGS

Options to ${YACC}. <Iu> []

YHEADER

If defined, add "-d" to YFLAGS, and add dependencies from <file>.y to <file>.h and <file>.c, and add <foo>.h to CLEANFILES.

YPREFIX

If defined, add "-p ${YPREFIX}" to YFLAGS.

ZIP

zip copression tool. <Iu> [zip]

### mkc.files.mk
The include file mkc.files.mk handles the FILES variable and is included from mkc.lib.mk and mkc.prog.mk. List of supported variables:

CLEANDIRDIRS

Additional directories to remove (recursively) for the cleandir target. <I M>

CLEANDIRFILES

Additional files to remove for the cleandir target. <I M>

CLEANDIRS

Additional directories to remove (recursively) for the clean and cleandir targets. <I M>

CLEANFILES

Additional files to remove for the clean and cleandir targets. <I M>

FILES

The list of files to install. <M>

FILESDIR

The location to install the files. <Mu> [${PREFIX}/bin]

FILESDIR_<fn>

The location to install the specific file <fn>. <Mu>

FILESGRP

File group. If bmake is run with root privileges, it defaults to <Mu>

FILESGRP_<fn>

File group of the specific file <fn>. <Mu> ${BINGRP} or to `id -g` otherwise. <Mu>

FILESMODE

File mode. <Mu> [${NONBINMODE}]

FILESMODE_<fn>

File mode of the specific file <fn>. <Mu>

FILESNAME

Optional name to install each file as. <Mu>

FILESNAME_<fn>

Optional name to install <fn> as. <Mu>

FILESOWN

File owner. If bmake is run with root privileges, it defaults to ${BINOWN} or to `id -u` otherwise. <Mu>

FILESOWN_<fn>

File owner of the specific file <fn>. <Mu>

### mkc.prog.mk
The include file mkc.prog.mk handles building program from one or more source files, along with their manual pages. It has a limited number of suffixes. List of supported variables:

DPINCDIRS

See LIBDEPS in section mk.subprj.mk.

DPLDADD

See LIBDEPS in section mk.subprj.mk.

DPLIBDIRS

See LIBDEPS in section mk.subprj.mk.

EXPORT_DYNAMIC

If "yes", add all symbols to the dynamic symbol table, that is make all symbols visible from dynamic objects at run time (e.g. dlopen-ed objects), otherwise only symbols referenced by some object file will be exported. <M> [no]

LDADD

Additional objects. Usually used for libraries. For example, to link with the compatibility and utility libraries, use:

```
    LDADD+=  -lutil -lcompat

```

<U>

LDADD0

The same as LDADD but LDFLAGS0 and LDADD0 are passed to the linker before LDFLAGS and LDADD. <M>

LDADD_<project>

Similar to LDADD but for project ${PROJECTNAME}.

LDFLAGS

Additional linker flags. Often used for specifying library directories.

```
    LDFLAGS+=  -L/opt/company/software/lib

```

<Mu I>

LDFLAGS0

The same as LDFLAGS but LDFLAGS0 and LDADD0 are passed to the linker before LDFLAGS and LDADD. Normally, LDFLAGS0 and LDADD0 should be modified in makefiles and should not be set from environment by user. <M>

LDFLAGS_<project>

Similar to LDFLAGS but for project ${PROJECTNAME}.

MKPIE

If "yes", create Position Independent Executable (PIE), otherwise create a regular executable. <Mu> [no]

MKSHARE

If "no", act as "MKHTML=no MKINFO=no MKCATPAGES=no MKMAN=no". I.e, don't build catman pages, man pages, info documentation,... <Iu> [yes]

PROG

The name of the program to build.

PROGNAME

The name that the above program will be installed as, if different from ${PROG}. <M>

PROGS

The names of the programs to build. If neither PROG nor PROGS is not supplied, nothing is built. <M>

SRCS

List of source files to build the program. If SRCS is not

defined, it's assumed to be ${PROG}.c. <M>

SRCS.<prog>

List of source files to build the program prog listed in PROGS. If SRCS.<prog> is not defined, it's assumed to be prog.c. <M>

USE_RELRO

If "yes", enables a technique to harden the data sections of an ELF binary/process. For security reasons it makes sense to set it to YES, it may slow down application startup, though. <Iu> [no]

mkc.prog.mk includes mkc.files.mk and therefore supports all variables supported by it.

The order of options passed to the C compiler: CPPFLAGS0, CPPFLAGS, CPPFLAGS_<project>, CFLAGS.ssp, CFLAGS.pie, CFLAGS.warns, CFLAGS, CFLAGS_<project>, CFLAGS.pic (for shared objects), COPTS, COPTS_<project>

The order of options passed to the C++ compiler: CPPFLAGS0, CPPFLAGS, CPPFLAGS_<project>, CXXFLAGS.ssp, CXXFLAGS.pie, CXXFLAGS.warns, CXXFLAGS, CXXFLAGS_<project>, CXXFLAGS.pic (for shared objects), COPTS, COPTS_<project>

### mkc.lib.mk
The include file mkc.lib.mk has support for building a static and dynanic library or DLL. mkc.lib.mk uses the following variables:

DPINCDIRS

See LIBDEPS in section mk.subprj.mk.

DPLDADD

See LIBDEPS in section mk.subprj.mk.

DPLIBDIRS

See LIBDEPS in section mk.subprj.mk.

EXPORT_SYMBOLS

Only symbols listed in a specified file (one symbol per line) are exported. Empty lines and comments started with # symbol are ignored. This variable has no effect on some platforms. By default all symbols are exported. <M> []

LDADD LDADD_<project>

Additional objects. See mkc.prog.mk

LDFLAGS LDFLAGS_<project>

Additional linker flags. See mkc.prog.mk

LIB

The name of the library to build. <M>

LIBDIR

See Common variables and mkc.files.mk sections.

LIBGRP

Library group. If bmake is run by an unprivileged user, it defaults to `id -g`. <Iu>

LIBMODE

Library mode. <Iu> [${NONBINMODE}]

LIBOWN

Library owner. If bmake is run by an unprivileged user, it defaults to `id -u`. <Iu>

MAN

The manual pages to be installed (use a .1 - .9 suffix). <M>

MKDLL

If "yes", build and install the dynamically loaded library (<lib>.so) instead of shared library. If "only", do not make static library. <M> [no]

MKSHLIB

If not "no", build and install shared library provided that SHLIB_MAJOR is defined. <IMu> [yes] (for MACHINE_ARCHs that support it)

MKSTATICLIB

If not "no", build and install static library. <IMu> [yes]

MKPICLIB

If not "no", build and install *_pic.a library. <IMu> [no]

MKPROFILELIB

If "no", don't build or install the profiling (*_p.a) libraries. <Iu> [no]

SHLIBMODE

Shared library mode. <Iu>

SHLIB_MAJOR

Major shared library number. If unset, shared library is not built. <M>

SHLIB_MINOR

Minor shared library number. <M> [0]

SHLIB_TEENY

Minor shared library number. <M> []

SRCS

List of source files to build the library. Suffix types

.s, .c, and .f are supported. Note, .s files are preferred

to .c files of the same name. <M>

Static libraries are ranlib'd when made. mkc.lib.mk includes mkc.files.mk and therefore supports all its variables as well. After creaion of libraries ${.CURDIR:T}.done file is created and used for handling inter-project (See LIBDEPS variable) dependencies.

The order of options passed to the C and C++ compilers are the same as in mkc.prog.mk.

### mkc.subprj.mk
The include file mkc.subprj.mk handles subprojects (subdirectories) organized as a dependency graph. It provides all targets provided by mkc.prog.mk. Variable SUBPRJ contains a list of pairs depdir:dir which mean that subproject dir depends on depdir. mkcmake all command will build all subprojects listed in SUBPRJ in a correct order (starting with subprojects having no dependencies and so on). There is also a target which allows the command bmake <subdir> where <subdir> is any directory listed in the variable SUBPRJ. The following targets are also provided: <target>-<subdir> where <target> is either of the following: all, clean, cleandir, depend, installdirs, install, uninstall and filelist. Also provided are: targets nodeps-<target>-<subdir> and subdir-<target>-<subdir>. Difference between <target>-<subdir> and nodeps-<target>-<subdir> is that mkcmake <target>-<subdir> runs the specified <target> for <subdir> and all its dependencies while mkcmake nodeps-<target>-<subdir> -- only for <subdir>. A target subdir-<target>-<subdir> is a synonym for nodeps-<target>-<subdir> See examples/hello_dictd subdirectory for the sample of use.

mkc.subprj.mk provides the following variables:

ALLTARGETS

A list of targets for which pre_*, do_* and post_* counterparts exist, for example, pre_all, do_all and post_all. pre_* target runs before do_* target which in turn runs before post_*. Unless action is provided for do_* targets they implement the standard behaviour of mk-configure. No action is provided for targets pre_* and post_*, so they are for user's extensions. The standard behaviour for ${ALLTARGETS} may also be extended by adding new prerequisites to targets do_*.

COMPATLIB

Subproject's basename for compatibility library. If this variable is set, MKC_SOURCE_FUNCLIBS and FEATURES do not change SRCS for subprojects other than ${COMPATLIB}. <M> []

EXPORT_VARNAMES

List of variables to export before running make for subdirectories. <Mu> [MKC_CACHEDIRSRCTOPOBJTOPSTATICLIBSCOMPATLIB]

INTERNALLIBS

A list of subprojects (basenames) with internal libraries. These libraries are static and not installed by target "install". <M> []

LIBDEPS

A list of library dependencies. Each token is a colon-separated pair. Its first component is a library subproject (dependency), the second one is the subproject for library or executable. The value of this variable is automatically added to SUBPRJ. Library dependencies listed in LIBDEPS automatically change CPPFLAGS0, LDFLAGS0 and LDADD0 of approptiate subprojects. <M> Suppose, we have <library:program> pair in LIBDEPS, also suppose that variable library is set to "library" subdirectory and variable program is set to "program" subdirectory. ${SRCDIR_library}/linkme.mk file is automatically included from ${SRCDIR_program}/Makefile if it exists. In this file DPLDADD [${library:T:S/^lib//}], DPLIBDIRS [${OBJDIR_${library:S,/,_,g}}] and DPINCDIRS [${SRCDIR_${library:S,/,_,g}} ${OBJDIR_${library:S,/,_,g}}], may be set to non-default values. These three variables then changes LDADD0, LDFLAGS0 and CPPFLAGS0 respectively in subproject "program". The dependency graph specified by variable LIBDEPS is available to all subproject via environment.

MKRELOBJDIR

If "yes", object directories ${OBJTOP}/dir are used. Unlike MAKEOBJDIRPREFIX object directories do not contain top-level ${.CURDIR} in paths. <Iu> [no]

NODEPS

This variable specifies a list of patterns that describes edges from dependency graph in targdep-prjdep:targ-prj or targ-prj:targ formats to be excluded from dependency graph. <M> []

NOEXPORT_VARNAMES

List of variables excluded from EXPORT_VARNAMES. <Mu> []

NOSUBDIR

If for some reason you want to exclude some subdirectories from build, list them in this variable. <U> []

OBJDIR_<dir>

Value of ${.OBJDIR} inside dir subdirectory. Slash symbols inside <dir> are replaced with underlines. In addition, OBJDIR_<dir:T> variable is set to ${OBJDIR_<dir>} if ${SHORTPRJNAME} is "yes".

SHORTPRJNAME

If "yes", special targets with last component of the subprojects are provided. <Im> [yes]

SRCDIR_<dir>

Value of ${.CURDIR} inside dir subdirectory. Slash symbols inside <dir> are replaced with underlines. In addition, SRCDIR_<dir:T> variable is set to ${SRCDIR_<dir>} if ${SHORTPRJNAME} is "yes".

STATICLIBS

A list of subprojects (basenames) with static libraries. If dependency is mentioned in this variable, the suffix _pic is automatically added for PIE-executables or shared libraries that depend on this library. This variable is automatically passed to subprojects via environment. <Mu> []

SUBPRJ

List of subprojects (subdirectories) and dependencies. If the subdirectory doesn't exist the subproject becomes "virtual" and may be used to group several subprojects into a new virtual one. <M>

SUBPRJ_DFLT

List of projects built and installed by default. The default is all projects listed in SUBPRJ. <IMu>

SUBPRJSRCTOP

This variables contains ${.CURDIR} directory and is passed to subprojects. <I> [${.CURDIR}]

TARGETS

A list of recursive targets. "Recursive" means that the target will be called for all subproject recursively (See mkc.subprj.mk and mkc.subdir.mk). <Im> [all, install, installdirs, uninstall, clean, cleandir, depends, test, configure, filelist, obj] By setting this variable in the Makefile one can add new targets for special purposes, for example, static code analysis, partial builds etc.

mkc.subprj.mk provides the following targets:

<subdir> and <subdir:T>

<subdir> is a subdirectory listed in SUBDIR or SUBPRJ. This target is equivalent to all-<subdir>. <subdir:T> means the last component of the directory and is created if ${SHORTPRJNAME} is "yes".

<target>-<subdir>

Runs the specified <target> for the specified <subdir>. The target <target>-<subdir:T> is provided if ${SHORTPRJNAME} is "yes".

subdir-<target>-<subdir> and nodeps-<target>-<subdir>

Runs the specified <target> for the specified <subdir> without dependencies. Targets subdir-<target>-<subdir:T> and nodeps-<target>-<subdir:T> are provided if ${SHORTPRJNAME} is "yes".

print_deps

Outputs the dependency graph on targets in tsort(1) format taking NODEPS and NOSUBDIR variables into account.

### mkc.subdir.mk
The include file mkc.subdir.mk contains the default targets for building subdirectories. It provides the same targets as mkc.prog.mk. For all of the directories listed in the variable SUBDIR, the specified directory will be visited and the target made. There is also a default target which allows the command bmake <subdir> where <subdir>

is any directory listed in the variable SUBDIR. As a special case, the use of a token .WAIT as an entry in SUBDIR acts as a synchronization barrier when multiple make jobs are run; subdirs before the .WAIT must complete before any subdirs after .WAIT are started. See bmake(1) for some caveats on use of .WAIT and other special sources. SUBDIR variable is provided as well as all variables provided by mkc.subprj.mk except SUBPRJ.

SUBDIR

List of subdirectories <M> mkc.subprj.mk

### mkc.configure.mk
mkc.configure.mk is an auxiliary include file for checking platform's features like headers, function or variable declarations, function implementation in a particular libraries, data types sizes etc. This include file is included by mkc.prog.mk and mkc.lib.mk automatically but in some cases it makes sense to include it explicitly. mkc.configure.mk itself includes mkc.init.mk, then mkc.conf.mk , and finally internal include file which updates CPPFLAGS, CFLAGS, LDADD and SRCS. mkc.configure.mk supports the following variables.

MKCHECKS

If "no", none of the checks are performed. It is set to "yes" unless target is "clean" and "cleandir".

MKC_CACHEDIR

Directory where intermediate and cache files are created. It defaults to ${.OBJDIR}. By default MKC_CACHEDIR variable is exported for subprojects. As a result cache files for subprojects are created in the top-level directory. If cache directory doesn't exist, it is created automatically.

MKC_CHECK_BUILTINS

mk-configure provides a number of built-in custom checks, that is, source files to compile or scripts to run in order to check for something. Checks listed in MKC_CHECK_BUILTINS will be run.

Avalable values: prog_flex, prog_bison, prog_gawk, prog_gm4, prog_gmake

Find flex, bison, GNU awk, GNU m4 or GNU make respectively by analysing program's help and/or version messages. If found, BUILTIN.prog_<progname> is set to the path, otherwise it is set to empty string. Note that gawk may be found as awk, bison as yacc, gm4 as m4, flex as lex and gmake as make.

prog_mkdep, prog_nbmkdep

Find traditional BSD mkdep(1) or recent NetBSD version of it respectively.

endianness

BUILTIN.endianness variable is set to either little, big or unknown depending on a hardware.

MKC_CHECK_CC_OPTS

A list of C compiler options to check. If ${CC} -c support the specified option, variable HAVE_CC_OPT.<option:S/=/_/g> is set to 1 and 0 otherwise. Double underline in the option is considered as a single space character.

```
Ex.

  MKC_CHECK_CC_OPTS = -Wall -errwarn=%all --param__ssp-buffer-size=1
Res.

 HAVE_CC_OPT.-Wall=1

 HAVE_CC_OPT.-errwarn_%all=0

 HAVE_CC_OPT.--param__ssp-buffer-size_1=1

```

MKC_CHECK_CCLD_OPTS

Same as MKC_CHECK_CC_OPTS except that option "-c" is not passed to the compiler, so, executable is created. As a result HAVE_CCLD_OPT.<option:S/=/_/g> is set to 1 or 0.

MKC_CHECK_CUSTOM

A list of custom checks (list of names). MKC_CUSTOM_FN.<custom_check_name> is a "C" or "C++" source filename or an executable program for your custom check, e.g., filename.c, filename.cc, subdir/filename.cxx, filename.C, filename.cpp or subdir/executable_script. mk-configure tries to compile or run the specified file and sets CUSTOM.<custom_check_name> variable to 1, 0 or other value. If MKC_CUSTOM_FN.<custom_check_name> is unset, it defaults to custom_check_name.c. Also -DCUSTOM_<CUSTOM_CHECK_NAME>=1 is added to CPPFLAGS if the specified check succeeded unless MKC_NOAUTO is set to 1 and MKC_CUSTOM_NOAUTO.<custom_check_name> is set to "yes". Here <CUSTOM_CHECK_NAME> is uppercase for <custom_check_name>. If MKC_CUSTOM_LINK.<custom_check_name> is "yes", then C or C++ source file is compiled and linked into executable. Also, CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS, LDADD, MKC_CUSTOM_CPPFLAGS.<custom_check_name>, MKC_CUSTOM_CFLAGS.<custom_check_name>, MKC_CUSTOM_CXXFLAGS.<custom_check_name>, MKC_CUSTOM_LDFLAGS.<custom_check_name> and MKC_CUSTOM_LDADD.<custom_check_name> flags are passed to the compiler. Normally cache file name contains <custom_check_name> unless MKC_CUSTOM_CACHE.<custom_check_name> is set to something else.

```
 Ex.  MKC_CHECK_CUSTOM+=               nested_funcs

      MKC_CUSTOM_FN.nested_funcs=      nested_funcs.c

      MKC_CUSTOM_FN.script_check=      checks/script_check

 Res. CUSTOM.nested_funcs=        1

      CUSTOM.script_check=        0

      CFLAGS+= -DCUSTOM_NESTED_FUNCS=1

```

Note that script for the check should be an executable file.

MKC_CHECK_CXX_OPTS

Same as MKC_CHECK_CC_OPTS but for C++ compiler. As a result HAVE_CXX_OPT.<option:S/=/_/g> is set to 1 or 0.

MKC_CHECK_CXXLD_OPTS

Same as MKC_CHECK_CCLD_OPTS but for C++ compiler. As a result HAVE_CXXLD_OPT.<option:S/=/_/g> is set to 1 or 0.

MKC_CHECK_DEFINES

List of define:header to check. <header> part is optional. As a result of the check bmake's variable HAVE_DEFINE.<define>.<header> (or HAVE_DEFINE.<define>) is set to either 0 or 1.

<header>: tr|./|__|g

Also -DHAVE_DEFINE_<DEFINE>_<HEADER>=1 or -DHAVE_DEFINE_<DEFINE>=1 is added to CPPFLAGS if the specified define was detected unless MKC_NOAUTO is set to 1.

<HEADER>: tr|a-z./|A-Z__|g

<DEFINE>: tr|a-z|A-Z|g

```
 Ex:  MKC_CHECK_DEFINES += RTLD_LAZY:dlfcn.h __GNUC__ _MSC_VER_

 Res: HAVE_DEFINE.RTLD_LAZY.dlfcn_h = 1

      HAVE_DEFINE.__GNUC__          = 1

      HAVE_DEFINE._MSC_VER_         = 0

      CFLAGS += -DHAVE_DEFINE_RTLD_LAZY_DLFCN_H=1 \

                -DHAVE_DEFINE___GNUC__=1

```

MKC_CHECK_FUNCLIBS

List of <function>:<library> pairs to check, <library> part is optional. If <library> is present, presense of <function> in libc is also checked automatically. As a result of the check bmake's variable HAVE_FUNCLIB.<function>.<library> (or HAVE_FUNCLIB.<function>) is set to either 0 or 1.

If <function> is found in <library> but not in libc or <function> is "main" and is found in <library>, "-l<library>" is automatically added to LDADD unless <function>:<library> is listed in MKC_NOAUTO_FUNCLIBS or MKC_NOAUTO_FUNCLIBS is equal to 1 or MKC_NOAUTO is set to 1

```
 Ex:  MKC_CHECK_FUNCLIBS  += strlcat fgetln getline getopt_long

      MKC_CHECK_FUNCLIBS  += crypt:crypt dlopen:dl nanosleep:rt

      MKC_CHECK_FUNCLIBS  += ftime:compat gettimeofday

      MKC_NOAUTO_FUNCLIBS += ftime:compat

 Res: HAVE_FUNCLIB.strlcat      = 1

      HAVE_FUNCLIB.fgetln       = 1

      HAVE_FUNCLIB.getline      = 0

      HAVE_FUNCLIB.getopt_long  = 1

      HAVE_FUNCLIB.crypt        = 0

      HAVE_FUNCLIB.crypt.crypt  = 1

      HAVE_FUNCLIB.dlopen       = 1

      HAVE_FUNCLIB.dlopen.dl    = 0

      HAVE_FUNCLIB.nanosleep    = 1

      HAVE_FUNCLIB.nanosleep.rt = 1

      HAVE_FUNCLIB.ftime        = 0

      HAVE_FUNCLIB.ftime.compat = 1

      HAVE_FUNCLIB.gettimeofday = 1

      LDADD += -lcrypt

```

MKC_CHECK_FUNCS<N>

List of <func>:<header> to check. <header> part is optional. Here <N> means the number of arguments. As a result of the check bmake's variable HAVE_FUNC<N>.<func>.<header> (or HAVE_FUNC<N>.<func>) is set to either 0 or 1.

<header>: tr|./|__|g

Also -DHAVE_FUNC<N>_<FUNC>_<HEADER>=(0 or 1) (or -DHAVE_FUNC<N>_<FUNC>=(0 or 1)) is added to CPPFLAGS if the specified function was detected unless MKC_NOAUTO is set to 1. If MKC_FUNC_OR_DEFINE.<func> is "yes", equivalent define leads to the same results.

<HEADER>: tr|a-z./|A-Z__|g

```
 Ex:  MKC_CHECK_FUNCS2 += fgetln:stdio.h

      MKC_CHECK_FUNCS6 += pselect:sys/select.h

      MKC_CHECK_FUNCS1 += htobe32:sys/endian.h

      MKC_FUNC_OR_DEFINE.htobe32 += yes

 Res: HAVE_FUNC2.fgetln.stdio_h = 1

      HAVE_FUNC6.pselect.sys_select_h = 1

      HAVE_FUNC1.htobe32.sys_endian_h=1

      CFLAGS += -DHAVE_FUNC2_FGETLN_STDIO_H=1 \

             += -DHAVE_FUNC6_PSELECT_SYS_SELECT_H=1 \
	     += -DHAVE_FUNC1_HTOBE32_SYS_ENDIAN_H

```

MKC_CHECK_HEADER_FILES

Same as MKC_CHECK_HEADERS but $CC -E is used for checking instead of $CC -c. Also, HAVE_HEADER_FILE.<header> variables and HAVE_HEADER_FILE<HEADER> defines are set.

MKC_CHECK_HEADERS

List of headers to check with the help of $CC -c. As a result of the check bmake's variable HAVE_HEADER.<header> is set to either 0 or 1.

<header>: tr|./|__|g

Also -DHAVE_HEADER_<HEADER>=(0 or 1) is added to CPPFLAGS unless MKC_NOAUTO is set to 1.

<HEADER>: tr|a-z./|A-Z__|g

```
 Ex:  MKC_CHECK_HEADERS += sys/time.h fcntl.h execinfo.h

 Res: HAVE_HEADER.sys_time_h = 1

      HAVE_HEADER.fcntl_h    = 1

      HAVE_HEADER.execinfo_h = 1

      CFLAGS += -DHAVE_HEADER_SYS_TIME_H=1 -DHAVE_HEADER_FCNTL=1

```

MKC_CHECK_MEMBERS

List of <type>.<member>:<header> to check. <header> part is optional. As a result of the check bmake's variable HAVE_MEMBER.<type>_<member>.<header> (or HAVE_MEMBER.<type>_<member>) is set to either 0 or 1 depending on the result.

<header>: tr|./|__|g

Also -DHAVE_MEMBER_<TYPE>_<MEMBER>_<HEADER>=1 (or -DHAVE_MEMBER_<TYPE>_<MEMBER>=1) is added to CPPFLAGS if the specified member was found in appropriate type unless MKC_NOAUTO is set to 1.

<HEADER>: tr|a-z./|A-Z__|g

<TYPE>: tr|a-z./|A-Z__|g

<MEMBER>: tr|a-z./|A-Z__|g

```
   Ex:  MKC_CHECK_VARS += struct-ifreq.ifr_ifrn.ifrn_name:net/if.h

        MKC_CHECK_VARS += struct-tm.tm_isdst:time.h

   Res: HAVE_MEMBER.struct_ifreq_ifr_ifrn_ifrn_name.net_if_h=1

        HAVE_MEMBER.struct_tm_tm_isdst.time_h=1

        CFLAGS += -DHAVE_MEMBER_STRUCT_IFREQ_IFR_IFRN_IFRN_NAME_NET_IF_H=1

        CFLAGS += -DHAVE_MEMBER_STRUCT_TM_TM_ISDST_TIME_H=1

```

MKC_CHECK_PROGS

List of <progname>s to check. As a result of the check bmake's variable HAVE_PROG.<progname> is set to either 1 (true) or 0 (false). Also PROG.<progname> is set to a full path of a program or to an empty string.

```
 Ex:  MKC_CHECK_PROGS += lua ruby gawk runawk

 Res: HAVE_PROG.lua             = 1

      PROG.lua                  = /usr/pkg/bin/lua

      HAVE_PROG.ruby            = 0

      HAVE_PROG.gawk            = 1

      PROG.gawk                 = /usr/bin/gawk

      HAVE_PROG.runawk          = 1

      PROG.runawk               = /usr/pkg/bin/runawk

```

If MKC_PROG.id.<progname> is set to, e.g, <prog_id>, then HAVE_PROG.<prog_id> and PROG.<prog_id> are set. MKC_PROG.id.<progname> also changes cache file names.

MKC_CHECK_PROTOTYPES

A list of checks (list of names) for C function prototypes. MKC_PROTOTYPE_FUNC.<name> is a C function prototype. MKC_PROTOTYPE_HEADERS.<name> is a list of headers separated by space or comma. mk-configure verifies that the specified prototype is correct and if so, HAVE_PROTOTYPE.<name> bmake variable is set to 1 and -DHAVE_PROTOTYPE_<NAME>=1 is added to CPPFLAGS unless MKC_NOAUTO is set to 1. Otherwise, HAVE_PROTOTYPE.<name> variable is set to 0.

```
Ex.

  MKC_CHECK_PROTOTYPES = posix_iconv const_iconv

  MKC_PROTOTYPE_FUNC.posix_iconv =

    size_t iconv(iconv_t,char**,size_t*,char**,size_t*)

  MKC_PROTOTYPE_FUNC.const_iconv =

    size_t iconv(iconv_t,const char**,size_t*,char**,size_t*)

  MKC_PROTOTYPE_HEADERS.posix_iconv = iconv.h

  MKC_PROTOTYPE_HEADERS.const_iconv = iconv.h
Res.

 HAVE_PROTOTYPE.posix_iconv=0

 HAVE_PROTOTYPE.const_iconv=1

 CFLAGS += -DHAVE_PROTOTYPE_CONST_ICONV=1

```

MKC_CHECK_SIZEOF

List of <type>:<header> to check. <header> part is optional. As a result of the check bmake's variable SIZEOF.<type>.<header> (or SIZEOF.<type>) is set to the data type size or string "failed".

<type>: tr|*-|P_|g

<header>: tr|/.|__|g

Also -DSIZEOF_<TYPE>_<HEADER>=<failed|1|2|...> (or -DSIZEOF_<TYPE>=<failed|1|2|...>) is added to CPPFLAGS if sizeof() check was successful unless MKC_NOAUTO is set to 1

<TYPE>: tr|a-z*-|A-ZP_|g

<HEADER>: tr|a-z/.|A-Z__|g

```
 Ex:  MKC_CHECK_SIZEOF += void*

      MKC_CHECK_SIZEOF += long-long off_t:sys/types.h

 Res: SIZEOF.voidP             = 4

      SIZEOF.long_long         = 4

      SIZEOF.off_t.sys_types_h = 8

      CFLAGS += -DSIZEOF_VOIDP=4 \

                -DSIZEOF_LONG_LONG=4 \

                -DSIZEOF_OFF_T_SYS_TYPES_H=8

```

MKC_CHECK_TYPES

List of type:header to check. <header> part is optional. As a result of the check bmake's variable HAVE_TYPE.<type>.<header> (or HAVE_TYPE.<type>) is set to either 0 or 1.

<header>: tr|./|__|g

Also -DHAVE_TYPE_<TYPE>_<HEADER>=1 (or -DHAVE_TYPE_<TYPE>=1) is added to CPPFLAGS if the specified type was detected unless MKC_NOAUTO is set to 1.

<HEADER>: tr|a-z./|A-Z__|g

<TYPE>: tr|a-z|A-Z|g

```
 Ex:  MKC_CHECK_TYPES += size_t:string.h

 Res: HAVE_TYPE.size_t.string_h = 1

      CFLAGS += -DHAVE_TYPE_SIZE_T_STRING_H=1

```

MKC_CHECK_VARS

List of variable:header to check. <header> part is optional. As a result of the check bmake's variable HAVE_DEFINE.<variable>.<header> (or HAVE_DEFINE.<variable>) is set to either 0 or 1

<header>: tr|./|__|g

Also -DHAVE_DEFINE_<VARIABLE>_<HEADER>=1 (or -DHAVE_DEFINE_<VARIABLE>=1) is added to CPPFLAGS if the specified variable was detected unless MKC_NOAUTO is set to 1.

<HEADER>: tr|a-z./|A-Z__|g

```
 Ex:  MKC_CHECK_VARS += sys_errlist:errno.h

 Res: HAVE_VAR.sys_errlist.errno_h = 1

      CFLAGS += -DHAVE_VAR_SYS_ERRLIST_ERRNO_H

```

MKC_COMMON_DEFINES

List of defines always passed to compiler in MKC_CHECK_{DEFINES,VARS,FUNCS<N>,SIZEOF} checks.

```
   Ex: MKC_COMMON_DEFINES += -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 # Linux

       MKC_COMMON_DEFINES += -D_ALL_SOURCE # Interix

```

MKC_COMMON_DEFINES.<OPSYS>

The same as MKC_COMMON_DEFINES but only for OPSYS (uname -s).

```
   Ex: MKC_COMMON_DEFINES.Linux   += -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64

       MKC_COMMON_DEFINES.Interix += -D_ALL_SOURCE

```

MKC_COMMON_HEADERS

List of header files always #include'd to the test .c file in MKC_CHECK_{DEFINES,VARS,FUNCS<N>,SIZEOF} checks. The default value is an empty list.

```
  Ex: MKC_COMMON_HEADERS += unistd.h stdlib stdio.h string.h

      MKC_CHECK_SIZEOF   += offs_t size_t ssize_t

```

MKC_CUSTOM_DIR

Directory with custom checks source files. See MKC_CHECK_CUSTOM. It defaults to ${.CURDIR}.

MKC_DELETE_TMPFILES

If set to 1, temporary files are removed.

MKC_FEATURES

This is a list of "features" required by project. In general, a feature is something that has problems with portability. This may be a function name or header missing on some platforms, for example. What developer needs to do is to add FEATURENAME to MKC_FEATURES variable and add #include <mkc_FEATURENAME.h> where it is needed. Internally, system requiremets are checked in the automatically included mkc_imp.f_FEATURENAME.mk file and all required actions (includes, define checks etc.) are made in mkc_FEATURENAME.h header file. Currently the following features are provided:

arc4random

This feature provides arc4random(3), arc4random_buf(3) and arc4random_uniform(3) functions available in BSDs. If these functions are absent on your system, install libbsd library.

bswap

This feature provides bswap16(3), bswap32(3) and bswap64(3) functions available in *BSD.

dprintf

This feature provides dprintf(3).

efun

This feature provides esetfunc(3), efopen(3), ecalloc(3), emalloc(3), erealloc(3), ereallocarr(3), estrdup(3), estrndup(3), estrlcpy(3), estrlcat(3), easprintf(3), estrtoi(3), estrtou(3) and evasprintf(3) functions from NetBSD.

err

This feature provides err(3), errx(3), verr(3) and verrx(3) BSD-isms.

errc

This feature provides errc(3) and verrc(3) BSD-isms.

fgetln

This feature provides fgetln(3) BSD-ism.

fparseln

This feature provides fparseln(3) BSD-ism.

fts

This feature provides fts_open(3), fts_read(3) etc. functions available on BSDs and Linux. If it is absent on your system, you have to install libfts (both headers and library). libfts is a part of musl project.

getdelim

This feature provides getdelim(3) from POSIX.

getline

This feature corresponds to getline(3) function which is a part of POSIX2008 unavailable on some systems. mkc_imp.f_getline.mk checks whether getline declaration is available in stdio.h and implementation is available in libc. If not, getline.c provided by mk-configure is added to SRCS and declaration is provided in mkc_getline.h header.

humanize_number

This feature provides humanize_number(3) function from NetBSD.

libdl

This feature checks whether libdl library is available and dlopen(3) is declared in dlfcn.h. If yes, -ldl is added to LDADD. mkc_libdl.h provides declarations for dlopen(3), dlsym(3), dlclose(3) etc.

libl

Adds -ll or -lfl to LDADD depending on which one is available. One can use this feature instead of LIBLEX variable.

libm

This feature checks whether libm is available and if yes, adds -lm to LDADD. Most UNIX-like systems have libm but Haiku, for example, does not. mkc_imp.f_libm.mk checks whether libm library is available and if yes, -lm is added to LDADD.

macro

This feature provides the following macro stolen from NetBSD. __aligned(x) defined as __attribute__((aligned(x))) if supported by compiler, __always_inline defined as __attribute__((always_inline)) if supported by compiler, __arraycount(a) defined as (sizeof(__a)/sizeof(__a[0])) , __constfunc defined as __attribute__((const)) if supported by compiler, __dead defined as __attribute__((noreturn)) if supported by compiler, MIN(a,b) and MAX(a,b), __pure defined as __attribute__((pure)) if supported by compiler, __printflike(n,m) defined as __attribute__((format (printf, n, m))) if supported by compiler.

posix_getopt

It is well-known that glibc getopt(3) does not conform to POSIX by default. This feature provides POSIX-ly correct getopt.

progname

This feature provides getprogname(3) and setprogname(3) functions available in *BSD.

pwdgrp

This feature provides user_from_uid(3), uid_from_user(3), group_from_gid(3), gid_from_group(3) functions from *BSD.

raise_default_signal

This feature provides function raise_default_signal(3) from NetBSD.

RB SPLAY

BSD systems provide sys/tree.h header where RB_* and SPLAY_* macroses are defined for red-black tree and splay. These features check whether sys/tree.h and appropriate macroses are available. If yes, mkc_RB.h and mkc_SPLAY.h include system-wide sys/tree.h, otherwise NetBSD version of sys/tree.h provided by mk-configure is included.

reallocarr

This feature provides reallocarr(3) function from NetBSD.

reallocarray

This feature provides reallocarray(3) function from OpenBSD.

shquote

This feature provides shquote(3) function from NetBSD.

SLIST SIMPLEQ STAILQ LIST TAILQ CIRCLEQ

BSD systems provide sys/queue.h header where SLIST_* etc. macroses are defined for lists and queues. These features check whether sys/queue.h and appropriate macroses are available. If yes, mkc_SLIST.h and others include system-wide sys/queue.h, otherwise NetBSD version of sys/queue.h provided by mk-configure is included.

strlcat

This feature corresponds to strlcat(3) function available on almost all systems except glibc-based Linux-es. mkc_imp.f_strlcat.mk checks whether strlcat declaration is available in string.h and implementation is available in libc. If not, strlcat.c provided by mk-configure is added to SRCS and declaration is provided in mkc_strlcat.h header.

strlcpy

Similar to strlcat.

strndup

This feature provides strndup(3) from POSIX.

strsep

This features provides strsep(3) and stresep(3) functions.

strtoi

This feature provides strtoi(3) function introduced in NetBSD.

strtou

This feature provides strtoi(3) function introduced in NetBSD.

vis

This feature provides vis(3), nvis(3), svis(3), snvis(3), strvis(3), strnvis(3), strsvis(3), strsnvis(3), strvisx(3), strnvisx(3), strenvisx(3), strsvisx(3), strsnvisx(3), strsenvisx(3), strunvis(3), strnunvis(3), strunvisx(3), strnunvisx(3) and unvis(3) from NetBSD.

warn

This feature provides warn(3), warnx(3), vwarn(3) and vwarnx(3) BSD-isms.

MKC_NOAUTO

See MKC_CHECK_{HEADERS,FUNCLIBS,FUNCS,VARS,DEFINES,SIZEOF}.

MKC_NOAUTO_FUNCLIBS

See MKC_CHECK_FUNCLIBS

MKC_NOCACHE

All results are cached unless MKC_NOCACHE variable is set non-empty value

MKC_REQUIRE_BUILTINS

The same as MKC_CHECK_BUILTINS, but failure is treated as a fatal error (See configure target).

MKC_REQUIRE_CUSTOM

The same as MKC_CHECK_CUSTOM, but failure is treated as a fatal error (See configure target). 0 and empty value of CUSTOM.xxx means failure.

MKC_REQUIRE_DEFINES

The same as MKC_CHECK_DEFINES, but absense of the define is treated as a fatal error (See configure target).

MKC_REQUIRE_FUNCLIBS

The same as MKC_CHECK_FUNCLIBS, but absense of funclib is treated as a fatal error (See configure target).

MKC_REQUIRE_FUNCS<N>

The same as MKC_CHECK_FUNCS<N>, but absense of the function declaration is treated as a fatal error (See configure target).

MKC_REQUIRE_HEADER_FILES

The same as MKC_CHECK_HEADER_FILES, but absense of header is treated as a fatal error (See configure target).

MKC_REQUIRE_HEADERS

The same as MKC_CHECK_HEADERS, but absense of header is treated as a fatal error (See configure target).

MKC_REQUIRE_MEMBERS

The same as MKC_CHECK_MEMBERS, but absense of the member is treated as a fatal error (See configure target).

MKC_REQUIRE_PROGS

The same as MKC_CHECK_PROGS, but absense of program is treated as a fatal error (See configure target).

MKC_REQUIRE_PROTOTYPES

The same as MKC_CHECK_PROTOTYPES, but incorrect prototype is treated as a fatal error (See configure target).

MKC_REQUIRE_TYPES

The same as MKC_CHECK_TYPES, but absense of the type declaration is treated as a fatal error (See configure target).

MKC_REQUIRE_VARS

The same as MKC_CHECK_VARS, but absense of the variable declaration is treated as a fatal error (See configure target).

MKC_SHOW_CACHED

Setting it to 0 will hide

```
   Checking ... (cached) ...

```

messages, that is, messages about fetching results from cache files.

MKC_SOURCE_DIR, MKC_SOURCE_DIR.<source>

Directory with sources for MKC_SOURCE_FUNCLIBS. If MKC_SOURCE_DIR.<source> is unset, MKC_SOURCE_DIR is used that defaults to ${.CURDIR}.

```
 Ex:  MKC_SOURCE_FUNCLIBS += getline

      MKC_SOURCE_DIR.getline.c = ${.CURDIR}/../missing

 Res: SRCS+= ${.CURDIR}/../missing/getline.c

      HAVE_FUNCLIB.getline= 0

```

MKC_SOURCE_FUNCLIBS

The same as MKC_CHECK_FUNCLIBS, but if <function> is absent both in the specified <library> and in libc, function.c is added to SRCS unless MKC_NOAUTO=1.

```
 Ex:  MKC_SOURCE_FUNCLIBS+= getline

 Res: SRCS+= getline.c

      HAVE_FUNCLIB.getline= 0

```

### mkc.conf.mk
The same as mkc.configure.mk but mkc.init.mk is not included by mkc.conf.mk in the beginning, and CFLAGS, CPPFLAGS, LDADD and SRCS varibales are not modified. Instead, internal variables MKC_CFLAGS, MKC_CPPFLAGS, MKC_LDADD and MKC_SRCS contain all changes and will be applied later. One can use this module for implementing your own "features" similar to MKC_FEATURES.

### mkc_imp.scripts.mk
It is internal include file which is included from mkc.prog.mk, mkc.lib.mk and mkc.files.mk. Do not use it directly! It provides installing and uninstalling the scripts. The following variables are provided:

SCRIPTS

A list of interpreter scripts (written in shell, awk, lua etc). These are installed like programs. <M>

SCRIPTSDIR

Target directory for scripts. <Iu> [${BINDIR}]

SCRIPTSDIR_<script>

Optional directory to install <script> to. If <script> has a form <subdir>/<filename>, SCRIPTSDIR_<subdir>_<filename> is used. <Mu>

SCRIPTSGRP

Script file group. <Iu> [${BINGRP}]

SCRIPTSMODE

Script file mode. <Iu> [${BINMODE}]

SCRIPTSNAME

The name that the above program will be installed as, if different from ${SCRIPTS}. <Mu>

SCRIPTSNAME_<script>

Optional name to install <script> as. If <script> has a form <subdir>/<filename>, SCRIPTSNAME_<subdir>_<filename> is used. <Mu>

SCRIPTSOWN

Script files owner. <Iu> [${BINOWN}]

### mkc_imp.lua.mk
mkc_imp.lua.mk is internal include file which is included from mkc.prog.mk and mkc.lib.mk. Do not use it directly. It provides support for Lua programming language, i.e. building and installing Lua- and/or C-based modules. The following variables are provided:

LUA_CMODDIR

Directory for compiled Lua modules written in, e.g., C or C++. It is assigned with the help of pkg-config --variable=INSTALL_CMOD lua command and can be overriden by user. <Iu>

LUA_CMODULE

Compiled Lua module written in, e.g., C or C++. Dot in the module name separates a dirname from basename. That is, actual .c file names are made of LUA_MODULES with dots replaced with undeline symbol. At installation time dots are replaced with slash. For example, if LUA_CMODULES=socket.foo, then socket_foo.c will be used for compiling a module and will be installed to ${LUA_CMODDIR}/socket/foo.so. <M>

LUA_LMODDIR

Directory for Lua modules written in Lua. It is assigned with the help of pkg-config --variable=INSTALL_LMOD lua command and can be overriden by user. <Iu>

LUA_LMODULES

Deprecated. Filenames of Lua modules. Use LUA_MODULES instead. <M>

LUA_MODULES

List of Lua modules to build and install. Dot in the module name separates a dirname from basename. That is, actual .lua file names are made of LUA_MODULES with dots replaced with undeline symbol. At installation time dots are replaced with slash. For example, if LUA_MODULES=socket.foo, then socket_foo.lua will be installed to ${LUA_LMODDIR}/socket/foo.lua <M>

SRCS

List of source files to build the LUA_CMODULE. SRCS defaults to ${LUA_CMODULE:S|.|_|g}.c. <M>

### mkc_imp.intexts.mk
mkc_imp.intexts.mk is internal include file which is included from mkc.prog.mk, mkc.lib.mk and mkc.files.mk. Do not use it directly. It provides conversion of <fn>.in files to <fn> by expanding the following @@ patterns:

```
 Pattern       Result
----------------------
@prefix@       ${PREFIX}
@bindir@       ${BINDIR}
@mandir@       ${MANDIR}
@sbindir@      ${SBINDIR}
@libdir@       ${LIBDIR}
@libexecdir@   ${LIBEXECDIR}
@datadir@      ${DATADIR}
@sysconfdir@   ${SYSCONFDIR}
@incsdir@      ${INCSDIR}
@vardir@       ${VARDIR}
@sharedstate@  ${SHAREDSTATEDIR}
```

The following variables are provided:

INFILES

List of files to generate. <M>

INSCRIPTS

List of scripts to generate. <M>

INTEXTS_REPLS

List of Pattern/Replacement pairs separated by space, e.g.

```
    INTEXTS_REPLS+=   version ${VERSION}

    INTEXTS_REPLS+=   author_email ${AUTHOR_EMAIL}

```

<M>

INTEXTS_SED

List of additional sed(1) expressions for expanding, e.g.

```
    INTEXTS_SED+=   -e 's,0.37.0,${VERSION},g'

```

<M>

### mkc_imp.info.mk
mkc_imp.info.mk is internal include file which is included from mkc.prog.mk, mkc.lib.mk and mkc.files.mk. Do not use it directly! This module provides creation of .info files from .txi, .texi and .texinfo sources and provides the following variables:

INFOFLAGS

Flags to pass to makeinfo. [] <Iu>

MKINFO

If "no", don't build or install Info documentation from Texinfo source files. <Iu> [yes]

TEXINFO

List of Texinfo source files. Info documentation will consist of single files with the extension replaced by .info. <M>

### mkc_imp.man.mk
mkc_imp.man.mk is internal include file which is included from mkc.prog.mk, mkc.lib.mk and mkc.files.mk. Do not use it directly! This module provides installation of manual pages and creation of catpages and HTML pages and provides the following variables:

HTMLDIR

Target directory for html pages generated from man pages. <Iu> [${MANDIR}]

MAN

Manual pages (usually end in .1 - .9). <M>

MANDIR

Target directory for man pages. <Iu> [${PREFIX}/man]

MANZ

If not "no", compress manual pages at installation time. <Iu> [no]

MKCATPAGES

If "no", don't build or install the catman pages. <Iu> [no]

MKHTML

If "no", don't build or install the HTML man pages. <Iu> [no]

MKMAN

If "no", don't build or install the man pages, and also acts as "MKCATPAGES=no MKHTML=no". <Iu> [yes]

MLINKS

List of manual page links (using a .1 - .9 suffix). The linked-to file must come first, the linked file second, and there may be multiple pairs. The files are hard-linked. <M>

USETBL

If not "no", preprocess man pages using tbl(1) while generating cat pages. <IM> [no]

### mkc_imp.links.mk
mkc_imp.links.mk is internal include file which is included from mkc.prog.mk, mkc.lib.mk and mkc.files.mk. Do not use it directly! This module provides creation of hard and symbolic links and provides the following variables:

LINKS

The list of binary links; should be full pathnames, the linked-to file coming first, followed by the linked file. The files are hard-linked. For example, to link ${BINDIR}/gzip and ${BINDIR}/gunzip, use:

```
    LINKS=   ${BINDIR}/gzip ${BINDIR}/gunzip

```

<M>

SYMLINKS

The list of symbolic links; should be full pathnames. Syntax is identical to LINKS. Note that DESTDIR is not automatically included in the link. <M>

### mkc_imp.inc.mk
mkc_imp.inc.mk is internal include file which is included from mkc.prog.mk, mkc.lib.mk and mkc.files.mk. Do not use it directly! This module provides installation of header files and provides the following variables:

INCS

The list of include files. <M>

INCSDIR

See mkc.init.mk.

INCSNAME

Target name of the include file, if only one; same as FILESNAME, but for include files. <M>

INCSNAME_<file>

The name file <file> should be installed as, if not <file>, same as FILESNAME_<file>, but for include files. <Mu>

INCSSRCDIR

Source directory for include files. This variable have an influence on CPPFLAGS (-I${INCSSRCDIR} is added) and on an installation of include files (paths in ${INCS} are relative to ${INCSSRCDIR}). <M> [.]

### mkc.minitest.mk
mkc.minitest.mk is an auxiliary include file that implement simple framework for unit tests. Idea: application provides the target test_output and expect.out file that contains ideal output. mkcmake test runs mkcmake test_output and compare generated output with expect.out.

MKC_DIFF

diff(1) command for comparing expected and actual results. <Iu> [diff]

TEST_PREREQS

Prerequisites for target "test". <Iu> [all]

### mkc_imp.pkg-config.mk
mkc_imp.pkg-config.mk is internal include file which is included from mkc.prog.mk and mkc.lib.mk. Do not use it directly! This module supports dependencies controlled by pkg-config program. As a result CPPFLAGS and LDADD variables are modified according to "pkg-config --cflags ..." and "pkg-config --libs ...". The following variables are provided:

MKC_CHECK_PKGCONFIG

List of libraries to check, for example, glib-2.0>=2.1. Spaces around <=, >=, =, < and > are not allowed. As a result of the check bmake's variable PKG_CONFIG.exists.<lib> is set to 1 for success or 0 for failure. Unless MKC_NOAUTO is set to 1 -DHAVE_PKGCONFIG_<LIB>=1 is also added to CPPFLAGS if <lib> was found. <LIB> is tr/a-z+.-/A-ZP__/ of <lib>. <M>

MKC_REQUIRE_PKGCONFIG

The same as MKC_REQUIRE_PKGCONFIG, but absense of library is treated as a fatal error (See configure target).

PCNAME.<lib>

On some systems several versions of the same library may be installed to differet directories (for example liblua for Lua 5.1 and 5.2). In order to avoid conflicts between them pc name is changed (for example, lua5.1 and lua5.2 instead of lua). This variable is a map from library name to pc name. <Iu> [${lib}]

PKG_CONFIG.exists.<lib>

If "1", <lib> exists, "0" otherwise. Inside <lib> <=, >=, =, < and > and replaced with _le_, _ge_, _eq_, _lt_ and _gt_ respectively. <Iu>

PKG_CONFIG.var.<lib>.<var>

Variable value (pkg-config --variable=<var> <lib>). <Iu>

PKG_CONFIG_VARS.<lib>

List of variables to check for library <lib>. <M>

### mkc_imp.pod.mk
mkc_imp.pod.mk is internal include file which is included from mkc.prog.mk and mkc.lib.mk. Do not use it directly! It provides support for POD (Plain Old Documentation) markup language, i.e. convertion of POD documents to MAN pages (suffix rules: .pod.1, ... , .pod.9) and HTMLs (.pod.html). The following variables are provided:

POD2HTML

Path to POD to HTML conversion utility <Iu> [pod2html].

POD2HTML_FLAGS

Flags passed to ${POD2HTML} <Iu> [].

POD2MAN

Path to POD to MAN conversion utility <Iu> [pod2man].

POD2MAN_FLAGS

Flags passed to ${POD2MAN} <Iu> [-r '' -n '${.TARGET:T:R}' -c ''].

### mkc_imp.dep.mk
mkc_imp.dep.mk is internal include file which is included from mkc.prog.mk and mkc.lib.mk. Do not use it directly! This include file contains the default targets for building .depend_${.CURDIR:T} files. It creates .d files from entries in SRCS and DPSRCS that are C, C++, or Objective C source files, and builds .depend_${PROJECTNAME} from the .d files. All other files in SRCS and all of DPSRCS will be used as dependencies for the .d files. The following variables are provided:

DPSRCS

List of source files which are needed for generating dependencies, but are not needed in ${SRCS}.

MKDEP_CC

Compiler passed to mkdep(1). <Iu> [${CC}].

SRCS

The same as in mkc.prog.mk and mkc.lib.mk.

### mkc_imp.foreign_autotools.mk
This module is activated if variable FOREIGN is set to "autotools" and provides support for building external projects using autotools. It also provides a recursive target mkgen for generating "configure" script, "Makefile.in" file etc. using autoreconf(1) utility. The following variables are provided:

AT_AUTORECONF_ARGS

Arguments passed to autoreconf(1). <U> [-sif].

AT_CONFIGURE_ARGS

Extra arguments passed to "configure" script set in addition to standard ones (--prefix, --bindir etc.). <Mu> [].

AT_CONFIGURE_ENV

Environment variables for "configure" script set in addition to standard ones (CC, CFLAGS etc.). <Mu> [].

AT_MAKE

Make(1)-like utility for the project. <Imu> [${MAKE}].

AT_USE_AUTOMAKE

If "yes", automake(1) is used. <M> [yes].

FSRCDIR

Relative (to ${.CURDIR}) or absolute directory to autotools-based sources.

### mkc_imp.help.mk
This mk file implements targets help, help_subprj and help_use.

help_use

Outputs the configuring options available for the project and descriptions for their values. Configuring options should be specified in USE_VARIABLES variable described below.

help_subprj

Outputs the list of subprojects (mkc.subprj.mk) and their descriptions. Subprojects are mentioned in SUBPRJ and SUBPRJ_DFLT variables. Description are specified in HELP_MSG.<subproject> variable.

USE_VARIABLES

A list of configuring variables. Let's assume that the only configuring variable is USESOMETHING and the valid values for it are: no (the default) and yes. Then developer may provide the following assignments in Makefile:

```
    USE_VARIABLES  += USESOMETHING

    USESOMETHING.descr  = "Configuring parameter SOMETHING"

    USESOMETHING.0  = "no: disable feature SOMETHING"

    USESOMETHING.1  = "yes: enable feature SOMETHING"

```

<M> [unset]

HELP_MSG.<subproject>

Description for project <subproject>. <M> [unset]

## CROSS COMPILATION
The following variables are used for compiling software using cross-tools.

MACHINE_GNU_PLATFORM

See TOOLCHAIN_PREFIX.

OPSYS_TARGET

OPSYS for target OS.

SYSROOT

Root directory for headers and libraries. If set, the following variables are set to ${TOOLCHAIN_DIR}/${TOOLCHAIN_PREFIX}<toolname>: AR, AS, CXX, CPP, CC, INSTALL, LD, NM, OBJCOPY, OBJDUMP, RANLIB, SIZE and STRIP. <U> [].

TOOLDIR

See TOOLCHAIN_DIR.

TOOLCHAIN_DIR

Directory that contains cross-toolchain. <U> [${TOOLDIR}/bin].

TOOLCHAIN_PREFIX

See SYSROOT. <U> [${MACHINE_GNU_PLATFORM}-].

## ENVIRONMENT VARIABLES
MAKECONF

Path to mk.conf file included by mkc.*.mk files

## FILES
/etc/mkcmake.conf

included by mkc.init.mk if exists

/etc/mk.conf

included by mkc.init.mk if exists

## BUGS
Target configure (configure) doesn't support parallel builds. In order to build project in parallel, run it like the following

```
   mkcmake configure

   mkcmake -j4 all
```

## SEE ALSO
mkc_check_header(1), mkc_check_prog(1), mkc_check_decl(1), mkc_check_funclib(1), mkc_check_sizeof(1), mkc_check_custom(1), bmake(1), mkdep(1),

## AUTHOR
Aleksey Cheusov <vle@gmx.net>


mkimage-profiles

package: mkimage-profiles

title: mkimage-profiles(7)

summary: ALT distribution family metaprofile

text:
# mkimage-profiles(7)

## NAME
mkimage-profiles - ALT distribution family metaprofile

## SYNOPSIS
make [options] [ <goal> ... ]

## DESCRIPTION
mkimage-profiles builds operating environment images based on ALT package repositories.

Run make help to obtain list of available goals.

## PREREQUISITES
mkimage-profiles only needs make(1) and rsync(1) to generate the build profile; mkimage is used to actually run the build (which involves hasher(7) quite a few times).

git(1) will be used if available so that the generated profile is an annotated git repository; graphviz(1) can be used to obtain build dependency graphs.

## RATIONALE
Long time ago when Linux distribution images were worked upon by hand there was little need for generalization and sharing the common base.

Building several "generic" ALT{, Linux} distros in a team and maintaining their educational flavours at the same time proved the need to be able to describe what's common and what's different in a way that doesn't resemble more or less complete forks.

Enter mkimage-profiles: choose what's closest to your dream image and add what's missing, or roll on your own using the rich library of existing parts and bits.

## REQUIREMENTS
The next-generation image build system for ALT must:

1.

provide reasonable means to describe common/differing aspects within image families;

2.

ensure reproducible build results;

3.

support distribution family maintenance workflows observed in the wild (e.g., with mkimage-profiles-desktop or earlier);

4.

help out with diagnosing build problems.

## ARCHITECTURE
mkimage-profiles implements four steps to achieve the above goals:

1.

initialize the off-tree mkimage profile (BUILDDIR);

2.

build up distribution's configuration there;

3.

copy over the needed subprofiles/features/lists/groups;

4.

build the ISO/VE/VM image.

This results in a compact "as-needed" style per-image profile that can be actually studied in a short amount of time and might get included into the generated image as a tarball for better reproducibility.

## EXAMPLES
make syslinux.iso should result in a minimal bootable ISO image.

Another example is Regular Builds project yielding weekly images: https://en.altlinux.org/regular

## AUTHOR
Written by Michael Shigorin <mike@altlinux.org>, Anton Midyukov <antohami@altlinux.org>

## REPORTING BUGS
Report bugs to https://bugzilla.altlinux.org

(Sisyphus project, mkimage-profiles component).

## COPYRIGHT
Copyright ©) 2010-2020 Michael Shigorin <mike@altlinux.org>, 2020-2024 Anton Midyukov <antohami@altlinux.org>

This is free software; see the source for copying conditions. There is NO WARRANTY; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

## FURTHER READING
First and foremost: /usr/share/mkimage-profiles/QUICKSTART

Please refer to README files in the tree starting with the toplevel one for more information; these can be assembled into a handbook using asciidoc(1) (available at https://nightly.altlinux.org/docs/ as weekly HTML/PDF updates).

Specific topics are covered within doc/ subdirectory; e.g. make options are described in doc/params.txt file.

## SEE ALSO
hsh(1), mkimage,

https://www.vimeo.com/23522095


mosquitto-tls

package: mosquitto

title: mosquitto-tls(7)

summary: Configure SSL/TLS support for Mosquitto

text:
# mosquitto-tls(7)

## NAME
mosquitto-tls - Configure SSL/TLS support for Mosquitto

## DESCRIPTION
mosquitto provides SSL support for encrypted network connections and authentication. This manual describes how to create the files needed.

Note

It is important to use different certificate subject parameters for your CA, server and clients. If the certificates appear identical, even though generated separately, the broker/client will not be able to distinguish between them and you will experience difficult to diagnose errors.

## GENERATING CERTIFICATES
The sections below give the openssl commands that can be used to generate certificates, but without any context. The asciicast at https://asciinema.org/a/201826 gives a full run through of how to use those commands.

## CERTIFICATE AUTHORITY
Generate a certificate authority certificate and key.

•openssl req -new -x509 -days <duration> -extensions v3_ca -keyout ca.key -out ca.crt

## SERVER
Generate a server key.

•openssl genrsa -des3 -out server.key 2048

Generate a server key without encryption.

•openssl genrsa -out server.key 2048

Generate a certificate signing request to send to the CA.

•openssl req -out server.csr -key server.key -new

Note

When prompted for the CN (Common Name), please enter either your server (or broker) hostname or domain name.

Send the CSR to the CA, or sign it with your CA key:

•openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days <duration>

## CLIENT
Generate a client key.

•openssl genrsa -des3 -out client.key 2048

Generate a certificate signing request to send to the CA.

•openssl req -out client.csr -key client.key -new

Send the CSR to the CA, or sign it with your CA key:

•openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days <duration>

## SEE ALSO
mosquitto(8), mosquitto-conf(5)

## AUTHOR
Roger Light <roger@atchoo.org>


mqtt

title: mqtt(7)

summary: MQ Telemetry Transport

text:
# mqtt(7)

## NAME
mqtt - MQ Telemetry Transport

## SYNOPSIS
MQTT

## DESCRIPTION
MQTT is a lightweight publish/subscribe messaging protocol. It is useful for use with low power sensors, but is applicable to many scenarios.

This manual describes some of the features of MQTT version 3.1.1/3.1, to assist end users in getting the most out of the protocol. For more complete information on MQTT, see http://mqtt.org/.

## PUBLISH/SUBSCRIBE
The MQTT protocol is based on the principle of publishing messages and subscribing to topics, or "pub/sub". Multiple clients connect to a broker and subscribe to topics that they are interested in. Clients also connect to the broker and publish messages to topics. Many clients may subscribe to the same topics and do with the information as they please. The broker and MQTT act as a simple, common interface for everything to connect to. This means that you if you have clients that dump subscribed messages to a database, to Twitter, Cosm or even a simple text file, then it becomes very simple to add new sensors or other data input to a database, Twitter or so on.

## TOPICS/SUBSCRIPTIONS
Messages in MQTT are published on topics. There is no need to configure a topic, publishing on it is enough. Topics are treated as a hierarchy, using a slash (/) as a separator. This allows sensible arrangement of common themes to be created, much in the same way as a filesystem. For example, multiple computers may all publish their hard drive temperature information on the following topic, with their own computer and hard drive name being replaced as appropriate:

•sensors/COMPUTER_NAME/temperature/HARDDRIVE_NAME

Clients can receive messages by creating subscriptions. A subscription may be to an explicit topic, in which case only messages to that topic will be received, or it may include wildcards. Two wildcards are available, + or #.

+ can be used as a wildcard for a single level of hierarchy. It could be used with the topic above to get information on all computers and hard drives as follows:

•sensors/+/temperature/+

As another example, for a topic of "a/b/c/d", the following example subscriptions will match:

•a/b/c/d

•+/b/c/d

•a/+/c/d

•a/+/+/d

•+/+/+/+

The following subscriptions will not match:

•a/b/c

•b/+/c/d

•+/+/+

\# can be used as a wildcard for all remaining levels of hierarchy. This means that it must be the final character in a subscription. With a topic of "a/b/c/d", the following example subscriptions will match:

•a/b/c/d

•#

•a/#

•a/b/#

•a/b/c/#

•+/b/c/#

Zero length topic levels are valid, which can lead to some slightly non-obvious behaviour. For example, a topic of "a//topic" would correctly match against a subscription of "a/+/topic". Likewise, zero length topic levels can exist at both the beginning and the end of a topic string, so "/a/topic" would match against a subscription of "+/a/topic", "#" or "/#", and a topic "a/topic/" would match against a subscription of "a/topic/+" or "a/topic/#".

## QUALITY OF SERVICE
MQTT defines three levels of Quality of Service (QoS). The QoS defines how hard the broker/client will try to ensure that a message is received. Messages may be sent at any QoS level, and clients may attempt to subscribe to topics at any QoS level. This means that the client chooses the maximum QoS it will receive. For example, if a message is published at QoS 2 and a client is subscribed with QoS 0, the message will be delivered to that client with QoS 0. If a second client is also subscribed to the same topic, but with QoS 2, then it will receive the same message but with QoS 2. For a second example, if a client is subscribed with QoS 2 and a message is published on QoS 0, the client will receive it on QoS 0.

Higher levels of QoS are more reliable, but involve higher latency and have higher bandwidth requirements.

•0: The broker/client will deliver the message once, with no confirmation.

•1: The broker/client will deliver the message at least once, with confirmation required.

•2: The broker/client will deliver the message exactly once by using a four step handshake.

## RETAINED MESSAGES
All messages may be set to be retained. This means that the broker will keep the message even after sending it to all current subscribers. If a new subscription is made that matches the topic of the retained message, then the message will be sent to the client. This is useful as a "last known good" mechanism. If a topic is only updated infrequently, then without a retained message, a newly subscribed client may have to wait a long time to receive an update. With a retained message, the client will receive an instant update.

## CLEAN SESSION / DURABLE CONNECTIONS
On connection, a client sets the "clean session" flag, which is sometimes also known as the "clean start" flag. If clean session is set to false, then the connection is treated as durable. This means that when the client disconnects, any subscriptions it has will remain and any subsequent QoS 1 or 2 messages will be stored until it connects again in the future. If clean session is true, then all subscriptions will be removed for the client when it disconnects.

## WILLS
When a client connects to a broker, it may inform the broker that it has a will. This is a message that it wishes the broker to send when the client disconnects unexpectedly. The will message has a topic, QoS and retain status just the same as any other message.

## SEE ALSO
mosquitto(8), mosquitto_pub(1), mosquitto_sub(1)

## AUTHOR
Roger Light <roger@atchoo.org>


mozplugger

package: mozilla-plugin-mozplugger

title: mozplugger(7)

text:
# mozplugger(7)

## NAME
mozplugger - a multimedia plugin for UNIX Web browsers that supports the mozilla npapi

## DESCRIPTION
MozPlugger is a browser plugin which can show many types of multimedia inside your Browser. To accomplish this, MozPlugger uses external programs such as mplayer, xanim, mtv, timidity and tracker.

## CONFIGURE FILE
You can configure mozplugger by changing the mozpluggerrc file(s). These can be located in any of the following directories depending on the browser:

For mozilla (and chromium) browsers

$MOZPLUGGER_HOME/

$XDG_CONFIG_HOME/mozplugger/

$HOME/.config/mozplugger/

$HOME/.mozplugger/

$HOME/.mozilla/

$MOZILLA_HOME/

/etc/

/usr/etc/

/usr/local/mozilla/

For netscape browsers

$MOZPLUGGER_HOME/

$XDG_CONFIG_HOME/mozplugger/

$HOME/.config/mozplugger/

$HOME/.mozplugger/

$HOME/.netscape/

/etc/

/usr/etc/

/usr/local/netscape/

For opera browsers

$MOZPLUGGER_HOME/

$XDG_CONFIG_HOME/mozplugger/

$HOME/.config/mozplugger/

$HOME/.mozplugger/

$HOME/.opera/

$OPERA_HOME/

/etc/

/usr/etc/

The command mozplugger-update must be run after installation and each time the configuration file changes or new helper applications are added to the system or old helper applications removed.

mozplugger-update will use the first mozpluggerrc it finds and ignore any others for each different browser installed on the system. The search order is from top of the list above, but skipping places not applicable to the particular browser that the config is being parsed for. mozplugger-update then caches processed results in files located at $XDG_CACHE_HOME/mozplugger/

The format of mozpluggerrc is very simple. The file is subdivided into sections. Each section starts with a plugin name and version in square brackets. This represents a class of mozplugger plugin. The name and version will be displayed as a separate plugin when viewing installed plugins in your browser. Some java script relies on the name and version of a plugin matching some value, hence the reason for seperate sections in mozpluggerrc. Two brackets are required because m4 processing needs to escape the brackets. e.g.

[[multimedia player @ 10.1]]

Within each section, the general layout is to have one or more lines describing mime types followed by one or more lines describing commands used to handle those mime types. Lines beginning with # are considered comments and are ignored. Here is a simple example:

video/mpeg: mpeg: Mpeg video

video/quicktime: qt,mov: Mpeg video

: xanim +W$window -Zr +q +Ze +f $file

Each line describing a mime type has three fields:

mime type : extensions : description

mime type

The mime type is the standardized name for the content type you want MozPlugger to handle. This must be the same type as the web server claims the file to be, or MozPlugger will not be used for that file, regardless of the extension. Note: Some web servers incorrectly report the wrong mime type, blame the web server adminstrator not mozplugger.

extensions

This is a comma separated list of extensions that should be associated with this particular mime type. The extensions are only used when a web server does not report what type of file it is, or when loading files directly from disk.

description

This is the description that shows up in about:plugins and in the application preferences section in Mozilla.

Lines that describe what command to use for a mime type must begin

with a whitespace and have two fields:

flags : command

flags

This is a space separated list of flags associated with the command and tells mozplugger how to handle this command. See below for further details.

command

This is a command which is sent to /bin/sh when handling this mime type. Mozplugger assumes the command line starts with the name of an application followed by various arguments passed to that application.

## USING M4
When running, mozplugger-update it will pass the mozpluggerrc file through m4, a general purpose macro processor (assuming m4 is installed). This provides the ablity to use macros within mozpluggerrc especially for those commonly used command lines. m4 brings text replacement, parameter substitution, file inclusion, string manipulation, conditional evaluation, arthemtic expressions, etc to mozpluggerrc. Please see m4 documentation for more details.

## FINDING THE RIGHT COMMAND
When MozPlugger is called from your browser, it looks through the cached processed configuration files and finds a matching mime type.

When a matching mimetype is found, it tries to figure out which command to use. Commands that have the flags loop, embed, noembed, link and fmatch will be rejected if they do not match what is expected from the associated HTML code (see later for details).

In addition for a command to be chosen the application has to be available. This will have been checked by mozplugger-update which will have assumed the first word of the command is the name of an application and search $PATH for that application. If that application is not found mozplugger-update will not have cached that in the processed config files. The output from mozplugger-update will indicate when applications have not been found.

Of the commands that remain, Mozplugger looks for the first command that has the stream flag set. If there is not such a command line, Mozplugger then downloads the file and picks the first (of the remaining) commands.

## WORKING WITH JAVA SCRIPT
Mozplugger supports a JavaScript interface that allows the state of the embedded object (i.e. mozplugger) to be queried from JavaScript. Currently mozplugger supports the following properties.

isPlaying

This property has the value true if the application that mozplugger launched to handle the embedded object is running and false if either no application was launched or that application has now terminated.

## WHEN IT DOESNT WORK
If for some reason the embedded object fails to be rendered in the browser, this could be a fault with the application as opposed to MozPlugger. To diagnosis the fault it is suggested that first you make sure that any output from the application will be visible to you by removing the noisy flag (if set in mozpluggerrc).

Next run the browser from the shell (xterm or equivalent) passing the appropriate browser command line flag to enable output from stdout and stderr to be displayed.

For example, for firefox the command line string is:

firefox -debug

This should allow any output from the application to be visible at the shell and hopefully lead to a diagnosis of the fault.

## FLAGS
autostart

This flag indicates that the command uses the $autostart environment variable. That is mozplugger will run the command on the assumption that the command/application will check the value of the $autostart environment variable. If this flag is not present and the HTML code for the embedded object indicates autostart is false, mozplugger will not run the command but instead draw a single start button.

repeat

This flag indicates that the command uses the $repeats environment variable. That is mozplugger will run the command on the assumption that the command/application will check the value of the $repeats environment variable and perform the repeats. If this flag is not set, mozplugger will perform the required number of repeats as indicated in the HTML code by calling the command $repeats times.

loop

This indicates that the command loops forever. If the HTML code for the embedded object indicates don't loop/repeat forever (e.g. the loop attribute is not present or not set to true), the command on this line will not be used.

stream

This indicates that this command can take an url. In this case, the environment variable $file contains the URL of the file to play and the browser does not download it. It is assumed that the command can handle the URL. Note: if a username and password is required for this URL, the command/application will have to obtain this as it is not passed to it from the browser.

ignore_errors

This flag tells MozPlugger to ignore the exit status of the command. For example is mozplugger is repeating the command 'n' times and the command exits with an error, normally mozplugger would terminate at this time. With this flag set, mozplugger continues the repeats.

noisy

This flag tells MozPlugger to redirect the stdout and stderr of the command to /dev/null.

swallow (name)

This flag tells mozplugger that the command will open a window with the specified name and that Mozplugger will then move this window inside your browser. If name is prefixed with '=' then mozplugger looks for an exact match with the window name, if the prefix is '~' then mozplugger looks for a case insensitive match, if prefixed with '*' then mozplugger looks for a window name that starts with 'name' and is case insensitive. If none of these prefixes then, mozplugger checks if name occurs anywhere in the window name, but is case sensitive. Note any spaces between the brackets are counted as part of the window name. The window name to use in mozpluggerrc can be obtained by using the utility xprop(). Run the command in question, type "xprop WM_CLASS" at a shell prompt and then click on the application window. In addition any occurance of %f in the name is replaced with the filename being loaded (without path), %p is replaced with the full filename including path. Some applications do not like to be swallowed and some window managers do not like windows being managed by mozplugger, so avoid using this option where possible.

fmatch (string)

This flag defines a command that will be used only if the filename or url (i.e. $file) contains 'string'. If 'string' is prefixed with '*' then mozplugger defines a match when the file starts with 'string' (the check is case insensitive). If 'string' is prefixed with '%' then mozplugger defines a match when the file ends with 'string' (the check is case insenstive and ignores any parameters at the end of a url {i.e. '?xxx=yyy'}). If none of these prefixes then mozplugger defines a match when the 'string' is found somewhere in the file (but this time match is case sensitive). Note any spaces between the brackets are counted as part of the 'string'.

nokill

This flag tells MozPlugger to not try to kill the command when leaving the page, and to not start the command in a loop. This is normally used for applications that are not swallowed and can play multiple files, such as xmms.

exits

This flag tells MozPlugger that the command will exits straight away and hence does not need to be killed when leaving the page, and to not start the command in a loop. This is normally used for applications that just display an image in the $window and then exit.

fill

This flag tells MozPlugger to maximize a swallowed window.

maxaspect

This flag tells Mozplugger to maximize a swallowed window while keeping the width/height ratio constant.

controls

This flag tells MozPlugger to draw controls and is typically used with audio files to display a controller with the buttons play, pause and stop. Be aware if the embedded object has no sub-window defined within the browser's window (e.g. if the HTML uses the tag hidden = true) then the controls will not appear.

embed

This flags tells Mozplugger to only use this command if the associated HTML refers to an embedded object that is a small part of a HTML page.

noembed

This flags tells Mozplugger to only use this command if the associated HTML refers to a separate window that only contains the object.

links

This flag tells Mozplugger to display as a button within the browser and when pressed to run the command without embedding in the browser. This can be used when swallow does not work.

needs_xembed

Some applications when embedded requires the Xembed protocol, other applications don't want the Xembed protocol. Add or remove this flag if you find that you cannot move keyboard focus to the embedded window. Currently it appears QT4 based applications require this flag.

## ENVIRONMENT VARIABLES
There are some envirnoment variables that control the behaviour of Mozplugger.

MOZPLUGGER_HOME

If MOZPLUGGER_HOME is defined, the folder $MOZPLUGGER_HOME is checked for the configuration file mozpluggerrc and is also used for the base of storing the results of processing mozpluggerrc

MOZPLUGGER_TMP

If MOZPLUGGER_TMP is defined, then any temporary files are placed in $MOZPLUGGER_TMP.

TMPDIR

If MOZPLUGGER_TMP is not defined, but TMPDIR is defined, then any temporary files are placed in $TMPDIR/mozplugger-xxx/ where xxx = PID.

PATH

mozplugger-update uses PATH to look for executables

MozPlugger gives some variables to /bin/sh when running the command,

these variables are:

$autostart

This variable contains 1 or 0. When set to 1 it indicates that the command should start playing/showing the associated media. By default it is 0 if controls flag is present and 1 otherwise, but it is overridden if the associated HTML contains the attribute autostart or autoplay. Command/applications that use this environment variable should also have the autostart flag set.

$repeats

This variable contains how many times the file should be played. By default it is once, but it is overridden if the associated HTML contains the attribute loop, numloop or playcount. Command/applications which use this environment variable should also have the repeat flag set.

$window

This is the X window Mozilla has given the plugin. This can be used with applications such as MPlayer to display graphics inside the mozilla window. Be aware if the embedded object has no sub-window defined within the browser's window (e.g. if the HTML uses the tag hidden = true) then the variable will have the value zero (null).

$hexwindow

Same as $window except the value is expressed as an hexidecimal string in the form 0xNNNNNN where NNNNNN is the hexadecimal digits.

$width

This is the horizontal resolution in pixels and is taken from the width attribute in the HTML code.

$height

This is the vertical resolution in pixels and is taken from the height attribute in the HTML code.

$file

This is the file to play. If the command has the stream flag set, this variable contains the URL of the file to play. This is taken from the associated HTML code. The value is that of the attribute src, data, href, qtsrc, filename, url or location depending on which is present and whether the <EMBED> or <OBJECT> tag is used. If the stream is not set, this variable contains a local temporary file that the browser has created.

$fragment

This is the part of the original URL that appears after the # if it exists. Sometimes this contains additional information that could be useful for the application e.g. starting page number in a pdf document

$mimetype

This variable contains the mime type of $file.

$VAR_<parameter_name>

All the parameters of the <EMBED> or <OBJECT> tags are made available in mozpluggerrc through environment variables. For example the parameter loop="1" in an <EMBED> tag defines the variable VAR_loop=1.

## BUGS
You have to run mozplugger-update after changing the configuration, or nothing will happen.

Netscape 3.x will not play anything for <EMBED> tags for which height or width are zero. This too is a Netscape bug.

Occassionally you may notice some zombie mozplugger-helper processes (defunct), this is not a bug, this is by design. The zombie processes occur when either the application exits or when using nokill flag (without exiting the page with the embedded object). The zombie(s) are reaped when closing the web page containing the associated embedded objects.

If using behind a non-transparent HTTP proxy, it may be found that the commands using the stream flag do not work. This is because the proxy settings are not passed to the application in the command line. To work around this situation, don't use the stream flag OR edit the mozpluggerrc file and passed in necessary proxy setiings via the command line.

It has been found that certain combinations of browser, embedded applications and window managers do not play nicely with the swallow flag. If this happens to you first try adding or removing the "needs_xembed" flag from the associated command in mozpluggerrc, if this fails remove the swallow flag and perhaps use the links flag instead.

## AUTHORS
Fredrik Hubinette, author of plugger which mozplugger is a fork of.

Louis Bavoil

Peter Leese