bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #33138] .PARLLELSYNC enhancement with patch


From: Eli Zaretskii
Subject: Re: [bug #33138] .PARLLELSYNC enhancement with patch
Date: Thu, 25 Apr 2013 05:57:02 +0300

> Date: Thu, 25 Apr 2013 02:16:33 +0200
> Cc: address@hidden, address@hidden
> From: Frank Heckenbach <address@hidden>
> 
> > > I can't follow you here. On POSIX, we don't need to pass a fd
> > > because it's always stdout/stderr. Or do mean something else?
> > 
> > I meant the file descriptor passed to fcntl to put a lock on it.  The
> > value of that descriptor is stored in sync_handle, whose type is
> > 'int'.
> 
> So you want to overload sync_handle to contain an fd on POSIX and a
> pointer on Windows?

I don't see it as an overloading.  'sync_handle' is already opaque,
even its name says so.  It just so happens that on Unix it is actually
a file descriptor.  And it just so happens that on Windows it will be
a handle to a mutex.

> I'm not sure I'd like this. Since it's used in separate code
> branches (ifdef'd or perhaps in different source files in compat)
> anyway, why not define separate variables of the appropriate types
> (preferably with different names, to reduce confusion)?

I don't see any confusion (how probable is it that someone who is
interested in Unix will ever look at the details of the Windows
implementation, and vice versa?).  And we never do that in Make, we
generally try to use the same variables.  If nothing else, it keeps
the number of ifdef's down.
> --- doc/make.texi.orig        2013-04-24 16:30:05.000000000 +0200
> +++ doc/make.texi     2013-04-25 02:08:58.000000000 +0200
> @@ -8639,6 +8639,17 @@
>  complex parallel build in the background and checking its output
>  afterwards.
>  
> +Note that with this option, each job's output is redirected to a
> +temporary file first. Some commands can behave differently depending
> +on the type of their standard output or standard error. E.g.,
> address@hidden --color=tty} might display a colored directory listing when
> +standard output is connected to a terminal. When using this option,
> +colors would be disabled because the output of the command goes to a
> +file. Note, however, that it is generally best to avoid such
> +commands in makefiles, independent of this option, since the
> +different behavior would also be triggered when users redirect the
> +whole output of @code{make}, e.g. to a log file.

Thanks.  I think you need two spaces between sentences (that's GNU
Coding Standards' requirement), and command lines people type should
be in @kbd, not @code.  Also, "e.g." needs either a comma or a @:
after it, to signal to TeX it's not an end of a sentence.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]