Without a better C/C++ integration story, Swift is still born in my world. > On Oct 28, 2017, at 8:04 AM, Goffredo Marocchi via swift-evolution > <swift-evolution@swift.org> wrote: > > Very well said, I kind of think that at this point in time you do much more > for the language by investing into SPM properly than Actors/Coroutines if you > had to choose. > > Sent from my iPhone > > On 28 Oct 2017, at 14:26, Karl Wagner via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> >>> On 23. Oct 2017, at 19:41, Jean-Christophe Pastant via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> Hi, >>> >>> Is there any news about features that are willling to be integrated into >>> SPM 5? >>> Those I see the most relevant: >>> - iOS support >>> - Some kind of configuration/settings support (debug, release, ...) >>> >>> I'd like to hear about it from maintainers, especially if there's a >>> priority order we should follow. >>> >>> Regards, >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> Yup. My opinions here: >> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170918/039885.html >> >> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170918/039885.html>. >> Basically, I think we need support for 1) resources (or ‘assets’) and 2) >> cross-platform modules. >> >> I think that a better package-manager would really accelerate the Swift >> ecosystem. We’ve had lots of people complaining about the lack of quality >> libraries (e.g. for maths and stats) during the Swift 3/4 phases. >> Personally, I still think it’s too much effort to integrate 3rd-party >> library projects in to my existing projects and to contribute to them, which >> is why I usually don’t. >> >> As for Xcode integration: Obviously only Apple can comment on the Xcode >> roadmap - but I will point out that, like the rest of Swift and LLVM, the >> package manager is open-source and designed with a library architecture. >> That means that any IDE could integrate support for SwiftPM, not just Xcode. >> As users, we can say what we’d like Apple to do with Xcode, but it’s all >> academic - since SwiftPM doesn’t support bundled assets, it can’t support >> graphical applications. Bundled assets aren’t just an issue for GUI >> applications, though - localisation tables, prepared databases and test >> resources are useful for any kind of package. >> >> So, for me the issue with assets is that some platforms have unique compiled >> formats (e.g. Apple’s asset catalogues) which support asset variants for >> localisations and display resolution. Obviously I want my output App to >> support all of these features. In fact, most modern platforms have support >> for some kind of asset variants — Apple calls it a TraitCollection, Android >> calls it a Context — so do we want to support this concept natively somehow >> in SwiftPM? >> >> I mean, let’s say I have this awesome cross-platform Swift >> application/library, and I’ve listed some files in my Package.swift and I >> can find them again at runtime on any platform - all cool. Now, I want to >> localise my package - what do I do? I’m going to have to create some >> middleware to translate platform-specific concepts in to a baseline which I >> can look-up based on some mangling I’m going to create for the file names. >> Localisation is a problem on servers, too (particularly for error messages), >> so some idea of asset variants could be something universal-enough to >> include in the package manager. >> >> - Karl >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
