httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: [apreq-2] perl glue on Win32
Date Mon, 16 Jun 2003 09:08:02 GMT
Randy Kobes <randy@theoryx5.uwinnipeg.ca> writes:

[...apreq.h patch...]

+0. I can't judge the correctness of this patch wrt Win32, but I've been 
following a commit-then-wait-for-Stas'-wrath^H^H^H^H^H^Hreview myself
;-).  Please use the same criterion regarding this and similar Win32 
patches.  If someone breaks your Win32 port in a future commit, just 
holler.

> I tried defining APREQ_DECLARE in terms of APR_DECLARE, as
> is done on non-Win32, and then use a compile-time flag
> APR_DECLARE_EXPORT, which I thought would do the same
> as the above, but then ran into problems with exporting
> and importing some symbols from the tests and from mod_apreq.

Interesting. 

> With this, I then get a couple of errors in compiling libapreq.
> The first one, from apreq_cookie.c, says
> ===================================================================
> apreq_cookie.c
> ..\src\apreq_cookie.c(65) : error C2059: syntax error : '('
> ..\src\apreq_cookie.c(71) : error C2059: syntax error : '('
> ==================================================================
> I think this is because VC++ seems to get confused by the
> declarations/definitions of apreq_cookie and apreq_add_cookie;
> the following

[...apreq_cookie.[ch] patch...]

+1.

> The next thing, in apreq_tables.c, is an error:
> ====================================================================
> apreq_tables.c ..\src\apreq_tables.c(504) : error C2152: '=' :
> pointers to functions with different attributes
> ..\src\apreq_tables.c(505) : error C2152: '=' : pointers to
> functions with different attributes
> ===================================================================
> I'm not sure of this, but the following helps here:
> ==================================================================
> Index: apreq_tables.c
> ===================================================================
> RCS file: /home/cvspublic/httpd-apreq-2/src/apreq_tables.c,v
> retrieving revision 1.31
> diff -u -r1.31 apreq_tables.c
> --- apreq_tables.c	20 May 2003 20:10:59 -0000	1.31
> +++ apreq_tables.c	16 Jun 2003 04:40:35 -0000
> @@ -501,8 +501,8 @@
>      /* XXX: is memset(*,-1,*) portable ??? */
>      memset(t->root, -1, TABLE_HASH_SIZE * sizeof(int));
> 
> -    t->merge  = apreq_merge_values;
> -    t->copy   = apreq_copy_value;
> +    t->merge  = (apreq_value_merge_t *) apreq_merge_values;
> +    t->copy   = (apreq_value_copy_t *) apreq_copy_value;
>      t->ghosts = 0;
>      return t;
>  }

The original source appears broken, but at the moment I 
don't like those casts.  Is it possible to change the 
apreq_value_(merge|copy)_t typedefs to include APREQ_DECLARE?

  typedef APREQ_DECLARE(apreq_value_t *) 
  (apreq_value_merge_t) (apr_pool_t *p, const apr_array_header_t *a);

  typedef APREQ_DECLARE(apreq_value_t *)
  (apreq_value_copy_t)(apr_pool_t *p, const apreq_value_t *v);

Not sure that will work though.  Another possibility would be 
to drop APREQ_DECLARE from apreq_copy_value() & apreq_merge_values()
in apreq.[ch].

> =============================================================
> Finally, in running the tests, I get an error about
> apr_table_compress being unresolved (I'm running Apache/2.0.46).
> The following

[...]

> helps here.

There is no apr_table_compress() function in apr_tables yet, 
so the undefined symbol will occur on all platforms.

The plan is to eventually drop apreq_tables once we get
the necessary (callback/compress) functionality into apr_tables.
In the meantime I've taken performance.c and tables.c
out of the CuTest suite, so I wouldn't worry about fixing 
those tests right now.

> With these diffs, all the enabled tests under t/ pass. The
> perl modules build successfully, but there's some problems
> with some of the tests, specifically involving inheritance
> (for example, in TestApReq/big_input.pm, the methods
> $apr->content_type() and $apr->print() can't be found,
> but the tests are OK if $r->content_type() and $r->print()
> are used).

Hmm, this is a pretty important (and timely) issue.
The base class for Apache::Request is determined
at load-time via Apache::Request->env, which should
normally return "Apache::RequestRec".  There might be
a problem with apreq_xs_env not finding the
apreq_env = "APACHE2" definition in mod_apreq.c.
You might try adding some Perl_warn diagnostics to the
APREQ_XS_DEFINE_ENV macro in xsbuilder/apreq_xs_postperl.h 
and check t/log/error_log for clues.

-- 
Joe Schaefer


Mime
View raw message