Milter-greylist

Hello all,


On 2013-08-30 16:45, Bruncsak, Attila wrote:
>  > My old make does not support parallel builds.
>  > Which is the configure option that I can use to disable that special
> build feature?
>  > ( Instead do the traditional sequential build. )

   Since this is my feature, I'll take the blame and try to explain ;)

> I have to be a bit more precise.
> My make does not even recognise the "-j" flag:
>
> make -j
> make: illegal option -- j
> usage: make [-CceFiNnqrstUux] [-p | -Tp] [-f makefile ]... [-k | -S]
> [macros=name]... [target_name]...

In the Makefile.in (and subsequently in Makefile) there is this
definition:

MAKESEQ=        $(MAKE) -j 1

I think you'll have to strip "-j 1" from it, so only $(MAKE) remains.
Please write if this helps?

I guess I should've made a configure-script to detect this support.
In my defense - I've been asking since winter for someone to test this
and post objections, nobody complained that the feature breaks on their
systems... you're the first to respond at all ;)

The build routine is (as you can see by tracing the targets) like this:

1) Default target is the first one, "all":

all:            milter-greylist rc-bsd.sh rc-redhat.sh \
                 rc-solaris.sh rc-debian.sh rc-gentoo.sh rc-suse.sh

2) It depends in particular on the main binary:
milter-greylist:        ${OBJ} ${OBJ_SEQ_FLAG}

3) This leads to this chain which should ensure that certain files
are only compiled sequentially, and others may be compiled seq or
paral - as the command-line make caller sees fit:

${OBJ_SEQ_FLAG}:        obj-seq
         sync || $(TRUE)

obj-seq:
         @echo "=== Call make sequential for objects sensitive to that 
(current make='$(MAKE)' MAKEFLAGS='$(MAKEFLAGS)'):"
         $(MAKESEQ) bld-seq

bld-seq:        ${OBJ_SEQ}
         $(TEST) -f ${OBJ_SEQ_FLAG} || $(TOUCH) ${OBJ_SEQ_FLAG}

So this invokes "make" again for the same Makefile but with flags
(or lack thereof) which would build the "bld-seq" target step by step;
possibly for a particular implementation of "make" some envvars (or
removal of some) is in order as well, such as MAKEFLAGS relevant for
gmake (AFAIK). This also causes the ${OBJ_SEQ_FLAG} to appear.

Now that I look at it, possibly the first half (test for existance
of the ${OBJ_SEQ_FLAG}) is not quite needed, at least it might maybe
interfere in the development cycle (i.e. just always touching and 
updating that file after a successful rebuild of prerequisites would
be cleaner - otherwise the seq objects are rebuilt every time), but
this is not fatal for dev, and of no consequence for users who build
the program once.

HTH,
//Jim Klimov