Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>
>> Well, it looks like there's a reason GnuWin32 hasn't advanced beyond
>> 2.5.4a - after that the flex developers proceeded to make flex use a
>> filter chain methodology that requires the use of fork(). Making it run
>> on Windows without the support of Msys or Cygwin would involve some
>> significant surgery, I suspect.
>>
>
> Egad, this is a mess :-(. I noticed in the flex changelog that they'd
> switched to using m4 instead of implementing all the text processing
> themselves. I suppose this is a consequence of that.
>
> But I'm not prepared to agree that M$ lameness should restrict us to
> using only a 1990s version of flex. Didn't somebody mention upthread
> that there is a Windows port of 2.5.33 available?
>
Not one that is standalone. It needs some runtime support for Unix-like
process control, either Cygwin or Msys. So my Cygwin and Mingw/MSys
buildfarm members are quite happily using flex built for their
respective environments. I am leveraging the fact that I run all three
of my Windows based buildfarm members on the same Windows instance to
let the MSVC member use the MSys flex.
>
>> Maybe for the time being we need to think about keeping scan.c in CVS.
>> It's not like scan.l gets updated all that often.
>>
>
> We could if we had to, though it amounts to saying that Windows-based
> developers don't get to touch the scanner.
>
>
>
True, but I'm not going to invest a large number of cycles on porting
this. I'm not very happy about it either. I guess anyone wanting to
develop on Windows and affect the scanner could install Cygwin or MSys.
cheers
andrew