From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>
Subject: Re: New Flex versions
Date: Sun, 13 Apr 2003 11:42:36 +0200
Message-ID: <000001c301a1$043265c0$2302a8c0@dualzastai>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <2593-Sat12Apr2003122446+0300-eliz@elta.co.il>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> > 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).