p

    Patrick Jackson

    2 years ago
    I've asked in here before, and will again. For those of you publishing libraries that support multiple architectures, is there an easier method other than acquiring access to machines of the support hardware and creating a build? To publish a library for all platforms I will need a mac, windows, and linux on a couple types of hardware. I see there is support for cross-platform compilation in the kotlin/native compiler, however does not seem possible from the multiplatform gradle plugin. Anyone have insight into this and when/if this situation will get better?
    russhwolf

    russhwolf

    2 years ago
    You only need 3 environments (Windows, Linux, Mac) to be able to build/deploy for all platforms. Using CI helps a lot here, since you can leverage a service like Github Actions or Azure Pipelines which has VMs of all three environments. Not sure what you see as not possible with the multiplatform plugin
    p

    Patrick Jackson

    2 years ago
    I mean cross-compile from one platform to another. Looks like there is at least experimental support for this in based off of this: https://github.com/JetBrains/kotlin-native/issues/2621
    I mean its not possible to build for all platforms from a single platform...
    ah I guess all the linux archs can be build from a single linux machine. Thanks for the response, it gives me hope. I'm going to try again to see if I can get some CI setup for publishing my lib. Last few attempts I hit obstacles that took up too much time and gave up.
    Arkadii Ivanov

    Arkadii Ivanov

    2 years ago
    Regarding Linux: yes you can build all Linux targets in a Linux x64 host but you won't be able to run tests for e.g. linuxArm32Hfp. There probably limitations for some other targets as well.
    russhwolf

    russhwolf

    2 years ago
    Yeah that's true. If your native code doesn't get too platform specific you can get by with just the desktop hosts, but if you need to test behavior differences on individual platforms (rather than just deploy a klib) then you need to run on that actual hardware.
    A big gotcha to watch out for there is 32-bit and 64-bit differences. For Apple stuff you can run stuff on the watchos simulator to check 32-bit, but I haven't done much there for Windows or Linux
    s

    serebit

    2 years ago
    You can't cross-compile for macOS on any other platform, for "legal reasons" (thanks apple), but you can cross-compile for Linux on Windows and vice versa
    Arkadii Ivanov

    Arkadii Ivanov

    2 years ago
    @serebit According to documentation:
    s

    serebit

    2 years ago
    Windows targets require a Windows host unless they are built on Linux using Wine, which is currently limited to an experimental target. Last I checked, anyway.
    Arkadii Ivanov

    Arkadii Ivanov

    2 years ago
    So it will be an emulated Linux host then
    And "64-bit Android Native target require a Linux or macOS host". So can't be built on Windows host.
    But yes you can legally emulate Windows, but can't macOS
    p

    Patrick Jackson

    2 years ago
    Thanks everyone! Looking into Github actions now with Mac, win, & linux environments to see if I can automate testing & deployment for all platforms.
    s

    serebit

    2 years ago
    Theoretically I think you can legally emulate macOS, but it's not worth the inevitable legal bodyslam from Apple even if they won't win
    m

    Mgj

    2 years ago
    You can legally emulate macOS on apple hardware
    If you end up disliking Github actions, Azure devops has a very generous free package that has mac, win and linux environments
    p

    Patrick Jackson

    2 years ago
    Got CD setup on my project (https://reduxkotlin.org) now with Github Actions. Actually pretty painless! Thank you all for comments & ideas.
    urg, spoke too soon. I've run into getting all the artifacts uploaded & released. For some reason I think the metadata is not pointing to the correct location for some of the artifacts...
    Ah got it now! Turns out the metadata was using the gradle module name for metadata module name...I updated the gradle module name to match the maven artifactIds and it works