There may be "bugs" in the build routines for procmail-3.11pre7.
Unless, of course, these are misunderstood "features". :)
(A)
In INSTALL (procmail-3.11pre7), the following is written:
Intended configurable options in Makefile are:
the install-destinations and the LOCKINGTEST directories (you can
optionally use something like 'make BASENAME=$HOME install' instead).
but,
it seems like the command-line macro definitions are not bequethed to
the make-launched makes, so,
make BASENAME=$HOME install
won't work as expected -- e.g., the manual-page installation target will
still be under /usr!
The workaround is to modify Makefile with the desired definition.
(B)
In some cases, the build routines overrule one's choice of compiler!
That this may happen is not at all clear.
I set a sh keyword parameter, CC, and bind it to the environment, and
expect *that* to be the macro definition of CC.
$ CC=gcc
$ export CC
$ make install
The original Makefile doesn't look like it overrules it, so I assumed
this standard mechanism worked as expected.
But, some init/autoconf magic *rewrites* the Makefile, inserting the
macro definition "CC = cc". Sigh.
Apparently the build routine realized that my gcc installation was
broken, and overruled my choice.
I'd rather that poorly-chosen user-supplied specifications cause
build failure (which can then be investigated), rather than be
mysteriously ignored. The build routines are trying to be too smart!
Best regards to the procmail community,
John Ruckstuhl
P.S.,
I was building procmail-3.11pre7 for two platforms, SunOS 4 and
Solaris 2.