Mail Archives: djgpp-workers/2003/04/13/05:47:07
> > From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
> > Date: Thu, 10 Apr 2003 21:23:27 +0200
> >
> > In trying to build it under windows (MSVC.NET, not cygwin),
> > I found portability issues that also apply to DJGPP.
> > Flex (like bison) now runs M4 in a subprocess to (pre)process
> > the skeleton - it uses fork/exec/wait/pipe to use this, which
> > will not work under DJGPP
>
> But popen should be a goodd enough replacement here.
>
> (Actually, the Flex build procedure should test whether a working
> `fork' is available, and if not, use `popen'.)
>
> > what's worse, it seems it does not always exec() in a fork
>
> What on earth for? A call to `fork' without `exec' means you have two
> processes running Flex's own code. What does each copy do after the
> call to `fork'?
The code that fork()s is applying a filter chain. That filter is
sometimes an external program (like m4) and sometimes an internal
function (like a filter that fixes the #line directives).
What's worse, one of those internal filters changes some of the
FDs in use, then invokes the forking function again (splitting
the entire filter chain).
Their main argument is that flex now requires a POSIX platform,
hence no tests for fork() etc.
And being told "DJGPP? Somebody wake me up, please!" after saying
the portability issues I found applied equally to DJGPP, doesn't
make me expect great cooperation from the flex maintainers.
Now I suppose the code could be reworked to use popen() for the
external programs and normal calls for the internal functions;
it just would require great care not to break anything (especially
with all the FDs flying around due to all the pipe()s).
- Raw text -