# for it to operate as expected. When included the module generates
# the requested rules based on the contents of its control variables.
# 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)
# 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
# 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
# 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 <>)
# 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 <>)
COPY_H = $(BASE)/buildlib/copy.mak
YODL_MANPAGE_H = $(BASE)/buildlib/yodl_manpage.mak
SGML_MANPAGE_H = $(BASE)/buildlib/sgml_manpage.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
FAIL_H = $(BASE)/buildlib/fail.mak
PODOMAIN_H = $(BASE)/buildlib/podomain.mak
XML_MANPAGE_H = $(BASE)/buildlib/xml_manpage.mak
FAIL_H = $(BASE)/buildlib/fail.mak
PODOMAIN_H = $(BASE)/buildlib/podomain.mak
mkdir -p $(patsubst %/,%,$(sort $(MKDIRS)))
# Header file control. We want all published interface headers to go
mkdir -p $(patsubst %/,%,$(sort $(MKDIRS)))
# Header file control. We want all published interface headers to go
# 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
# 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