1
0
mirror of https://github.com/samba-team/samba.git synced 2025-01-12 09:18:10 +03:00
samba-mirror/source4/build/smb_build
Jelmer Vernooij 82037a75ea r24814: Fix headers, trim core.h even more.
(This used to be commit 9647f860bd)
2007-10-10 15:03:14 -05:00
..
cflags.pm r22400: only add srcdir and builddir path if they differ 2007-10-10 14:51:14 -05:00
config_mk.pm r22452: fix creation of MK_FILES variable in Makefile 2007-10-10 14:51:21 -05:00
dot.pl r15521: Take an optional subsystem name to generate a dependency graph for 2007-10-10 14:05:45 -05:00
env.pm r19908: Fix order of paths in pc files. 2007-10-10 14:28:35 -05:00
header.pm r15375: Rename readline.h to smbreadline.h avoid clashes with system header. 2007-10-10 14:05:29 -05:00
input.pm r23862: Explain who requested unknown dependency. Helps a lot in chasing dependency hell when trimming down s4 platform 2007-10-10 15:01:05 -05:00
main.pl r22031: Make sure we rewrite the include directives in CFLAGS to contain 2007-10-10 14:49:43 -05:00
makefile.pm r24814: Fix headers, trim core.h even more. 2007-10-10 15:03:14 -05:00
output.pm r22455: split dependecies array for compiling and linking and use better names:-) 2007-10-10 14:51:22 -05:00
README.txt r13867: Wrap the cflags.sh hack in the build system. You can now simply 2007-10-10 13:52:18 -05:00
summary.pm r21684: remove summary line for gtk code, as it's now maintained out-of-tree 2007-10-10 14:49:11 -05:00
TODO r16040: Support more recent versions of autoconf 2007-10-10 14:08:52 -05:00

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 typicly 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
header.pm - build.h generation
cflags.pm - Generates cflags.txt for file-specific cflags

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.