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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
