--------------
The developer is expected to write a makefile fragment, in each
-relevant subdirectory, called `Subdir.sd.mk'.
+relevant subdirectory, called `Dir.sd.mk'.
These fragments may contain ordinary make language. Unqualified
filenames are relative to the build toplevel, and all commands all run
`the build directory corresponding to this .sd.mk file', etc.
There are a variety of convenient constructions.
-The result is that to a large extent, the Subdir.sd.mk has an easy way
+The result is that to a large extent, the Dir.sd.mk has an easy way
to namespace its "local" make variables, and an easy way to refer to
its "local" filenames (and filenames in general).
-The Subdir.sd.mk's are filtered, fed through autoconf in the usual way
+The Dir.sd.mk's are filtered, fed through autoconf in the usual way
(for @..@-substitutions) and included by one autogenerated toplevel
makefile.
which exists purely to capture ordinary make invocations and arrange
for something suitable to happen.
-Where there are dependencies between subdirectories, each Subdir.sd.mk
+Where there are dependencies between subdirectories, each Dir.sd.mk
can simply refer to files in other subdirectories directly.
Invocation, "recursive" per-directory targets
subdirectory `src' has a target `src/all'. The rules for these are
automatically generated from the settings of the per-directory
&TARGETS variables. &TARGETS is magic in this way. (In
-src/Subdir.sd.mk, &TARGETS of course refers to a make variable called
+src/Dir.sd.mk, &TARGETS of course refers to a make variable called
src_TARGETS.)
The `all' target in a parent directory is taken to imply the `all'
The files Prefix.sd.mk and Suffix.sd.mk in the toplevel of the source
are automatically processed before and after each individual
-directory's Subdir.sd.mk, and the &-substituted contents therefore
+directory's Dir.sd.mk, and the &-substituted contents therefore
appear once for each subdirectory.
This lets you do per-directory boilerplate. Some useful boilerplate
&:include subdirmk/clean.sd.mk
For example you could put that in Suffix.sd.mk.
-The top-level Subdir.sd.mk is the first makefile included after the
+The top-level Dir.sd.mk is the first makefile included after the
autogenerated `main.mk' which merely has some basic settings and
includes. So if you want to get in early and set global variables,
-put them near the top of Subdir.sd.mk.
+put them near the top of Dir.sd.mk.
The file Final.sd.mk in the toplevel directory is processed and
included after all the other files.
------------------
If want to set global variables, such as CC, that should only be done
-once. You can put them in your top-level Subdir.sd.mk, or a separate
+once. You can put them in your top-level Dir.sd.mk, or a separate
file you `include' and declare using SUBDIRMK_MAKEFILES.
If you need different settings of variables like CC for different
subdirectories, you should probably do that with target-specific
variable settings. See the info node `(make) Target-specific'.
-Subdirectory templates `.sd.mk' vs plain autoconf templates `.mk.in'
+Directory templates `.sd.mk' vs plain autoconf templates `.mk.in'
--------------------------------------------------------------------
There are two kinds of template files.
Instantiated Usu. once per subdir Once only
- Need to be mentioned No, but Subdir.sd.mk All not in subdirmk/
+ Need to be mentioned No, but Dir.sd.mk All not in subdirmk/
in configure.ac? via SUBDIRMK_SUBDIRS via SUBDIRMK_MAKEFILES
How to include `&:include foo.sd.mk' `include foo.mk'
in all relevant .sd.mk in only one
- (but not needed for Subdir.sd.mk
+ (but not needed for Dir.sd.mk
Prefix, Suffix, Final)
If you `include subdirmk/regen.mk', dependency management and
(i) In the build tree, or in the source tree ?
- (ii) In (or relative to) the subdirectory to which this Subdir.sd.mk
+ (ii) In (or relative to) the subdirectory to which this Dir.sd.mk
relates, or relative to the project's top level ?
(iii) Absolute or relative pathname ? Usually relative pathnames
m4_include([subdirmk/subdirmk.ac])
SUBDIRMK_SUBDIRS([...list of subdirectories in relative syntax...])
-Write a Subdir.sd.mk in each directory. The toplevel one should
+Write a Dir.sd.mk in each directory. The toplevel one should
probably contain:
include subdirmk/usual.mk
-----
You can convert your project incrementally. Start with the top-level
-Makefile.in and rename it to Subdir.sd.mk, and add the appropriate
+Makefile.in and rename it to Dir.sd.mk, and add the appropriate
stuff to configure.ac, and fix everything up. Leave the existing
$(MAKE) -C for your existing subdirectories alone. Then you can
convert individual subdirectories, or classes of subdirectories, at
# $(srcdir)/subdirmk/generate [--srcdir=SRCDIR] [--] SUBDIR...
#
# generates in each subdirectory
-# Subdir.mk.tmp
+# Dir.mk.tmp
# Makefile
# and in toplevel
# main.mk.tmp
my ($f, $enoentok) = @_;
process_input_mk($targets, "${srcdir}/$f", \$esclit, $enoentok);
};
- $pi->("Prefix.sd.mk", 1);
- $pi->("${dir_prefix}Subdir.sd.mk", 0);
- $pi->("Suffix.sd.mk", 1);
+ $pi->("Prefix.sd.mk", 1);
+ $pi->("${dir_prefix}Dir.sd.mk", 0);
+ $pi->("Suffix.sd.mk", 1);
}
sub process_subtree ($$);
# ^ this is the only var which we need before we come back from
# the recursion.
- push @output_makefiles, "${dir_prefix}Subdir.mk";
+ push @output_makefiles, "${dir_prefix}Dir.mk";
write_makefile($dir_prefix, scalar @$path);
my %targets = (all => []);
}
set_dir_vars($path);
- start_output_file("${dir_prefix}Subdir.mk.tmp");
+ start_output_file("${dir_prefix}Dir.mk.tmp");
if ($node->[2]) {
filter_subdir_mk(\%targets);
} else {
- my $sdmk = "${dir_prefix}Subdir.sd.mk";
+ my $sdmk = "${dir_prefix}Dir.sd.mk";
if (stat $sdmk) {
die
"subdirmk: $sdmk unexpectedly exists (${dir_prefix} not mentioned on subdirmk/generate command line, maybe directory is missing from SUBDIRMK_SUBDIRS)";
# Usage:
# include subdirmk/regen.mk
-# (probably in toplevel Subdir.sd.mk)
+# (probably in toplevel Dir.sd.mk)
#
# Arranges that config.status is automatically rerun to update
# makefiles from templates, whenever a template *.sd.mk or *.mk.in is
# This filtering arranges that we can often run config.status to
# generate only particular output files. We look for *inputs* that
# have changed. If the only inputs that have changed are ones that we
-# know affect only one output (Subdir.sd.mk, Final.sd.mk and *.mk.in),
+# know affect only one output (Dir.sd.mk, Final.sd.mk and *.mk.in),
# we pass config.status the corresponding output file names.
# Otherwise we pass nothing and config.status does them all. We need
-# to mention Subdir.sd.mk twice because if $(top_srcdir) is `.', make
+# to mention Dir.sd.mk twice because if $(top_srcdir) is `.', make
# elides the directory part from $?. Similarly but not identically
# Final.sd.mk.
$(SUBDIRMK_REGEN_NDEBUG): REGEN STAMP WANTS DEPS=$?
./$(CONFIG_STATUS) $(if \
- $(filter-out Subdir.sd.mk %/Subdir.sd.mk \
+ $(filter-out Dir.sd.mk %/Dir.sd.mk \
Final.sd.mk $(top_srcdir)/Final.sd.mk \
%.mk.in \
, $?),, \
~ianmdlvl / secnet.git / commitdiff