# bmake

## Introduction

In the past when building large software projects, I've had to ensure that GNU make (if not my own patched version of it), was installed and had developed a set of macros to greatly simplify delveloping complex build trees.

My main development machine for the last few years, runs 4.4BSD (NetBSD to be precise), and the BSD source code tree is an excellent example of managing a large software project. In following NetBSD's -current delevlopment, I learned to use the new BSD Makefiles and make(1), I'll refer to it as bmake from here on. Since then all my new projects and many of my old ones use bmake. Since bmake.tar.gz uses GNU's autoconf and is quite portable, I've skipped the effort of making the rest of my distribution support GNU make.

It may be insteresting to note that much of my tree uses the same simple Makefile, it is:

    # RCSid:
    #	$Id: bmake.html,v 1.2 1997/02/09 11:02:02 sjg Exp $
    #
    #	@(#) Copyright (c) 1995 Simon J. Gerraty
    #
    #	This file is provided in the hope that it will
    #	be of use.  There is absolutely NO WARRANTY.
    #	Permission to copy, redistribute or otherwise
    #	use this file is hereby granted provided that
    #	the above copyright notice and this notice are
    #	left intact.
    #
    #	Please send copies of changes and bug-fixes to:
    #	sjg@quick.com.au
    #

    # a totally generic makefile suits 90% of projects

    PROG=	${.CURDIR:T}

    SRCS=	$(PROG).c

    .include <bsd.prog.mk>

## macros

The example Makefile above, perhaps suggests why I like bmake(1). The important magic is in the line:

    .include <bsd.prog.mk>

Makefiles for libraries inlcude bsd.lib.mk btw. Anyway, apart from reading a bunch of rules from the system macros (/usr/share/mk/* by default) it reads "../Makefile.inc" thus provinding a hook for much magic. My Makefile.inc files typically look for Makefile.${MACHINE}.inc as well.

## obj

Another cool feature of bmake(1) is that if the directory obj exists in the same directory as the Makefile, then bmake will chdir into it before doing anything else. This helps keep the build tree clean, and if the obj directories are symlinks off to a separate file system, eg.

    /usr/src/bin/cat/obj -> /usr/obj/bin/cat

then suddenly building for multiple architectures is very easy. Since I typically export my tree via NFS and want to gather the binaries into my configs tree, I have the variable OBJMACHINE set, so that bmake uses obj.${MACHINE} rather than just obj, thus a parallel symlinked obj tree is not needed.

### MACHINE

The variable MACHINE is built into bmake. The script bmake/machine.sh is used to set it it from the output of uname(1).

$Id: bmake.html,v 1.2 1997/02/09 11:02:02 sjg Exp $
Copyright (c) 1997 QUICK.COM.AU