Opened 11 years ago

Last modified 11 years ago

#2 new task

Add existing MS4W mapscript packages

Reported by: jmckenna Owned by: warmerdam
Priority: major Component: Package
Version: Alpha Keywords:
Cc: tamas, assefa

Description

MS4W currently includes the following mapscript packages: php csharp java python

PHPMapscript is currently the only mapscript included in OSGeo4W, as a separate package. At least csharp, java, and python should also be added as separate packages.

Change History (8)

comment:1 Changed 11 years ago by warmerdam

Cc: tamas added
Owner: changed from osgeo4w-dev@… to warmerdam

I have packaged pkg-mapscript-java. I have also now packaged Python 2.5 and will take care of python mapscript.

Perhaps Tamas would be interested in packaging c# mapscript?

comment:2 Changed 11 years ago by warmerdam

Component: InstallerPackage

comment:3 in reply to:  1 Changed 11 years ago by tamas

Replying to warmerdam:

I have packaged pkg-mapscript-java. I have also now packaged Python 2.5 and will take care of python mapscript.

Perhaps Tamas would be interested in packaging c# mapscript?

Yes I'm interested in. But I'm a bit hesitant to think it could be done without having the same version of the mapserver sources and using the same compiler version as for the main builds. My best bet is to use the latest stable from SVN and MSVC71 but it won't likely work along with an older source versions. Or do we have a mapserver-dev package (with libs and headers) along with the sources have been used to create it?

My other concern is the compiler affinity of the C# packages. MapScript C# targeting various frameworks like the .NET Framework 2.0 will require to use MSVC80 compatible binaries. Is it allowed to host 2 or more different versions of the same mapserver package in osgeo4w?

Best regards,

Tamas

comment:4 Changed 11 years ago by warmerdam

OK, mapscript-python (stable and dev) are now packaged.

Tamas,

I would suggest you start out with c# bindings for 5.0.x stable. The mapserver source file (http://download.osgeo.org/osgeo4w/release/mapserver/mapserver-5.0.2-2-src.tar.bz2) contains the nmake.opt file that was used. So using that it should be fairly easy to recreate the mapscriptvars file (if you use that). The main mapserver package also installs the include files which is helpful.

Does csharp use the mapscriptvars file?

Assefa - it would be helpful (I think) if the mapserver package installed mapscriptvars in the install include directory along with the include files. That would make it cleaner to build the various mapscripts in a compatible way. What do you think?

Tamas - I think (hope) it is possible for MSVC80 compiled C# bindings to call an MSVC7.1 compiled libmap.dll for the core. I don't want to see us producing multiple copies of the mapserver package for different compilers. If we have to do that, I think we have failed to some extent. But it should be possible for you to produce C# mapscript packages for .net 2.0 using MSVC8 and .net 1.1 using something older (VC7.1?). Or just pick one .net framework that you want to support and only produce a package for that.

comment:5 Changed 11 years ago by warmerdam

Cc: assefa added

Assefa - would you mind reviewingmy previous comment with regard to mapscriptvars in the package?

Thanks,

comment:6 in reply to:  4 Changed 11 years ago by tamas

Replying to warmerdam:

OK, mapscript-python (stable and dev) are now packaged.

Tamas,

I would suggest you start out with c# bindings for 5.0.x stable. The mapserver source file (http://download.osgeo.org/osgeo4w/release/mapserver/mapserver-5.0.2-2-src.tar.bz2) contains the nmake.opt file that was used. So using that it should be fairly easy to recreate the mapscriptvars file (if you use that). The main mapserver package also installs the include files which is helpful.

Does csharp use the mapscriptvars file?

No, it doesn't. Currently the csharp makefile includes the nmake.opt from the root directory. Therefore if you specify something different (like using an external optfile in addition) then we might also specify this when building the csharp bindings. It must be noted that I use only the make or nmake tools for making up the builds, therefore the mapscriptvars should be created in a makefile friendly fashion in order to use it direcly when creating the bindings.

Tamas - I think (hope) it is possible for MSVC80 compiled C# bindings to call an MSVC7.1 compiled libmap.dll for the core. I don't want to see us producing multiple copies of the mapserver package for different compilers. If we have to do that, I think we have failed to some extent. But it should be possible for you to produce C# mapscript packages for .net 2.0 using MSVC8 and .net 1.1 using something older (VC7.1?). Or just pick one .net framework that you want to support and only produce a package for that.

It might be possible but it's potentially unsupported by microsoft, therefore it's not guaranteed to work in every condition. Though the assemblies targeting different runtimes may definitely work side by side (except for the win64 and win32 relations) but we cannot safely use dlls with different CRT dependecies.

I think it would be reasonable to restrict the builds to the same compiler and platform at osgeo4w, I'll be trying to create a script to produce csharp package using your sources and compiled libs.

In addition I'm just working on a makefile to create a consistent build for various compilers and platforms for those who cannot rely on the osgeo4w versions. I guess the mapscript csharp users are potentially an addressed group in this regard.

Tamas

comment:7 in reply to:  4 Changed 11 years ago by assefa

with regard to comments on mapscriptvars, I think that make sense. Looking into the current packages, I did not realize until now, but we already install the mapscriptvars with the include files.

Another comment with regard to php mapscript and the php dev pacakge: I will move those inside the mapserver directory beside the other mapscript packages.

comment:8 Changed 11 years ago by (none)

milestone: Beta Release

Milestone Beta Release deleted

Note: See TracTickets for help on using tickets.