Loading a mapfile from a string...

[Steve Lime]

Good idea. I can add them if it's generally ok with folks.

Steve

>>> On 4/27/2007 at 2:05 PM, in message
<f3b73b7d0704271205s71a9470dn7c005800b3ffb93f at mail.gmail.com>, "Tamas Szekeres"
<szekerest at gmail.com> wrote:
> 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...)
>> >>
>>
>>