On Mon, 18 May 2020 at 07:42, Jan Ehrhardt wrote:
> Ivan Zhakov in gmane.comp.apache.apr.devel (Thu, 14 May 2020 12:08:26
> +0300):
> >Do we really need to keep compatibility code for operating systems
> >that are not supported for years just for a few special companies?
> >They still can use
Ivan Zhakov in gmane.comp.apache.apr.devel (Thu, 14 May 2020 12:08:26
+0300):
>Do we really need to keep compatibility code for operating systems
>that are not supported for years just for a few special companies?
>They still can use APR 1.x anyway.
>
>PS: This topic has been discussed a year ago.
On 14/05/2020 10:48, Steffen wrote:
On Wednesday 13/05/2020 at 10:41, Mladen Turk wrote:
Hi,
Please tell me what is the exact issue with dsw/dsp/mak.
Hard to work with and maintain, but if someone
founds it usabe, then fine.
When I look at the cmake in current HTTP/Apr GA, it is not good
On Thu, 14 May 2020 at 11:48, Steffen wrote:
>
>
>
>
> Good day,
>
> On Wednesday 13/05/2020 at 10:41, Mladen Turk wrote:
> > Hi,
> >
> > Related mostly to Windows port
> >
> > 1. Remove all those .dsp, .dsw .mak files from APR trunk
> > None of them works for years.
> > Replace all that
Good day,
On Wednesday 13/05/2020 at 10:41, Mladen Turk wrote:
Hi,
Related mostly to Windows port
1. Remove all those .dsp, .dsw .mak files from APR trunk
None of them works for years.
Replace all that with cmake
-1
I works from the beginning, and can be used with VC6.0 - VS16.
Gregg Smith in gmane.comp.apache.apr.devel (Wed, 13 May 2020 14:49:37
-0700):
>Well, with very little work I'm sure the dsw/dsp will still work in any
>Visual Studio IDE of the day.
True. I am still using the dwp/dsw conversion for building apr and httpd
in Visual Studio up to VS 2019. The only
Mladen Turk in gmane.comp.apache.apr.devel (Wed, 13 May 2020 10:41:37
+0200):
>Related mostly to Windows port
>
>1. Remove all those .dsp, .dsw .mak files from APR trunk
>None of them works for years.
>Replace all that with cmake
-1 for #1. I am still using the dsp/dsw's in apr and httpd.
On Wed, May 13, 2020, 15:08 Gregg Smith wrote:
>
> #1, I think this may be your opinion but not so much mine. No, .mak/defs
> are not in trunk but they never have been and they have been added at
> fork to currently all the 1.0 series. And unless I'm mistaken, 1.7 was
> not that long ago.
>
I guess I'm very confused.
All modern flavors of Visual Studio *ship* cmake and ninja. The CMake
config lets us toggle options, things that static build files can't do
well. CMake will emit nmake, or ninja, or vcproj/sln. And as noted
elsethread, it should be able to build for Linux as easily as
Well, with very little work I'm sure the dsw/dsp will still work in any
Visual Studio IDE of the day. They are not that difficult to modify by
hand. The mak/dep files have to be generated since they are not in
trunk. I wish they were in trunk even though they are more difficult to
hand modify,
On 13/05/2020 22:08, Gregg Smith wrote:
#1, I think this may be your opinion but not so much mine. No, .mak/defs are
not in trunk but they never have been and they have been added at fork to
currently all the 1.0 series. And unless I'm mistaken, 1.7 was not that long
ago.
Well, I'll try
Hello,
On 5/13/2020 1:41 AM, Mladen Turk wrote:
Hi,
Related mostly to Windows port
1. Remove all those .dsp, .dsw .mak files from APR trunk
None of them works for years.
Replace all that with cmake
2. Remove all _WIN32_WCE, APR_NOT_IN_WCE
Just a bunch of code for Windows CE that
On Wed, 13 May 2020 at 22:31, Mladen Turk wrote:
> On 13/05/2020 21:04, Ivan Zhakov wrote:
> > On Wed, 13 May 2020 at 11:41, Mladen Turk mt...@apache.org>> wrote:
> >
> > 1. Remove all those .dsp, .dsw .mak files from APR trunk
> > None of them works for years.
> >
> > Not as I
On Wed, May 13, 2020 at 3:41 AM Mladen Turk wrote:
> Hi,
>
> Related mostly to Windows port
>
> 1. Remove all those .dsp, .dsw .mak files from APR trunk
> None of them works for years.
> Replace all that with cmake
> 2. Remove all _WIN32_WCE, APR_NOT_IN_WCE
> Just a bunch of code for
On 13/05/2020 21:04, Ivan Zhakov wrote:
On Wed, 13 May 2020 at 11:41, Mladen Turk mailto:mt...@apache.org>> wrote:
1. Remove all those .dsp, .dsw .mak files from APR trunk
None of them works for years.
Not as I objection, but .mak files work for me.
Not for me. .mak files are
On Wed, 13 May 2020 at 11:41, Mladen Turk wrote:
> Hi,
>
> Related mostly to Windows port
>
> 1. Remove all those .dsp, .dsw .mak files from APR trunk
> None of them works for years.
>
Not as I objection, but .mak files work for me.
Replace all that with cmake
> 2. Remove all
On 13/05/2020 11:28, Branko Čibej wrote:
On 13.05.2020 10:41, Mladen Turk wrote:
1. Remove all APU_XXX references
Since the apr-util is apr
remove all APU_XXX defines and API
This will cause any coded that's upgrading from apr/apu 1.x to apr 2.x
and uses those symbols to break. That's
On 13.05.2020 11:58, Greg Stein wrote:
> Isn't the whole idea of moving to 2.0 to lose the dead weight, and
> allow a break in API compatibility?
Sure is. The question is, what's dead weight and what's gratuitous breakage.
$ cat apu.h
#include "apr.h"
#define APU_XXX...
^^^ could be seen as
Isn't the whole idea of moving to 2.0 to lose the dead weight, and allow a
break in API compatibility?
On Wed, May 13, 2020 at 4:28 AM Branko Čibej wrote:
> On 13.05.2020 10:41, Mladen Turk wrote:
> > Hi,
> >
> > Related mostly to Windows port
> >
> > 1. Remove all those .dsp, .dsw .mak files
On 13.05.2020 10:41, Mladen Turk wrote:
> Hi,
>
> Related mostly to Windows port
>
> 1. Remove all those .dsp, .dsw .mak files from APR trunk
> None of them works for years.
> Replace all that with cmake
> 2. Remove all _WIN32_WCE, APR_NOT_IN_WCE
> Just a bunch of code for Windows CE that
20 matches
Mail list logo
