100% interoperability with C++ wouldn’t be my priority. I mean, everyone’s going to decide for themselves what creek they want to paddle up, but there are a lot of languages with other attractive features and not that one, and you don’t really need it. I mean, I’ve used the Be API with Python, Haskell and Ocaml, and they sure aren’t C++ interoperable.
Swift seems nice, but to me not really a typical open source project. The things we bring on board to Haiku are typically sort of guerilla projects for a while, that is, back at headquarters they may not know about the existence of a Haiku port right away, until it becomes a real thing that’s worth upstreaming patches etc. That seems somewhat foreign to Swift world, and I wonder how easy it will be to get Haiku on the list.
Fortunately, I could successfully build the Swift 5.9 (sorry, not a new version) with @return_0e 's repo and Haiku R1 beta6 environment. It requires small workarounds to build, but it succeeded and it seems to work.
I’m interested in packaging this for the Haikuports, but it has somewhat weird build step which source dependency checkout script. It resembles Rust packages depend on other packages with Cargo.toml and cargo tool.
@Begasus can I run such a checkout script which pulls LLVM and build it in Haikuports build? The first checkout and building it on my VM on the MacBook Pro 2017 took probably 4-5 hours with 4 core and 8GB RAM.
Or packaging prebuild binaries like rust_bin or early Iceweasel builds is viable?
Network access is removed from haikuporter on buildmasters, so a script pulling sources won’t work in a recipe, you could do that on a local build with an extra line in the haikuports.conf file.
Had a look at swift the other day, drove me nuts so didn’t go any further but I would like to help out where possible (IIRC the issue is with older ICU/boost versions in use in the recipe).
If nothing else works I guess a _bin package would be good enough for now. But trying to get some local build up and running would be nice first.