Dynamic libmap.so

[Tamas Szekeres]

Howard,

I prefer retaining both of the two options enabling the user to select
the preferred deployment model. It's true that the default option
differs for the UNIX and the Windows builds, but i havent found any
problematic issue related to this.

However we should equalize the way how the various data providers /
output format providers communicate with the mapserver core and
minimize the dependency from each other. Furthermore we should
consider to enable the option for the providers being linked
dinamically to mapserver.

What is the current state of the C API you have mentioned. Do we have
ideas or concepts?
(Maybe I have missed something)

Best Regards,

Tamas Szekeres


2006/5/18, Howard Butler <hobu at iastate.edu>:
> All,
>
> After some futzing, I was able to build a dynamic libmap on OS X
> using the "make shared" target in the Makefie.  I was wondering if
> there were historical reasons why we don't always build a dynamic
> libmap.so, and why we normally do static linking for programs like
> mapserv and shp2img.  Static building happens in MapScript as well,
> and this complicates the MapScript build process, forcing us to use
> the "mapscriptvars" hack for TCL, Perl, Python, and Ruby to pick up
> libs, definitions, and header files.
>
> Some questions about the MapServer build process:
> - If MapServer is to have a C API, is it expected that this would be
> built and linked to applications dynamically?
> - Will a dynamic libmap build simplify our MapScript build process?
> MapServer build process?
> - Are there performance/memory footprint gains to be had from a
> dynamic libmap.so?
>
> Howard
>