You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Stein <gs...@lyra.org> on 2000/11/15 20:55:04 UTC
Re: cvs commit: apache-2.0/src/lib/apr/test testucs.c
On Wed, Nov 15, 2000 at 11:52:43AM -0000, trawick@locus.apache.org wrote:
> trawick 00/11/15 03:52:41
>
> Modified: src/lib/apr/test testucs.c
> Log:
> Fix an include path so that make depend works in this directory.
>
> Revision Changes Path
> 1.2 +1 -1 apache-2.0/src/lib/apr/test/testucs.c
>
> Index: testucs.c
> ===================================================================
> RCS file: /home/cvs/apache-2.0/src/lib/apr/test/testucs.c,v
> retrieving revision 1.1
> retrieving revision 1.2
> diff -u -r1.1 -r1.2
> --- testucs.c 2000/10/17 17:09:11 1.1
> +++ testucs.c 2000/11/15 11:52:36 1.2
> @@ -1,5 +1,5 @@
> #include "apr_xlate.h"
> -#include "../i18n/unix/i18n.h"
> +#include "../include/arch/unix/i18n.h"
> #include <wchar.h>
> #include <string.h>
Wouldn't that be "arch/unix/i18n.h" ?
Maybe tweak the include path that is used for apr/test/ ?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
RE: cvs commit: apache-2.0/src/lib/apr/test testucs.c
Posted by rb...@covalent.net.
<copied to dev@apr.apache.org, because this conversation should be on the
APR dev list>
> > This is wrong in general. The test programs should behave like external
> > programs. This means that they can't use anything in the arch directory
> > at all. The only include files they have access to is apr/include.
>
> However, testucs tests something that isn't exposed in the API. It's an
> internal utility (until we bind it into apr_xlat_anything) that should be
> exposed using existing semantics. It uses native semantics for fast file
> names and other string transformations.
What are we trying to test that we need to include a private header? My
original purpose for the test directory was as a place to prove that APR
works. If it doesn't work in this case, we should fix it, not hack around
it.
> My fundimental problem with apr_xlate is that we -still- don't have a
> license compatible i18nlib, ergo no win32 xlat. Suggestions?
I take it i18nlib is the i18n lib on Windows? Does FreeBSD have a lib
that we can hack to work on Windows.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: cvs commit: apache-2.0/src/lib/apr/test testucs.c
Posted by rb...@covalent.net.
<copied to dev@apr.apache.org, because this conversation should be on the
APR dev list>
> > This is wrong in general. The test programs should behave like external
> > programs. This means that they can't use anything in the arch directory
> > at all. The only include files they have access to is apr/include.
>
> However, testucs tests something that isn't exposed in the API. It's an
> internal utility (until we bind it into apr_xlat_anything) that should be
> exposed using existing semantics. It uses native semantics for fast file
> names and other string transformations.
What are we trying to test that we need to include a private header? My
original purpose for the test directory was as a place to prove that APR
works. If it doesn't work in this case, we should fix it, not hack around
it.
> My fundimental problem with apr_xlate is that we -still- don't have a
> license compatible i18nlib, ergo no win32 xlat. Suggestions?
I take it i18nlib is the i18n lib on Windows? Does FreeBSD have a lib
that we can hack to work on Windows.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: cvs commit: apache-2.0/src/lib/apr/test testucs.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Wednesday, November 15, 2000 3:05 PM
>
> On Wed, 15 Nov 2000, Greg Stein wrote:
>
> > > @@ -1,5 +1,5 @@
> > > #include "apr_xlate.h"
> > > -#include "../i18n/unix/i18n.h"
> > > +#include "../include/arch/unix/i18n.h"
> > > #include <wchar.h>
> > > #include <string.h>
> >
> > Wouldn't that be "arch/unix/i18n.h" ?
> >
> > Maybe tweak the include path that is used for apr/test/ ?
>
> This is wrong in general. The test programs should behave like external
> programs. This means that they can't use anything in the arch directory
> at all. The only include files they have access to is apr/include.
However, testucs tests something that isn't exposed in the API. It's an
internal utility (until we bind it into apr_xlat_anything) that should be
exposed using existing semantics. It uses native semantics for fast file
names and other string transformations.
My fundimental problem with apr_xlate is that we -still- don't have a
license compatible i18nlib, ergo no win32 xlat. Suggestions?
Bill
Re: cvs commit: apache-2.0/src/lib/apr/test testucs.c
Posted by rb...@covalent.net.
On Wed, 15 Nov 2000, Greg Stein wrote:
> > @@ -1,5 +1,5 @@
> > #include "apr_xlate.h"
> > -#include "../i18n/unix/i18n.h"
> > +#include "../include/arch/unix/i18n.h"
> > #include <wchar.h>
> > #include <string.h>
>
> Wouldn't that be "arch/unix/i18n.h" ?
>
> Maybe tweak the include path that is used for apr/test/ ?
This is wrong in general. The test programs should behave like external
programs. This means that they can't use anything in the arch directory
at all. The only include files they have access to is apr/include.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------