Re: [Buildroot] [PATCH/next vRFCv2 3/3] package/flutter-engine: new package

["Yann E. MORIN" <yann.morin.1998@free.fr>]

Thomas, All,

On 2023-08-08 19:56 +0200, Thomas Petazzoni via buildroot spake thusly:
> On Mon,  7 Aug 2023 18:35:27 -0600
> Adam Duskett <adam.duskett@amarulasolutions.com> wrote:
> > index 0000000000..572c055bea
> > --- /dev/null
> > +++ b/package/flutter-engine/gen-tarball
> > @@ -0,0 +1,108 @@
> > +#!/usr/bin/env bash
> > +# Call gclient and generate a flutter-engine source tarball if one does not
> > +# already exist.
> > +#
> > +# Author: Adam Duskett <adam.duskett@amarulasolutions.com>

Authorship is not needed: it's tracked in git.

Also, it is going to be wrong the moment someone else changes that file.
Using the authorship from git will always be correct, though.

[--SNIP--]
> > +main() {
> > +  parse_opts "${@}"
> > +  if [ ! -e "${TARBALL}" ]; then
> 
> I'm not sure about this condition. Why is there? If the tarball is
> already there, I would expect this tool to re-generate it and overwrite
> it, rather than "do nothing".

Well, we do not redownload an archive if it is already downloaded. This
is what this test does: skip the download if the archive is already
present lcally.

We have the same test package/pkg-gemneric.mk line 190:

    if test ! -e $($(PKG)_DL_DIR)/`basename $$p` ; then

and in the download wrapper, line 67-onward:

   67     # If the output file already exists and:
   68     # - there's no .hash file: do not download it again and exit promptly
   69     # - matches all its hashes: do not download it again and exit promptly
   70     # - fails at least one of its hashes: force a re-download
   71     # - there's no hash (but a .hash file): consider it a hard error
   72     if [ -e "${output}" ]; then
   73         if support/download/check-hash ${quiet} "${hfile}" "${output}" "${output##*/}"; then
   74             exit 0

So this test does exactly the same thing.

Regards,
Yann E. MORIN.

> Thanks for this work. Seriously, it looks quite good, and close to a
> state where it can be merged. I think it no longer needs to be in the
> "RFC" state.

Yes, this is a very good work overall, for such a complex stack.

We've been discussing this series on IRC, too, and it looks like there
are missing pieces. Adam will correct me where I'm wrong, but here's
what I understood from our discussion:

 1. flutter-engine is a set of libraries that implement the runtime,
    this is what this package will provide, and flutter apps will have
    to select it and have it in their _DEPENDENCIES;

 2. there is a package, flutter-sdk-bin, that provides a compiler to
    compiler flutter apps into Dart code; we'll need to have it packaged
    as host-flutter-sdk-bin; flutter apps will need to have that in
    their _DEPENDENCIES;

 3. there is another package (which one?) that provide 'flutter', an
    executable that is in charge of starting flutter apps on the target.
    It looks like flutter-pi is such a package, but there might be
    others.

So, if I understood everything (far from granted!), the sequence is
about to look like this:

    flutter app source code
        |
        v
    flutter-sdk-bin to compile
        |
        v
    Dart code
        |
        v
    Target in /usr/share/flutter/app-name

    flutter-pi or other
        |
        v
    Target in /usr/bin/flutter

Then at runtime on the target:

    $ /usr/bin/flutter app-name

So, there are a lot more details to sort out, but it looks like the full
stack is about this shape. More or less... Maybe less than more... Who
knows?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot