This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 libiberty, there.

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

Mark Mitchell
CodeSourcery, LLC

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]