[Buildroot] [[PATCH v2 2/2] package/mender-artifact: initial support

[Mirza Krak]

On Sun, Sep 2, 2018 at 3:47 PM, Thomas Petazzoni
<thomas.petazzoni at bootlin.com> wrote:
>
> Hello Mirza,
>
> Overall it looks good, except for one aspect, which will require a bit
> of discussion.
>
> On Mon, 27 Aug 2018 13:37:28 +0200, Mirza Krak wrote:
>
> > diff --git a/package/mender-artifact/Config.in.host b/package/mender-artifact/Config.in.host
> > new file mode 100644
> > index 0000000000..d2deabc783
> > --- /dev/null
> > +++ b/package/mender-artifact/Config.in.host
> > @@ -0,0 +1,20 @@
> > +config BR2_PACKAGE_HOST_MENDER_ARTIFACT
> > +     bool "host mender-artifact"
> > +     depends on BR2_PACKAGE_HOST_GO_ARCH_SUPPORTS
> > +     depends on BR2_PACKAGE_HOST_GO_CGO_LINKING_SUPPORTS
> > +     depends on BR2_TOOLCHAIN_HAS_THREADS
>
> I am not happy about those dependencies, because they are dependencies
> meant to be used for *target* packages, not for *host* packages.
>
> BR2_TOOLCHAIN_HAS_THREADS is easy: it's not needed for host packages,
> as we assume the build machine has thread support.
>
> For the other dependencies, it's a bit more complicated, but I believe
> somewhat similar to the situation we have with the Rust support.
>
> Right now, BR2_PACKAGE_HOST_GO_ARCH_SUPPORTS indicates if the
> currently selected target architecture is supported by Go. This is fine
> for target packages.
>
> But apparently, host-go provides really two things:
>
>  (1) A Go compiler capable of building code for the host machine.
>
>  (2) A Go compiler capable of building code for the target machine.
>
> For Go target packages, We are currently using (2), and for packages
> that rely on (2), using BR2_PACKAGE_HOST_GO_ARCH_SUPPORTS make sense.
>
> However, with your support for host packages, what we rely on is (1).
> And for that BR2_PACKAGE_HOST_GO_ARCH_SUPPORTS doesn't make a lot of
> sense.
>
> For example, BR2_PACKAGE_HOST_GO_ARCH_SUPPORTS says that Go is not
> available on the ARC architecture. But for building a host package, we
> really don't care about this: what matters is that Go is capable of
> building code for the x86 or x86-64 build machine.
>
> Therefore, we should probably use the same strategy as Rust, which is
> proposed in patch http://patchwork.ozlabs.org/patch/961158/:
>
>  - The BR2_PACKAGE_HOST_GO_ARCH_SUPPORTS is changed to only indicate if
>    Go supports the host/build system architecture. In our case, it
>    should probably just be:
>
>         depends on BR2_PACKAGE_HOST_GO_BOOTSTRAP_ARCH_SUPPORTS
>
>    All host Go packages should depend on this option.
>
>  - A new BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS that indicates if Go
>    supports the target system architecture. It should be:
>
>         depends on BR2_PACKAGE_HOST_GO_ARCH_SUPPORTS
>         depends on (BR2_arm && BR2_TOOLCHAIN_SUPPORTS_PIE) || BR2_aarch64 \
>                 || BR2_i386 || BR2_x86_64 || BR2_powerpc64le \
>                 || BR2_mips64 || BR2_mips64el
>         depends on !BR2_ARM_CPU_ARMV4
>         # MIPS R6 support in Go has not yet been developed.
>         depends on !BR2_MIPS_CPU_MIPS64R6
>
> Of course we can only do this if host-go builds correctly regardless of
> whether the target architecture is supported or not. What Rust does is:
>
>  - If the target is architecture is supported by Rust, it installs
>    support for building code for both the host and the target
>    architectures.
>
>  - If the target is architecture is not supported by Rust, it only
>    installs support for building code for the host architecture.
>
> Do you know how Go supports this ? I have no idea how Go is told to
> support this or that architecture. Could you investigate this ?

My priorities have shifted a bit but I plan on getting back on this
one (need to investigate as I do not know the answers to above).

If someone else holds the answers please feel free to jump in.

-- 
Mirza Krak | Embedded Solutions Architect | https://mender.io

 Northern.tech AS | @northerntechHQ