Loading a mapfile from a string...

Steve Lime Steve.Lime at DNR.STATE.MN.US
Sun Apr 29 23:36:06 EDT 2007


I wanted to hear from Howard on SVN setup. I gave him the tar ball today
minus those files an didn't want to make any changes behind that although
others might be.

Steve

>>> "Tamas Szekeres" <szekerest at gmail.com> 04/29/07 6:25 PM >>>
Steve,

When will you make these changes? It seems that the nightly snapshot
contains the wrong version as well. So I cannot proceed in setting up
the OSGeo buildbot slaves for Windows with the current set-up.

Best regards,

Tamas



2007/4/27, Steve Lime <Steve.Lime at dnr.state.mn.us>:
> 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...)
> >> >>
> >>
> >>
>
>



More information about the mapserver-dev mailing list