Re: Make collect2 be buildable when host=i386-mingw,target=something else

[DJ Delorie <dj at redhat dot com>]

> > Right, but I meant creating an API based on the fundamental concepts
> > of pipes existing seems wrong to me - it means we've got the wrong
> > abstraction.
> 
> I'm open to suggestions,

I'm thinking a function that takes a struct, where the struct tells it
what it needs to do - list of commands with vectors, what to do with
stdin/stdout/stderr, etc.  Kind of like a popenv().  The application
should be able to tell libiberty "I need to run this chain of
commands, and I want to read stdin myself" and let libiberty worry
about whether it's going to use pipes, files, or whatnot.

typedef enum { redir_none, redir_file, redir_app, redir_null} pchain_redir;

struct pchain_info {
  void *app_hook;
  void *pchain_hook;
  pchain_redir stdin_redir;
  pchain_redir stdout_redir;
  pchain_redir stderr_redir;
  int new_stdin;
  int new_stdout;
  int new_stderr;
  int exit_code;
  int (message_cb)(void *, char *);
};

/* app fills in struct */

void *pchain_start(char ***command_list, struct pchain_info *info);
void *pchain_start1(char *command_string, struct pchain_info *info);
  (the second case, we do simple "split by spaces" for a single command)

/* app does read/write, plus struct valid */

void pchain_finish(void *);

/* exit codes etc in struct valid */

> but really, DJGPP is the aberration here; every other supported
> system has pipes, so why not fake them on DJGPP so the application
> doesn't have to care?

Because there isn't any way to fake them.  At least, not in a way that
a pipe-aware application would be able to use them.