cogentcore
building for Android and iOS with all dependencies handled for you.
Describe the feature
Being able to easily and reliably build for IOS and Android on any Desktop.
Lots of devs have their own ways to handle this and it leads reproducibility issues.
Relevant code
https://github.com/worldiety/goup
This does all the leg work and works on all Desktops.
It's very simple how it works. It will install the android and iOS tooling ( obvious IOS only works on Mac ) into an isolated folder of your choosing. It has a Resources file to match versions together: https://github.com/worldiety/goup/blob/master/resources.xml
Then you can write a bit of golang for CognetCore to access these tools using the environment exports. Its currently setup for go mobile, but its easy to extend. It may also be possible to import goup, and extend that way. Not sure yet...
Then if you want it also has a build yaml format, that can be extended for CognentCore, so that builds for all OS'S can be described with this format. https://github.com/worldiety/goup/blob/master/example/goup.yaml and https://github.com/worldiety/goup/blob/master/goupyaml.go
I think it would be an excellent way to make builds for CognetCore reliable and easy.
It can easily be setup to work with https://github.com/cogentcore/core/blob/main/cmd/core/mobile/sdkpath/sdkpath.go using the environment variables that you can se in the code at https://github.com/worldiety/goup/blob/master/goup.go
I think forking and then imposing it is best way to approach this.
I am using this and it's fast and very easy to grok. I just did a Makefile that taps into its exports.
Desktop and Mobile packaging can also be added later too. For example Macs want a PKG or DMG, Windows want an MSI, and Linux wants whatever.
Thanks for the suggestion and the research!
I'm not completely sure how applicable this is to Cogent Core; we have our own build system that allows for easy compilation for all targets. For example, core build android builds a full .apk file with no extra work required. The same is true for core build ios, which makes a .app file. I thought I had documented this on the Cogent Core website, but I guess I forgot to; apologies for that. I will work on adding that documentation now.
We also support desktop packaging for most platforms already; core pack makes a .app and a .dmg on macOS and a .deb on Linux. I started working on the .msi for Windows a couple of months ago but never finished it; I will work on finishing it soon.
The one thing that we are missing is an easy way to install the Android SDK, iOS XCode developer tools, and necessary things on Windows automatically. If goup has something that we can use in the core command line tool to do that, that would be very helpful. For example, it would be amazing to just run core setup android instead of going to the Android SDK website, downloading a bunch of things, and going through various installers. If you can figure out some way to do that based on the goup code, that would be great!
Describe the feature
Being able to easily and reliably build for IOS and Android on any Desktop.
Lots of devs have their own ways to handle this and it leads reproducibility issues.
Relevant code
https://github.com/worldiety/goup
This does all the leg work and works on all Desktops.
It's very simple how it works. It will install the android and iOS tooling ( obvious IOS only works on Mac ) into an isolated folder of your choosing. It has a Resources file to match versions together: https://github.com/worldiety/goup/blob/master/resources.xml
Then you can write a bit of golang for CognetCore to access these tools using the environment exports. Its currently setup for go mobile, but its easy to extend. It may also be possible to import goup, and extend that way. Not sure yet...
Then if you want it also has a build yaml format, that can be extended for CognentCore, so that builds for all OS'S can be described with this format. https://github.com/worldiety/goup/blob/master/example/goup.yaml and https://github.com/worldiety/goup/blob/master/goupyaml.go
I think it would be an excellent way to make builds for CognetCore reliable and easy.
It can easily be setup to work with https://github.com/cogentcore/core/blob/main/cmd/core/mobile/sdkpath/sdkpath.go using the environment variables that you can se in the code at https://github.com/worldiety/goup/blob/master/goup.go
I think forking and then imposing it is best way to approach this.
I am using this and it's fast and very easy to grok. I just did a Makefile that taps into its exports.
Desktop and Mobile packaging can also be added later too. For example Macs want a PKG or DMG, Windows want an MSI, and Linux wants whatever.
Please look at https://github.com/fyne-io/fyne/blob/d8e9fe02c9bb9e4b4c42778f5cae8ffcc43f36e2/cmd/fyne/internal/mobile/env.go#L344 and add to https://github.com/cogentcore/core/blob/757d3200ec8f86974af1de0c146a430f9a750d21/cmd/core/mobile/env.go#L455,
I know termux is relative smalll comunity, but it is interasting option to build apk on android ... https://m.youtube.com/watch?v=uGtVjf4_Ivo&pp=ygURdGVybXV4IGdvbGFuZyBhcGs%3D
By the way do you realy want skip generate .dex file? I know that it is in many case easier to less expierence programer (to set java_home - sdk), but it is not provided options (it is not flexible) to expience programmer ...
I looked at the goup code, and they do indeed have code for downloading the Android SDK, NDK, and JDK for you. However, as the project is not really maintained and does not export things in an importable package, I think it just makes sense to copy the relevant code for downloading all of those things and put it into the core tool.
@MatejMagat305, can you do a PR for the env handling changes you are requesting to get termux building working? For the dex file, we are currently generating a dex.go file from the relevant Java ahead of time, which is a lot more convenient and performant because the Java file almost never changes, so the user doesn't have to constantly build it. Is there any reason that someone would need to compile the dex file themself?
@MatejMagat305, can you do a PR for the env handling changes you are requesting to get termux building working? For the dex file, we are currently generating a
dex.gofile from the relevant Java ahead of time, which is a lot more convenient and performant because the Java file almost never changes, so the user doesn't have to constantly build it. Is there any reason that someone would need to compile the dex file themself?
Pr to env I give you tomorow, some special function like bluetooth will probably newer available in GO at android ..., but I give up, it is so rare that is not your problem...
I am absolutely interested in supporting more advanced native mobile features like bluetooth at some point, and I think that support for those can be built into the existing Java files in a suitable way. Regardless, that is a more difficult step that is not a super high priority right now, but it would certainly be good to implement at some point.
I am absolutely interested in supporting more advanced native mobile features like bluetooth at some point, and I think that support for those can be built into the existing Java files in a suitable way. Regardless, that is a more difficult step that is not a super high priority right now, but it would certainly be good to implement at some point.
I never was able to try it, but I was tried bluetooth: https://github.com/fyne-io/fyne-x/pull/58/files, if you want, you can inspire .., maybe https://git.wow.st/gmp/ble/src/branch/master/BlessedConnect.java will be also usefull
@MatejMagat305, thank you for the links! I filed a separate issue (#984) for bluetooth and put the links there.
@gedw99, thanks for the advice! I think it is important for us to have unified core tool, and depending on a separate codebase would almost certainly lead to a lot of duplicative code and inconsistency. All of our mobile building code is based around a unified configuration structure and execution package, so I think it makes more sense to just take all of the relevant code from goup and fold it into the core tool. That way, we will have all of the necessary functionality without having a separate and inconsistent codebase. Also, I think that Fyne and Gio will have similar reasoning and are unlikely to want to have a shared codebase for mobile building.