Re: Build error in swig-pl

[Stefan Sperling <st...@elego.de>]

On Tue, Jun 30, 2009 at 12:10:31PM -0700, David James wrote:
> Perl bindings, Ruby bindings: Just add "result_pool" to the list of
> variables in the %apply statement. The "scratch_pool" should not be
> added to the apply statement, because we don't want the perl bindings
> to associate the returned variables with the scratch_pool. It would
> look like this:
> 
> #if def SWIGPERL
> %apply apr_pool_t *pool {
>    apr_pool_t *dir_pool,
>    apr_pool_t *file_pool,
>    apr_pool_t *node_pool,
>    apr_pool_t *result_pool
> };
> #endif
> 
> #if def SWIGRUBY
> %apply apr_pool_t *pool {
>    apr_pool_t *dir_pool,
>    apr_pool_t *file_pool,
>    apr_pool_t *node_pool,
>    apr_pool_t *result_pool
> };
> #endif

OK that's easy to do.

> Python bindings: Create a specialized typedef for scratch_pool, but

Do you mean typemap instead of typedef?

> leave result_pool alone so that it will be caught by the existing
> wrapper for apr_pool_t *. In this case, the important part about
> wrapping scratch_pool separately is that we make sure that the
> existing wrapper for apr_pool_t * does not grab the scratch pool and
> think that it is being used to store variables. We would also want to
> write a test case to make sure that the returned variables are
> associated with the right pool.

Can you explain this in more detail? Where is the pool wrapper defined?
And once I have that, do I just copy that and rename pool to scratch_pool?

It seems like quite a bit of domain knowledge is required to
work with this stuff :(

Stefan