From 3deece559159150a0710d8160f39583ba7f2e582 Mon Sep 17 00:00:00 2001 From: Jelmer Vernooij Date: Sun, 31 Oct 2010 02:17:29 +0100 Subject: s4: Remove the old perl/m4/make/mk-based build system. The new waf-based build system now has all the same functionality, and the old build system has been broken for quite some time. Autobuild-User: Jelmer Vernooij Autobuild-Date: Sun Oct 31 02:01:44 UTC 2010 on sn-devel-104 --- source4/build/smb_build/README.txt | 83 -------------------------------------- 1 file changed, 83 deletions(-) delete mode 100644 source4/build/smb_build/README.txt (limited to 'source4/build/smb_build/README.txt') diff --git a/source4/build/smb_build/README.txt b/source4/build/smb_build/README.txt deleted file mode 100644 index eac3905cce..0000000000 --- a/source4/build/smb_build/README.txt +++ /dev/null @@ -1,83 +0,0 @@ -The Samba Build System -====================== - -The build system basically has two main parts: the autoconf-generated -shell scripts which check for availability of functions and libraries -which is stored in the .m4 files and the information about the various -subsystems which is stored in the .mk files. - -Object Types ------------- -the build system knows about the following object types - -SUBSYSTEM: - a SUBSYSTEM is basicly a collection of functions, which provide an - an generic API for a specific problem (e.g. libldb provides an api - for gneric ldb databases. libldb_plugin provides a generic api - for calling ldb plugins, so 'libldb' and 'libldb_plugin' are subsystems) - -MODULE: - a MODULE is a specify implementation of a API provided by a SUBSYSTEM. - (e.g. 'libldb_tdb' and 'libldb_ldap' are implementations of the subsystem 'libldb' API, - and 'libldb_plugin_timestamp' is a module of the 'libldb_plugin' subsystem) - -EXT_LIB: - an EXT_LIB is an external library which is needed by a SUBSYSTEM, MODULE, BINARY or LIBRARY. - (e.g. 'gtk' or 'KRB5') - -BINARY: - a BINARY means a executable binary file. - (e.g. 'smbtorture' or 'ldbedit') - a BINARY typically has only commandline handling and basic - functionality code in it and depends on the functions of - SUBSYSTEM's (REQUIRED_SUBSYSTEMS). - -LIBRARY: - a LIBRARY means a static and/or shared library, - which depends on the used OS. - (e.g. for libldb 'libldb.so', 'libldb.so.0' 'libldb.so.0.0.1' - and libldb.a are created on linux) - a LIBRARY typicly has only glue code in it and depends on - SUBSYSTEM's (REQUIRED_SUBSYSTEMS). - -File summary: -------------- -public.m4 - public M4 macros of the build system -config_mk.pm - Support for reading .mk files -dot.pm - Support for generating .dot files for analysis of dependencies -input.pm - Input validation -main.pm - Main -makefile.pm - Makefile generation -output.pm - Dependency calculation - -Layout -------- - -Toplevel file: configure.in -- included by autogen.sh: aclocal.m4 - which includes the SMB_YXZ*() macros - -- default tests of the build system - are in build/smb_build/check_*.m4 - (mostly compiler and basic C type and function - checks) - -- subsystem specific stuff should be included by 'SMB_INCLUDE_M4()' - - -Generating the configure file -------------------------- -you need to rerun ./autogen.sh when 'configure.in' or any -'.m4' file was modified, then you need to rerun configure. - - -Generating config.status ------------------------------ -you need to run ./config.status (or 'configure') after a '.mk' -file was changed. - - -Examples --------- -for now please take a look at the .m4 and .mk files -you find in the source tree, they should be a good reference to start. -- cgit