Re: possible solution for -Otarget recurse (was: Re: Some serious issues with the new -O option)

[Eli Zaretskii]

> From: Paul Smith <address@hidden>
> Cc: address@hidden
> Date: Sun, 05 May 2013 12:56:48 -0400
> 
> On Sun, 2013-05-05 at 19:36 +0300, Eli Zaretskii wrote:
> > However, I wonder what was the reason for splitting the definition of
> > GMK_EXPORT in two, and putting each part in a different file.
> 
> Well, because the gnumake.h file is intended to be installed into the
> user's /usr/include or similar, and included in a binary package build
> of make such as RPM or DEB or whatever, and be included by the user's
> code, and when it's included there it should NEVER (IIUC) be using the
> in-make variant.

That's true, but it's common to have the same header be included when
building the application or library which provides the exported
services.

> However, if you really want it back the way it was please do choose a
> more unique name than "MAIN".  Something prefixed with "GMK_" at least.

OK, will do.

> > Make never changes the I/O mode of its standard streams.  And it
> > shouldn't, since everything Make itself writes or reads is always
> > plain text.  Since the standard streams always start in text mode,
> > your suggestion boils down to make input from the temporary file be
> > always in text mode.
> 
> Well, I assumed that something that invoked make could set the mode and
> then make could inherit that mode.  I don't know if that's how it works
> or not in Windows.  And of course I doubt anyone does that.

The text/binary mode cannot be inherited the way file descriptors are.
That mode is entirely private to each application, and the startup
code provided by MS (to which MinGW is compatible) unconditionally
initializes it to text mode.  Each application decides on its own how
it should treat its standard streams; most leave them at the default
text mode, but some switch to binary.  Examples of the latter are
ports of 'cat' ("cat foo > bar" should create a file that is identical
to 'foo'), carefully done ports of 'tr' and Sed (otherwise you cannot
edit in or out CR characters), etc.

> I understand your point.  I just wonder if this difference might end up
> being visible to the user in some way.

If the users will see any difference, it means (barring bugs in Make)
the child program used binary I/O where it would use text I/O had its
stdout/stderr not been redirected.  But this belongs to the broader
class of problems with -O, not unlike the colored screen output that
was discussed here a few days ago.