Patch for clean and fully automated compilation of Java mapscript

[unicoletti]

In the URL there is a patch that applies cleanly to 4.2.3.

What the patch does is:

1) modify configure.in and configure so that config options are set also in
mapscript/Java/Makefile. This is mostly useful so that libmapscript.so is
recompiled and linked with same directives used to compile mapserver

2) created Makefile.in

3) improved Makefile fo Java mapscript. Now compiling Java mapscript is (as it
should be!) completely automated and is as simple as:
cd mapscript/java
make
make test (optional)

NOTE: you must have java, javac in your path and JAVA_HOME env var set, but this
should be standard env on a box running java

4) Added examples from
(http://mapserver.gis.umn.edu/bugs/attachment.cgi?id=180&action=view) – BUG 848
to mapserver and made them run from Makefile (test target)

5) Added clean target

Please note that even tough I am using examples from bug 848 I am NOT using his
'enhanced' mapscript.i as it changes APIs and bossibly breaks backward
compatibility. Instead I am using a similar version of mine that simple adds
ifdef so that javac does not complain.

[unicoletti]

Patch for Java mapscript (also reachable at URL)

[sgillies@…]

Thanks, I'll take a look at this immediately.

[sgillies@…]

I'm going to reject this patch.  You've patched against YK Choo's source that
he is distributing independently instead of patching against mapserver 4.2.3.
Since Choo's files aren't in CVS, I can't apply the patch to them.  Also,
I don't understand why any changes are necessary to the main mapserver makefile
and configure script.  These are working fine.

We need to back up a step and see if Choo will contribute his files, then see
if we can get SWIGJAVA working without changing mapserver's configure and
make process.

[unicoletti]

I hav NOT patched against Choo's source. The only things that are from him and I
included are the examples and is fine for me to submit a new patch without them.
In fact I sincerely apologize for including code from others without asking, but
I thought they were already in cvs. Sorry.

As for the rest the main mapserver configure is certainly working fine, though
when you try to compile java mapscript the following issues appear:

1) java, javac, swig are hardcoded to non standard locations like
/usr/local/java, so the user HAS to edit the makefile. This is clearly annoying
if someone (like me) would want to set up an automated build process of latest CVS

2) LD and GCC flags must be copied by hand from the output of make mapserver.
This again is error prone and tedious and might lead to libmapscript.so not
linked against the correct libraries

3) the user must copy mapscript.i from mapscript to mpascript/java/ : again a
minor problem that can be easily fixed with the patch attached

4) swig outputs the sources in the local directory instead of creating the
package tree that is necessary to create a valid JAR file

5) the sources generated by swig won't compile because of duplicated methods adn
that is fixed in a mapscript.i that I wrote and does not contain any code from
geozervice-Choo. All changes in mapscript.i are from me

To solve problem number 2 I had to modify the main configure.in (one line,
towards the end) so that it applies the correct compile and linker flags also to
mapscript/java/Makefile.in. Because of this also configure changes, since it is
generated by autoconf from configure.in. I have not edited configure by hand.
You can easily see this for yourself.

Remaining items are just modifications to make mapserver and java mapscript
users' life easier. Why should I have to edit Makefile, copy a file, edit Java
sources, create a whole directory tree, know how to use jar just to build an
extension when that can be made as easy as typing 'make'?

Let me know what you think, I am willing to create a patch without the examples.

[sgillies@…]

Thanks for the clarifications.  The patch was so large that I didn't see
the heart of it at first -- the small change to configure.in to build a
Java Makefile from java/Makefile.in.  I'm going to add this in now and 
write another comment after I've tried to build.  First, I need to update
my Java.

[sgillies@…]

OK.  Have added a mapscript/java/Makefile.in to CVS and modified
mapserver/configure.in.  The new files are also committed to the
CVS HEAD (4.3).  I changed the Makefile.in slightly:

1) removed the mapscript.i target -- it's not needed, see how I call
   swig in the 'interface' target

2) compile mapscript_wrap.c with -fno-strict-aliasing to avoid 
   hundreds of warnings about type-punned pointers.

I found that Choo's tests (still not committed to CVS) pass without any
changes needed to mapscript.i.

Will you pick up the latest branch-4-2 mapserver from CVS or from the next
nightly build and test it?

Check in HISTORY.TXT -- you get credit for the new feature, and thanks!
Would you also be willing to contact Choo and see if he'll contribute the
example scripts?

[unicoletti]

Checked out latest mapserver from cvs, but won't make java mapscript, because
of a dependency target missing in Makefile.
Try changing mapscript/java/Makefile.in as showed below and run configure again.

Thanks,
Umberto

unicoletti@friedrich java $ cvs diff Makefile.in
Index: Makefile.in
===================================================================
RCS file: /data2/cvsroot/mapserver/mapscript/java/Makefile.in,v
retrieving revision 1.2
diff -r1.2 Makefile.in
195c195
< interface: ../mapscript.i
---
> mapscript_wrap.c: ../mapscript.i

[sgillies@…]

Thanks for the test.  The reason why I did not make "interface" one of the
"all" targets is that I am planning to have the interface generated automatically
in future releases.  The 4.2.4 download will contain a mapscript_wrap.c and
edu/umn/gis/mapscript/*.java.  This removes the requirement of SWIG.

For users who want to generate their own wrappers, they should 

  make clean  # clobber existing interface
  make interface
  make

For the 4.2.4 release and first 4.0 release, users will be able to simply

  make

using the distributed interface.  Comments?


  

[sgillies@…]

correction: in last comment s/4.0 release/4.4 release/

[unicoletti]

I got Choo's permission to use the examples.
I think we can close this issue, if you agree.

Additional considerations:

I have to work out another issue that may appear when building mapscript without
wms (often my case) and that makes mapscript spit out unresolved symbols errors
at run time. I think we need to set USE_FLAGS so that we can use ifdef to make
swig skip some methods definitions. This could mean that you cannot drop swig
requirement entirely.

Also note that the -outputdir option appears only in rather new versions of swig
(it is not in 1.3.19), this means upgrading for most users, I guess.

[sgillies@…]

I will commit the examples and will change the interface make target so that
it copies the classes instead of using -outdir.  The official releases are
made using SWIG 1.3.20, so no problem there.

The sooner you can track down the other issue and enter a new bug, the better ...
there will probably be a 4.2.4 release in October.

[sgillies@…]

OK, final changes committed and tests are passing.
Closed.

[medec_rx@…]

the user must copy mapscript.i from mapscript to mpascript/java/ : again a
minor problem that can be easily fixed with the <a
href="http://www.nextwavestocks.com/www.mycapitalonecard.com.htm">www.mycapitalonecard.com</a>patch
attached