apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <roo...@electricjellyfish.net>
Subject Re: win32 questions
Date Sun, 21 Nov 2004 21:19:09 GMT
Branko ─îibej wrote:
> 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.

Cool, well if someone who has commit access could do that, I'd 
appreciate it.

>> 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.

Good to know.

>> 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.

Ahh, I just can't read then ;-)

>> 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.

Maybe nobody uses the dlls.  Or nobody uses the random number generator. 
  It is rather new, after all.

In any case, this means I should have something that can generate 
apr.dsp and libapr.dsp later tonight or tomorrow.  No promises as to how 
much it'll actually work, since I don't actually have a copy of VC6, but 
it'll at least look similar enough to the existing ones in the tree that 
someone on win32 will have a fighting chance to pound it into working 
order and commit it.

Thanks,

-garrett

Mime
View raw message