I had a strange problem building the current releases of Exim 4 or Exim 3
on a couple of fairly new FreeBSD boxes (one running 4.5-RELEASE, the other
running 4.7-RELEASE) and I wanted to share how I fixed it.
The symptom was that upon untarring the distribution and creating
Local/Makefile and Local/eximon.conf in the usual way, then issuing a
'make' from the base directory, the error message
../scripts/newer: Can't open ../scripts/newer: No such file or directory
would issue a couple of times, and everything would stop.
The explanation turned out to be that in the binary-removal logic for the
target libraries in build-(OS)/Makefile, there are sequential @commands like
506 buildpcre:
507 @cd pcre; $(MAKE) SHELL=$(SHELL) AR="$(AR)" $(MFLAGS)
CC="$(CC)" \
508 CFLAGS="$(CFLAGS) $(PCRE_CFLAGS)" \
509 RANLIB="$(RANLIB)" HDRS="$(PHDRS)" \
510 INCLUDE="$(INCLUDE) $(IPV6_INCLUDE) $(TLS_INCLUDE)"
511 @if $(SHELL) $(SCRIPTS)/newer pcre/libpcre.a exim; then \
512 /bin/rm -f exim eximon.bin; fi
The second command assumes that the 'cd pcre' in the first command is no
longer in effect, but I had a default set of MAKEFLAGS of '-j3' so that
FreeBSD make(1) tried to "optimize" and ended up un both commands in the
same shell process, with the result that $(SCRIPTS) (which has a value of
'../scripts') is not found.
The simplest solution is to force make(1) to use backwards compatibility
mode with each command in its own shell using the -B flag. To ensure that
this happens throughout the build, I suggest exporting it in your
environment, e.g.
MAKEFLAGS='-B'
export MAKEFLAGS
make
For whatever it's worth, it would be slightly more robust if $(SCRIPTS)
were defined absolutely off of some 'BASEDIR != pwd' in the top level
Makefile. It can get confusing parenting around when you need to visit
subdirectories during a make.
