You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2016/12/01 05:23:53 UTC
1.6 apr/apr-util scope/timetable?
Even as httpd is operating under paralysis by analysis, we are long past a
year since the last releases.
Is there anything holding up the jumps to 1.6, or 2.0?
I'd personally like to see an API harmonising memcache to redis, but that
can't possibly be a showstopper to any incremental release.
If nobody else offers, I'll T&R 1.6 objects in 72 or so hours for a vote,
alongside the first 2.0 RC.
Feedback welcomed.
Cheers,
Bill
Re: 1.6 apr/apr-util scope/timetable?
Posted by Gregg Smith <gl...@gknw.net>.
Please ignore my comments about this.
thx
On 11/30/2016 10:27 PM, Gregg Smith wrote:
> On 11/30/2016 10:05 PM, Gregg Smith wrote:
> revert
>> As for cmakelist.txt, I doubt this is going to work any longer, at
>> least at those paths;
>>
>> SET(EXPAT_SOURCES
>> xml/expat/lib/xmlrole.c
>> xml/expat/lib/xmltok.c
>> xml/expat/lib/xmlparse.c
>> )
>
Re: 1.6 apr/apr-util scope/timetable?
Posted by Gregg Smith <gl...@gknw.net>.
On 11/30/2016 10:05 PM, Gregg Smith wrote:
revert
> As for cmakelist.txt, I doubt this is going to work any longer, at
> least at those paths;
>
> SET(EXPAT_SOURCES
> xml/expat/lib/xmlrole.c
> xml/expat/lib/xmltok.c
> xml/expat/lib/xmlparse.c
> )
Re: 1.6 apr/apr-util scope/timetable?
Posted by Gregg Smith <gl...@gknw.net>.
On 11/30/2016 9:23 PM, William A Rowe Jr wrote:
> Even as httpd is operating under paralysis by analysis, we are long past a
> year since the last releases.
>
> Is there anything holding up the jumps to 1.6, or 2.0?
>
> I'd personally like to see an API harmonising memcache to redis, but that
> can't possibly be a showstopper to any incremental release.
>
> If nobody else offers, I'll T&R 1.6 objects in 72 or so hours for a vote,
> alongside the first 2.0 RC.
>
> Feedback welcomed.
It doesn't look like the option for libxml2 has been backported, I'm
beginning to think it isn't going to be.
As far as I can tell redis is in except for win legacy.
As for cmakelist.txt, I doubt this is going to work any longer, at least
at those paths;
SET(EXPAT_SOURCES
xml/expat/lib/xmlrole.c
xml/expat/lib/xmltok.c
xml/expat/lib/xmlparse.c
)
I'm close to having the legacy for both, I could commit apr/apu by end
of week which I guess is within the 72 hours minus time difference.
Re: 1.6 apr/apr-util scope/timetable?
Posted by Gregg Smith <gl...@gknw.net>.
On 12/3/2016 4:11 PM, William A Rowe Jr wrote:
> On Sat, Dec 3, 2016 at 1:04 PM, Gregg Smith <gl...@gknw.net> wrote:
>
> Right off the bat, with 1.6, we should enable IPv6 out of the box.
I couldn't agree more on this. I was going to mention it but evidently I
spaced it.
Re: 1.6 apr/apr-util scope/timetable?
Posted by Gregg Smith <gl...@gknw.net>.
On 12/3/2016 4:11 PM, William A Rowe Jr wrote:
> On Sat, Dec 3, 2016 at 1:04 PM, Gregg Smith <gl...@gknw.net> wrote:
>
>> As for I, the only problematic VC IDE is 10 because it simply refuses to
>> recognize /implib which is a baked in bug. Instead it names the import
>> library the same as the project so all consumers trying to link to
>> apr-1/libapr-1.lib cannot. The majority of squeaking over the years seems
>> to be that VC version IIRC.
>>
>> Renaming the apr/apu/api projects with -1 seems to fix that problem (and
Was there any objection from anyone on this?
> Right off the bat, with 1.6, we should enable IPv6 out of the box. You
> shouldn't have to toggle too much to build crypto or connectors,
I already stated I thought IPv6 was a good idea, I'm on the fence about
crypto because at least 1 downstream project's legacy build would have
to do it again and where the _try* exists it's already too late unless
it can be moved ahead, not sure, never tried.
Re: 1.6 apr/apr-util scope/timetable?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Sat, Dec 3, 2016 at 1:04 PM, Gregg Smith <gl...@gknw.net> wrote:
> As for I, the only problematic VC IDE is 10 because it simply refuses to
> recognize /implib which is a baked in bug. Instead it names the import
> library the same as the project so all consumers trying to link to
> apr-1/libapr-1.lib cannot. The majority of squeaking over the years seems
> to be that VC version IIRC.
>
> Renaming the apr/apu/api projects with -1 seems to fix that problem (and
> remove the link warnings about it) last time I had a VC10 on a machine.
> Quite frankly now is the time to do this for both 1.6 & 2.0. At such time
> as consumers require functions of these versions they can change their
> build to use them if, like httpd, they build it inline with their project.
>
That would seem to be the least destructive way to transition, especially
if CMake is the 'suggested' approach. Feel free to commit that change on
2.0/1.6. I generally don't like disrupting build folks within a major
release cycle, but we have precedent here on the autoconf side, and at
least waited for a minor bump.
The biggest thing for me is that I like to turn features on that are off
> (like IPv6, crypto and db connectors). I've scripted it yet I realize it's
> easy to do with cmake with a mile long command. I do not like having to
> configure each piece and build separately however. Since during new
> releases of a certain consumer I have to do at least 6 builds (x86/64 over
> 3 different VC versions) this becomes more time consuming and more prone to
> error.
>
Right off the bat, with 1.6, we should enable IPv6 out of the box. You
shouldn't have to toggle too much to build crypto or connectors, since they
have subordinate build projects, and if something is off we should fix
that. The only lingering headache for me is to toggle LIBICONV over
APR_ICONV defines, and as you say, a quick patch or awk script solves that.
> Steffen of Apache Lounge wants them, he has voiced this a number of times.
> I did some homework knowing this would come up again and Steffen is by huge
> proportion the largest provider of binaries for Windows. His builds are
> used for every link on the httpd projects download page [1][3] and then
> some with the exception of Apache Haus. I do not think it's too much of a
> problem to keep them, how much time does it take maintaining them with how
> little they ever change? [2]
>
> So -1 to dropping legacy. Since mak/dep are made from dsw/dsp -1 to
> removing them as well.
>
I am certain we agree on the state of APR 1.6, that we will preserve these.
I'm strongly -1 to preserving these for APR 2.0. The corresponding Visual
Studio is *physically not available*, due to Sun/MS legal outcomes. Since
we already required a fixwin32make script to get this into any usable
condition, it seems like a fixcmake result files should get us to an actual
set of .mak files and solution/project files that aren't fix-pathed. I'm
going to explore that and see what can be done.
> Gregg
>
> [1] I know where speaking of apr here but I am looking downstream and I do
> not think that is an incorrect thing to do.
> [2] I realize 2.0 may be in a bit of disrepair at the moment but there's
> time.
>
> [3]https://www.apachehaus.net/misc/wamps.txt
>
>
>
> On 03.12.2016 16:40, William A Rowe Jr wrote:
>
>> I'm wondering, where do we go on trunk with 2.0 on Windows,
>>> now that we can emit solution/project files from CMake, or just
>>> straightforward .mak files? It insisting on a local install of CMake
>>> all that much of a hassle for the Windows build machine?
>>>
>>
>
Re: 1.6 apr/apr-util scope/timetable?
Posted by Gregg Smith <gl...@gknw.net>.
As for I, the only problematic VC IDE is 10 because it simply refuses to
recognize /implib which is a baked in bug. Instead it names the import
library the same as the project so all consumers trying to link to
apr-1/libapr-1.lib cannot. The majority of squeaking over the years
seems to be that VC version IIRC.
Renaming the apr/apu/api projects with -1 seems to fix that problem (and
remove the link warnings about it) last time I had a VC10 on a machine.
Quite frankly now is the time to do this for both 1.6 & 2.0. At such
time as consumers require functions of these versions they can change
their build to use them if, like httpd, they build it inline with their
project.
The biggest thing for me is that I like to turn features on that are off
(like IPv6, crypto and db connectors). I've scripted it yet I realize
it's easy to do with cmake with a mile long command. I do not like
having to configure each piece and build separately however. Since
during new releases of a certain consumer I have to do at least 6 builds
(x86/64 over 3 different VC versions) this becomes more time consuming
and more prone to error.
Steffen of Apache Lounge wants them, he has voiced this a number of
times. I did some homework knowing this would come up again and Steffen
is by huge proportion the largest provider of binaries for Windows. His
builds are used for every link on the httpd projects download page
[1][3] and then some with the exception of Apache Haus. I do not think
it's too much of a problem to keep them, how much time does it take
maintaining them with how little they ever change? [2]
So -1 to dropping legacy. Since mak/dep are made from dsw/dsp -1 to
removing them as well.
Gregg
[1] I know where speaking of apr here but I am looking downstream and I
do not think that is an incorrect thing to do.
[2] I realize 2.0 may be in a bit of disrepair at the moment but there's
time.
[3]https://www.apachehaus.net/misc/wamps.txt
On 03.12.2016 16:40, William A Rowe Jr wrote:
>> I'm wondering, where do we go on trunk with 2.0 on Windows,
>> now that we can emit solution/project files from CMake, or just
>> straightforward .mak files? It insisting on a local install of CMake
>> all that much of a hassle for the Windows build machine?
Re: 1.6 apr/apr-util scope/timetable?
Posted by Branko Čibej <br...@apache.org>.
On 03.12.2016 16:40, William A Rowe Jr wrote:
> I'm wondering, where do we go on trunk with 2.0 on Windows,
> now that we can emit solution/project files from CMake, or just
> straightforward .mak files? It insisting on a local install of CMake
> all that much of a hassle for the Windows build machine?
In my never humbler opinioin: If we maintain a CMake build, whoever
builds from source on Windows should have a local install of CMake. My
experience is that Visual Studio project files generated from CMake are
less than intuitive to use correctly; whenever I use CMake on Windows, I
end up casting this simple spell to build with the generated project files:
cmake --build .
This works consistently regardless of the version of Visual Studio. I've
found that otherwise I'd have to use either msbuild.exe or devenv.exe,
depending on version. Building from the VS GUI /usually/ works but I've
seen enough quirks to never quite trust it.
-- Brane
P.S.: I admit my methods are distinctly (if unintentionally) unfriendly
to the point-and-click crowd.
Re: 1.6 apr/apr-util scope/timetable?
Posted by Branko Čibej <br...@apache.org>.
On 24.12.2016 18:56, Ivan Zhakov wrote:
> CMakeCache.txt On 24 December 2016 at 13:36, Branko \u010cibej
> <br...@apache.org> wrote:
>> On 24.12.2016 08:23, Ivan Zhakov wrote:
>>>>> CMake pollutes working copy with some unrelated files.
>>>> ...it does? I don't think I've had any pollution with my workflow, since
>>>> CMake gives you the option to separate the build tree from the source tree.
>>>> What files do you see showing up?
>>>>
>>> I wasn't aware that CMake has an option for separate build tree. How I
>>> can enable it?
>> mkdir build
>> cd build
>> cmake ..\source
>> cmake --build .
>>
> I've tried but it didn't work. After further investigation I found
> that out of source tree build doesn't work if MakeCache.txt is present
> in source tree.
Hmm, yes, cmake is "smart" that way. Usually the following works for me:
'svn cleanup --remove-unversioned --remove-ignored'
-- Brane
Re: 1.6 apr/apr-util scope/timetable?
Posted by Ivan Zhakov <iv...@visualsvn.com>.
CMakeCache.txt On 24 December 2016 at 13:36, Branko Čibej
<br...@apache.org> wrote:
> On 24.12.2016 08:23, Ivan Zhakov wrote:
>>>> CMake pollutes working copy with some unrelated files.
>>>
>>> ...it does? I don't think I've had any pollution with my workflow, since
>>> CMake gives you the option to separate the build tree from the source tree.
>>> What files do you see showing up?
>>>
>> I wasn't aware that CMake has an option for separate build tree. How I
>> can enable it?
>
> mkdir build
> cd build
> cmake ..\source
> cmake --build .
>
I've tried but it didn't work. After further investigation I found
that out of source tree build doesn't work if MakeCache.txt is present
in source tree. Anyway, now this issue is resolved. I still getting
error when I try to build expat tests.
--
Ivan Zhakov
Re: 1.6 apr/apr-util scope/timetable?
Posted by Branko Čibej <br...@apache.org>.
On 24.12.2016 08:23, Ivan Zhakov wrote:
>>> CMake pollutes working copy with some unrelated files.
>>
>> ...it does? I don't think I've had any pollution with my workflow, since
>> CMake gives you the option to separate the build tree from the source tree.
>> What files do you see showing up?
>>
> I wasn't aware that CMake has an option for separate build tree. How I
> can enable it?
mkdir build
cd build
cmake ..\source
cmake --build .
Re: 1.6 apr/apr-util scope/timetable?
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 27 December 2016 at 22:08, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Sat, Dec 24, 2016 at 1:23 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>
>>
>> Regarding my current problem: I'm getting the following when I attempt
>> to build expat:
>> [[[
>> runtestspp.obj : error LNK2019: unresolved external symbol
>> _align_limit_to_full_utf8_characters referenced in function "void
>> __cdecl test_utf8_auto_align(void)" (?test_utf8_auto_align@@YAXXZ)
>> [D:\Ivan\SVN\expat-cmake\runtestspp.vcxproj]
>> ]]]
>
>
> That's a problem, yes. It looks like a possible expat build issue. Seems
> to apply to the expat test suite. You can toggle building tests in expat
> and obtain the necessary libs separately.
>
> I have no such issues; building expat 2.2.0 my working expat is;
>
> cmake -G "NMake Makefiles" -D CMAKE_INSTALL_PREFIX=..\thirdparty \
> -D BUILD_SHARED_LIBS=ON -D CMAKE_BUILD_TYPE=RelWithDebInfo \
> -D CMAKE_COLOR_MAKEFILE=OFF .
> nmake all install
>
I'm using Visual Studio generator. May be this explains the difference.
> I apply one patch to cmake to compile and link RelWithDebInfo correctly
> to emit .pdb's (It hadn't behaved as documented). This all is working
> under both Studio 2010 and 2015.
>
> FWIW - libxml2 is both a supported substitute for expat in apr-2, as well
> as a requirement for mod_proxy_html, which is why I'm leaning toward
> ignoring expat in the future and having both rely exclusively on libxml2.
>
Did you measure libxml2 vs expat performance? Btw Subversion depends
on libexpat directly because APR doesn't provide SAX XML parser
interface.
>> > Agreed. But three years down the road, after the expert who hand-crafted
>> > a
>> > custom .mak solution has moved on to better things and we're on Visual
>> > Studio vNext, I'm guessing you'll find the same thing will happen there
>> > too
>> > -- unless you have a plan in mind to avoid it?
>> >
>> Well, Visual Studio vNext is going to support CMake builds out of the
>> box and it sounds very promising. But I cannot get it work for APR yet
>> :(
>
> Do you have a similar apr example, or is it simply that you got jammed
> in expat and couldn't move forwards?
>
I've just jammed in expat and didn't move forward.
> I also have this which illustrates windows builds;
>
> https://wiki.apache.org/httpd/WindowsTrunkCompilation
>
> Hope that proves interesting/useful.
Thanks for the link. Btw SourceForge now provides URL for unattended
package download. For example the following command downloads libexpat
2.2.0:
$ curl -L -o expat-2.2.0.tar.bz2
https://downloads.sourceforge.net/project/expat/expat/2.2.0/expat-2.2.0.tar.bz2
--
Ivan Zhakov
Re: 1.6 apr/apr-util scope/timetable?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Sat, Dec 24, 2016 at 1:23 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>
> Regarding my current problem: I'm getting the following when I attempt
> to build expat:
> [[[
> runtestspp.obj : error LNK2019: unresolved external symbol
> _align_limit_to_full_utf8_characters referenced in function "void
> __cdecl test_utf8_auto_align(void)" (?test_utf8_auto_align@@YAXXZ)
> [D:\Ivan\SVN\expat-cmake\runtestspp.vcxproj]
> ]]]
That's a problem, yes. It looks like a possible expat build issue. Seems
to apply to the expat test suite. You can toggle building tests in expat
and obtain the necessary libs separately.
I have no such issues; building expat 2.2.0 my working expat is;
cmake -G "NMake Makefiles" -D CMAKE_INSTALL_PREFIX=..\thirdparty \
-D BUILD_SHARED_LIBS=ON -D CMAKE_BUILD_TYPE=RelWithDebInfo \
-D CMAKE_COLOR_MAKEFILE=OFF .
nmake all install
I apply one patch to cmake to compile and link RelWithDebInfo correctly
to emit .pdb's (It hadn't behaved as documented). This all is working
under both Studio 2010 and 2015.
FWIW - libxml2 is both a supported substitute for expat in apr-2, as well
as a requirement for mod_proxy_html, which is why I'm leaning toward
ignoring expat in the future and having both rely exclusively on libxml2.
> Agreed. But three years down the road, after the expert who hand-crafted a
> > custom .mak solution has moved on to better things and we're on Visual
> > Studio vNext, I'm guessing you'll find the same thing will happen there
> too
> > -- unless you have a plan in mind to avoid it?
> >
> Well, Visual Studio vNext is going to support CMake builds out of the
> box and it sounds very promising. But I cannot get it work for APR yet
> :(
Do you have a similar apr example, or is it simply that you got jammed
in expat and couldn't move forwards?
I also have this which illustrates windows builds;
https://wiki.apache.org/httpd/WindowsTrunkCompilation
Hope that proves interesting/useful.
Re: 1.6 apr/apr-util scope/timetable?
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 21 December 2016 at 10:05, Jacob Champion <ch...@gmail.com> wrote:
> Ooh, this caught my eye. Mild apologies for poking my head in.
>
> On 12/20/2016 10:48 PM, Ivan Zhakov wrote:
>>
>> The problem with generators like CMake that they multiply problems in
>> MSVC + SDK.
>
>
> Can you expand on this? I'm quite happy with CMake + APR 2.0 + httpd on
> Windows for my test builds.
>
I mean that with CMake you may get many combinations of CMake
problems/quirks and MSVC problems.
Regarding my current problem: I'm getting the following when I attempt
to build expat:
[[[
runtestspp.obj : error LNK2019: unresolved external symbol
_align_limit_to_full_utf8_characters referenced in function "void
__cdecl test_utf8_auto_align(void)" (?test_utf8_auto_align@@YAXXZ)
[D:\Ivan\SVN\expat-cmake\runtestspp.vcxproj]
]]]
>> I personally still prefer using native build tools, like APR *already*
>> uses for other platforms: autoconf/configure for *nix, NWGNUMake for
>> Netware. The only benefit would be if CMake will be possible for *all*
>> platforms, for *nix feel CMake pain too :) In this case benefit would
>> to have single place for included source files etc.
>
>
> This position confuses me a bit. I thought the entire point of CMake was to
> generate a native build system, no? And you can choose *which* build system
> to generate based on the tools you have available to you, which is awesome.
>
> I understand CMake has bugs, and I agree that those bugs have to be weighed
> against the benefit of using "yet another" tool. But the job of the CMake
> developers is to find and fix those bugs, while the job of APR developers
> should be to find and fix bugs in APR (as opposed to fixing bugs in yet
> another handcrafted build system).
>
Indirection is the problem: I have to find the way how to instruct
CMake to generate native build system files as I want and don't break
other generators result.
>> CMake pollutes working copy with some unrelated files.
>
>
> ...it does? I don't think I've had any pollution with my workflow, since
> CMake gives you the option to separate the build tree from the source tree.
> What files do you see showing up?
>
I wasn't aware that CMake has an option for separate build tree. How I
can enable it?
>> Generated solution/project files are not perfect and to tweak them
>> developer have to deal with CMake.
>
>
> Agreed. But three years down the road, after the expert who hand-crafted a
> custom .mak solution has moved on to better things and we're on Visual
> Studio vNext, I'm guessing you'll find the same thing will happen there too
> -- unless you have a plan in mind to avoid it?
>
Well, Visual Studio vNext is going to support CMake builds out of the
box and it sounds very promising. But I cannot get it work for APR yet
:(
--
Ivan Zhakov
Re: 1.6 apr/apr-util scope/timetable?
Posted by Jim Jagielski <ji...@jaguNET.com>.
I'm thinking that trying to do a 1.6 release in Jan 2017 makes
some sense. It would help in some httpd things. As far as
I can tell, everyone is in agreement, but wanted clarity to
make sure.
thx.
Re: 1.6 apr/apr-util scope/timetable?
Posted by Jacob Champion <ch...@gmail.com>.
Ooh, this caught my eye. Mild apologies for poking my head in.
On 12/20/2016 10:48 PM, Ivan Zhakov wrote:
> The problem with generators like CMake that they multiply problems in
> MSVC + SDK.
Can you expand on this? I'm quite happy with CMake + APR 2.0 + httpd on
Windows for my test builds.
> I personally still prefer using native build tools, like APR *already*
> uses for other platforms: autoconf/configure for *nix, NWGNUMake for
> Netware. The only benefit would be if CMake will be possible for *all*
> platforms, for *nix feel CMake pain too :) In this case benefit would
> to have single place for included source files etc.
This position confuses me a bit. I thought the entire point of CMake was
to generate a native build system, no? And you can choose *which* build
system to generate based on the tools you have available to you, which
is awesome.
I understand CMake has bugs, and I agree that those bugs have to be
weighed against the benefit of using "yet another" tool. But the job of
the CMake developers is to find and fix those bugs, while the job of APR
developers should be to find and fix bugs in APR (as opposed to fixing
bugs in yet another handcrafted build system).
> CMake pollutes working copy with some unrelated files.
...it does? I don't think I've had any pollution with my workflow, since
CMake gives you the option to separate the build tree from the source
tree. What files do you see showing up?
> Generated solution/project files are not perfect and to tweak them developer have to deal with CMake.
Agreed. But three years down the road, after the expert who hand-crafted
a custom .mak solution has moved on to better things and we're on Visual
Studio vNext, I'm guessing you'll find the same thing will happen there
too -- unless you have a plan in mind to avoid it?
--Jacob
Re: 1.6 apr/apr-util scope/timetable?
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 17 December 2016 at 10:54, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Sat, Dec 17, 2016 at 1:34 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>
>> On 3 December 2016 at 18:40, William A Rowe Jr <wr...@rowe-clan.net>
>> wrote:
>> > On Sat, Dec 3, 2016 at 6:00 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> >> 1. Currently apr 1.6.x doesn't build on Windows using makefiles:
>> >> [[[
>> >> link.exe @C:\Users\ivan\AppData\Local\Temp\nm2BCE.tmp
>> >> Creating library .\x64\Release\libapr-1.lib and object
>> >> .\x64\Release\libapr-1.exp
>> >> poll.obj : error LNK2019: unresolved external symbol
>> >> apr_poll_drain_wakeup_pipe referenced in function impl_pollset_poll
>> >> select.obj : error LNK2001: unresolved external symbol
>> >> apr_poll_drain_wakeup_pipe
>> >> pollcb.obj : error LNK2019: unresolved external symbol
>> >> apr_poll_create_wakeup_pipe referenced in function
>> >> apr_pollcb_create_ex
>> >> pollset.obj : error LNK2001: unresolved external symbol
>> >> apr_poll_create_wakeup_pipe
>> >> pollcb.obj : error LNK2019: unresolved external symbol
>> >> apr_poll_close_wakeup_pipe referenced in function pollcb_cleanup
>> >> pollset.obj : error LNK2001: unresolved external symbol
>> >> apr_poll_close_wakeup_pipe
>> >> .\x64\Release\libapr-1.dll : fatal error LNK1120: 3 unresolved
>> >> externals
>> >> NMAKE : fatal error U1077: '"C:\Program Files
>> >> (x86)\VS14\VC\BIN\amd64\link.exe"' : return code '0x460'
>> >> Stop.
>> >> NMAKE : fatal error U1077: '"C:\Program Files
>> >> (x86)\VS14\VC\BIN\amd64\nmake.exe"' : return code '0x2'
>> >> Stop.
>> >> ]]]
>> >>
>> >> Attached patch apr-1.6.x-win32-fix-makefiles-v1.patch.txt fixes this
>> >> problem. There is no makefiles for Windows on trunk, so how should I
>> >> proceed? May I just commit this patch to 1.6.x branch or it's better
>> >> to propose it to STATUS?
>> >
>> >
>> > +1 to simply commit. "windows makefiles" (as derived from .dsp/.dsw)
>> > had proven too volatile to leave on trunk, a lot like "configure"
>> > itself.
>> > The theory had been that 1.released doesn't change all that much
>> > again, even as trunk is expanded and refactored.
>> >
>> Committed in r1772477.
>>
>> >> 2. The same problem with CMake build. There is no such problem on
>> >> trunk. Attached patch apr-1.6.x-win32-fix-cmake-v1.patch
>> >>
>> Committed in r1772478.
>>
>> >> 3. Compilation fails due unresolved external symbol
>> >> file_socket_pipe_close referenced in function
>> >> _apr_poll_close_wakeup_pipe. This happens because there is no
>> >> file_socket_pipe_close() function on the 1.6.x branch: it's named
>> >> apr_file_socket_pipe_close(). Solution could either backport r892386
>> >> [1] from trunk or apply attached patch
>> >> (apr-1.6.x-unix-wakeup.patch.txt) . The r892386 doesn't merge cleanly
>> >> so I think applying local patch to branch is better.
>> >>
>> >> I'm not familiar with APR release/backport process yet, so please
>> >> excuse me if my questions are stupid.
>> >>
>> >> [1] https://svn.apache.org/r892386
>> >
>> >
>> > Nope, no dumb questions here.
>> >
>> > I'm wondering, where do we go on trunk with 2.0 on Windows,
>> > now that we can emit solution/project files from CMake, or just
>> > straightforward .mak files? It insisting on a local install of CMake
>> > all that much of a hassle for the Windows build machine?
>> >
>> From the library consumer perspective it's always better when library
>> can be build using native tools. For Windows it's .mak files or
>> msbuild scripts. Requiring tools like CMake is not only adds
>> additional dependency to install. It also it's another tools with it's
>> own quirks/problems etc. As anecdotal evidence I still cannot build
>> APR 2.0 using CMake, because I cannot build Expat using CMake.
>
>
> Ok, in all fairness, that's not a fair comment, not one VS toolchain
> works like the prior revision of the VS toolchain, unlike most all
> *nix toolchains.
>
I've different experience: I'm switching from toolchain VS 2010 to
VS2012, VS2013, VS2015 and VS2017 without problems.
> And the size of the CMake toolchain is essentially nothing, compared
> to the scope of any MSVC + SDK toolchain. Yes, it is an extra tool,
> and so are bash/sed/awk/libtool/etc/etc on *nix.
The problem with generators like CMake that they multiply problems in
MSVC + SDK.
>
> Digging into expat 2.2.0 because that's all we have to discuss...
> it is CMake. And that is the only current version. Your objection,
> once again?
>
I personally still prefer using native build tools, like APR *already*
uses for other platforms: autoconf/configure for *nix, NWGNUMake for
Netware. The only benefit would be if CMake will be possible for *all*
platforms, for *nix feel CMake pain too :) In this case benefit would
to have single place for included source files etc.
>>
>> But as library developer things are a little bit more complicated:
>> Visual Studio solution/project files are almost required for good
>> development/debugging experience. In theory CMake generates them, but
>> in practice there are several problems:
>> - CMake pollutes working copy with some unrelated files.
>
>
> And abspaths that are moronic, but that is sadly by-design.
>
>>
>> - Generated solution/project files are not perfect and to tweak them
>> developer have to deal with CMake.
>
>
> Which is different than what arbitrary project/solution files that any
> individual projects create? httpd requires at least 12-14 distinct
> component builds.
>
>>
>> Because of problems above I use my own solution/project files for
>> Apache Serf development and don't use SCons which 'official' build
>> system for Serf.
>
>
> And I've reinvented all those wheels too, for at least 15 years.
> It would be nice to start finding some common reference points.
>
>>
>> I think ideal build system for library like APR should be:
>> - Hand crafted NMake files to build library from source distribution.
>> - Solution/project files for some predefined version of Visual Studio
>> (currently newer version of Visual Studio supports reading and
>> building solutions/projects created by older Visual Studio version)
>
>
> All of this has been done. The worst of the best by the OpenSSL
> team. The most convoluted by our effort. In the end, fixing the
> results of the CMake output might be the straightest line to one
> solid solution, and patching CMake in minor respects, especially
> if accepted upstream, would be even more efficient.
>
> Consider that all of your Visual Studio interactive arguments do
> apply equally to giving an Eclipse-based gcc developer the same
> introspection of the sources, and debugging capabilities.
>
> Immediate term, based on yet another failed httpd release, is
> that .dsp files must die now (or, at least in 2.0 release.) Some
> facility for a straightforward makefile should remain, but no one
> can argue that an unavailable Microsoft-discarded-by-Sun-
> lawsuit product fills that void.
>
> apr/build/fixwin32mak.pl has existed forever because of how
> bogus all of these files are. Why not tweak them to address
> our frustration with CMake?
>
Of course .dsp files must die. I suggest to replace them with
straightforward, handwritten makefiles as an official way to build APR
on Windows.
--
Ivan Zhakov
Re: 1.6 apr/apr-util scope/timetable?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Sat, Dec 17, 2016 at 1:34 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 3 December 2016 at 18:40, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> > On Sat, Dec 3, 2016 at 6:00 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> >> 1. Currently apr 1.6.x doesn't build on Windows using makefiles:
> >> [[[
> >> link.exe @C:\Users\ivan\AppData\Local\Temp\nm2BCE.tmp
> >> Creating library .\x64\Release\libapr-1.lib and object
> >> .\x64\Release\libapr-1.exp
> >> poll.obj : error LNK2019: unresolved external symbol
> >> apr_poll_drain_wakeup_pipe referenced in function impl_pollset_poll
> >> select.obj : error LNK2001: unresolved external symbol
> >> apr_poll_drain_wakeup_pipe
> >> pollcb.obj : error LNK2019: unresolved external symbol
> >> apr_poll_create_wakeup_pipe referenced in function
> >> apr_pollcb_create_ex
> >> pollset.obj : error LNK2001: unresolved external symbol
> >> apr_poll_create_wakeup_pipe
> >> pollcb.obj : error LNK2019: unresolved external symbol
> >> apr_poll_close_wakeup_pipe referenced in function pollcb_cleanup
> >> pollset.obj : error LNK2001: unresolved external symbol
> >> apr_poll_close_wakeup_pipe
> >> .\x64\Release\libapr-1.dll : fatal error LNK1120: 3 unresolved externals
> >> NMAKE : fatal error U1077: '"C:\Program Files
> >> (x86)\VS14\VC\BIN\amd64\link.exe"' : return code '0x460'
> >> Stop.
> >> NMAKE : fatal error U1077: '"C:\Program Files
> >> (x86)\VS14\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> >> Stop.
> >> ]]]
> >>
> >> Attached patch apr-1.6.x-win32-fix-makefiles-v1.patch.txt fixes this
> >> problem. There is no makefiles for Windows on trunk, so how should I
> >> proceed? May I just commit this patch to 1.6.x branch or it's better
> >> to propose it to STATUS?
> >
> >
> > +1 to simply commit. "windows makefiles" (as derived from .dsp/.dsw)
> > had proven too volatile to leave on trunk, a lot like "configure" itself.
> > The theory had been that 1.released doesn't change all that much
> > again, even as trunk is expanded and refactored.
> >
> Committed in r1772477.
>
> >> 2. The same problem with CMake build. There is no such problem on
> >> trunk. Attached patch apr-1.6.x-win32-fix-cmake-v1.patch
> >>
> Committed in r1772478.
>
> >> 3. Compilation fails due unresolved external symbol
> >> file_socket_pipe_close referenced in function
> >> _apr_poll_close_wakeup_pipe. This happens because there is no
> >> file_socket_pipe_close() function on the 1.6.x branch: it's named
> >> apr_file_socket_pipe_close(). Solution could either backport r892386
> >> [1] from trunk or apply attached patch
> >> (apr-1.6.x-unix-wakeup.patch.txt) . The r892386 doesn't merge cleanly
> >> so I think applying local patch to branch is better.
> >>
> >> I'm not familiar with APR release/backport process yet, so please
> >> excuse me if my questions are stupid.
> >>
> >> [1] https://svn.apache.org/r892386
> >
> >
> > Nope, no dumb questions here.
> >
> > I'm wondering, where do we go on trunk with 2.0 on Windows,
> > now that we can emit solution/project files from CMake, or just
> > straightforward .mak files? It insisting on a local install of CMake
> > all that much of a hassle for the Windows build machine?
> >
> From the library consumer perspective it's always better when library
> can be build using native tools. For Windows it's .mak files or
> msbuild scripts. Requiring tools like CMake is not only adds
> additional dependency to install. It also it's another tools with it's
> own quirks/problems etc. As anecdotal evidence I still cannot build
> APR 2.0 using CMake, because I cannot build Expat using CMake.
>
Ok, in all fairness, that's not a fair comment, not one VS toolchain
works like the prior revision of the VS toolchain, unlike most all
*nix toolchains.
And the size of the CMake toolchain is essentially nothing, compared
to the scope of any MSVC + SDK toolchain. Yes, it is an extra tool,
and so are bash/sed/awk/libtool/etc/etc on *nix.
Digging into expat 2.2.0 because that's all we have to discuss...
it is CMake. And that is the only current version. Your objection,
once again?
> But as library developer things are a little bit more complicated:
> Visual Studio solution/project files are almost required for good
> development/debugging experience. In theory CMake generates them, but
> in practice there are several problems:
> - CMake pollutes working copy with some unrelated files.
>
And abspaths that are moronic, but that is sadly by-design.
> - Generated solution/project files are not perfect and to tweak them
> developer have to deal with CMake.
>
Which is different than what arbitrary project/solution files that any
individual projects create? httpd requires at least 12-14 distinct
component builds.
> Because of problems above I use my own solution/project files for
> Apache Serf development and don't use SCons which 'official' build
> system for Serf.
>
And I've reinvented all those wheels too, for at least 15 years.
It would be nice to start finding some common reference points.
> I think ideal build system for library like APR should be:
> - Hand crafted NMake files to build library from source distribution.
> - Solution/project files for some predefined version of Visual Studio
> (currently newer version of Visual Studio supports reading and
> building solutions/projects created by older Visual Studio version)
All of this has been done. The worst of the best by the OpenSSL
team. The most convoluted by our effort. In the end, fixing the
results of the CMake output might be the straightest line to one
solid solution, and patching CMake in minor respects, especially
if accepted upstream, would be even more efficient.
Consider that all of your Visual Studio interactive arguments do
apply equally to giving an Eclipse-based gcc developer the same
introspection of the sources, and debugging capabilities.
Immediate term, based on yet another failed httpd release, is
that .dsp files must die now (or, at least in 2.0 release.) Some
facility for a straightforward makefile should remain, but no one
can argue that an unavailable Microsoft-discarded-by-Sun-
lawsuit product fills that void.
apr/build/fixwin32mak.pl has existed forever because of how
bogus all of these files are. Why not tweak them to address
our frustration with CMake?
Re: 1.6 apr/apr-util scope/timetable?
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 3 December 2016 at 18:40, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Sat, Dec 3, 2016 at 6:00 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> 1. Currently apr 1.6.x doesn't build on Windows using makefiles:
>> [[[
>> link.exe @C:\Users\ivan\AppData\Local\Temp\nm2BCE.tmp
>> Creating library .\x64\Release\libapr-1.lib and object
>> .\x64\Release\libapr-1.exp
>> poll.obj : error LNK2019: unresolved external symbol
>> apr_poll_drain_wakeup_pipe referenced in function impl_pollset_poll
>> select.obj : error LNK2001: unresolved external symbol
>> apr_poll_drain_wakeup_pipe
>> pollcb.obj : error LNK2019: unresolved external symbol
>> apr_poll_create_wakeup_pipe referenced in function
>> apr_pollcb_create_ex
>> pollset.obj : error LNK2001: unresolved external symbol
>> apr_poll_create_wakeup_pipe
>> pollcb.obj : error LNK2019: unresolved external symbol
>> apr_poll_close_wakeup_pipe referenced in function pollcb_cleanup
>> pollset.obj : error LNK2001: unresolved external symbol
>> apr_poll_close_wakeup_pipe
>> .\x64\Release\libapr-1.dll : fatal error LNK1120: 3 unresolved externals
>> NMAKE : fatal error U1077: '"C:\Program Files
>> (x86)\VS14\VC\BIN\amd64\link.exe"' : return code '0x460'
>> Stop.
>> NMAKE : fatal error U1077: '"C:\Program Files
>> (x86)\VS14\VC\BIN\amd64\nmake.exe"' : return code '0x2'
>> Stop.
>> ]]]
>>
>> Attached patch apr-1.6.x-win32-fix-makefiles-v1.patch.txt fixes this
>> problem. There is no makefiles for Windows on trunk, so how should I
>> proceed? May I just commit this patch to 1.6.x branch or it's better
>> to propose it to STATUS?
>
>
> +1 to simply commit. "windows makefiles" (as derived from .dsp/.dsw)
> had proven too volatile to leave on trunk, a lot like "configure" itself.
> The theory had been that 1.released doesn't change all that much
> again, even as trunk is expanded and refactored.
>
Committed in r1772477.
>> 2. The same problem with CMake build. There is no such problem on
>> trunk. Attached patch apr-1.6.x-win32-fix-cmake-v1.patch
>>
Committed in r1772478.
>> 3. Compilation fails due unresolved external symbol
>> file_socket_pipe_close referenced in function
>> _apr_poll_close_wakeup_pipe. This happens because there is no
>> file_socket_pipe_close() function on the 1.6.x branch: it's named
>> apr_file_socket_pipe_close(). Solution could either backport r892386
>> [1] from trunk or apply attached patch
>> (apr-1.6.x-unix-wakeup.patch.txt) . The r892386 doesn't merge cleanly
>> so I think applying local patch to branch is better.
>>
>> I'm not familiar with APR release/backport process yet, so please
>> excuse me if my questions are stupid.
>>
>> [1] https://svn.apache.org/r892386
>
>
> Nope, no dumb questions here.
>
> I'm wondering, where do we go on trunk with 2.0 on Windows,
> now that we can emit solution/project files from CMake, or just
> straightforward .mak files? It insisting on a local install of CMake
> all that much of a hassle for the Windows build machine?
>
From the library consumer perspective it's always better when library
can be build using native tools. For Windows it's .mak files or
msbuild scripts. Requiring tools like CMake is not only adds
additional dependency to install. It also it's another tools with it's
own quirks/problems etc. As anecdotal evidence I still cannot build
APR 2.0 using CMake, because I cannot build Expat using CMake.
But as library developer things are a little bit more complicated:
Visual Studio solution/project files are almost required for good
development/debugging experience. In theory CMake generates them, but
in practice there are several problems:
- CMake pollutes working copy with some unrelated files.
- Generated solution/project files are not perfect and to tweak them
developer have to deal with CMake.
Because of problems above I use my own solution/project files for
Apache Serf development and don't use SCons which 'official' build
system for Serf.
I think ideal build system for library like APR should be:
- Hand crafted NMake files to build library from source distribution.
- Solution/project files for some predefined version of Visual Studio
(currently newer version of Visual Studio supports reading and
building solutions/projects created by older Visual Studio version).
--
Ivan Zhakov
Re: 1.6 apr/apr-util scope/timetable?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Sat, Dec 3, 2016 at 6:00 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>
> 1. Currently apr 1.6.x doesn't build on Windows using makefiles:
> [[[
> link.exe @C:\Users\ivan\AppData\Local\Temp\nm2BCE.tmp
> Creating library .\x64\Release\libapr-1.lib and object
> .\x64\Release\libapr-1.exp
> poll.obj : error LNK2019: unresolved external symbol
> apr_poll_drain_wakeup_pipe referenced in function impl_pollset_poll
> select.obj : error LNK2001: unresolved external symbol
> apr_poll_drain_wakeup_pipe
> pollcb.obj : error LNK2019: unresolved external symbol
> apr_poll_create_wakeup_pipe referenced in function
> apr_pollcb_create_ex
> pollset.obj : error LNK2001: unresolved external symbol
> apr_poll_create_wakeup_pipe
> pollcb.obj : error LNK2019: unresolved external symbol
> apr_poll_close_wakeup_pipe referenced in function pollcb_cleanup
> pollset.obj : error LNK2001: unresolved external symbol
> apr_poll_close_wakeup_pipe
> .\x64\Release\libapr-1.dll : fatal error LNK1120: 3 unresolved externals
> NMAKE : fatal error U1077: '"C:\Program Files
> (x86)\VS14\VC\BIN\amd64\link.exe"' : return code '0x460'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files
> (x86)\VS14\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> Stop.
> ]]]
>
> Attached patch apr-1.6.x-win32-fix-makefiles-v1.patch.txt fixes this
> problem. There is no makefiles for Windows on trunk, so how should I
> proceed? May I just commit this patch to 1.6.x branch or it's better
> to propose it to STATUS?
>
+1 to simply commit. "windows makefiles" (as derived from .dsp/.dsw)
had proven too volatile to leave on trunk, a lot like "configure" itself.
The theory had been that 1.released doesn't change all that much
again, even as trunk is expanded and refactored.
> 2. The same problem with CMake build. There is no such problem on
> trunk. Attached patch apr-1.6.x-win32-fix-cmake-v1.patch
>
> 3. Compilation fails due unresolved external symbol
> file_socket_pipe_close referenced in function
> _apr_poll_close_wakeup_pipe. This happens because there is no
> file_socket_pipe_close() function on the 1.6.x branch: it's named
> apr_file_socket_pipe_close(). Solution could either backport r892386
> [1] from trunk or apply attached patch
> (apr-1.6.x-unix-wakeup.patch.txt) . The r892386 doesn't merge cleanly
> so I think applying local patch to branch is better.
>
> I'm not familiar with APR release/backport process yet, so please
> excuse me if my questions are stupid.
>
> [1] https://svn.apache.org/r892386
Nope, no dumb questions here.
I'm wondering, where do we go on trunk with 2.0 on Windows,
now that we can emit solution/project files from CMake, or just
straightforward .mak files? It insisting on a local install of CMake
all that much of a hassle for the Windows build machine?
Re: 1.6 apr/apr-util scope/timetable?
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 1 December 2016 at 08:23, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> Even as httpd is operating under paralysis by analysis, we are long past a
> year since the last releases.
>
> Is there anything holding up the jumps to 1.6, or 2.0?
>
> I'd personally like to see an API harmonising memcache to redis, but that
> can't possibly be a showstopper to any incremental release.
>
> If nobody else offers, I'll T&R 1.6 objects in 72 or so hours for a vote,
> alongside the first 2.0 RC.
>
> Feedback welcomed.
>
1. Currently apr 1.6.x doesn't build on Windows using makefiles:
[[[
link.exe @C:\Users\ivan\AppData\Local\Temp\nm2BCE.tmp
Creating library .\x64\Release\libapr-1.lib and object
.\x64\Release\libapr-1.exp
poll.obj : error LNK2019: unresolved external symbol
apr_poll_drain_wakeup_pipe referenced in function impl_pollset_poll
select.obj : error LNK2001: unresolved external symbol
apr_poll_drain_wakeup_pipe
pollcb.obj : error LNK2019: unresolved external symbol
apr_poll_create_wakeup_pipe referenced in function
apr_pollcb_create_ex
pollset.obj : error LNK2001: unresolved external symbol
apr_poll_create_wakeup_pipe
pollcb.obj : error LNK2019: unresolved external symbol
apr_poll_close_wakeup_pipe referenced in function pollcb_cleanup
pollset.obj : error LNK2001: unresolved external symbol
apr_poll_close_wakeup_pipe
.\x64\Release\libapr-1.dll : fatal error LNK1120: 3 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files
(x86)\VS14\VC\BIN\amd64\link.exe"' : return code '0x460'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files
(x86)\VS14\VC\BIN\amd64\nmake.exe"' : return code '0x2'
Stop.
]]]
Attached patch apr-1.6.x-win32-fix-makefiles-v1.patch.txt fixes this
problem. There is no makefiles for Windows on trunk, so how should I
proceed? May I just commit this patch to 1.6.x branch or it's better
to propose it to STATUS?
2. The same problem with CMake build. There is no such problem on
trunk. Attached patch apr-1.6.x-win32-fix-cmake-v1.patch
3. Compilation fails due unresolved external symbol
file_socket_pipe_close referenced in function
_apr_poll_close_wakeup_pipe. This happens because there is no
file_socket_pipe_close() function on the 1.6.x branch: it's named
apr_file_socket_pipe_close(). Solution could either backport r892386
[1] from trunk or apply attached patch
(apr-1.6.x-unix-wakeup.patch.txt) . The r892386 doesn't merge cleanly
so I think applying local patch to branch is better.
I'm not familiar with APR release/backport process yet, so please
excuse me if my questions are stupid.
[1] https://svn.apache.org/r892386
--
Ivan Zhakov
Re: 1.6 apr/apr-util scope/timetable?
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 21 December 2016 at 07:50, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Nov 30, 2016 23:23, "William A Rowe Jr" <wr...@rowe-clan.net> wrote:
>
> Is there anything holding up the jumps to 1.6, or 2.0?
>
> I'd personally like to see an API harmonising memcache to redis, but that
> can't possibly be a showstopper to any incremental release.
>
>
> What other active itches can be scratched by the middle of January? If
> things can't quite come together... Nothing suggests that 1.7 couldn't
> follow fairly quickly.
>
What is the development plan for 1.7? Is going to be branched from
trunk of from 1.6.x branch? Personally I'd like to focus on APR 2.0.
--
Ivan Zhakov
Re: 1.6 apr/apr-util scope/timetable?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Dec 20, 2016 22:50, "William A Rowe Jr" <wr...@rowe-clan.net> wrote:
Ensure we build well with distributing expat.
*without* (sorry - please excuse tablet keyboard.)
Re: 1.6 apr/apr-util scope/timetable?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Nov 30, 2016 23:23, "William A Rowe Jr" <wr...@rowe-clan.net> wrote:
Is there anything holding up the jumps to 1.6, or 2.0?
I'd personally like to see an API harmonising memcache to redis, but that
can't possibly be a showstopper to any incremental release.
What other active itches can be scratched by the middle of January? If
things can't quite come together... Nothing suggests that 1.7 couldn't
follow fairly quickly.
My short list (the idea above is more of a 1.7 sort of timetable) is...
Ensure we build well with distributing expat.
Ensure various win32 builds are solid, especially CMake.
Add flags to apr_uri interface to allow invalid input is rejected.
That's my entire shortlist for the next few weeks, what else do we all have
in mind?
Re: 1.6 apr/apr-util scope/timetable?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Nov 30, 2016 at 11:23 PM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> Even as httpd is operating under paralysis by analysis, we are long past a
> year since the last releases.
>
> Is there anything holding up the jumps to 1.6, or 2.0?
>
> I'd personally like to see an API harmonising memcache to redis, but that
> can't possibly be a showstopper to any incremental release.
>
https://bz.apache.org/bugzilla/show_bug.cgi?id=42848 (IP TOS) looks
like a good enhancement before we tag 1.6. Anything else lingering?
> If nobody else offers, I'll T&R 1.6 objects in 72 or so hours for a vote,
> alongside the first 2.0 RC.
>
>
Since we have some positive activity on this thread, I'm going to put
off a T&R into sometime next week, to give us a chance to pick these
things up. Please update STATUS in apr / apr-util 1.6 branches with
any low-hanging fruit over the weekend so I don't miss it.
I can't think of a way to tag an intermediate, 1.9.x won't work by our
versioning rules, so I'm tempted to call it 2.0.0-dev-rc1 (with the intent
to have a number of -rcX tags before we bless 2.0.0-stable). Another
idea would be to use 2.0.X as 'unstable' (always -dev) and have our
first stable-GA ready release as 2.1.0. Thoughts?
Re: 1.6 apr/apr-util scope/timetable?
Posted by Nick Kew <ni...@apache.org>.
> On 1 Dec 2016, at 04:23, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Even as httpd is operating under paralysis by analysis, we are long past a year since the last releases.
>
> Is there anything holding up the jumps to 1.6, or 2.0?
>
> I'd personally like to see an API harmonising memcache to redis, but that can't possibly be a showstopper to any incremental release.
>
> If nobody else offers, I'll T&R 1.6 objects in 72 or so hours for a vote, alongside the first 2.0 RC.
>
> Feedback welcomed.
Thanks for picking this up.
I’d like to take a quick look for low-hanging backports ahead of 1.6.
Not sure how that might fit in 72 hours, but I’ll prioritise taking a look.
—
Nick Kew
Re: 1.6 apr/apr-util scope/timetable?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Dec 1, 2016 at 2:09 AM, Nick Kew <ni...@apache.org> wrote:
>
> > On 1 Dec 2016, at 04:23, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> >
> > Even as httpd is operating under paralysis by analysis, we are long past
> a year since the last releases.
> >
> > Is there anything holding up the jumps to 1.6, or 2.0?
> >
> > I'd personally like to see an API harmonising memcache to redis, but
> that can't possibly be a showstopper to any incremental release.
> >
> > If nobody else offers, I'll T&R 1.6 objects in 72 or so hours for a
> vote, alongside the first 2.0 RC.
> >
> > Feedback welcomed.
>
> OK, now I recollect why the only APR I’ve touched in years is trunk.
> The 1.x APR/APR_UTIL tree appears to be in limbo, with no trunk of its own.
> We have branches/1.6 serving as a trunk-substitute, and 1.5 in an
> indeterminate
> state (Is it active? Are backports relevant? Is that tumbleweed in the
> cracks?)
>
> Bill, I take it branches/1.6 is the current focus for all backports?
>
/repos/asf/apr/apr/trunk is 2.0, yes
/repos/asf/apr/apr-util/trunk is dead (merged into apr/trunk/)
/repos/asf/apr/apr/branches/1.5.x is current
/repos/asf/apr/apr/branches/1.6.x is next
/repos/asf/apr/apr-util/branches/1.5.x is current
/repos/asf/apr/apr-util/branches/1.6.x is next
The only reason I see for a 1.5.x release would be a security fix, but
provided
we have no regression reports building 1.6.x, it won't be necessary to
backport
those to 1.5.x IMO.
Is anyone taking an interest in updating the website to reflect where we are
> and reduce confusion? If not, I’ll have a go.
>
I have a few too many other things on my plate a.t.m. but am happy to review
edits.
Re: 1.6 apr/apr-util scope/timetable?
Posted by Nick Kew <ni...@apache.org>.
> On 1 Dec 2016, at 04:23, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Even as httpd is operating under paralysis by analysis, we are long past a year since the last releases.
>
> Is there anything holding up the jumps to 1.6, or 2.0?
>
> I'd personally like to see an API harmonising memcache to redis, but that can't possibly be a showstopper to any incremental release.
>
> If nobody else offers, I'll T&R 1.6 objects in 72 or so hours for a vote, alongside the first 2.0 RC.
>
> Feedback welcomed.
OK, now I recollect why the only APR I’ve touched in years is trunk.
The 1.x APR/APR_UTIL tree appears to be in limbo, with no trunk of its own.
We have branches/1.6 serving as a trunk-substitute, and 1.5 in an indeterminate
state (Is it active? Are backports relevant? Is that tumbleweed in the cracks?)
Bill, I take it branches/1.6 is the current focus for all backports?
Is anyone taking an interest in updating the website to reflect where we are
and reduce confusion? If not, I’ll have a go.
—
Nick Kew