win32 questions

[Garrett Rooney <ro...@electricjellyfish.net>]

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?

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?

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?

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?

Thanks,

-garrett

Re: win32 questions

[Garrett Rooney <ro...@electricjellyfish.net>]

Branko Čibej wrote:

>> Cool, well if someone who has commit access could do that, I'd 
>> appreciate it.
> 
> 
> /me picks up his magic wand... and finds there's also a 
> threadproc/beos/threadcancel.c, whereupon he decides to wait for further 
> responses before removing both.
> 
> Neither seems to be mentioned in any build scripts, though.

Yeah, and both are old enough that they still have the 1.1 license at 
the top.  I wonder why they were missed when the conversion happened. 
At first I assumed it was a bug in the cvs2svn conversion or something, 
but they still exist in the CVS repository, so that doesn't seem likely...

>> 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.
> 
> 
> Wonderful. I'll see if I can find some time to test the generator.

Great, thanks.

-garrett

Re: win32 questions

[Branko Čibej <br...@xbc.nu>]

Garrett Rooney wrote:

> Branko Čibej wrote:
>
>> 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.

/me picks up his magic wand... and finds there's also a 
threadproc/beos/threadcancel.c, whereupon he decides to wait for further 
responses before removing both.

Neither seems to be mentioned in any build scripts, though.

>> Sounds like a bug to me. I wonder how come nobody has noticed yet.
>
> Maybe nobody uses the dlls.

httpd uses the DLLs. :-)

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

That's more likely, yes.

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

Wonderful. I'll see if I can find some time to test the generator.

-- Brane

Re: win32 questions

[Garrett Rooney <ro...@electricjellyfish.net>]

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

Re: win32 questions

[Branko Čibej <br...@xbc.nu>]

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