Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Message

Re: [milter-greylist] milter-greylist 4.5.5 is available

2013-09-05 by Jim Klimov

A few of my messages were bounced for some reason, so I'll combine
them here and try again:


On 2013-09-05 16:04, Oliver Fromme wrote:
 > By the way, the use of "sync" should be removed, too, it
 > doesn't make any sense.

It forces a sort of barrier that build-programs with dirty buffers
(or the kernel's write-cache) should now flush and finalize the
built files on-disk. De-facto this improved reliability of builds
for me over NFS, whatever the "science" behind the curtains

 >
 > It should also be pointed out that the semantics of the -j
 > option of bsd make (e.g. FreeBSD) is slightly different than
 > the -j option of gnu make. In particular, -j 1 does *not*
 > switch parallel building off completely, unless you also use
 > the -B option, or you don't use -j at all.

I introduced the patch around February... everybody was quiet
despite my numerous requests for testing on their systems so
we can decide if further work is needed before integrations.

Now that the tests are included in configure.ac, I think it
is easy to extend them for different combinations of flags
for "make" of choice. It is also possible to specify the exact
value of MAKESEQ and MAKEPAR (command and parameters) with
configure flags now for the user's particular system, and
work without auto-guessing prone to failure.

As for BSD make, if you call "make -j 1 -B" or "make" from
another, parallel, "make -j N" - does either of the former
invokations guarantee that the "inner" make will build its
targets sequentially, strictly one-after-another?

 >> This is also my opinion. It seems that introduce more probelems that
 >> it solves.

With loud noise on-list, mostly?

The milter-greylist project was not buildable in parallel before
this patch, it is buildable now. Since this matters to me, I see
it as an improvement.

Attila's problem was solved as far as I know (awaiting ultimate
testing result from him though), and this addition should no
longer break default builds (without "exotic" parameters, and
executed sequentially). There are also said flags to disable the
guessing and specify the "make" methods of choice.

On 2013-09-05 16:37, Emmanuel Dreyfus wrote:
 > On Thu, Sep 05, 2013 at 04:04:37PM +0200, Oliver Fromme wrote:
 >  > I agree that it's best not to try to use -j at all, given
 >  > that milter-greylist doesn't benefit much from parallel
 >  > builds anyway.
 >
 > Anyone wants to speak in favor of pralelle build? Or shall I back it out?

I want, I did, strongly; though I am biased :)

Put another way: Does anyone else suffer from this patch?

I benefit from it, the one person who had and reported specific
failures on his system - these problems were AFAIK solved.

If this feature does not break builds for you, and especially if
you don't care for parallel builds at all, why be so offensive?

There are many features in projects that are disabled by compile
time flags (say, IPv6 support, or support for an SPF library other
than the one I happen to use) which I don't care about and which
don't influence me - I dont run around yelling to rip them out ;)

//Jim

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.