Jim Klimov wrote:
> 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
If that's really true, then your NFS implementation is
severely broken. sync(1) doesn't even have any effect on
the kernel's view of file meta data. Therefore it is
completely unclear how a call to sync can influence the
behaviour of a makefile.
All that sync(1) does is to suggest (not enforce) that
the kernel writes some (not all) of its dirty buffers to
the device at some point in the future (not immediately).
Therefore, in ancient times, the sync(1) command was
usually typed three times with a short pause between, in
order to increase the chance that dirty buffers were
written. Sometimes there were "magic" things like
"sync; sleep 1; sync; sleep 1; sync" in shell scripts.
Mostly it made people feel better, but didn't have any
real use apart from that.
Nowadays, the sync(1) commands is actually superfluous
and could safely be removed from operating systems, in
my opinion. It's not even POSIX standard.
> > 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.
I'm not following every new beta version of milter-greylist,
I just don't have the time. And there are times when I just
delete the mails from the milter-greylist list because I
already have too many other things to care for.
> 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?
If you don't want parallel builds, don't use -j with the
outer make in the first place. If only specific parts
may not be build parallel, you can use the .NOTPARALLEL
or .NO_PARALLEL special targets.
Another way would be to simply require gnu make and don't
support any other make variant. Many software projects do
that already. Then you can safely use all of the gnu make
features (including -j) without having to care about all
kinds of make variants and their subtle differences.
> 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?
I'm sorry if I sounded offensive. That was not my intention.
I just pointed out a potential cause of problems, and at
least one member of the list did report problems with his
system's make implementation. This is to be expected;
any non-trivial Makefile that's supposed to run with all
kinds of different make implementations will hit such
problems sooner or later. As pointed out above, it would
probably better to require gnu make and use only that one.
By the way, personally I think that compatibility with old
legacy systems should not be retained at all costs.
If someone uses an OS that's 5 or 6 years old, it's better
he upgrades to a more recent and standards-compliant one,
instead of putting the compatibility burden on software
developers.
Just to mention an example, there was recently a report
of a problem with nesting `backticks` in shell commands.
That's exactly the reason why shell scripts should use
$(foo) syntax instead of `foo`, because the former can
be nested without problems. Of couse the ancient /bin/sh
of Solaris doesn't support that syntax, even though it is
POSIX standard for *ages*, but that's why there is /bin/ksh
or /usr/xpg4/bin/sh, both of which are much close to POSIX
and support $() syntax.
Just my two cents. YMMV.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Handelsregister: Amtsgericht Muenchen, HRA 74606, Gesch\ufffdftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsreg.: Amtsgericht M\ufffdnchen,
HRB 125758, Gesch\ufffdftsf\ufffdhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen/-Produkte + mehr: http://www.secnetix.de/bsd
"C++ is to C as Lung Cancer is to Lung."
-- Thomas Funke