Re: PATCH to support native Windows builds

[Mark Mitchell <mark at codesourcery dot com>]

DJ Delorie wrote:

> My original argument against it wasn't that it used pipes, but that it
> added a platform-specific API to libiberty.  Since the purpose of
> libiberty is to provide platform independence, that code just doesn't
> belong in libiberty.  It is an invalid abstraction for libiberty, and
> that is the key to my objection.

OK, I understand.  Thanks for explaining.

(I'm not entirely sure that this interface can't be implemented on all 
platforms of interest.  For example, the way I would implement it on 
DOS, would be to have a write to a pipe write to a temporary file, and 
then document the interface to say that there were limitations on these 
pipes made by "pmkpipe" relative to standard UNIX pipes.  In particular, 
on some systems the output buffer for writing to the pipe is unbounded 
-- no output will show up until the process exits.  That's sufficient 
for GCC.  But, if you're convinced this interface doesn't make sense on 
DOS, then I'll not argue the point.)

> DOS is not the reason for my objection, just an example.

Are there any other examples?

> From what I recall of the topic, what you're really looking for is a
> popen() equivalent without the shell tokenizing nightmare, right?  

Well, from a high level, what I'm looking for is "make GCC work on 
Windows (without Cygwin)".  Everything else is a detail. :-)

So, I'd be happy with any reasonable interface.  But, I'm not going to 
have the time to work out another interface, let alone implement and 
test it.  So, the question from my point of view is whether the 
community would rather have Windows support with the perhaps-imperfect 
CodeSourcery patch, or wait for something better.  To me, it seems like 
the tradeoffs are in favor of accepting the patch.

It sounds like you'd not object if we just put the pipe/exec code 
directly into collect2.c; then we'd not be polluting the libiberty 
interface.  The downside to that is that we'd have do duplicate code 
already in libiberty; pieces of pexecute would have to be copied into 
other code.  The CodeSourcery patch factors the code that's already in 
libiberty, there.

Why not just document these pexec/pmkpipe interfaces as unportable 
pieces of the libiberty interface?

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com