Hover: support cross-compile

[txthinking]

This is really a nice project.
I want to ask if hover support cross-compile, ep: build Windows app on macOS,
what other work or obstacles need to be done?

Thank you.

[pchampio]

For cgo cross-compiling there is this project: https://github.com/karalabe/xgo
Haven't tested yet.

[GeertJohan]

Eventually, hover may use xgo to cross-compile apps. Have looked at it, but didn't get it to work yet. Re-opening this issue as it is a valid request. (Not sure why @txthinking closed?)

[JasCodes]

@GeertJohan Any indication how much work we might be looking at?

[pchampio]

@GeertJohan is on vacation ⛺.

I can try to answer the question:
At first-hand xgo seems to be easy to use. However, when we look at go-flutter, there is a lot of cgo involved (flutter/engine glfw/glfw OpenGL). I think it's too much work for @GeertJohan and me to handle; there are other more critical issues to fix.

[pchampio]

As @joeblew99 pointed-out https://github.com/lucor/fyne-cross is a VERY good example.

Looking for maintainer! to implement this hover feature.

[joeblew99]

@Drakirus thanks for moving it.
I cant maintain it. But i think its pretty easy to maintain actually since it golang.
Also it will be able to do the Mobile builds too, which i think its awesome.

[provokateurin]

After the new build methods get merged (#20) the names for the builds need to be updated to add architectures.
I think I will try to implement cross-compile as my next contribution to this project :)

[Alex-A4]

Actually, how to make that build? Any examples?

[provokateurin]

I created a PR for cross-compiling yesterday go-flutter-desktop/hover#23

[joeblew99]

@jld3103
fyne-cross ( https://github.com/lucor/fyne-cross ) added cross build for ARM also in the Develop branch now. Its a work in progres. Fyne has their code working on mobiles and web now (although its a bit scratchy still) so they got the extended their cross build to support it.

Its also interesting to watch out for what the old maintainer of gomobile is doing too.
https://git.sr.ht/~eliasnaur/gio/tree/
Its similar to Fyne but the way the go build works is independent of gomobile. gomobile sometimes got in your way i found.
https://git.sr.ht/~eliasnaur/gio/tree/master/cmd/gio/iosbuild.go
https://git.sr.ht/~eliasnaur/gio/tree/master/cmd/gio/androidbuild.go

[provokateurin]

@joeblew99 My work is based on fyne-cross.
I think ARM is not the main target of go-flutter, but could be interesting tough.

[joeblew99]

I agree with you and think the best approach is what you are taking using fyne-cross and gomobile But i know with the Dart FFI work, gomobile will get in our way possibly because it gomobile does not give enough control. SO i just wanted to put it in the issue so we know there is another way to attack the problem if we hit this later.

…

On Thu, Sep 12, 2019 at 11:41 AM jld3103 ***@***.***> wrote: @joeblew99 <https://github.com/joeblew99> My work is based on fyne-cross. I think ARM is not the main target of go-flutter, but could be interesting tough. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#128?email_source=notifications&email_token=AC3RU45GBCBLEAFPDVC7RS3QJIFFNA5CNFSM4HIOALL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6RJOJI#issuecomment-530749221>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC3RU444O2DELZA7XGSCSMTQJIFFNANCNFSM4HIOALLQ> .

[GeertJohan]

Cross-compilation support has just landed through go-flutter-desktop/hover/pull/23
Thanks @jld3103 !

[fourscience]

@joeblew99 My work is based on fyne-cross.
I think ARM is not the main target of go-flutter, but could be interesting tough.

Actually there are many arm boards running generic linux kernel, i have an embedder written in C, but the whole setup is somewhat hard for newcomers, i was checking out go then and found this :)
i would agree that by default nor ARM or Wayland is a main target, but it could very well fit some devices (tv, set top boxes, smart stuff)
an example would be webos (lg)

so ill create a pr for arm and wayland support as well :)

regarding package types ill add wgt (openwebos and webos) if needed (for now webos < 4)

other platforms such as tizen might work as well

[provokateurin]

@fourscience That would be great! I changed my mind some months ago about ARM and I think it's actually a reason to use go-flutter if we support it, because FDE doesn't.

[fourscience]

@fourscience That would be great! I changed my mind some months ago about ARM and I think it's actually a reason to use go-flutter if we support it, because FDE doesn't.

May i ask about splitting cross compilation into 2 segments?

i would not influence the docker part, but any non supported platforms by flutter requires the engine built, as gn does it would be nice to pass go the compilation flags instead of relying on specific targets, so i would propose to adding flags to pointing to a local engine path (engine/src/out/platform etc), so that directory contains the c headers, libs and icu for consumption

therefor anyone can define their own libflutter, the next step would to pass down the cc cxx compilers and targets (like you use the toolchain on the engine) :)

on the other hand i was thinking about moving some stuff around glfw, so extension would be available for pure framebuffer implementation, or other kits (sdl, gtk, pure x11 and wayland etc)

i know it sounds a lot but currently this project seems more reasonable then the shell/platform stuff in the engine repo, dont get me wrong they do an awesome job, but this does not depend on gn and internals just like their desktop counterpart,

as for know ill add arm support then do pr's if you guys are interested along the way 👍

[provokateurin]

I absolutley agree with you. We need to restructure hover into a "proper" build system now that we got so many steps to choose from.

therefor anyone can define their own libflutter, the next steo would to pass down the cc cxx compilers and targets (like you use the toolchain on the engine) :)

So we could build for anything? If then we need some predefined targets like now for everyone.

[fourscience]

@jld3103
Basicly yes, as far as go compiler can go :D

I would propose a different hover build/run cli arguments list, something like:

• target: (clang docs borrowed) https://llvm.org/doxygen/classllvm_1_1Triple.html
  The triple has the general format _{---, where:
  arch = x86_64, i386, arm, thumb, mips, etc.
  sub = for ex. on ARM: v5, v6m, v7a, v7m, etc.
  vendor = pc, apple, nvidia, ibm, etc.
  sys = none, linux, win32, darwin, cuda, etc.
  abi = eabi, gnu, android, macho, elf, etc.
  ex: arm-linux-gnueabi, arm-linux-gnueabihf (hardfloat support), armv7-linux-eabi
  This would be used to pick the corresponding gocross target if no toolchain is specified}
• toolchain: a path to a toolchain, if no target is specified it would be like: /path/bin/gcc
  otherwise it would pick /path/bin/target-triple-gcc for use (ex: /path/bin/arm-linux-gnueabi-gcc)
• mode/runtime: debug/release/release-jit/profile
• local-engine-path: For now hover uses a cache dir and populates that, if this arguments is not
  specified that we can fall back for that, otherwise we should get the artifacts (libflutter_engine.so, icudtl, headers etc) from here, ex: /engine/src
• local-engine: the artifact label ex: android_debug_unopt, linux_host_debug this will be appended to the local-engine-path like this: localEnginePath + '/out/' + localEngine, on a sidenote, when someone does the compile step with ninja and states the out directory is different, we should note them that this should be changed accordingly

Side notes:

using flutter build will need the host artifacts (as for cross compiling it wont work with the snapshots for the target, but that might change)

This would allow the hover build to use any libflutter artifacts (ex: compiled for rpi4) and use any gcc to assemble the binary (rpi has their own toolchains)

As for the opengl arguments, this would be a different topic, as well as glfw on it's own. but for now it would be nice to pass down that we want to use for ex gles2 wayland

otherwise i would propose to separate glfw as much as we can, and try to add a different solution as well to mature in that way (like https://github.com/veandco/go-sdl2)

for hot reloading i would add a reverse forwarding as well, opening up options to use adb,sdb,adbi,ares (other cli debug utilities) to forward the port so flutter can attach to it, therefor adding capabilities to run the binary on ex a rpi4, forward the port, and attach to it :) hot reload for remote targets :) as well as a local mirror of the observatory

Cmake example:

if(NOT TARGET)
   set(TARGET host_debug_unopt)
endif()

if(NOT ENGINE_PATH)
# Flutter engine is a peer directory to flutter in our case, otherwise 
set(ARTIFACT_DIR "${FLUTTER_ROOT}/../engine/src/out/${TARGET}")
elseif()
set(ARTIFACT_DIR "${ENGINE_PATH}/out/${TARGET}")
endif()


find_library(
        FLUTTER_LIB
        NAMES libflutter_engine flutter_engine libflutter_engine.so
        flutter_engine
        PATHS "${ARTIFACT_DIR}"
)

if (NOT FLUTTER_LIB)
    message(SEND_ERROR "Did not find lib flutter")
endif()


# Copy the flutter library here since the shared library
# name is `./libflutter_engine.dylib`.

set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)

set(EXECUTABLE_OUTPUT_PATH "bin")

add_custom_command(
        TARGET flutter POST_BUILD
        COMMAND ${CMAKE_COMMAND} -E copy
                ${FLUTTER_LIB}
                ${EXECUTABLE_OUTPUT_PATH})
add_custom_command(
        TARGET flutter POST_BUILD
        COMMAND ${CMAKE_COMMAND} -E copy
                ${ARTIFACT_DIR}/icudtl.dat
                ${EXECUTABLE_OUTPUT_PATH}/data)

# COPY libs, only on nix
file(GLOB RUNTIME_LIBS ${ARTIFACT_DIR}/*.so)
foreach(CurrentLib IN LISTS RUNTIME_LIBS)
    add_custom_command(
                TARGET flutter POST_BUILD
                COMMAND ${CMAKE_COMMAND} -E copy_if_different ${CurrentLib} ${EXECUTABLE_OUTPUT_PATH}
                COMMENT "Copying lib: ${CurrentLib}")
endforeach()

# copy assets for the current build target, so a linker can work with it
file(COPY ${CMAKE_SOURCE_DIR}/../build/flutter_assets DESTINATION ${EXECUTABLE_OUTPUT_PATH}/data/)
message("OUT ${EXECUTABLE_OUTPUT_PATH}/")

[provokateurin]

That sounds really awesome. Can you create a new issue to track your proposed changes?