From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Adam Duskett <adam.duskett@amarulasolutions.com>
Cc: Angelo Compagnucci <angelo@amarulasolutions.com>,
Michael Trimarchi <michael@amarulasolutions.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Asaf Kahlon <asafka7@gmail.com>,
buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH vRFC 3/3] package/flutter-engine: new package
Date: Sun, 23 Jul 2023 23:26:02 +0200 [thread overview]
Message-ID: <20230723212602.GC3544423@scaer> (raw)
In-Reply-To: <20230720233629.1642220-4-adam.duskett@amarulasolutions.com>
Adam, All,
On 2023-07-20 16:36 -0700, Adam Duskett spake thusly:
> There are many issues with this package:
>
> - The release tarballs from https://github.com/flutter/engine are in no state
> to compile. They are only for the use of gclient to download a source
> directory structure suitable to build the Flutter engine! If you download,
> extract and attempt to run `./tools/gn --no-goma --no-prebuilt-dart-sdk`, you
> receive the error message:
> `No such file or directory: 'flutter/flutter/third_party/gn/gn.'
>
> But wait! Wasn't the gn binary just called? No, that's a wrapper in the
> Flutter source tree that formats arguments to call the real gn binary.
> The real gn is not provided in the tarball but is downloaded via gclient
> (among many other supporting repositories.)
>
> Even worse, the flutter repository depends on the .git dirs being present.
s/flutter repository/flutter buildsystem/ maybe?
> (https://github.com/meta-flutter/meta-flutter/issues/271) This dependency
> means it is not possible to create a reproducible tarball from the downloaded
> sources, which is why there is no .hash file provided.
>
> I have asked the flutter project to release full tarballs suitable for
> compiling here: https://github.com/flutter/flutter/issues/130734
>
> - The clang toolchain wrapper does not work properly, resulting in the immediate
> errors of:
> -Wl,-z,now: 'linker' input unused
> -Wl,-z,relro: 'linker' input unused
Those two are us adding them because of BR2_RELRO_FULL (-Wl,-z,relro
alone would be due to BR2_RELRO_PARTIAL).
It does recognise that they are linker options, but why are they
rejected? Do you have more context to provide?
> The solution is to use clang.br_real and clang++.br_real.
Most probably not, because you lose a lot of the options set by
Buildroot (optimisation ,target CPU, etc...). The real solution is to
understand why -Wl-z-relro/now are rejected, and if they really are not
needed, to find a way to tell the toolchain wrapper not set them for
clang tools.
> - If using per_package builds, flutter-engine tries to use the host /usr/bin/ld
> instead of the one provided by the compiler, resulting in linking errors.
> As such, if BR2_PER_PACKAGE_DIRECTORIES is enabled, we search for the ld
> provided by the compiler in the host directory and set the path accordingly.
Can this be related to the above -Wl issue?
> - libtessellator.so (built by flutter) requires three files:
> crtbeginS.o crtendS.o libgcc.a. However, the toolchain path isn't referenced
> when linking. The solution is to copy those three files to the staging lib
> directory before building.
>
> Tested with:
> - Debian 11 and 12
> - Ubuntu 18.04, 20.04, and 22.04
> - Fedora 38
> - Per package directory enabled and disabled
> - x86_64, arm64
>
> Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
> ---
[--SNIP--]
> diff --git a/package/flutter-engine/0001-disable-pre-canned-sysroot.patch b/package/flutter-engine/0001-disable-pre-canned-sysroot.patch
> new file mode 100644
> index 0000000000..c4064a77c9
> --- /dev/null
> +++ b/package/flutter-engine/0001-disable-pre-canned-sysroot.patch
> @@ -0,0 +1,32 @@
> +From 49a14e693124dc34f2cccbfb755d01a1198aa6bf Mon Sep 17 00:00:00 2001
> +From: Adam Duskett <adam.duskett@amarulasolutions.com>
You're not the author; Joel Winarske is. That's also the authorship
there is in the upstream issue you referenced.
[--SNIP--]
> diff --git a/package/flutter-engine/0002-remove-explicit-x11-dependency.patch b/package/flutter-engine/0002-remove-explicit-x11-dependency.patch
> new file mode 100644
> index 0000000000..1345d4a3dd
> --- /dev/null
> +++ b/package/flutter-engine/0002-remove-explicit-x11-dependency.patch
> @@ -0,0 +1,33 @@
> +From b1a5db9318ca33a03f2700758d5debad907d21b6 Mon Sep 17 00:00:00 2001
> +From: Adam Duskett <adam.duskett@amarulasolutions.com>
Ditto
> +Date: Wed, 19 Jul 2023 15:26:40 -0700
> +Subject: [PATCH] remove explicit x11 dependency
> +
> +This is redundant, as the gtk pkg-config query will reference x11 if that's how
Not so much redundant, but rather superfluous and may conflict with the
actual rendering system used in gtk3 (e.g. wayland).
> diff --git a/package/flutter-engine/0003-disable-undefined-version.patch b/package/flutter-engine/0003-disable-undefined-version.patch
> new file mode 100644
> index 0000000000..468ec4daf9
> --- /dev/null
> +++ b/package/flutter-engine/0003-disable-undefined-version.patch
> @@ -0,0 +1,32 @@
> +From 9512040259f3970dd5ca08fd9ebcfd42e7539997 Mon Sep 17 00:00:00 2001
> +From: Adam Duskett <aduskett@gmail.com>
> +Date: Tue, 18 Jul 2023 15:21:51 -0700
> +Subject: [PATCH] Disable undefined-version
> +
> +This isn't a valid flag for ld, and flutter compiles just fine with the
> +no-undefined-version flag.
Without that option, the linker will just ignore a symbol with an
undefined version. With the option, a smbol with an undefined version
turns into an error.
So indeed, without the option, the check is relaxed so it is not
surprising the build does not fail.
[--SNIP--]
> diff --git a/package/flutter-engine/Config.in b/package/flutter-engine/Config.in
> new file mode 100644
> index 0000000000..fe72191e77
> --- /dev/null
> +++ b/package/flutter-engine/Config.in
> @@ -0,0 +1,93 @@
> +config BR2_PACKAGE_FLUTTER_ENGINE_ARCH_SUPPORTS
> + bool
> + default y if BR2_aarch64
> + default y if BR2_arm && !BR2_ARM_CPU_ARMV4 && !BR2_ARM_CPU_ARMV5
> + default y if BR2_i386
> + default y if BR2_x86_64
Since it uses clang, i'd also add: BR2_PACKAGE_LLVM_ARCH_SUPPORTS, but
this is a bit fuzzy for me what option we should add, if any...
> +
> +config BR2_PACKAGE_FLUTTER_ENGINE
> + bool "flutter-engine"
> + depends on BR2_PACKAGE_FLUTTER_ENGINE_ARCH_SUPPORTS
> + depends on BR2_TOOLCHAIN_USES_GLIBC
> + depends on BR2_TOOLCHAIN_GCC_AT_LEAST_5
> + depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL # pthreads
> + depends on BR2_INSTALL_LIBSTDCPP
> + depends on !BR2_TOOLCHAIN_HAS_GCC_BUG_64735 # std::shared_future
> + depends on !BR2_STATIC_LIBS
> + depends on BR2_USE_WCHAR # std::wstring
> + depends on BR2_HOST_GCC_AT_LEAST_5
> + depends on BR2_PACKAGE_HAS_LIBGL || BR2_PACKAGE_HAS_LIBGLES
> + select BR2_PACKAGE_HOST_DEPOT_TOOLS
> + select BR2_PACKAGE_FREETYPE
> + select BR2_PACKAGE_ZLIB
> + help
> + Flutter is Google's SDK for crafting beautiful, fast user
> + experience for mobile, web, and desktop from a single
> + codebase. Flutter works with existing code, is used by
> + developers and organizations around the world, and is
> + free and open source.
> +
> + The Flutter Engine is a portable runtime for hosting
> + Flutter applications. It implements Flutter's core
> + libraries, including animation and graphics, file and
> + network I/O, accessibility support, plugin architecture,
> + and a Dart runtime and compile toolchain. Most developers
> + will interact with Flutter via the Flutter Framework,
> + which provides a modern, reactive framework, and a rich
> + set of platform, layout and foundation widgets.
> +
> + https://github.com/flutter/engine
> +
> +if BR2_PACKAGE_FLUTTER_ENGINE
> +
> +choice
> + prompt "Runtime mode"
> + default BR2_PACKAGE_FLUTTER_ENGINE_RUNTIME_RELEASE
Mabye:
default BR2_PACKAGE_FLUTTER_ENGINE_RUNTIME_DEBUG if BR2_ENABLE_RUNTIME_DEBUG
default BR2_PACKAGE_FLUTTER_ENGINE_RUNTIME_RELEASE
Which brings up the question: do we need the profile mode in Buildroot,
or can we settle with just Release vs. Debug?
If so, then no need for this choice; just test BR2_ENABLE_RUNTIME_DEBUG
in flutter.mk
[--SNIP--]
> diff --git a/package/flutter-engine/flutter-engine.mk b/package/flutter-engine/flutter-engine.mk
> new file mode 100644
> index 0000000000..aa392a31d8
> --- /dev/null
> +++ b/package/flutter-engine/flutter-engine.mk
> @@ -0,0 +1,286 @@
> +################################################################################
> +#
> +# flutter-engine
> +#
> +################################################################################
> +
> +# Flutter-engine has a release on the GitHub page. However, that release is
> +# only for Google. Its intended purpose is for the gclient tool provided by
> +# Google in their depot-tools package. To use the source code, we must use
> +# gclient to download the flutter-engine source code along with several other
> +# projects. Unfortunately, the Buildroot download system does not have the
> +# capability of using gclient, and considering this package is the only
> +# package that uses gclient, we side-step the entire download process and
> +# perform the following steps if a tarball does not exist already:
> +#
> +# - Copy the pre-made gclient config file to a temporary download
> +# directory.
> +# - Run gclient sync to generate a source directory with the proper
> +# flutter-engine source code in the correct places.
> +# - Run mk_tar_gz to create a tarball.
> +# - Copy the tarball to $(FLUTTER_ENGINE_DL_DIR)
> +# directory to create a reproducible tarball.
> +#
> +# There is no hash provided, as the gn binary (used for configuration) relies
> +# on the .git directories, so there is no way to make reproducible tarballs.
> +FLUTTER_ENGINE_VERSION = 3.10.6
> +
> +# There is nothing for Buildroot to download. This is handled by gclient.
> +FLUTTER_ENGINE_SITE =
> +FLUTTER_ENGINE_SOURCE =
> +FLUTTER_ENGINE_LICENSE = BSD-3-Clause
> +FLUTTER_ENGINE_LICENSE_FILES = LICENSE
> +FLUTTER_ENGINE_TARBALL_PATH = $(FLUTTER_ENGINE_DL_DIR)/flutter-$(FLUTTER_ENGINE_VERSION).tar.gz
> +FLUTTER_ENGINE_INSTALL_STAGING = YES
> +FLUTTER_ENGINE_DOWNLOAD_DEPENDENCIES = host-depot-tools
> +FLUTTER_ENGINE_DEPENDENCIES = \
> + host-clang \
> + host-ninja \
> + host-pkgconf \
> + freetype \
> + zlib
> +
> +# Dispatch all architectures of flutter
> +ifeq ($(BR2_i386),y)
> +FLUTTER_ENGINE_TARGET_ARCH = x86
> +FLUTTER_ENGINE_TARGET_TRIPPLE = x86-linux
> +else ifeq ($(BR2_x86_64),y)
> +FLUTTER_ENGINE_TARGET_ARCH = x64
> +FLUTTER_ENGINE_TARGET_TRIPPLE = x86_64-linux
> +else ifeq ($(BR2_arm)$(BR2_armeb),y)
> +FLUTTER_ENGINE_TARGET_ARCH = arm
> +FLUTTER_ENGINE_TARGET_TRIPPLE = arm-linux
> +else ifeq ($(BR2_aarch64),y)
> +FLUTTER_ENGINE_TARGET_ARCH = arm64
> +FLUTTER_ENGINE_TARGET_TRIPPLE = aarch64-linux
> +endif
> +
> +ifeq ($(BR2_PACKAGE_FLUTTER_ENGINE_RUNTIME_RELEASE),y)
> +FLUTTER_ENGINE_RUNTIME_MODE=release
> +else ifeq ($(BR2_PACKAGE_FLUTTER_ENGINE_RUNTIME_PROFILE),y)
> +FLUTTER_ENGINE_RUNTIME=profile
> +else
> +FLUTTER_ENGINE_RUNTIME=debug
> +endif
> +
> +FLUTTER_ENGINE_BUILD_DIR = \
> + $(@D)/out/linux_$(FLUTTER_ENGINE_RUNTIME_MODE)_$(FLUTTER_ENGINE_TARGET_ARCH)
> +
> +FLUTTER_ENGINE_INSTALL_FILES = libflutter_engine.so libflutter_linux_gtk.so
> +
> +FLUTTER_ENGINE_CONF_OPTS = \
> + --clang \
> + --depot-tools $(HOST_DIR)/share/depot_tools \
> + --embedder-for-target \
> + --linux-cpu $(FLUTTER_ENGINE_TARGET_ARCH) \
> + --no-build-embedder-examples \
> + --no-clang-static-analyzer \
> + --no-enable-unittests \
> + --no-goma \
> + --no-prebuilt-dart-sdk \
> + --runtime-mode $(FLUTTER_ENGINE_RUNTIME_MODE) \
> + --target-os linux \
> + --target-sysroot $(STAGING_DIR) \
> + --target-toolchain $(HOST_DIR) \
> + --target-triple $(FLUTTER_ENGINE_TARGET_TRIPPLE)
> +
> +ifeq ($(BR2_arm)$(BR2_armeb),y)
> +FLUTTER_ENGINE_CONF_OPTS += \
> + --arm-float-abi $(call qstrip,$(BR2_GCC_TARGET_FLOAT_ABI))
> +endif
> +
> +ifeq ($(BR2_PACKAGE_FLUTTER_ENGINE_ARTIFACTS),y)
> +FLUTTER_ENGINE_CONF_OPTS += --build-engine-artifacts
> +else
> +FLUTTER_ENGINE_CONF_OPTS += --no-build-engine-artifacts
> +endif
> +
> +ifeq ($(BR2_OPTIMIZE_0),y)
> +FLUTTER_ENGINE_CONF_OPTS += --unoptimized
> +endif
> +
> +ifeq ($(BR2_ENABLE_LTO),y)
> +FLUTTER_ENGINE_CONF_OPTS += --lto
> +else
> +FLUTTER_ENGINE_CONF_OPTS += --no-lto
> +endif
> +
> +ifeq ($(BR2_STRIP_strip),y)
> +FLUTTER_ENGINE_CONF_OPTS += --stripped
> +else
> +FLUTTER_ENGINE_CONF_OPTS += --no-stripped
> +endif
> +
> +ifeq ($(BR2_PACKAGE_FONTCONFIG),y)
> +FLUTTER_ENGINE_DEPENDENCIES += fontconfig
> +FLUTTER_ENGINE_CONF_OPTS += --enable-fontconfig
else
FLUTTER_ENGINE_CONF_OPTS += --disable-fontconfig
> +endif
> +
> +ifeq ($(BR2_PACKAGE_HAS_LIBGL),y)
> +FLUTTER_ENGINE_DEPENDENCIES += libgl
> +endif
> +
> +ifeq ($(BR2_PACKAGE_HAS_LIBGLES),y)
> +FLUTTER_ENGINE_DEPENDENCIES += libgles
> +endif
> +
> +ifeq ($(BR2_PACKAGE_MESA3D),y)
> +FLUTTER_ENGINE_DEPENDENCIES += mesa3d
> +endif
> +
> +ifeq ($(BR2_PACKAGE_MESA3D_VULKAN_DRIVER),y)
> +FLUTTER_ENGINE_CONF_OPTS += --enable-vulkan
else
FLUTTER_ENGINE_CONF_OPTS += --diable-vulkan
> +endif
> +
> +ifneq ($(BR2_PACKAGE_XORG7)$(BR2_PACKAGE_LIBXCB),yy)
Prefer positive logic:
ifeq ($(BR2_PACKAGE_XORG7)$(BR2_PACKAGE_LIBXCB),yy)
FLUTTER_ENGINE_DEPENDENCIES += libxcb
else
[the hack]
endif
> +define FLUTTER_ENGINE_VULKAN_X11_SUPPORT_FIXUP
> + $(SED) "s%vulkan_use_x11.*%vulkan_use_x11 = false%g" -i \
> + $(@D)/build_overrides/vulkan_headers.gni
> +endef
> +FLUTTER_ENGINE_PRE_CONFIGURE_HOOKS += FLUTTER_ENGINE_VULKAN_X11_SUPPORT_FIXUP
> +else
> +FLUTTER_ENGINE_DEPENDENCIES += libxcb
> +endif
> +
> +ifneq ($(BR2_PACKAGE_WAYLAND),y)
Ditto, positive logic please.
> +define FLUTTER_ENGINE_VULKAN_WAYLAND_SUPPORT_FIXUP
> + $(SED) "s%vulkan_use_wayland.*%vulkan_use_wayland = false%g" \
> + $(@D)/build_overrides/vulkan_headers.gni
> +endef
> +FLUTTER_ENGINE_PRE_CONFIGURE_HOOKS += FLUTTER_ENGINE_VULKAN_WAYLAND_SUPPORT_FIXUP
> +else
> +FLUTTER_ENGINE_DEPENDENCIES += wayland
> +endif
> +
> +ifeq ($(BR2_PACKAGE_LIBGTK3),y)
> +FLUTTER_ENGINE_DEPENDENCIES += libgtk3
> +else
> +FLUTTER_ENGINE_CONF_OPTS += --disable-desktop-embeddings
> +endif
> +
> +ifeq ($(BR2_PACKAGE_LIBGLFW),y)
> +FLUTTER_ENGINE_DEPENDENCIES += libglfw
> +FLUTTER_ENGINE_CONF_OPTS += --build-glfw-shell
> +else
> +FLUTTER_ENGINE_CONF_OPTS += --no-build-glfw-shell
> +endif
> +
> +# The clang toolchain wrapper causes a lot of the following errors:
> +# error: -Wl,-z,now: 'linker' input unused [-Werror,-Wunused-command-line-argument]
> +# error: -Wl,-z,relro: 'linker' input unused [-Werror,-Wunused-command-line-argument]
Ah, that's because linker options are passed when we are not linking but
just compiling. And that's an error because of -Werror!
Can we disable -Werror instead of skipping the wrappers?
> +# Excplicitly use the real clang binaries for cc and cxx.
> +ifeq ($(BR2_CCACHE),y)
> +define FLUTTER_ENGINE_COMPILER_PATH_FIXUP
> + $(SED) "s%cc =.*%cc = \"\$${toolchain_bin}/ccache clang.br_real\""%g \
> + $(@D)/build/toolchain/custom/BUILD.gn
> +
> + $(SED) "s%cxx =.*%cxx = \"\$${toolchain_bin}/ccache clang++.br_real\""%g \
> + $(@D)/build/toolchain/custom/BUILD.gn
> +endef
> +else
> +define FLUTTER_ENGINE_COMPILER_PATH_FIXUP
> + $(SED) "s%cc =.*%cc = \"\$${toolchain_bin}/clang.br_real\""%g \
> + $(@D)/build/toolchain/custom/BUILD.gn
> +
> + $(SED) "s%cxx =.*%cxx = \"\$${toolchain_bin}/clang++.br_real\""%g \
> + $(@D)/build/toolchain/custom/BUILD.gn
> +endef
> +endif
> +FLUTTER_ENGINE_PRE_CONFIGURE_HOOKS += FLUTTER_ENGINE_COMPILER_PATH_FIXUP
> +
> +# If using per_package builds, flutter-engine tries to use the /usr/bin/ld instead of
> +# the one provided by the compiler, resulting in linking errors.
> +ifeq ($(BR2_PER_PACKAGE_DIRECTORIES),y)
> +define FLUTTER_ENGINE_GET_PATH
> + (ld_bin_path=$$(dirname $$(realpath $$(find $(PER_PACKAGE_DIR)/flutter-engine -name ld -type f))); \
> + echo $${ld_bin_path}:$(BR_PATH):$(HOST_DIR)/share/depot_tools; \
> + )
> +endef
> +else
> +define FLUTTER_ENGINE_GET_PATH
> + echo $(BR_PATH):$(HOST_DIR)/share/depot_tools
> +endef
> +endif
> +
> +# Generate a tarball if one does not already exist.
> +define FLUTTER_ENGINE_GENERATE_TARBALL
> + (if [ ! -e $(FLUTTER_ENGINE_TARBALL_PATH) ]; then \
Don't use a subshell here (parenthesis are toally unneeded and
superfluous).
> + . ./support/download/helpers && \
> + rm -rf $(@D)/dl-tmp && mkdir -p $(@D)/dl-tmp && \
> + $(INSTALL) -D -m 0755 $(FLUTTER_ENGINE_PKGDIR)/gclient \
This is not gclient, this is .gclient, but having a source fiel that is
a dot-file in the tree is not nice. Can we just name it dot-gclient
instead:
$(FLUTTER_ENGINE_PKGDIR)/dot-gclient
> + $(@D)/dl-tmp/.gclient && \
> + $(SED) "s%!FLUTTER_VERSION!%$(FLUTTER_ENGINE_VERSION)%g" \
> + $(@D)/dl-tmp/.gclient && \
> + cd $(@D)/dl-tmp && \
> + $(DEPOT_TOOLS_GCLIENT) \
> + sync \
> + --delete_unversioned_trees \
> + -j$(PARALLEL_JOBS) \
> + --no-history \
> + --reset \
> + --shallow && \
> + mkdir -p $(FLUTTER_ENGINE_DL_DIR); \
> + cd $(@D)/dl-tmp && \
> + mk_tar_gz \
> + $(@D)/dl-tmp/src \
> + flutter-$(FLUTTER_ENGINE_VERSION) \
> + "$$(git -C $(@D)/dl-tmp/src log -1 --pretty=format:%ci)" \
> + $(FLUTTER_ENGINE_TARBALL_PATH) && \
> + rm -rf $(@D)/dl-tmp; \
> + fi \
> + )
I think this big if-block should go into a helper script (yeah, yeah., I
may have written something using make code in my earlier suggestion, but
that was not smart of me...)
So:
define FLUTTER_ENGINE_GENERATE_TARBALL
$(FLUTTER_PKGDIR)/gen-tarball \
--version $(FLUTTER_ENGINE_VERSION) \
--tarball $(FLUTTER_ENGINE_TARBALL_PATH) \
--dot-gclient $(FLUTTER_ENGINE_PKGDIR)/dot-gclient \
--scratch-dir $(@D)/dl-tmp
endef
And then a sequence of complex script shell is easier to write, to
review, and to maintain.
> +endef
> +FLUTTER_ENGINE_POST_DOWNLOAD_HOOKS += FLUTTER_ENGINE_GENERATE_TARBALL
> +
> +define FLUTTER_ENGINE_EXTRACT_CMDS
> + gzip -d -c $(FLUTTER_ENGINE_TARBALL_PATH) | tar --strip-components 1 -C $(@D) -xf -
> +endef
> +
> +define FLUTTER_ENGINE_CONFIGURE_CMDS
> + # libtessellator requires these three files, but the toolchain path isn't
> + # referenced when linking. Copy them to the staging lib directory before
> + # building.
> + $(Q)$(foreach i,crtbeginS.o crtendS.o libgcc.a,
> + $(Q)if [ ! -e $(STAGING_DIR)/usr/lib/$(i) ]; then \
> + file_path=$$(find $(HOST_DIR) -type f -name $(i)); \
This is going to be a bit more complex than that, because of multi-lib
or multi-arch external toolchains. See the mess it is to find the
sysroot in toolchain/helpers.mk
But seriously though, why are they not brought in? Did you try to run
the linking command manually in debug mode (--verbose if calling ld
directly, of -Wl.--verbose if using gcc to link)?
Is it using ld to do the link, or is it using gcc?
Is ld binutils', or is it lld? This might also have a link as to why
-Wl,-z,now and -Wl,-z,relro are not supported...
> + $(INSTALL) -D -m 0755 $${file_path} $(STAGING_DIR)/usr/lib/$(i); \
> + fi \
> + )
> + (cd $(@D)/ && \
> + rm -rf $(FLUTTER_ENGINE_BUILD_DIR) && \
> + PATH=$(shell $(call FLUTTER_ENGINE_GET_PATH)) \
> + ./flutter/tools/gn $(FLUTTER_ENGINE_CONF_OPTS) \
> + )
> +endef
> +
> +define FLUTTER_ENGINE_BUILD_CMDS
> + (cd $(@D); \
> + PATH=$(shell $(call FLUTTER_ENGINE_GET_PATH)) \
> + PYTHONNOUSERSITE=y \
> + $(HOST_DIR)/bin/ninja \
> + -j $(PARALLEL_JOBS) \
> + -C $(FLUTTER_ENGINE_BUILD_DIR) \
> + )
> +endef
> +
> +define FLUTTER_ENGINE_INSTALL_STAGING_CMDS
> + $(foreach i,$(FLUTTER_ENGINE_INSTALL_STAGING_FILES),
Err... FLUTTER_ENGINE_INSTALL_STAGING_FILES is set nowhere?
Regards,
Yann E. MORIN.
> + $(Q)if [ -e $(FLUTTER_ENGINE_BUILD_DIR)/$(i) ]; then \
> + $(INSTALL) -D -m 0755 $(FLUTTER_ENGINE_BUILD_DIR)/$(i) \
> + $(STAGING_DIR)/usr/lib/$(i); \
> + fi \
> + )
> + $(INSTALL) -D -m 0755 $(FLUTTER_ENGINE_BUILD_DIR)/flutter_embedder.h \
> + $(STAGING_DIR)/usr/include/flutter_embedder.h
> +endef
> +
> +define FLUTTER_ENGINE_INSTALL_TARGET_CMDS
> + $(foreach i,$(FLUTTER_ENGINE_INSTALL_FILES),
> + $(Q)if [ -e $(FLUTTER_ENGINE_BUILD_DIR)/$(i) ]; then \
> + $(INSTALL) -D -m 0755 $(FLUTTER_ENGINE_BUILD_DIR)/$(i) \
> + $(TARGET_DIR)/usr/lib/$(i); \
> + fi \
> + )
> +endef
> +
> +$(eval $(generic-package))
> diff --git a/package/flutter-engine/gclient b/package/flutter-engine/gclient
> new file mode 100644
> index 0000000000..168e9a368d
> --- /dev/null
> +++ b/package/flutter-engine/gclient
> @@ -0,0 +1,16 @@
> +# This file is taken from the output of meta-flutter/lib/gn.py
> +
> +solutions = [{
> + "managed": False,
> + "name": "src/flutter",
> + "url": "https://github.com/flutter/engine.git@!FLUTTER_VERSION!",
> + "custom_vars": {
> + "download_android_deps": False,
> + "download_windows_deps": False,
> + "download_linux_deps": False
> + },
> + "custom_deps": {
> + "src/third_party/dart/third_party/pkg/tools":
> + "https://dart.googlesource.com/tools.git@unified_analytics-v1.1.0"
> + }
> +}]
> --
> 2.41.0
>
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
--
.-----------------.--------------------.------------------.--------------------.
| 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
next prev parent reply other threads:[~2023-07-23 21:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-20 23:36 [Buildroot] [PATCH vRFC 0/3] Initial flutter packages Adam Duskett
2023-07-20 23:36 ` [Buildroot] [PATCH vRFC 1/3] package/python-httplib2: add host variant Adam Duskett
2023-07-20 23:36 ` [Buildroot] [PATCH vRFC 2/3] package/depot-tools: new package Adam Duskett
2023-07-23 19:52 ` Yann E. MORIN
2023-07-20 23:36 ` [Buildroot] [PATCH vRFC 3/3] package/flutter-engine: " Adam Duskett
2023-07-23 21:26 ` Yann E. MORIN [this message]
2023-07-25 15:38 ` Adam Duskett
2023-07-20 23:37 ` [Buildroot] [PATCH vRFC 0/3] Initial flutter packages Adam Duskett
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230723212602.GC3544423@scaer \
--to=yann.morin.1998@free.fr \
--cc=adam.duskett@amarulasolutions.com \
--cc=angelo@amarulasolutions.com \
--cc=asafka7@gmail.com \
--cc=buildroot@buildroot.org \
--cc=michael@amarulasolutions.com \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox