# 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
# 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
Each file gets a block at the top that should describe what the file does,
basically a summary of purpose along with any special notes and
attributions. The }}} and {{{ are folding marks if you have a folding
-editor such as jed, the function seperators are intended to give
-a visual seperate between functions for easier browsing of the larger files,
+editor such as jed, the function separators are intended to give
+a visual separate between functions for easier browsing of the larger files,
or indexed folding if you have such an editor.
Each file should have 1 or 0 primary include files, that include
pointer is an 'input' parameter (designated generally by an =0,
indicating a default of 'none')
-Non-ownership transfering arrays/lists should probably return an iterator
+Non-ownership transferring arrays/lists should probably return an iterator
typedef or references..
HCoop / ntk / apt.git / commitdiff