Re: Experimental C unit test suite available for hacking

On 05/23/2018 10:32 AM, Marion et Christophe JAILLET wrote: > '--with-test-suite=...' is for the Perl test framework, not for the > 'test/httpdunit'. Ah, yes! Thanks for the reminder; --with-test-suite only enables the `make check` functionality. Sorry, it's been too long. On 05/23/2018 01:21

Re: Experimental C unit test suite available for hacking

Le 23/05/2018 à 20:52, Micha Lenk a écrit : Am 23.05.2018 um 20:18 schrieb Marion et Christophe JAILLET: Could you please try to 'make clean' and 'make' to see if you still have the build issue? No change. :( Regards, Micha I can reproduce the issue if I don't pass any --enable-mpms-shared

Re: Experimental C unit test suite available for hacking

Am 23.05.2018 um 20:18 schrieb Marion et Christophe JAILLET: > Could you please try to 'make clean' and 'make' to see if you still have > the build issue? No change. :( Regards, Micha

Re: Experimental C unit test suite available for hacking

Le 23/05/2018 à 14:48, Micha Lenk a écrit : On 05/25/2017 11:44 PM, Jacob Champion wrote (almost a year ago): Last week I had a personal hackathon since I couldn't make it out to ApacheCon. As a result there is now a C-language unit test suite available in branches/httpdunit (based on

Re: Experimental C unit test suite available for hacking

Le 23/05/2018 à 16:14, Micha Lenk a écrit : Hi Eric, On 05/23/2018 02:59 PM, Eric Covener wrote: I guess the CI setup needs to be updated to at least build the unit tests? I did not configure the build explicitly to run the unit tests, so it is just the plain "make" that causes this

Re: Experimental C unit test suite available for hacking

Le 23/05/2018 à 16:21, Joe Orton a écrit : On Wed, May 23, 2018 at 04:14:39PM +0200, Micha Lenk wrote: Hi Eric, On 05/23/2018 02:59 PM, Eric Covener wrote: I guess the CI setup needs to be updated to at least build the unit tests? I did not configure the build explicitly to run the unit

Re: Experimental C unit test suite available for hacking

On Wed, May 23, 2018, 7:35 AM Micha Lenk wrote: > > It should only get built if you configure --with-test-suite=... and > > specify the path to a perl-framework wc. It builds for me in trunk. > > Hmm, no difference. It seems to get built independent from whether you > specify

Re: Experimental C unit test suite available for hacking

Hi Joe, On 05/23/2018 04:21 PM, Joe Orton wrote: On Wed, May 23, 2018 at 04:14:39PM +0200, Micha Lenk wrote: Hi Eric, On 05/23/2018 02:59 PM, Eric Covener wrote: I guess the CI setup needs to be updated to at least build the unit tests? I did not configure the build explicitly to run the

Re: Experimental C unit test suite available for hacking

On Wed, May 23, 2018 at 04:14:39PM +0200, Micha Lenk wrote: > Hi Eric, > > On 05/23/2018 02:59 PM, Eric Covener wrote: > > I guess the CI setup needs to be updated to at least build the unit tests? > > I did not configure the build explicitly to run the unit tests, so it is > just the plain

Re: Experimental C unit test suite available for hacking

Hi Eric, On 05/23/2018 02:59 PM, Eric Covener wrote: I guess the CI setup needs to be updated to at least build the unit tests? I did not configure the build explicitly to run the unit tests, so it is just the plain "make" that causes this target to get build. I would expect the CI setup to

Re: Experimental C unit test suite available for hacking

On Wed, May 23, 2018 at 8:48 AM, Micha Lenk wrote: > On 05/25/2017 11:44 PM, Jacob Champion wrote (almost a year ago): >> >> Last week I had a personal hackathon since I couldn't make it out to >> ApacheCon. As a result there is now a C-language unit test suite available >> in

Re: Experimental C unit test suite available for hacking

On 25 May 2017, at 11:44 PM, Jacob Champion wrote: > Last week I had a personal hackathon since I couldn't make it out to > ApacheCon. As a result there is now a C-language unit test suite available in > branches/httpdunit (based on trunk). I've tested it with a

Re: slotmem + balancer

> On May 20, 2018, at 4:59 PM, Yann Ylavic wrote: > > > Now we are back to 2.4.29 code, r1822341 is in again, and I committed > additional changes (minimal hopefully) to address the issues reported > in PR 62308 (and PR 62044 still). My own testing, based on the tests >