On 10/29/2013 9:00 AM, William A. Rowe Jr. wrote:
On Mon, 28 Oct 2013 18:00:26 -0700
Gregg Smith<g...@gknw.net> wrote:
On 10/28/2013 2:37 PM, William A. Rowe Jr. wrote:
On Mon, 28 Oct 2013 16:58:45 -0400
Jeff Trawick<traw...@gmail.com> wrote:
On Mon, Oct 28, 2013 at 4:54 PM, William A. Rowe Jr.
<wr...@rowe-clan.net>wrote:
On Mon, 28 Oct 2013 13:01:09 -0400
Jeff Trawick<traw...@gmail.com> wrote:
On Mon, Oct 28, 2013 at 12:50 PM, Gregg Smith<g...@gknw.net>
wrote:
Just a note,
On 10/19/2013 10:32 AM, Gregg Smith wrote:
On 10/19/2013 7:26 AM, Jeff Trawick wrote:
On Thu, Oct 17, 2013 at 11:08 PM, Gregg Smith<g...@gknw.net
<mailto: g...@gknw.net>> wrote:
I'd like to first rid the 1.5 traditional Windows build
of the Release9x& Debug9x targets. Anyone against this?
no concerns here; is there code that can get deleted too?
probably, I would assume so, I haven't ran it down that far
yet.
I did not do this after all nor do I think I am brave enough to.
apr_escape, testescape and gen_test_char were added into the
build with r1534053.
.mak/.dep files were added in r1534516.
We should be ready to go on the Windows side now.
So, given that 1.5 remains compatible with 1.4... but projects
which build APR themselves will have to adapt to the new
gen_test_char or we need to make the suggested change, let's just
take the httpd example.
Does it make more sense for httpd 2.2 Makefile.win to detect the
presence of gen_test_char and build it when encountered, or does
it make more sense to compile-link-invoke gen_test_char.c? I'm
happy to make the respective change later tonight or tomorrow,
based on consensus.
Is the Windows build interface of apr 1.5.x different such that
httpd's Makefile.win would care?
httpd itself doesn't use apr escape and shouldn't care that apr
happens to have a build utility of the same name as one of its own
(or something is borked).
The httpd 2.2 Makefile.win build invokes the pcre, expat, apr,
apr-iconv and apr-util builds project-by-project, it doesn't use
any corresponding top-level build mechanics. This was one aspect
that was greatly improved by moving to the httpd-2.4 model.
If httpd doesn't pre-build gen_test_char before apr.mak, then the
apr build will fail, unless we nest the new gen_test_char pre-build.
I think the better solution for a one-source file, source generation
app is to embed that build into the [lib]apr.dsp/mak files for now.
But as an alternative, we can teach httpd 2.2 Makefile.win to
anticipate this requirement if that project is present. That would
mean that 1.5 apr wouldn't build with older httpd 2.2 releases,
only the next release onwards.
This is done. The stumble point is that apr.h must be there to
compile gen_test_char.c and it must be run before ar_escape.c is
compiled. So after a lot of trying different ways to do this and get
everything to fire off at the right point in time, I just had to
sandwich it all during the creation of apr.h.
This works in both apr.mak and libspr.mak as well.
Suggestion - should we simply use the CROSS_COMPILE path when building
for win32 .dsp/.mak files, instead?
You mean using the CMake and dropping the "Traditional build" completely?
-1
I currently do not see the problem with having both at this time. Of
course, I am only one voice here. Once 1.5 is tagged I do not forsee any
further problems arising since this should all be set in stone till
1.next/2.0.
