apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neale Ranns <ne...@ranns.org>
Subject [PATCH] Port testucs to Unix
Date Thu, 28 Jul 2005 21:26:05 GMT

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



Mime
View raw message