<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Shiro,<br>
    </p>
    <div class="moz-cite-prefix">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? <br>
      <br>
      I thought of that option as well.<br>
    </div>
    <div class="moz-cite-prefix">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.</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Kind Regards<br>
      Robin<br>
    </div>
    <div class="moz-cite-prefix">On 08.09.21 21:05, Shiro wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:B96EE847-2FBC-4920-911B-5DD22EC945CF@gmail.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      Hi, Robin,
      <div class=""><br class="">
      </div>
      <div class="">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…).</div>
      <div class=""><br class="">
      </div>
      <div class="">The “patch trick” to manage license contamination
        has worked well for others in the past.</div>
      <div class=""><br class="">
      </div>
      <div class="">Cheers,</div>
      <div class="">-Shiro<br class="">
        <div><br class="">
          <blockquote type="cite" class="">
            <div class="">On Sep 8, 2021, at 11:51 AM, Robin Müller <<a
                href="mailto:robin.mueller.m@gmail.com" class=""
                moz-do-not-send="true">robin.mueller.m@gmail.com</a>>
              wrote:</div>
            <br class="Apple-interchange-newline">
            <div class="">
              <div dir="ltr" class="">
                <div class="">Hi,</div>
                <div class=""><br class="">
                </div>
                <div class="">Unfortunately, there was no other reply to
                  the request.</div>
                <div class=""><br class="">
                </div>
                <div class="">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.</div>
                <div class="">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.</div>
                <div class=""><br class="">
                </div>
                <div class="">Kind Regards<br class="">
                </div>
                <div class="">Robin<br class="">
                </div>
              </div>
              <br class="">
              <div class="gmail_quote">
                <div dir="ltr" class="gmail_attr">On Thu, 5 Aug 2021 at
                  17:00, Gedare Bloom <<a
                    href="mailto:gedare@rtems.org" target="_blank"
                    class="" moz-do-not-send="true">gedare@rtems.org</a>>
                  wrote:<br class="">
                </div>
                <blockquote class="gmail_quote" style="margin:0px 0px
                  0px 0.8ex;border-left:1px solid
                  rgb(204,204,204);padding-left:1ex">STM is not going to
                  fix their Ultimate Liberty License at this time.<br
                    class="">
                  <a
href="https://github.com/STMicroelectronics/STM32CubeH7/issues/139#issuecomment-890806010"
                    rel="noreferrer" target="_blank" class=""
                    moz-do-not-send="true">https://github.com/STMicroelectronics/STM32CubeH7/issues/139#issuecomment-890806010</a><br
                    class="">
                  <br class="">
                  So, we need to avoid using their example codes.<br
                    class="">
                  <br class="">
                  On Wed, Jun 9, 2021 at 12:16 PM Gedare Bloom <<a
                    href="mailto:gedare@rtems.org" target="_blank"
                    class="" moz-do-not-send="true">gedare@rtems.org</a>>
                  wrote:<br class="">
                  ><br class="">
                  > I joined the Issue. Thanks for working on this.<br
                    class="">
                  ><br class="">
                  > On Wed, Jun 9, 2021 at 11:30 AM Robin Müller <<a
                    href="mailto:robin.mueller.m@gmail.com"
                    target="_blank" class="" moz-do-not-send="true">robin.mueller.m@gmail.com</a>>
                  wrote:<br class="">
                  > ><br class="">
                  > > I posted a reply but I think it did not go
                  through. Will post it now.<br class="">
                  > ><br class="">
                  > > Kind Regards<br class="">
                  > > Robin<br class="">
                  > ><br class="">
                  > > On Wed, 9 Jun 2021 at 18:31, Robin Müller
                  <<a href="mailto:robin.mueller.m@gmail.com"
                    target="_blank" class="" moz-do-not-send="true">robin.mueller.m@gmail.com</a>>
                  wrote:<br class="">
                  > >><br class="">
                  > >> Hi,<br class="">
                  > >><br class="">
                  > >> I received a reply from STM32 about the
                  licensing issues. They requested more specific
                  information about the "vendor device restrictions" 
                  for the HAL code.<br class="">
                  > >> The issue is here: <a
                    href="https://github.com/STMicroelectronics/STM32CubeH7/issues/139"
                    rel="noreferrer" target="_blank" class=""
                    moz-do-not-send="true">https://github.com/STMicroelectronics/STM32CubeH7/issues/139</a><br
                    class="">
                  > >> 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!<br
                    class="">
                  > >><br class="">
                  > >> Kind Regards<br class="">
                  > >> Robin<br class="">
                  > >><br class="">
                  > >> On Wed, 28 Apr 2021 at 02:45, Chris
                  Johns <<a href="mailto:chrisj@rtems.org"
                    target="_blank" class="" moz-do-not-send="true">chrisj@rtems.org</a>>
                  wrote:<br class="">
                  > >>><br class="">
                  > >>> On 28/4/21 2:58 am, Robin Müller
                  wrote:<br class="">
                  > >>> > Okay, I can understand that
                  you'd like to have one build system only. We had the<br
                    class="">
                  > >>> > same issue with a former
                  Makefile build system and the new CMake system and<br
                    class="">
                  > >>> > decided to make the former
                  system obsolete> because maintaining both of them
                  would be too much work<br class="">
                  > >>> For RTEMS what we use has been
                  selected for a range of important reasons and the<br
                    class="">
                  > >>> rtems-central repo and the qual work
                  highlights the importance of those<br class="">
                  > >>> decisions. Waf is a python framework
                  for building software and in rtems.git our<br class="">
                  > >>> build system support is written in a
                  clearly defined portable language with<br class="">
                  > >>> power helper libraries. We can run
                  code formatters on our build system, have<br class="">
                  > >>> unit tests and there is even source
                  level debuggers. We treat the build system<br class="">
                  > >>> like any other piece of code we
                  have.<br class="">
                  > >>><br class="">
                  > >>> > First thing I  can do is that I
                  split up the patch and extract the CMake<br class="">
                  > >>> > specific files. Concerning a
                  clean solution to allow users to use CMake without<br
                    class="">
                  > >>> > introducing files like
                  CMakeLists.txt,<br class="">
                  > >>> > I am not sure right now.
                  Extracting the information required by CMake would<br
                    class="">
                  > >>> > again require scripts to export
                  source files and include paths.<br class="">
                  > >>> > The simplest solution would
                  still be a CMakeLists.txt file in the root here<br
                    class="">
                  > >>> > which simply sets source files
                  and include paths in the parent scope.<br class="">
                  > >>> > which would again be another
                  form of maintenance burden because it still needs<br
                    class="">
                  > >>> > to figure out which port
                  sources to add etc.<br class="">
                  > >>><br class="">
                  > >>> What about scons, meson, or a plain
                  Makefile for those who just want to use<br class="">
                  > >>> make, then there is GNU make and BSD
                  make, the list is large? Do we open the<br class="">
                  > >>> repo up so all build systems are
                  welcome? I think we would have to so we are not<br
                    class="">
                  > >>> picking favourites.<br class="">
                  > >>><br class="">
                  > >>> Who tests these build system files
                  when the package is released? As the person<br
                    class="">
                  > >>> who releases RTEMS I do not have the
                  time or capability to do this.<br class="">
                  > >>><br class="">
                  > >>> > The rtems-cmake support is able
                  to live without CMakeLists.txt files in RTEMS<br
                    class="">
                  > >>> > because the BSP is already
                  compiled at that point. Doing something similar<br
                    class="">
                  > >>> > would require a similar process
                  like done in the BSP where rtems-lwip is<br class="">
                  > >>> > compiled as a static library
                  for a specific BSP,<br class="">
                  > >>> > installed somewhere and then an
                  application can link against it while also<br class="">
                  > >>> > including the headers.<br
                    class="">
                  > >>><br class="">
                  > >>> I welcome the idea of rtems-cmake to
                  grow a community of those using cmake to<br class="">
                  > >>> build RTEMS applications. It is
                  great to see this happening.<br class="">
                  > >>><br class="">
                  > >>> > For the RTEMS BSP this is done
                  through provided PKG Config files. It just seems<br
                    class="">
                  > >>> > like a lot of effort for a
                  comparatively small library.<br class="">
                  > >>> > Maybe someone has a better
                  idea?<br class="">
                  > >>><br class="">
                  > >>> I do not have a better solution than
                  PKG config. Most build systems provide<br class="">
                  > >>> support so it should be something
                  that can be accommodated.<br class="">
                  > >>><br class="">
                  > >>> > I am also not sure if users who
                  are used to CMake would not just do the same<br
                    class="">
                  > >>> > thing I did if there are no
                  CMakeLists.txt files present and the<br class="">
                  > >>> > library/repository is simple
                  enough:<br class="">
                  > >>><br class="">
                  > >>> I would discourage this and maybe
                  not for the reasons you may be thinking of.<br
                    class="">
                  > >>> The repo is new and is it is
                  exciting there is work happening on it but in time<br
                    class="">
                  > >>> it will become stable and it will be
                  released with RTEMS and this puts it in the<br
                    class="">
                  > >>> same configuration management basket
                  as the BSP (kernel) and tools. The RSB can<br class="">
                  > >>> build it in a controlled way with
                  reports and you just access it like the BSP.<br
                    class="">
                  > >>><br class="">
                  > >>> > Add those themselves in the
                  project root or throughout the repository fork<br
                    class="">
                  > >>> > structure. But it's your call
                  of course. Maybe some more (user) opinions would<br
                    class="">
                  > >>> > help as well.<br class="">
                  > >>><br class="">
                  > >>> I see rtems-cmake providing that
                  role, thank you for it. We have learnt the hard<br
                    class="">
                  > >>> way over a few decades to be mindful
                  when adding these things. Strong portable<br class="">
                  > >>> eco-system level interfaces are our
                  focus.<br class="">
                  > >>><br class="">
                  > >>> Chris<br class="">
                </blockquote>
              </div>
              _______________________________________________<br
                class="">
              devel mailing list<br class="">
              <a href="mailto:devel@rtems.org" class=""
                moz-do-not-send="true">devel@rtems.org</a><br class="">
              <a class="moz-txt-link-freetext" href="http://lists.rtems.org/mailman/listinfo/devel">http://lists.rtems.org/mailman/listinfo/devel</a></div>
          </blockquote>
        </div>
        <br class="">
      </div>
    </blockquote>
  </body>
</html>