Hi Shiro,
So you mean, retain the STM32 file unchanged in the source tree and then
applying the patch? Or copy it from somewhere and then apply the patch?
I thought of that option as well.
The only issue I see here is that I merged the (example) files provided
by STM32 so that one file can be used for every lwIP API. I managed to
have the same files for alle three APIs this way, which is the cleaner
solution in my opinion. But I guess I could just take the base files for
the Raw API provided by STM32, create the patch to add support for all
other APIs and add all other tweaks required for RTEMS, and then provide
that patch somewhere.
Kind Regards
Robin
On 08.09.21 21:05, Shiro wrote:
Hi, Robin,
Would it be possible to retain the STM32 code, but carve out the
“contaminated” lwIP code into a patch file. Then RTEMS code base
remains “clean” and if I, any user, chose to enable lwIP on STM32, I
could do so by applying that patch. I’d contaminate my src tree, but
that’d be my responsibility and in any case, I’d be compliant (target
is after all an STM32…).
The “patch trick” to manage license contamination has worked well for
others in the past.
Cheers,
-Shiro
On Sep 8, 2021, at 11:51 AM, Robin Müller <robin.muelle...@gmail.com
<mailto:robin.muelle...@gmail.com>> wrote:
Hi,
Unfortunately, there was no other reply to the request.
Easiest solution would be to exclude the STM32 code completely out of
RTEMS code for now. I can host it as example code in a personal
repository.
But then I might have to change the architecture of the lwIP code
again which provided some building blocks to make porting/using it
easier.
Kind Regards
Robin
On Thu, 5 Aug 2021 at 17:00, Gedare Bloom <ged...@rtems.org
<mailto:ged...@rtems.org>> wrote:
STM is not going to fix their Ultimate Liberty License at this time.
https://github.com/STMicroelectronics/STM32CubeH7/issues/139#issuecomment-890806010
<https://github.com/STMicroelectronics/STM32CubeH7/issues/139#issuecomment-890806010>
So, we need to avoid using their example codes.
On Wed, Jun 9, 2021 at 12:16 PM Gedare Bloom <ged...@rtems.org
<mailto:ged...@rtems.org>> wrote:
>
> I joined the Issue. Thanks for working on this.
>
> On Wed, Jun 9, 2021 at 11:30 AM Robin Müller
<robin.muelle...@gmail.com <mailto:robin.muelle...@gmail.com>> wrote:
> >
> > I posted a reply but I think it did not go through. Will post
it now.
> >
> > Kind Regards
> > Robin
> >
> > On Wed, 9 Jun 2021 at 18:31, Robin Müller
<robin.muelle...@gmail.com <mailto:robin.muelle...@gmail.com>> wrote:
> >>
> >> Hi,
> >>
> >> I received a reply from STM32 about the licensing issues.
They requested more specific information about the "vendor device
restrictions" for the HAL code.
> >> The issue is here:
https://github.com/STMicroelectronics/STM32CubeH7/issues/139
<https://github.com/STMicroelectronics/STM32CubeH7/issues/139>
> >> Can anyone provide more information about this (maybe even
directly in the issue) ? I can forward it to them as well. Thanks
a lot in advance!
> >>
> >> Kind Regards
> >> Robin
> >>
> >> On Wed, 28 Apr 2021 at 02:45, Chris Johns <chr...@rtems.org
<mailto:chr...@rtems.org>> wrote:
> >>>
> >>> On 28/4/21 2:58 am, Robin Müller wrote:
> >>> > Okay, I can understand that you'd like to have one build
system only. We had the
> >>> > same issue with a former Makefile build system and the
new CMake system and
> >>> > decided to make the former system obsolete> because
maintaining both of them would be too much work
> >>> For RTEMS what we use has been selected for a range of
important reasons and the
> >>> rtems-central repo and the qual work highlights the
importance of those
> >>> decisions. Waf is a python framework for building software
and in rtems.git our
> >>> build system support is written in a clearly defined
portable language with
> >>> power helper libraries. We can run code formatters on our
build system, have
> >>> unit tests and there is even source level debuggers. We
treat the build system
> >>> like any other piece of code we have.
> >>>
> >>> > First thing I can do is that I split up the patch and
extract the CMake
> >>> > specific files. Concerning a clean solution to allow
users to use CMake without
> >>> > introducing files like CMakeLists.txt,
> >>> > I am not sure right now. Extracting the information
required by CMake would
> >>> > again require scripts to export source files and include
paths.
> >>> > The simplest solution would still be a CMakeLists.txt
file in the root here
> >>> > which simply sets source files and include paths in the
parent scope.
> >>> > which would again be another form of maintenance burden
because it still needs
> >>> > to figure out which port sources to add etc.
> >>>
> >>> What about scons, meson, or a plain Makefile for those who
just want to use
> >>> make, then there is GNU make and BSD make, the list is
large? Do we open the
> >>> repo up so all build systems are welcome? I think we would
have to so we are not
> >>> picking favourites.
> >>>
> >>> Who tests these build system files when the package is
released? As the person
> >>> who releases RTEMS I do not have the time or capability to
do this.
> >>>
> >>> > The rtems-cmake support is able to live without
CMakeLists.txt files in RTEMS
> >>> > because the BSP is already compiled at that point. Doing
something similar
> >>> > would require a similar process like done in the BSP
where rtems-lwip is
> >>> > compiled as a static library for a specific BSP,
> >>> > installed somewhere and then an application can link
against it while also
> >>> > including the headers.
> >>>
> >>> I welcome the idea of rtems-cmake to grow a community of
those using cmake to
> >>> build RTEMS applications. It is great to see this happening.
> >>>
> >>> > For the RTEMS BSP this is done through provided PKG
Config files. It just seems
> >>> > like a lot of effort for a comparatively small library.
> >>> > Maybe someone has a better idea?
> >>>
> >>> I do not have a better solution than PKG config. Most build
systems provide
> >>> support so it should be something that can be accommodated.
> >>>
> >>> > I am also not sure if users who are used to CMake would
not just do the same
> >>> > thing I did if there are no CMakeLists.txt files present
and the
> >>> > library/repository is simple enough:
> >>>
> >>> I would discourage this and maybe not for the reasons you
may be thinking of.
> >>> The repo is new and is it is exciting there is work
happening on it but in time
> >>> it will become stable and it will be released with RTEMS
and this puts it in the
> >>> same configuration management basket as the BSP (kernel)
and tools. The RSB can
> >>> build it in a controlled way with reports and you just
access it like the BSP.
> >>>
> >>> > Add those themselves in the project root or throughout
the repository fork
> >>> > structure. But it's your call of course. Maybe some more
(user) opinions would
> >>> > help as well.
> >>>
> >>> I see rtems-cmake providing that role, thank you for it. We
have learnt the hard
> >>> way over a few decades to be mindful when adding these
things. Strong portable
> >>> eco-system level interfaces are our focus.
> >>>
> >>> Chris
_______________________________________________
devel mailing list
devel@rtems.org <mailto:devel@rtems.org>
http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
