DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=33490>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33490 ------- Additional Comments From [EMAIL PROTECTED] 2006-02-11 21:10 ------- I think I can pause to explain why this hasn't been committed (and wouldn't be in it's present form.) A few of the workarounds are a bit too twisted, no offense intended. The defines used to toggle features could be better handled. Perhaps easier, can you clarify if autoconf/libtool are effective for gcc and mingw environments on Win32? Some of the changes are to .h files that could be deconstructed into .h.in and .hw files for cleaner autodetection. Win32 VC could continue to copy .hw inputs, while autoconf could resolve some of the features. That doesn't help the borland case, of course. But the biggest rule is to keep the patches to one purpose, instead of making the reviewer untangle a set of things that is going on in a large patch. For example, I quickly committed the bit about #else APR_... that was a syntax error (it's fixed on the next 0.9, 1.2 and trunk branches.) If the other parts of this patch were seperated out by function, folks could discuss what the best approach is for each of your desired changes, or apply your recommended patch as-is if there is agreement. Thank you for your efforts, and please consider simplifying and breaking the recommended patch up by behavior. Otherwise I'll try to pull this apart bit by bit, but that's only as my time allows. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
