[Top][All Lists]

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

Re: possible solution for -Otarget recurse (was: Re: Some serious issues

From: Paul Smith
Subject: Re: possible solution for -Otarget recurse (was: Re: Some serious issues with the new -O option)
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.  I wanted to separate that in-make variant out so that
users would never see it or have the possibility of accidentally using
it, so I moved it into our internal headers which are never installed
anywhere outside our source tree and would not be included in a GNU make
binary package.

This is slightly more potential maintenance on our part internally but
is much safer for the user which is a tradeoff I'll almost always

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.

> > One other thing: I changed the pump function to read from a FD but write
> > to a FILE*, because all our other uses of stdout/stderr use FILE* and
> > it's not wise to mix them.  It works fine.  While I was in there I
> > noticed the handling of the text/binary mode.  I wonder if this is not
> > quite right.  It seems to me that since we're going to be writing to
> > stdout/stderr anyway, if we're going to set the mode at all we should be
> > setting the mode on the temporary file to match the mode on
> > stdout/stderr, before we write to it, rather than setting the mode on
> > stdout/stderr to match the temporary file.
> > 
> > What do you think?
> 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.

I understand your point.  I just wonder if this difference might end up
being visible to the user in some way.  But, we'll leave it as-is.

reply via email to

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