]> git.saurik.com Git - apt.git/blobdiff - buildlib/defaults.mak
test: apt-get source with more than one argument
[apt.git] / buildlib / defaults.mak
index a171522d55c5e59641180aceaabd450a731928f2..599b9ed852d6af3086e31550097371c3fb0b036e 100644 (file)
@@ -6,26 +6,26 @@
 # 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
-# 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 <>)
 
 # 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
 # within the source itself which is much more compatible with compilation
 # environments.
 ifndef NOISY
@@ -81,9 +81,7 @@ MANPAGE_H = $(BASE)/buildlib/manpage.mak
 PROGRAM_H = $(BASE)/buildlib/program.mak
 PYTHON_H = $(BASE)/buildlib/python.mak
 COPY_H = $(BASE)/buildlib/copy.mak
 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
 
 FAIL_H = $(BASE)/buildlib/fail.mak
 PODOMAIN_H = $(BASE)/buildlib/podomain.mak
 
@@ -99,12 +97,12 @@ endif
 
 # Source location control
 # SUBDIRS specifies sub components of the module that
 
 # 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. 
 # 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+=
 # will be published to.
 # This should be declared before including this file
 HEADER_TARGETDIRS+=
@@ -120,10 +118,10 @@ MKDIRS := $(BIN)
 # list
 .PHONY: headers library clean veryclean all binary program doc dirs
 .PHONY: maintainer-clean dist-clean distclean pristine sanity
 # list
 .PHONY: headers library clean veryclean all binary program doc dirs
 .PHONY: maintainer-clean dist-clean distclean pristine sanity
-all: binary doc
+all: dirs binary doc
 binary: library program
 maintainer-clean dist-clean distclean pristine sanity: veryclean
 binary: library program
 maintainer-clean dist-clean distclean pristine sanity: veryclean
-headers library clean veryclean program:
+startup headers library clean veryclean program test update-po manpages debiandoc:
 
 veryclean:
        echo Very Clean done for $(SUBDIR)
 
 veryclean:
        echo Very Clean done for $(SUBDIR)
@@ -133,7 +131,7 @@ dirs:
        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
-# 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
 # search paths here
 vpath %.h $(SUBDIRS)
 $(INCLUDE)/%.h $(addprefix $(INCLUDE)/,$(addsuffix /%.h,$(HEADER_TARGETDIRS))) : %.h
@@ -142,7 +140,7 @@ $(INCLUDE)/%.h $(addprefix $(INCLUDE)/,$(addsuffix /%.h,$(HEADER_TARGETDIRS))) :
 # 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 
-# 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
 # by the DEPFLAG case.
 # Compile rules are expected to call this macro after calling the compiler
 ifdef GCC3DEP
@@ -174,12 +172,11 @@ ifeq ($(NUM_PROCS),1)
   PARALLEL_RUN=no
 endif
 
   PARALLEL_RUN=no
 endif
 
-# mvo: commented out, lead to build failures in the arch-build target
-#ifndef PARALLEL_RUN
-# PARALLEL_RUN=yes
-# .EXPORT: PARALLEL_RUN
-# # handle recursion
-# ifneq ($(NUM_PROCS),)
-#  MAKEFLAGS += -j $(NUM_PROCS)
-# endif
-#endif
+ifndef PARALLEL_RUN
+ PARALLEL_RUN=yes
+ export PARALLEL_RUN
+ # handle recursion
+ ifneq ($(NUM_PROCS),)
+  MAKEFLAGS += -j $(NUM_PROCS)
+ endif
+endif