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

Reply via email to