The release tools' makefile body inspects a number of
target variables that you can define. The variables
define what you want to build and where the results ought to be
installed. All the target variables start with TARGET, and
the remaining part of the name tells the type of the target. At times
there are several similar target types that differ only in where the
results are to be installed.
Below are the definitions of what each target variable does and
how you would use it. The way to use them is to assign values to
those variables before including standard.mk. The makefile
body inspects the values and defines the rules to build the named
targets. Where both private and normal targets can be mentioned, the
difference is in visibility. For file-kind targets the difference is
that private targets will not be installed by the release tools. The
primary use for them is typically as test programs or utilities the
package needs during the build and builds itself. For directory-kind
targets the difference is that the private ones will be ignored by
SRT-defined rules that normally recurse into subdirectories. Those
can be useful for defining subdirectories for documentation or
testsuites that need to be under explicit control of the package
authors.
 | The executable file name extension $(exeext) should not be used
when naming programs in these variables or in their property
definitions. The release tools will add the suffix when it defines
rules to build the targets. The only occasion where the suffix should
be used in the makefile is when the program is mentioned in
dependencies or rules in the makefile. Since the suffix is defined
only after standard.mk has been included, such rules must
come after the inclusion. Note that the implication of generating the
rules with the suffix is that if you wish to name that target on the
make command line, then you need to add the suffix. |
- TARGET_BINS, TARGET_PRIVATE_BINS
Programs, typically executables built from sources or
shell scripts delivered with the package. The targets mentioned in
TARGET_BINS will be installed into $(bindir). If no properties have been
defined for a program, the developer becomes responsible for writing
the rules for it; it will still be installed by the release tools.
Moreover, if only parts of the properties have been defined--such
as only object files but no source files are mentioned--the
developer becomes responsible for delivering the missing
bits.
- TARGET_SBINS
Like TARGET_BINS except that these will
be installed into $(sbindir).
- TARGET_LIBEXECS
Like TARGET_BINS except that these will
be installed into $(libexecdir).
| The target and property definition variables should
always use the unix library naming conventions:
libname.a for archive libraries and
libname.so for shared libraries. SRT will
map the name to the operating system's and the compiler's conventions
when generating rules.
In contrast, the library prefix $(libprefix) and the suffixes
$(libext) and
$(shlext)
should be used when naming libraries in makefile rules.
For example, the archive library class ought to be called
libclass.a in the target and property variable definitions,
but $(libprefix)class.$(libext) in dependencies. Again,
as these variables will be defined only after standard.mk
has been included, the rules using them must come after the standard
makefile body has been included. |
 | On AIX 4.1 and on Windows NT it is not possible to build
both a shared library and an archive library with the same base name.
If you are building on these platforms you must give the libraries
different base names such as name and shname.
This is because on both of these systems either the shared library
itself or some associated file will end up having the same extension
as an archive library. |
| On AIX 4.1 shared libraries will depend on two additional
targets: an .imp file and an .exp file; the base
names of these are the same as the shared library name. These files
need to define the imports and exports of the library, respectively,
as described in the AIX linker manuals. For example, if you want the
library to export all symbols it defines except for dlclose,
dlopen, dlsym and
dlerror[1] and import none itself, you could write rules
something like this:
libshclass.exp: $(libshclass.so_OBJS)
echo '#! libshclass.a' > $@
nm -B $^ | grep ' [BAD] ' | sed 's/^ *//' | cut -f3 -d' ' | \
sort | uniq | sed '/dl\(close\|open\|sym\|error\)/d' >> $@
libshclass.imp:
echo '#! libshclass.a' > $@ |
|
| On Windows NT no DEF file is expected; the source code is
expected to use the __declspec modifiers to mark what is to
be imported and exported. This will automatically cause the linker to
create the DEF file and the import library. The import library will
be installed together with the DLL. |
- TARGET_LIBS, TARGET_PRIVATE_LIBS
Archive libraries. The targets mentioned in
TARGET_LIBS will be installed into $(libdir). If no properties have been
defined for a program, the developer becomes responsible for writing
the rules for it; it will still be installed by the release tools.
Moreover, if only parts of the properties have been defined--such
as only object files but no source files are mentioned--the
developer becomes responsible for delivering the missing
bits.
- TARGET_SHLIBS, TARGET_PRIVATE_SHLIBS
Shared libraries;[2] the targets mentioned in
TARGET_SHLIBS will be installed into $(libdir).
- TARGET_SUBDIRS, TARGET_PRIVATE_SUBDIRS
The subdirectories for which make should
generate rules. SRT-defined phony rules such as install
will descend into the public kind of subdirectories. No rules will be
generated for descending into the private subdirectories. It is up to
the makefile author to write dependencies or commands that will cause
the recursion. Note that the subdirectory names must be immediate
subdirectories of $(srcdir), that is, their names cannot
contain slashes.
- TARGET_SUBPACKAGES
The subpackages make should descend into. Note
that subpackages are not normal subdirectories and must not be treated
as such. The value of this variable would typically be just
@PACKAGES@; a real value would then be substituted by the
configure script.
The first five of the following targets (TARGET_DATA
through TARGET_ARCHINCLUDE) all accept file and directory
names and allow targets to be renamed upon installation. Each value
in these variables ought to be either of the form
NAME:INSTNAME or just a plain
NAME without colons in it; the latter is equivalent to
NAME:NAME. The meaning of these
pair is that NAME will be copied to the installation
directory as INSTNAME. If the target is a file, the
copying will be carried out only if the installation target does not
exist or the local version has changed (not just has an updated time
stamp). If the target is a directory, it will be copied into the
installation directory with tar,[3] followed by removing all CVS
directories and GNUmakefiles from the installation area.
The target renaming can also be used to create directories in
the installation area. For example, specifying a documentation target
doc/relnotes.txt:MyPackage/notes/relnotes.txt will cause
the directory MyPackage/notes to be created before the
file is copied there. Moreover, for either type of of targets the
input will be automatically looked up in the current directory, in
$(srcdir) and in
$(top_srcdir), in
that order. There is no need to mention these variables if the file
or the directory exists in one of these. For instance, in the same
example doc directory would usually be found in
$(srcdir).
- TARGET_DATA
Files or directories to install into $(datadir).
- TARGET_SHARE
Files or directories to install into $(sharedstatedir).
- TARGET_DOC
Files or directories to install into $(docdir).
- TARGET_INCLUDE
Files or directories to install into $(includedir).
- TARGET_ARCHINCLUDE
Files or directories to install into $(archincludedir).
- TARGET_MAN
Manual page targets. The targets mentioned in this
variable must be of the form
S:FILE.EXT where
S is a manual section number (1 through 9, 1m, or the
lowecal letter L). The files will be installed into the directory for
that manual section (see $(man1dir) through $(manldir)) with the file name
extension appropriate to that section (see $(man1ext) through $(manlext)). That is, only the
non-directory part of FILE part will remain unchanged;
the directory and the extension will be determined by the manual
section. Like with the other targets mentioned above, the files will
be looked up in $(srcdir)
and $(top_srcdir), in
that order, if they are not found in the current
directory.
- TARGET_OTHER
Other targets that will be built but not installed
anywhere. You might want to use this and provide your own
install-local and installdirs-local target
extensions to handle special cases.
- TARGET_REMAKE_CONFIGURE
This variable can only be set to empty or the value
yes. If set, rules will be created to regenerate
configure from configure.in and to update
config.status if configure has changed. This
variable can be set meaningfully in directories other than just the
top level makefile in the package: it will still update the
config.status.
- TARGET_REMAKE_MAKEFILES[4]
Makefiles targets. The targets mentioned in this
variable have to be makefiles generated by the configure
script, and would typically be the list of files mentioned in the
first argument to SRT_OUTPUT. The same syntax of defining
just a file or a file and a template separated by colons is accepted.
The makefile will depend on config.status so for maximum
benefit you would want to define TARGET_REMAKE_CONFIGURE
also.
The reason why this works is that make will try to update
all makefiles (using the targets defined in the makefile itself)
before building any other targets. Thus, when you have defined this
target variable and you modify GNUmakefile.in,
GNUmakefile will be recreated by running
config.status. After that make will restart itself
with the new makefile, and then consider the targets it was to build.
If nothing needs to be updated make will proceed as
usual.
- TARGET_REMAKE_HEADERS
Like TARGET_REMAKE_MAKEFILES but for header
files generated by configure. That is, you would give here
the same argument as you would give to AC_CONFIG_HEADER in
configure.in.
Notes