apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@xbc.nu>
Subject Re: win32 questions
Date Sun, 21 Nov 2004 21:14:24 GMT
Garrett Rooney wrote:

> I'm playing around with autogenerating dsp files again, and ran into a 
> few weird things I wanted to ask about...
> First of all, threadproc/win32/threadcancel.c doesn't seem to be 
> built.  Or to be finished for that matter, the only function in there 
> that isn't commented out is ap_cancel_thread, which clearly isn't an 
> apr function.  There doesn't seem to be any thread cancellation 
> support anywhere else in APR, so can we just delete this file?

I'd say yes. We can always ressurect it if it becomes interesting.

> Second, I notice in apr.dsp we explicitly exclude misc/win32/apr_app.c 
> from being built, which makes sense, since you clearly don't want it 
> in the library all the time.  Is it absolutely necessary for apr.dsp 
> to exclude it, or can we get away with just not listing it?

Not listing it is enough.

> Third, there are a bunch of header files (apr_random.h, 
> arch/win32/apr_arch_proc_mutex.h, arch/win32/apr_arch_thread_cond.h, 
> and arch/win32/apr_dbg_win32_handles.h specifically) that aren't 
> listed in apr.dsp but do exist in the tree and one 
> (apr_private_common.h) that doesn't exist but is listed.  Any reason 
> this can't be resynched with reality?

apr_private_common.h certainly does exist. It's in include/arch. The 
others should be added to the .dsp.

> Finally, it seems that the random/unix/*.c code is built as part of 
> apr.dsp (the static lib) but not as part of libapr.dsp (the dll), is 
> there a reason for this?

Sounds like a bug to me. I wonder how come nobody has noticed yet.

-- Brane

View raw message