before shared caching and other SMP features were
committed.
Thanks for the details. I guess we need an updated MinGW test run to see
where the particular issues are and see if and why they exist.
Currently trunk doesn't build on windows at all, mostly stuff at the
winsock api level.
The
I undid part of that, by renaming each of these Config
files to something including the directory name (e.g. ssl/Config.h ->
ssl/SslConfig.h).
This is all in revno 3 of the mswin branch; it can be merged to
trunk any time IMO (hard to post a patch, it's mostly file renaming).
--
/kinkie
t; So this morning I undid part of that, by renaming each of these Config
> files to something including the directory name (e.g. ssl/Config.h ->
> ssl/SslConfig.h).
> This is all in revno 3 of the mswin branch; it can be merged to
> trunk any time IMO (hard to post a patc
On 21/01/2012 2:46 a.m., Kinkie wrote:
I can handle that.
In most cases what is needed is extra header files. Should I go
through the normal review process or are these harmless enough to be
merged directly?
Thank you. Normal process I think for this part, just in case we miss
something in the
On Fri, Jan 20, 2012 at 3:43 PM, Amos Jeffries wrote:
> On 21/01/2012 2:46 a.m., Kinkie wrote:
I can handle that.
In most cases what is needed is extra header files. Should I go
through the normal review process or are these harmless enough to be
merged directly?
>>>
hat, by renaming each of these Config
files to something including the directory name (e.g. ssl/Config.h ->
ssl/SslConfig.h).
This is all in revno 3 of the mswin branch; it can be merged to
trunk any time IMO (hard to post a patch, it's mostly file renaming).
Oh, and I've hit a ma
On 21/01/2012 4:01 a.m., Kinkie wrote:
On Fri, Jan 20, 2012 at 3:43 PM, Amos Jeffries wrote:
On 21/01/2012 2:46 a.m., Kinkie wrote:
I can handle that.
In most cases what is needed is extra header files. Should I go
through the normal review process or are these harmless enough to be
merged dir
>>> The ultimate end for include/config.h file was to be renamed to
>>> include/squid.h when the old squid.h was emptied out.
>>>
>>> That could be done early like Robert was suggesting a while back;
>>> * moving todays squid.h to squid-old.h
>>> * updating all the existing #include for squid.h t
what happens when anything in any
> of those directories includes "config.h" ? big mess.
>
> So this morning I undid part of that, by renaming each of these Config
> files to something including the directory name (e.g. ssl/Config.h ->
> ssl/SslConfig.h).
> This is all
On 01/20/2012 07:11 AM, Kinkie wrote:
> Oh, and I've hit a major snag with the windows port: TypedMsgHdr
> inherits from msghdr, which is not available on MinGW. There are
> several variants, but in order to try and understand what can be done
> (and if I'm up to the task) I would need to understa
On Fri, Jan 20, 2012 at 11:52 PM, Alex Rousskov
wrote:
> On 01/20/2012 07:11 AM, Kinkie wrote:
>
>> Oh, and I've hit a major snag with the windows port: TypedMsgHdr
>> inherits from msghdr, which is not available on MinGW. There are
>> several variants, but in order to try and understand what can
On 01/23/2012 04:06 AM, Kinkie wrote:
> On Fri, Jan 20, 2012 at 11:52 PM, Alex Rousskov
> wrote:
>> On 01/20/2012 07:11 AM, Kinkie wrote:
>>
>>> Oh, and I've hit a major snag with the windows port: TypedMsgHdr
>>> inherits from msghdr, which is not available on MinGW. There are
>>> several variant
> Whether it is better to continue to use inheritance or switch to a data
> member depends on the msghdr/etc API for a given platform. For a dummy
> squid-specific struct representing msghdr to make TypedMsgHdr and
> friends compile on Windows, it would probably be easier to keep the
> inheritance
Hi,
here's the first part of the merge proposal for the mswin branch.
What I'm doing is simply to examine and try to validate the output of
a "bzr send" from the mswin branch.
These changes should be quite local and windows-specific; when they're
not, they're
On 21/01/2012 11:12 a.m., Kinkie wrote:
Hi,
here's the first part of the merge proposal for the mswin branch.
What I'm doing is simply to examine and try to validate the output of
a "bzr send" from the mswin branch.
These changes should be quite local and windows-specif
15 matches
Mail list logo