Eli Zaretskii wrote:
> > Date: Thu, 25 Apr 2013 02:16:33 +0200
> > Cc: e...@gnu.org, bug-make@gnu.org
> > From: Frank Heckenbach <f.heckenb...@fh-soft.de>
> >
> > > > 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.
Alright, in this case I'd suggest renaming it to sync_fd on the
POSIX side.
> 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?).
I often grep through sources in order to quickly find all places a
declaration is used.
> 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.
My suggestion was under the assumption that we use different
declarations because of different types anyway -- which I still
recommend, though Paul might have to decide this one.
If I understand it correctly, roughly we'd have now:
intptr_t sync_handle;
[...]
#ifdef POSIX
sync_handle = (intptr_t) fileno (stdout);
#else
sync_handle = (intptr_t) get_mutex_handle (...);
#endif
[...]
#ifdef POSIX
fcntl ((int) sync_handle, ...);
#else
lock_mutex ((mutex *) sync_handle);
#endif
I.e., everything about it is separate, apart from the declaration,
and the latter uses a type that isn't quite right for either one.
Though I generally like reducing the number of ifdefs, in this case
it seems more consistent to split the declaration, so it's clear
that these are really two different things. As a side benefit, if in
the future someone tried to use it in common code, they would get
compile-time errors on the other platform, rather than silently
producing wrong code (like applying some fd operation to a mutex
handle).
> 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.
Changed.
--- 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.,
+@kbd{ls --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.
+
@item -q
@cindex @code{-q}
@itemx --question
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
