hi,

firstly apologies if i have gone about this all wrong; this is my first contribution.

it was mentioned in the status mail this morning (28th July) that testucs needs to be ported to unix. i have attempted to do this.

the testucs app tests the two functions  apr_conv_utf8_to_ucs2 and apr_conv_ucs2_to_utf8. These functions are only declared for win32. Looking at this code there doesn't seem to be much that is win32 specific in it (in fact it does compile unchanged on linux). So to get this test to work on unix i just have to link this to functions into the unix shared lib.

two ways i see to do this:
    1) a clean way:
    i move the win32 arch dependant utf8 files (include/arch/win32/apr_arch_utf8.h and misc/win32/utf8.c) to a common place (include/apr_utf8.h and strings/apr_utf8.c (aplogies for the use of the strings dir, but it seemed like to most appropriate. of course i can change that)). Then update all win32 files that #include the old locations, change the .dsp files (this i did manually so i could be wrong) and update the test/internal/Makefile.in (to build the test) and the testucs.c file (to reflect the include path changes)

    clean.patch that is attached does this.

    2) a dirty way
    i copied the win32 arch files to the unix arch directory. I updated the test/internal/Makefile.in file to include the arch dependant files. The arch directory that is included is set by the configure script.

    dirty.patch that is attached does this.

both patches are based on version 1.1.1.

you must ./buildconf and ./configure once applied (for both patches), since i moved some files around.

using both patches i have now run the testucs program on my linux box. the testall program also reports success. the real (almost laughable) downside is that i do not have a windows compile environment to test that i have not broken it there. there is a distinct possibility that i have.

i prefer the clean patch, but i don't now enough about the consequences to comment on whether it is suitable. the dirty way would work better with symbolic links not straight copies.


i hope that is what was required and that i have contributed in the correct way

neale