Tom Lane wrote:
Andrew Dunstan <and...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
