#  $HeadURL$ $LastChangedRevision$

#
#  Preamble
#

include 			$(shell aderoot include)/Makefile

#
#  Variables used only in this Makefile
#

FAD_MF_CREATEDIR_CMD		= $(ADE_MF_CREATEDIR_CMD)
FAD_MF_CREATEDIR_FLAGS		= $(ADE_MF_CREATEDIR_FLAGS)
FAD_MF_OTHERINSTALLDIRS		= $(STTDIR)/fadscan $(CFGDIR)/fadscan $(LOGDIR)/fadscan

#
#  Recipes for ADE-standard targets
#

list_subdirs:
				echo bin bldcfg doc man tests

#
#  Dependencies for ADE-standard targets
#

#  If $(FAD_MF_OTHERINSTALLDIRS) is mentioned as the dependencies for the 'install'
#  target, then, from pristine sources, 'make configure' will generate the warning
#  "Makefile:35: target `/fadscan' given more than once in the same rule." which
#  is because: before 'make configure' has completed, STTDIR, CFGDIR and LOGDIR are
#  not defined (paths.mk does not exist, but its non-existence is not an error). 
#  This in turn means that FAD_MF_OTHERINSTALLDIRS, from the defintion above, is equal 
#  to '/fadscan /fadscan /fadscan'. And hence the warning message. Therefore, 
#  variables based on at-some-time undefined variables should not be allowed in the
#  dependency list. But in a recipe is ok. Or at least, this fixes the 
#  'make clean distclean; make configure' problem. Running 'make configure compile
#  install' would probably be bad because the 'make install' part of that would be
#  using still undefined paths I think. Though I'm not 100% sure of this. But if
#  the configure and install parts are run as separate commands, then there is
#  no problem; the variable (STTDIR, ...) will have been defined by the configure
#  step (which didn't see it undefined in the install-time recipe) and when the
#  install step is run then the variable is defined.
install:			other_directories_for_fadscan


#
#  Recipes for non-ADE targets
#

other_directories_for_fadscan:
				$(FAD_MF_CREATEDIR_CMD) $(FAD_MF_CREATEDIR_FLAGS) $(FAD_MF_OTHERINSTALLDIRS)