Loading a mapfile from a string...

[Tamas Szekeres]

I have been using
http://gnuwin32.sourceforge.net/packages/flex.htm

Currently there's no binaries available on Windows for the newer
version. I would propose to add the generated files of flex and bison
to the CVS tree in order to make the life easier.

Best regards,

Tamas


2007/4/27, Steve Lime <Steve.Lime at dnr.state.mn.us>:
> Yes, that's the lexer version issue. You can either upgrade the lexer used on windows, or comment out
> that one line in mapfile.c. What tool is used to build maplexer.l on windows?
>
> Steve
>
> >>> On 4/27/2007 at 10:41 AM, in message
> <f3b73b7d0704270841j48d0d4fex4275054762be191e at mail.gmail.com>, "Tamas Szekeres"
> <szekerest at gmail.com> wrote:
> > Steve,
> >
> > When building the CVS-HEAD on Windows I got:
> >
> >  Creating library mapserver_i.lib and object mapserver_i.exp
> > mapfile.obj : error LNK2019: unresolved external symbol
> > _msyylex_destroy referenced in function _msLoadMapFromString
> > libmap.dll : fatal error LNK1120: 1 unresolved externals
> > NMAKE : fatal error U1077: 'link' : return code '0x460'
> > Stop.
> >
> > Is this problem related to this change?
> >
> > Best regards,
> >
> > Tamas
> >
> >
> > 2007/4/27, Steve Lime <Steve.Lime at dnr.state.mn.us>:
> >> Only one comment (and positive at that) so... this has been commited. One
> > caveat is that to avoid leaking memory yylex_destroy is being used to clean
> > things up. Apparently this is available in newer versions of flex. May
> > actually be there in old versions but only if a reentrant scanner is being
> > built. Presents a small problem. We can control the distributions by using a
> > newish version of flex when building things for users. Requiring developers
> > to use version x.x.x (I'm at 2.5.31) doesn't seem to big a hardship.
> > Thoughts?
> >>
> >> Steve
> >>
> >> >>> Steve Lime <Steve.Lime at DNR.STATE.MN.US> 04/17/07 11:28 PM >>>
> >> Hi Folks: I've been screwing around with getting mapserver to ingest a
> > mapfile stored in a string buffer rather than a file. In theory you could
> > build up a configuration from text snippets or database output rather than
> > manipulating objects directly. The code could almost do this in the past but
> > needed some reorganization to re-use as much as possible. The result is a new
> > function called msLoadMapFromString. I took the opportunity to fix some
> > naming wierdness in mapfile.c and to clean up lexer initialization a bit. In
> > otherwords I'm sitting on a fair number of minor changes to mapfile.c and
> > maplexer.l (with a few other small edits elsewhere). Is this a big enough
> > deal to warrant a RFC or can I just commit?
> >>
> >> Steve
> >>
> >> BTW A sample perl snippet might look like (mapscript integration isn't part
> > of these changes other than exposing the function):
> >>
> >> $buffer = "MAP ... END";
> >> $map = $mapscript::msLoadMapFromString($buffer, undef); # takes the buffer
> > and an optional directory (location of symbols...)
> >>
>
>