|
@@ -6,26 +6,26 @@
|
|
|
# for it to operate as expected. When included the module generates
|
|
# for it to operate as expected. When included the module generates
|
|
|
# the requested rules based on the contents of its control variables.
|
|
# 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
|
|
# local variables. To do this we use the 'Computed Names' feature of
|
|
|
# gmake. Each module declares a LOCAL scope and access it with,
|
|
# gmake. Each module declares a LOCAL scope and access it with,
|
|
|
# $($(LOCAL)-VAR)
|
|
# $($(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)
|
|
# 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
|
|
# and then within the rule $(@F) gets back $(LOCAL)! Other rules will
|
|
|
# have to use some other mechanism (filter perhaps?) The reason such
|
|
# have to use some other mechanism (filter perhaps?) The reason such
|
|
|
# lengths are used is so that each directory can contain several 'instances'
|
|
# 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 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
|
|
# 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
|
|
# 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
|
|
# there. However unlike automake this is not done with a VPATH build
|
|
|
# (vpath builds break the distinction between #include "" and #include <>)
|
|
# (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
|
|
# within the source itself which is much more compatible with compilation
|
|
|
# environments.
|
|
# environments.
|
|
|
ifndef NOISY
|
|
ifndef NOISY
|
|
@@ -99,12 +99,12 @@ endif
|
|
|
|
|
|
|
|
# Source location control
|
|
# Source location control
|
|
|
# SUBDIRS specifies sub components of the module that
|
|
# 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
|
|
# This should be declared before including this file
|
|
|
SUBDIRS+=
|
|
SUBDIRS+=
|
|
|
|
|
|
|
|
# Header file control.
|
|
# 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.
|
|
# will be published to.
|
|
|
# This should be declared before including this file
|
|
# This should be declared before including this file
|
|
|
HEADER_TARGETDIRS+=
|
|
HEADER_TARGETDIRS+=
|
|
@@ -133,7 +133,7 @@ dirs:
|
|
|
mkdir -p $(patsubst %/,%,$(sort $(MKDIRS)))
|
|
mkdir -p $(patsubst %/,%,$(sort $(MKDIRS)))
|
|
|
|
|
|
|
|
# Header file control. We want all published interface headers to go
|
|
# 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
|
|
# search paths here
|
|
|
vpath %.h $(SUBDIRS)
|
|
vpath %.h $(SUBDIRS)
|
|
|
$(INCLUDE)/%.h $(addprefix $(INCLUDE)/,$(addsuffix /%.h,$(HEADER_TARGETDIRS))) : %.h
|
|
$(INCLUDE)/%.h $(addprefix $(INCLUDE)/,$(addsuffix /%.h,$(HEADER_TARGETDIRS))) : %.h
|
|
@@ -142,7 +142,7 @@ $(INCLUDE)/%.h $(addprefix $(INCLUDE)/,$(addsuffix /%.h,$(HEADER_TARGETDIRS))) :
|
|
|
# Dependency generation. We want to generate a .d file using gnu cpp.
|
|
# 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,
|
|
# 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
|
|
# 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.
|
|
# by the DEPFLAG case.
|
|
|
# Compile rules are expected to call this macro after calling the compiler
|
|
# Compile rules are expected to call this macro after calling the compiler
|
|
|
ifdef GCC3DEP
|
|
ifdef GCC3DEP
|
David Kalnischkies