# for it to operate as expected. When included the module generates
# the requested rules based on the contents of its control variables.
-# This works out very well and allows a good degree of flexability.
-# To accomidate some of the features we introduce the concept of
+# This works out very well and allows a good degree of flexibility.
+# To accommodate some of the features we introduce the concept of
# local variables. To do this we use the 'Computed Names' feature of
# gmake. Each module declares a LOCAL scope and access it with,
# $($(LOCAL)-VAR)
-# This works very well but it is important to rembember that within
-# a rule the LOCAL var is unavailble, it will have to be constructed
-# from the information in the rule invokation. For stock rules like
+# This works very well but it is important to remember that within
+# a rule the LOCAL var is unavailable, it will have to be constructed
+# from the information in the rule invocation. For stock rules like
# clean this is simple, we use a local clean rule called clean/$(LOCAL)
# and then within the rule $(@F) gets back $(LOCAL)! Other rules will
# have to use some other mechanism (filter perhaps?) The reason such
# lengths are used is so that each directory can contain several 'instances'
# of any given module. I notice that the very latest gmake has the concept
# of local variables for rules. It is possible this feature in conjunction
-# with the generated names will provide a very powerfull solution indeed!
+# with the generated names will provide a very powerful solution indeed!
# A build directory is used by default, all generated items get put into
# there. However unlike automake this is not done with a VPATH build
# (vpath builds break the distinction between #include "" and #include <>)
-# but by explicly setting the BUILD variable. Make is invoked from
+# but by explicitly setting the BUILD variable. Make is invoked from
# within the source itself which is much more compatible with compilation
# environments.
ifndef NOISY
PROGRAM_H = $(BASE)/buildlib/program.mak
PYTHON_H = $(BASE)/buildlib/python.mak
COPY_H = $(BASE)/buildlib/copy.mak
-YODL_MANPAGE_H = $(BASE)/buildlib/yodl_manpage.mak
-SGML_MANPAGE_H = $(BASE)/buildlib/sgml_manpage.mak
-XML_MANPAGE_H = $(BASE)/buildlib/xml_manpage.mak
+PO4A_MANPAGE_H = $(BASE)/buildlib/po4a_manpage.mak
FAIL_H = $(BASE)/buildlib/fail.mak
PODOMAIN_H = $(BASE)/buildlib/podomain.mak
# Source location control
# SUBDIRS specifies sub components of the module that
-# may be located in subdrictories of the source dir.
+# may be located in subdirectories of the source dir.
# This should be declared before including this file
SUBDIRS+=
# Header file control.
-# TARGETDIRS indicitates all of the locations that public headers
+# TARGETDIRS indicates all of the locations that public headers
# will be published to.
# This should be declared before including this file
HEADER_TARGETDIRS+=
mkdir -p $(patsubst %/,%,$(sort $(MKDIRS)))
# Header file control. We want all published interface headers to go
-# into the build directory from thier source dirs. We setup some
+# into the build directory from their source dirs. We setup some
# search paths here
vpath %.h $(SUBDIRS)
$(INCLUDE)/%.h $(addprefix $(INCLUDE)/,$(addsuffix /%.h,$(HEADER_TARGETDIRS))) : %.h
# Dependency generation. We want to generate a .d file using gnu cpp.
# For GNU systems the compiler can spit out a .d file while it is compiling,
# this is specified with the INLINEDEPFLAG. Other systems might have a
-# makedep program that can be called after compiling, that's illistrated
+# makedep program that can be called after compiling, that's illustrated
# by the DEPFLAG case.
# Compile rules are expected to call this macro after calling the compiler
ifdef GCC3DEP
projects / apt.git / blobdiff