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
Message
Re: [milter-greylist] milter-greylist 4.5.5 is available
2013-09-05 by Jim Klimov
Attachments
- No local attachments were found for this message.