[PATCH 00/13] Replace mongoose with civetweb.

[Christian Mauderer]

Am 27.04.2016 um 02:07 schrieb Chris Johns:
> On 26/04/2016 22:22, Christian Mauderer wrote:
>> Am 26.04.2016 um 04:51 schrieb Chris Johns:
>>> On 26/04/2016 07:22, Joel Sherrill wrote:
>>>>
[removed part not relevant for this part of the discussion]
>>>>       >>
>>>>       >> 2. Currently there is one test case for mghttpd
>>>>      (libtests/mghttpd01).
>>>>       >> This is one of the few tests that check some networking
>>>> functions in
>>>>       >> RTEMS.
>>>
>>> I would be concerned if the only way we can do network testing is to
>>> consume a 3prd party package's source into RTEMS. :)
>>
>> It's not the only test that tests network functions in RTEMS. But as far
>> as I know, there are not many. If we remove it, it will be one less.
> 
> I do not have a simple answer. I have a radical one, split the testsuite
> in 2, with the part in RTEMS specific to the internal and API parts of
> RTEMS, and a second repo that is the tests that depend on "other" parts,
> eg 3rd party libraries. Those tests could configure which tests are
> built depending on the libraries detected. The work flow would need to
> be fast and easy to ensure a speedy compile/test cycle.
> 
> I am going on a bit about this stuff, but I feel it is important. In
> time we will have Buildbot running and we will need to get this stuff
> integrated and my hope is Buildbot, developers and users all use the
> same work flow.
> 
>>
>>>
>>>> Further we should not loose the ability to test software
>>>>      when it
>>>>       >> is build with RSB.
>>>
>>> I agree.
>>>
>>>> How would we handle tests for software in RSB?
>>>>       >>
>>>>       >
>>>>       > That's a Chris question. We should aim to have tests which run
>>>> with
>>>>       > either network stack for RSB built network services. This is a
>>>> good
>>>>       > requirement on the plan to moving to separately built network
>>>> stacks
>>>>       > and services.
>>>
>>> Network testing is an open topic as is vertically integrated packages.
>>> The testing issues exists with libbsd, lwip and the in-tree stack once
>>> we move out of the source tree. As we flesh out the details of
>>> vertically integrating packages we need to figure out now to manage
>>> testing.
>>>
>>> What tests does civetweb provide? If the test is important I would
>>> assume it is important to all users. Can civetweb build the test?
>>>
>>
>> Civetweb has a number of tests. But I think that most would not work
>> with RTEMS without changing them. In RTEMS we currently have a
>> relatively simple testcase that just checks some basic functions.
> 
> OK.
> 
>>
>> I don't think that we would be able to run either of them with the
>> current RSB. And I don't have enough time to integrate a way for testing
>> into RSB within the current project. So moving civetweb out of RTEMS
>> currently means that it is not tested any longer with an RTEMS system
>> (or only if someone does it manually after changing something).
> 
> I do not think the RSB is the way forward for testing. It could build
> tests as a package but that would be the extent. We have rtems-test in
> the tools repo but it is need of further work.
> 
> I do not think we will find a suitable answer for testing in the short
> term. I suspect a second testsuite package may be the answer.
> 
> Chris

I put some work into building civetweb using RSB. My configuration is
now able to build a "libcivetweb.a" using the Makefile of civetweb.

The next steps would be to remove mghttpd from RTEMS. Currently that
means that I have to remove the test too. Any ideas where we could move
it to? If we don't have a solution: Do we really want to leave the code
untested until someone has the time and budget to implement a external
test suit?

Theoretically it should be possible to build and install the libcivetweb
without a RTEMS BSP. When building the BSP, we could detect if the
"civetweb.h" file is there using autoconf and either build the mghttpd01
test or not depending on the result. This would allow it to keep an
RTEMS-specific test for civetweb inside the RTEMS repository.

The only problem is: Currently there is no way to build civetweb prior
to the BSP. Civetweb uses some of the network headers that are currently
provided by the BSP. So the process would extend to the following:
- build BSP (without mghttpd01 test)
- build civetweb
- re-build BSP (this time with mghttpd01 test)
- run tests

This could be solved by moving the network headers into newlib like
suggested in the other thread of discussion.

Kind regards,

Christian

-- 
--------------------------------------------
embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.