build procmail with conservative locking?

Regarding  building procmail-3.11pre7:

How would one rewrite Makefile and/or config.h (?) to be most 
conservative in choice of locking mechanism, so that the executable 
remains reliable when new, possibly less robust, nfs cross-mounting
configurations are introduced?

You might think that the /var/mail (or whatever) would be relatively
stable, but, I like using "lockfile" for lots of things unrelated to
email -- and I'm assuming that the choice of locking mechanism is
built into lockfile, too.

Makefile refers to:
    #LOCKINGTEST=100        # Uncomment (and change) if you think you know
    #                       it better than the autoconf lockingtests.
    #                       This will cause the lockingtests to be hotwired.
    #                       100     to enable fcntl()
    #                       010     to enable lockf()
    #                       001     to enable flock()
    #                       Or them together to get the desired combination.

config.h refers to:
    /*#define NO_fcntl_LOCK     /* uncomment any of these three if you       */
    /*#define NO_lockf_LOCK     /* definitely do not want procmail to make   */
    /*#define NO_flock_LOCK     /* use of those kernel-locking methods       */


I was building procmail-3.11pre7 for two platforms, SunOS 4 and 
Solaris 2.
FWIW, 
the Solaris 2 (SunOS 5.5) build automatically chose 
        Locking strategies:     dotlocking, fcntl()
The SunOS 4.1.3 build automatically chose
        Locking strategies:     dotlocking, fcntl(), lockf(), flock()

Procmail et al will be used, occasionally, on many different 
systems/combinations -- but usually automatically on a single mailserver,
which is currently SunOS 4.1.4, nfs-mounting the mailspool from
an Auspex fileserver.

Thanks for any recommendations.
Best regards,
John Ruckstuhl