hhariri
Piotr Krzemiński
11/09/2023, 10:33 AMStylianos Gakis
11/09/2023, 10:42 AMFilip Wiesner
11/09/2023, 10:52 AMuses YAML for its project configuration formatNoooooo kodee sad
amal
11/09/2023, 10:52 AMStylianos Gakis
11/09/2023, 10:55 AMPiotr Krzemiński
11/09/2023, 11:07 AMStylianos Gakis
11/09/2023, 11:09 AMdarkmoon_uk
11/09/2023, 11:10 AMPHondogo
11/09/2023, 11:11 AMhhariri
darkmoon_uk
11/09/2023, 11:12 AMJacob Ras
11/09/2023, 11:16 AMIt allows us to experiment with the UX and the IDE support much faster. We’ll review the language choice as we proceed with the design and based on demand.
Jon Bailey
11/09/2023, 11:26 AMAnton Makeev
11/09/2023, 11:35 AMdarkmoon_uk
11/09/2023, 11:41 AMJon Bailey
11/09/2023, 11:54 AMLeonardo Silveira
11/09/2023, 12:29 PMstreetsofboston
11/09/2023, 12:43 PMLeonardo Silveira
11/09/2023, 12:44 PMPiotr Krzemiński
11/09/2023, 12:44 PMdarkmoon_uk
11/09/2023, 12:46 PMstreetsofboston
11/09/2023, 12:47 PMLeonardo Silveira
11/09/2023, 12:56 PMOliver Eisenbarth
11/09/2023, 1:02 PMsergey.bogolepov
11/09/2023, 1:10 PMAppreciate if it's too early or uncertain to comment; but any thoughts on Combine/Flows bridging out-of-the box?Yes, it is something we would like to provide out-of-the box. Can't promise anything regarding Combine as it is effectively deprecated in favour of AsyncSequence. In the meantime, you can use either SKIE or KMP-NativeCoroutines.
darkmoon_uk
11/09/2023, 1:23 PMczuckie
11/09/2023, 1:35 PMAnton Makeev
11/09/2023, 1:43 PMLandry Norris
11/09/2023, 1:57 PMakapanina
11/09/2023, 1:59 PMAnton Makeev
11/09/2023, 2:04 PMI'm already using KMP where I compile a Kotlin only framework and link it into my Swift only app, is this Kotlin/Swift sources in the same directory thing a different thing to KMP?it's the same machinery under the hood
PHondogo
11/09/2023, 2:14 PMLeonardo Silveira
11/09/2023, 2:17 PMJon Bailey
11/09/2023, 2:24 PMchristophsturm
11/09/2023, 3:38 PMeygraber
11/09/2023, 4:38 PMAnton Makeev
11/09/2023, 4:42 PMJon Bailey
11/09/2023, 4:44 PMFudge
11/09/2023, 9:12 PMdarkmoon_uk
11/09/2023, 9:16 PMFudge
11/09/2023, 9:18 PMdarkmoon_uk
11/09/2023, 9:21 PMLandry Norris
11/09/2023, 9:21 PMFudge
11/09/2023, 9:22 PMdarkmoon_uk
11/09/2023, 9:24 PMLandry Norris
11/09/2023, 9:25 PMFudge
11/09/2023, 9:27 PMLandry Norris
11/09/2023, 9:29 PMFudge
11/09/2023, 9:29 PMDidier Villevalois
11/10/2023, 8:23 AMStylianos Gakis
11/10/2023, 8:28 AMhhariri
gildor
11/10/2023, 9:54 AMmv
instead of IDE experiences.
Of course, it's funny that programming history of builds systems goes back and forth between imperative back to declarative. But IDE and tooling support is such a huge thing for productivity in multi-module world, that I don't see how it can be solved when your build files are not declarative.
Probably have a combination of those is the solution, but I think this middle ground is not found yet, maybe Amper is a great playground to find it, have a tool which combines declarative configs, which work properly with IDE and flexibility of Gradle (or whatever will be BE of it in future)Didier Villevalois
11/10/2023, 10:00 AMgildor
11/10/2023, 10:09 AMPHondogo
11/10/2023, 10:10 AMgildor
11/10/2023, 10:10 AMPiotr Jagielski
11/10/2023, 10:55 AMdarkmoon_uk
11/10/2023, 11:09 AMFudge
11/10/2023, 4:59 PMPiotr Jagielski
11/10/2023, 5:14 PMWaldemar Kornewald
11/10/2023, 11:47 PMnonJvmMain
or jvmCommonMain
and other combinations)
a. Instead of going with sourceSet hierarchies or src@jvm
+ src@ios
and other single-sourceSet folder solutions why can’t I just use a folder name with a comma-separated list like src@ios,js
to list multiple targets that should share the same files? Then I wouldn’t need any Gradle config with a custom sourceSet hierarchy or copy-pasted files for this. Or going even crazier, maybe we can put everything into a single src
folder and then allow package folders and individual files to be marked with ...@ios,jvm,android
(default being @common
)?
2. proper BOM modules
3. an easy to use maven-publish setup (and I’m not even talking about getting your project published on Maven Central which makes it 10x more complicated)
4. publishing XCFrameworks
5. building and publishing multiple XCFrameworks in a way that they can share code (we have multiple SDKs which need to be integrated in different client apps and proper code sharing requires really ugly solutions)
6. adding pod dependencies in a way that works half-way sanely in a multi-module setup where pod deps need to be transitive and the linkOnly flag needs to be set correctly per module; also C/C++ pods sometimes need an explicit header
or moduleName
param and with 1.9.20 we explicitly need to pass -compiler-option -fmodules
only for certain modules. Kotlin really should detect most of this for us…
7. auto-creating the iPhone simulator for unit tests (configuring the CI and dev machines by hand is just too error-prone and wastes time for the whole team)
8. fixing up the generated Podfile to set the correct IPHONEOS_DEPLOYMENT_TARGET
because some iOS deps force us
9. packaging assets and translations for KMP (e.g. in XCFrameworks and JS)
a. generating custom .podspecs for local dev with those extra assets
10. various levels of R8 obfuscation for Android (we have debuggable and other configs which are important when trying to understand a bug in release builds)
11. fixing the buggy/broken JS .d.ts type definitions in a post-processing step
12. configuring js browser tests
13. publishing npm packages
14. setting up Dokka with sane defaults (like picking up README.md from modules automatically, activating multi-module docs, configuring Gfm output so that we can pipe that through mkdocs because Dokka’s HTML doesn’t work well for multi-module projects, etc.)
15. splitting the publication and build steps via env vars, so the local dev setup normally builds and publishes (to mavenLocal) everything, but the CI parallelizes and/or separates these builds, so a 2h long CI SDK build can at least finish the Android publication quickly; also for local testing our Android devs often, but not always, want to only publish the Android artifacts to mavenLocal because that’s like 10x faster than waiting for an unnecessary iOS build
16. ktlint and detekt integration (this could be a standard feature)
17. code coverage setup for all KMP sourceSets and exclusions e.g. for generated code
18. project/module versioning based on Git tags
19. dependency license tracking
20. listing outdated dependencies
21. compiler options (e.g. strict mode) and module/project wide opt-ins
22. …
There is so much you have to take care of in a Gradle-based KMP project. Our project surely had to invest several weeks of effort into those build scripts, so different teams could reuse them without thinking much about Gradle. Many of these things could be default conventions instead. The current Gradle setup is optimized for the simple app use-case instead of the multi-module SDKs + multi-apps use-case.
Also, the build system should try to force users much more into writing global/reusable build configs by default instead of per-module. It’s way too easy to start configuring Android settings in android-app/build.gradle.kts
(or module.yaml
) and then once you transition to a multi-app project this concept breaks down. Why not have a global app config in the root build script right from the start then? Most or maybe even all per-module config should live in the root build script (or multiple root scripts which include each other). Even the per-module dependencies benefit a lot if they’re reusably defined in a global build script such that dependency version numbers can’t become inconsistent and so you can group multiple dependencies for easier reuse. Per-module configs are almost always plain wrong and should not be the default.
Also, regarding plugins (Gradle and compiler): I don’t like that we have to repeat the kotlinx.serialization plugin (and others) in multiple modules and whenever you forget that you get unintuitive error messages. Why can’t compiler plugins be added transitively as part of dependencies, too? We have the same problem with the webpack.config.d configs which aren’t transitive and thus result in ~50 copy-pasted files in the whole repo. Most build configs should be transitive. That’s also an important property of global build configs which are basically transitive from the root to their child modules.
So, we’re missing proper defaults and conventions and transitive configs to get the build scripts down to just a few really essential lines of code. The problem with Gradle, Gulp, webpack and other programming language centered build systems is that they make it easy to just create a workable 50% solution and anyone who needs more must build on top. Gradle’s other problem is also the JVM dependency and its overhead. YAML forces you to think much harder about a 100% solution and keep it trivially simple. Still, I’d prefer some Kotlin based solution which allows much better code reuse to keep the build scripts as tiny as possible. Though who knows, maybe with the right approach there’s hardly any YAML necessary.Anton Makeev
11/11/2023, 11:09 AMa. Instead of going with sourceSet hierarchies orCould you please take a look at the following section and share your thoughts? (and feel free to join the #amper channel to continue discussion) https://github.com/JetBrains/amper/blob/main/docs/Documentation.md#project-layout https://github.com/JetBrains/amper/blob/main/docs/Documentation.md#aliases+src@jvm
and other single-sourceSet folder solutions why can’t I just use a folder name with a comma-separated list likesrc@ios
to list multiple targets that should share the same files? Then I wouldn’t need any Gradle config with a custom sourceSet hierarchy or copy-pasted files for this. Or going even crazier, maybe we can put everything into a singlesrc@ios,js
folder and then allow package folders and individual files to be marked withsrc
(default being...@ios,jvm,android
)?@common
Jacob Ras
11/13/2023, 1:33 PMMaarten
11/21/2023, 7:13 PM