Home | History | Annotate | Line # | Download | only in tools
README revision 1.3
      1 $NetBSD: README,v 1.3 2014/09/30 07:34:50 apb Exp $
      2 
      3 Notes for NetBSD src/tools
      4 
      5 
      6 Background
      7 ==========
      8 
      9 Several programs that are part of NetBSD are also built as tools.  Such
     10 programs are typically built twice: once as a tool and once as part of
     11 the release build.  Tools are relevant only when the make(1) variable
     12 USETOOLS=yes, which is the default for most NetBSD builds.
     13 
     14 Tools are built on the host platform, using the host compiler,
     15 and will run on the host platform during the cross-build of the
     16 remainder of NetBSD.  They are built near the beginning of a NetBSD
     17 build (e.g. "build.sh tools" or "make tools" from the top level src
     18 directory), and installed in ${TOOLDIR}.
     19 
     20 Tools are executed during the main part of the build, when several
     21 TOOL_* variables defined in src/share/mk/bsd.*.mk will refer to the
     22 tools installed in ${TOOLDIR}.
     23 
     24 
     25 Portability
     26 ===========
     27 
     28 Programs that are built as tools need to be more portable than other
     29 parts of NetBSD, because they will need to run on the host platform.
     30 
     31 Tools should restrict themselves to C language features that are defined
     32 in C89 (ISO 9899-1989); they should avoid using C99 features.
     33 
     34 Tools may library features defined in C89 and in POSIX (IEEE Std 1003.1)
     35 (XXX year?), and features that are provided by the src/tools/compat
     36 framework described below.
     37 
     38 If a tool attempts to use a feature that is not available on the host
     39 platform, then the tools build will fail.  This can be addressed by
     40 changing the tool to avoid that feature, or by adding the feature to the
     41 src/tools/compat framework.  It is usually easy to add new macros or
     42 functions to src/tools/compat, and that is usually better than adding
     43 compatibility definitions to individual tools.
     44 
     45 
     46 Compatibility framework
     47 =======================
     48 
     49 src/tools/compat provides a compatibility framework for use by tools.
     50 It installs the following components, and more:
     51 
     52 ${TOOLDIR}/lib/libnbcompat.a
     53 
     54     A library containing functions that are needed by some tools.
     55 
     56 ${TOOLDIR}/include/nbtool_compat.h
     57 
     58     A header file defining macros that are needed by some tools.
     59 
     60 ${TOOLDIR}/share/compat/defs.mk
     61 
     62     A makefile fragment, to be included by other makefiles,
     63     to define make variables appropriate for building tools.
     64 
     65     Among other things, this makefile fragment automatically adds
     66     the libnbcompat.a library to the LDADD and DPADD variables,
     67     so that tools will be linked with that library, and adds
     68     -I${NETBSDSRCDIR}/tools/compat and -DHAVE_NBTOOL_CONFIG_H=1 to the
     69     HOST_CPPFLAGS variable, so that compiled programs can detect when
     70     they are being built as tools.
     71 
     72 
     73 Adapting Makefiles for use with tools
     74 =====================================
     75 
     76 Makefiles under src/tools/*/Makefile should define the HOSTPROG
     77 variable.  This is typically done by tools/Makefile.hostprog,
     78 which is directly or indirectly included by all Makefiles in
     79 src/tools/*/Makefile.
     80 
     81 Makefiles in the non-tools part of the src tree can test whether or not
     82 the HOSTPROG variable is defined, in order tell the difference between
     83 building a tool and building part of a NetBSD release, and they may
     84 alter their behavior accordingly.
     85 
     86 For example, the Makefile may conditionally refrain from compiling and
     87 linking certain files, and the Makefile may conditionally pass macros to
     88 the compiler via constructs like this:
     89 
     90     .if defined(HOSTPROG)
     91     CPPFLAGS+= -DWITH_FEATURE_X=0 # exclude feature X from tools build
     92     .else
     93     CPPFLAGS+= -DWITH_FEATURE_X=1 # include feature X in release build
     94     .endif
     95 
     96 Adapting Programs for use with tools
     97 ====================================
     98 
     99 When a tool is being built, the C compiler should automatically be
    100 invoked with -DHAVE_NBTOOL_CONFIG_H=1.  This is done as a result of
    101 settings in ${TOOLDIR}/share/compat/defs.mk, which should be included
    102 from src/tools/Makefile.host, which should be included directly or
    103 indirectly from src/tools/*/Makefile.
    104 
    105 A C source file can test whether the HAVE_NBTOOL_CONFIG_H macro is
    106 defined, in order to tell whether or not it is being compiled as part of
    107 a tool.
    108 
    109 In order to obtain the definitions provided by the tools compatibility
    110 framework, almost every C source file that is built as part of a tool
    111 should have lines like these as the first non-comment lines:
    112 
    113     #if HAVE_NBTOOL_CONFIG_H
    114     #include "nbtool_config.h"
    115     #endif
    116 
    117 To omit features from the tools version of a program, the program
    118 may test the HAVE_NBTOOL_CONFIG_H macro, like this:
    119 
    120     #if HAVE_NBTOOL_CONFIG_H
    121        ... code to be used when built as a tool
    122     #else
    123        ... code to be used when built as part of a release
    124     #endif
    125 
    126 It is often preferable to use macros whose names refer to the features
    127 that should be included or omitted.  See the section on "Adapting
    128 Makefiles for use with tools" for an example in which the Makefile
    129 passes -DWITH_FEATURE_X=0 or -DWITH_FEATURE_X=1 to the compiler
    130 according to whether or not the program is being built as a tool.  Then
    131 the program can use code like this:
    132 
    133     #if WITH_FEATURE_X 
    134        ... code to be used when FEATURE X is desired,
    135        ... e.g. when being built as part of a release.
    136     #else
    137        ... code to be used when FEATURE X is not desired,
    138        ... e.g. when being built as a tool.
    139     #endif
    140 
    141