0N/AThis is documentation of the Makefile system used in this tree.
0N/AThis tree builds hundreds of open source modules that are each released
0N/Aseparately and delivered as source in separate tarballs. These modules
0N/Aare organized in subdirectories based on the
X.Org module list, though
0N/Amodules from other sources are included as appropriate. For instance,
0N/AIn this tree, the term "module" is used for a specific set of source built
0N/Agenerally from a single tarball from upstream, such as xterm or fontconfig.
0N/AThe directories grouping these together are referred to as "module type"
0N/Adirectories - app, lib, font, etc. Each module is thus found in a
0N/Asubdirectory of the form open-src/<module type>/<module> . Various flags
0N/Acan be set at either the individual module level or for all modules of a
2362N/AFor each module, at build time the tarball is unpacked to a directory named
2362N/A"unpacked-src", patches applied for post-release bug fixes or customizations,
0N/Aand then the build is run. Since those subdirectories can be competely
0N/Arecreated from the source tarball and patches, rebuilding the tree or running
0N/A"make clobber" simply removes them entirely and recreates them.
0N/ATo allow building both 32-bit and 64-bit versions in the same build,
0N/Aand building both sparc and x86 versions in the same tree, the objects are
0N/Athen built in subdirectories named build-amd64, build-i386, build-sparc,
0N/Aand build-sparcv9 in each modules' directory. "make clean" or "make clobber"
0N/Asimply removes these build directories entirely, and lets the next build
955N/Arecreate them as needed.
0N/ANote that some modules, especially the fonts, use different build-* patterns
0N/Afor the variants they build, and thus trying to have both sparc & x86
0N/Aplatforms building in the same directory at the same time will likely fail
0N/Aas they stomp on each other in those directories. Running one build then
0N/Athe other should work.
0N/AYou should be able to run make commands in any module directory or
0N/Amodule-type directory, though since most of the intermodule dependencies
0N/Aare not declared, many modules will break unless you've done a full-tree
0N/Abuild at some point to populate the proto area with the bits needed.
0N/A=============================================================================
0N/AMake targets you can build in each module:
0N/A------------------------------------------
0N/AFor most of these you can append _32 or _64 to do just the 32-bit or 64-bit
0N/Aversions of the targets, while the version listed here repeats for all build
0N/Atypes set in the BUILD_TYPES variable. These are defined in the
0N/Amay add additional rules needed for modules of that type.
0N/A Completely removes build-* directories.
0N/A Completely removes build-* & unpacked-src directories.
955N/A Creates unpacked-src directories by unpacking sources from tarball
955N/A Runs GNU autoconf script or similar configuration steps if
955N/A needed, including autoreconf or delibtoolize if variables are set.
955N/A (Runs make source first if needed, and creates build-* directory
955N/A Compile the software into the binaries that get installed.
955N/A (Runs make configure first if needed.)
955N/A Install files into the proto area where make_release_packages
955N/A will pull them from to make packages and where other parts of
955N/A the build will use them. (Runs make build first if needed.)
955N/Amake all (or just "make" with no arguments)
955N/A equivalent to make build for most modules
955N/A same as make all, but with compiler optimization flags changed
955N/A to "-g". (Note that if you haven't done a make clean first,
955N/A doesn't force a recompile, so running make debug in a directory
955N/A you already built non-debug may not actually build debug versions.)
955N/A same as make install, but with compiler optimization flags changed
955N/A to "-g". (See warning on make debug about doing a make clean first.)
955N/A module, download it from $(SOURCE_URL). (See "Building from git"
955N/A section below if MODULE_VERSION=git.)
955N/A Create a directory new/ containing patches generated against the
955N/A current tarball. Useful when updating to a new version and patches
955N/A still apply, but you want to get rid of warnings about patch fuzz
955N/A See "Building from git" section below.
955N/A Run the make install rules with DESTDIR set to a temporary directory,
955N/A that includes all the installed files. If a manifest already exists
955N/A there, this merges changes with the existing manifest so that you can
955N/A update when upgrading to a new upstream release.
955N/A=============================================================================
955N/AMake targets you can build in parent directories:
955N/A-------------------------------------------------
955N/AIn the top-level open-src directory, or any of the module type directories,
955N/Ayou can run these make commands to run the appropriate targets for all modules
955N/Ain that directory. The Makefiles at each level all include the same rules
955N/A Run make all in all subdirectories.
0N/A Run make clean in all subdirectories.
955N/A Run make clobber in all subdirectories.
955N/A Run make clobber in all subdirectories, then make all in all subdirs.
0N/A Run make install in all subdirectories.
0N/A Run make download in all subdirectories.
0N/A Run make source in all subdirectories.
0N/A Run make git-update in all subdirectories.
0N/A Run make debug-build in all subdirectories.
0N/A Run make debug-install in all subdirectories.
0N/A=============================================================================
0N/AVariables that can be set in the Makefile for each module:
0N/A----------------------------------------------------------
0N/ARequired for all modules:
0N/A - Name of the module being built - usually the same as the name of the
0N/A directory it's being built in and the tarball used for the sources.
0N/A - Version of the source to use, used by default in the tarball name and
0N/A source directory unpacked from it. Also exported to the package
0N/A attributes as __version:$(MODULE_NAME)__ for use in package manifests.
0N/A "git" - see "Building from git" below
0N/A "src" - used when there is no upstream tarball, only local sources
0N/ARequired for some modules:
0N/A - Interface Stability to list in attributes section of man page
0N/A * Required if SUNTOUCHED_MANPAGES is not empty
0N/A - Name of library built in this module
0N/A * Required for lib modules if SUNTOUCHED_MANPAGES is not empty
0N/A or if *.spec files are being used to set library versioning information.
0N/AOptional, default is empty:
0N/A - Command to use to uncompress tarball, if not bzcat
0N/A - Patches to apply to the sources after unpacking the tarball
Entries can be either a simple file name or filename,flags
to specify flags to be passed to gpatch. The flags argument
is most commonly used to specify -p1 to ignore the a/ & b/ path
prefixes in git-generated patch files - if no flags are specified,
-p0 is passed to treat paths as relative to the top of $(SOURCE_DIR).
- Directory containing additional source files to be linked into the
source directory by the default_source rule.
- If set to "yes", causes the build directory creation to make links for
all the files in the source directory into each build directory.
- Man pages to add Solaris attributes section and other common Solaris
MODULE_SUNTOUCH_MAN_FLAGS
-a '{attribute, value}, ...' - entries for Attributes section table
-l libname - add library line to synopsis
-p path - add path to command in synopsis
- ARC cases that covered this module, both for future reference by engineers
- description of the module to be used in license notices or package metadata
It should be short, specific, concise text, identifying the technology
covered by the associated license(s). It should fit naturally in the
sentence "This package may contain XXX." For example, "XXX" might be
"the xset command" or "bzip2 compression software." When appropriate,
this may begin with "portions of" or another, more specific qualifying
- description of software covered by a particular license notice, overrides
MODULE_LICENSE_PREPEND, MODULE_LICENSE_APPEND
- Files to be added to the beginning or end of LICENSE_FILE when generating
the license notice placed in the package.
- If an Oracle copyright notice should be added to a package to reflect
Oracle's modifications, then this should be the year string to include,
usually in the form "first, last", as in "1970, 2038". May be a single
year if modifications were all made in the same year.
- Third party license tracking number from Oracle's licensing database.
- Names of pkgconfig .pc or
.pc.in files in the module, which will be
"fixed" to add required -R flags for linking libraries with and remove
MODULE_SOURCE_DEPS, MODULE_CONFIGURE_DEPS,
MODULE_BUILD_DEPS, MODULE_INSTALL_DEPS
- Makefile
targets/rules that the default_* rules list as dependencies
MODULE_ADD_SOURCE_TARGETS, MODULE_ADD_CONFIGURE_TARGETS,
MODULE_ADD_BUILD_TARGETS, MODULE_ADD_INSTALL_TARGETS
- Additional
targets/rules run by "make source", "make configure", etc.
in addition to default_* if *_TARGETS is not overridden. Run for each
- Additional arguments passed to configure script by default_config rule
- Additional environment variables passed to configure script
- C Compiler flags passed to configure via CFLAGS variable by
- C++ Compiler flags passed to configure via CXXFLAGS variable by
- C preprocessor flags (-I & -D) passed to configure via CPPFLAGS
variable by default_config rule.
- C Compiler flags passed to configure via CFLAGS variable by
default_config rule when building debug versions (such as via "make debug")
- Linker flags passed to configure via LDFLAGS variable by default_config
USE_DEFAULT_CONFIG_CPPFLAGS
- If set to "no", don't pass the normal set of -I flags in CPPFLAGS
to configure script in default_config rule. MODULE_CPPFLAGS and
MODTYPE_CPPFLAGS will still be passed.
USE_DEFAULT_CONFIG_LDFLAGS
- If set to "no", don't pass the normal set of linker flags in LDFLAGS
to configure script in default_config rule. MODULE_LDFLAGS and
MODTYPE_LDFLAGS will still be passed.
- If set to "no", don't pass the normal set of default environment variables
to configure script in default_config rule. MODULE_CONFIG_ENV and
MODTYPE_CONFIG_ENG will still be passed.
- If set to "yes", the default_source rule will run autoreconf in the source
patches have been applied to the *.ac/*.am/*.in source files.
- If set to "yes", the default_config rule will run the script
- Additional options passed via LD_OPTIONS environment variable to
force options to be used by ld, regardless of options passed by
- Additional environment variables passed when calling make
by default_build & default_install rules
- Additional command line arguments passed when calling make
by default_build & default_install
- Additional command line arguments passed when calling make
- Additional command line arguments passed when calling make
MODULE_X11_BINCOMPAT_LINKS
MODULE_X11_LIBCOMPAT_LINKS
- For binaries previously delivered in
/usr/X11/bin or libraries previously
to the basenames of files to link from each of those directories to
the .so.* names, if both are still delivered.
Optional, with non-empty default:
* Important, for these, to override the default values, you must not only
set the variable, but set another variable <variable>_SET=yes before the
Makefile.inc is included to prevent the default from being set. For
-
IPS/pkg(5) package name that this module is shipped in. Used in
attributes section of man page, when generating manifests, and for
delivering license and other metadata from the build to the package.
Default: $(MODTYPE_PKGHIER)/$(MODULE_NAME), translated to lowercase
-
IPS/pkg(5) package classification that the package should be listed
under in the Package Manager GUI. Must be one of the values defined
- Name of the upstream source of this module, or "NONE"
Published in package metadata as the
info.upstream tag for the package.
Default:
X.Org Foundation
- URL of the web site of the upstream source of this module
- Compiler to use, either "suncc" or "gcc".
which is set to suncc in the master sources.
- make command to use, either "$(MAKE)" or "$(GNUMAKE)".
Default: "$(MAKE)" (which is assumed to be Solaris make, not GNU).
- Prefix to install files under, passed to configure scripts via --prefix.
Default: $(X11_DIR) (aka /usr).
- Directory to install documentation under
Default: $(MODTYPE_DOC_DIR) if it is set, otherwise
- Directory that will be created when the source tarball is unpacked.
Default: $(MODULE_NAME)-$(MODULE_VERSION)
Set to "NONE" if there is no upstream tarball.
- For
X.Org sources, what directory the source tarball & git repo is in
- URL to download the SOURCE_TARBALL from when running "make download"
Default: $(XORG_RELEASES_URL)/$(SOURCE_TARBALL_DIR)/$(SOURCE_TARBALL_NAME)
- URL to check out the current sources via the git code manager if
MODULE_VERSION is set to "git" - see "Building from git" below
Default: $(XORG_GIT_URL)/$(SOURCE_TARBALL_DIR)/$(MODULE_NAME).git
- What type of output to build for this module - usually the word-size of
the binaries built (32
and/or 64), but may be set to any string if other
distinctions are useful. For most modules that don't build binaries,
(fonts, proto headers, docs, etc.) it's set to 32 for simplicity.
For each value xx in this list, a build_xx directory will be made and
the source_xx, configure_xx, build_xx and install_xx rules run.
SOURCE_TARGETS, CONFIGURE_TARGETS, BUILD_TARGETS, INSTALL_TARGETS
- Makefile
targets/rules to run for "make source", "make configure",
"make build", and "make install"
Defaults: default_source, default_configure, default_build, default_install
The *_TARGETS may be appended to by setting the MODTYPE_ADD_*_TARGETS
and/or MODULE_ADD_*_TARGETS variables.
- File created by running the default_configure rule. If this file exists,
make will not run the default_configure rule - if it does not exist, it
Default: $(SOURCE_DIR)/Makefile
- File containing copyright & license information for this module.
Will be copied to $(MODULE_PKG_METADATA_DIR) and added as a license
File is looked for first in module directory, if not found there,
in top-level source directory (SOURCE_DIR).
- Name of the license. See the "license" attribute in pkg(5) for details.
Must be unique for each license aggregated into a package, so if two
upstream modules with different license texts are delivered into the
same package, they cannot both have the license name "MIT License", which
is why our default string includes the package name to disambiguate.
The value "Oracle" is a special case, indicating that Oracle owns all the
IP in a module, and can choose to release under the license terms of its
choice, while others building from this source tree will be using under
the MIT license terms that Oracle has offered the sources under.
The license used in this case depends on the LICENSE_CHOICE setting
Default: MIT License ($(MODULE_NAME))
- For modules in the lib directory, Multi-thread safety level to list in
attributes section of SUNTOUCHED_MANPAGES
Default: See XInitThreads(3X11)
=============================================================================
Variables that can be set in the
Makefile.inc for each module type:
-------------------------------------------------------------------
Some settings are common to most, if not all of the modules of a given
type. For those, these variables can be set in
open-src/<module_type>/
Makefile.inc - they have the same meanings and uses
as the MODULE_* versions documented above, and appear in commands before
the MODULE_* versions - the general pattern is
foo=<tree-wide-defaults> $(MODTYPE_foo) $(MODULE_foo)
Required for all module types:
- Name of the directory for this module type, usually the same as the
directory for the module type in
X.Org's source trees.
Optional, default is empty:
- MODTYPE_SUNTOUCH_MAN_FLAGS
- MODTYPE_ADD_SOURCE_TARGETS
- MODTYPE_ADD_CONFIGURE_TARGETS
- MODTYPE_ADD_BUILD_TARGETS
- MODTYPE_ADD_INSTALL_TARGETS
- MODTYPE_BUILD_MAKEFLAGS
- MODTYPE_INSTALL_MAKEFLAGS
Optional, with non-empty default:
[See note in module variable section about setting _SET variables to override]
=============================================================================
Setting per-platform variables:
-------------------------------
for the platform being built. You can reference this variable in the
names of other variables to set different values for each platform.
For instance, to build only 64-bit on SPARC, but both 32-bit and 64-bit
BUILD_TYPES=$(BUILD_TYPES_$(MACH))
=============================================================================
---------------------------------
"make setup" in the top-level directory of the X gate (
i.e. the parent of
differ depending on who is building, such as distro branding, licensing,
To force a specific configuration, specify X_BUILD_OPTIONS when running
make setup X_BUILD_OPTIONS=opensolaris
Otherwise it will strip the last two components of the output of domainname,
lowercase them and look for a matching file - for instance, if building on
If X_BUILD_OPTIONS is not found, and a domainname match is not found, then
- String used when a reference to the distro name is needed. Mostly used
- Vendor name string reported by the X server in the log & protocol.
The vendor name needs to include "
X.Org Foundation" for software
like cairo that does strstr on VendorName to detect servers built
or for xdpyinfo to convert the vendor version integer to a human-friendly
- URL printed by the X server for Xorg -version, in the
Xorg.0.log, and
in crash messages, for where to get help or check you have the latest
Optional, with empty default:
- file containing a notice prepended to package license notices for modules
containing GPL licensed sources, for builders who wish to specify choice
of licenses in modules that are dual-licensed or "GPLv2 or later".
- name of a file in
pkg/transforms that is added to the list passed to
pkgmogrify when building packages, for setting distribution-specific
- url for a mirror site containing all the upstream tarballs needed during
the build - can be any protocol supported by wget. If not set, then
"make download" will wget directly from the upstream sites on the internet.
Optional, with non-empty default:
* Important, for these, to override the default values, you must not only
set the variable, but set another variable <variable>_SET=yes before the
Makefile.inc is included to prevent the default from being set.
- For modules with MODULE_LICENSE="Oracle", this controls which license
terms are published in the package. This must be set to "Oracle" for
builds done for Oracle Solaris. If not set, it defaults to "open",
which is the value that all others must use, unless they have obtained
special permission from Oracle to license the sources under something
other than the standard MIT license terms used for X11 software.
XORG_RELEASES_URL & SF_DOWNLOADS_URL
- urls for
X.Org & sourceforge mirrors to download tarballs from
FDO_GIT_URL & XORG_GIT_URL
X.Org, Mesa, pixman, etc. - defaults to anonymous git over http, can
change to use another protocol if needed
=============================================================================
Tools for developers to use:
find-build-errors - looks for a
log/buildit-XW file (or another file you
specify on the command line) and tries to isolate out just the
build errors for easier reading than the raw build logs.
If you did buildit -p, also shows packaging errors.
xmake - when you change one file in a large module like xserver and just
want to rebuild in that subdirectory of the build-<platform>
tree, running xmake will attempt to run make or gmake in that
directory with the same flags and environment variables that would
be passed from running make in the module make directory
xmake can also be used in higher level directories of the tree
where it will call dmake with the correct options for parallel
=============================================================================
For debugging and development purposes, such as working on the merge of
a
X.org release still in development, you can choose to to check out a
the upstream sources from a the git repository instead of a tarball.
You must *NOT* check in to the master gate a module using this feature,
since this would produce a build that's not reproducible and changing
To use this, set MODULE_VERSION to "git" in a module's Makefile.
To check out a branch other than master, add GIT_BRANCH="branch-name".
Once you've done this "make download" will clone the git repo initially, and
"make git-update" will update an existing repo. The clone will be located
in the $(MODULE_NAME)-git subdirectory in the module directory, and the
"make source" command will copy it instead of unpacking a tarball.
=============================================================================
Known deficiencies (aka TODO):
Things we should fix someday, but haven't had time to do yet, include:
- Builds are slower than they could be. Things we might be able to do to
- Using a cache of configure script results shared among all the
- Profiling the builds to see where bottlenecks are
- There aren't dependency relationships listed in most of the module
and make, because it won't find many of the dependencies - pretty much you
have to run ./buildit at the toplevel first to build the entire tree and then
go to work on the module you care about. It would be cool if it would do
this for you (like I believe the ON tree does), though tracking down all the
dependencies will probably take a while - getting them done for
xserver/xorg first would be most useful.
=============================================================================
Copyright (c) 2008, 2014, Oracle
and/or its affiliates. All rights reserved.
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice (including the next
paragraph) shall be included in all copies or substantial portions of the
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.