This is the mail archive of the
mailing list for the GCC project.
Re: PATCH to support native Windows builds
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
Why not just document these pexec/pmkpipe interfaces as unportable
pieces of the libiberty interface?