[PATCH 00/13] Replace mongoose with civetweb.

[Chris Johns]

On 28/04/2016 18:27, Christian Mauderer wrote:
> 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:
>>>>>
> I put some work into building civetweb using RSB. My configuration is
> now able to build a "libcivetweb.a" using the Makefile of civetweb.

Excellent. GNU make is available in the RSB on all hosts.

How do we package this Makefile?

We have a few things happening we need to land in a coordinated manner. 
We have this work, libbsd, LwIP, and the removal of the current stack 
from the RTEMS source tree. If we do not attempt to coordinate these 
pieces work will be repeated, code duplicated and users will be given a 
confusing inconsistent view of networking.

What you have done here is really important and you are breaking new 
ground. We also have a GSoC project under-way for LwIP and Pavel and I 
have been discussing that work. There are a number of strikingly similar 
issues appearing.

We are currently thinking of a repo for LwIP on git.rtems.org, eg 
rtems-lwip.git. It will contain some build system support files, 
license, a readme (I suppose) and a submodule reference to the upstream 
LwIP repo. The submodule would be a specific hash of the upstream 
project. At release time the release process creates a single tarball of 
all source, I do this for libbsd now.

Do you think this would work for civetweb?

What is not clear to me is do we following the LwIP path and a separate 
repo for this package or do we have an 'rtems-net-services.git' repo 
this code is part of? A combined repo would mean the build system used 
is either a mix based on each part or we unify it to a common build 
system. In time we will have other pieces of code added, eg telnetd etc 
as we moved that from the in source tree.

I see Sebastian removed the unreferenced services directory from libbsd 
this week (the vc email was too big for the list) and thank you 
Sebastian. It did make me wonder how we manage these things.

We also need to unify the network configuration for testing. Currently 
libbsd is inconsistent. Some tests use the waf configure command line 
settings and others do not and force DHCP. I am looking to change this 
so we can have a better solution that allows more complex 
configurations. The intention is this can be used for LwIP as well. I 
will post my ideas when I get time.

> 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?

This is a really good question. I do not know and it also relates to how 
we package this code.

> 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.

I do not wish to see this happen. It is specifically these type of 
changes I am concerned with because it forces a dependence beyond 
standards based headers. We need agreed rules here and we need to stick 
to them.

I see we have a structure issue with these types of tests and I think we 
need find a general solution.

> 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.

Beyond the standards based headers?

> 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.

Lets figure out a suitable scalable architecture for network services 
like this then come back and look at the detail. This is just one package.

Chris