All, I’m working on a SPEC file for Apple’s swift programming language. I believe it’s currently working and conforms to the community guidelines but I have some questions: 1) The swift name conflicts with several existing packages. I’m thinking swiftlang would be appropriate as this is similar to the golang package. 2) Building swift is a relatively involved (and slow) process. There are 9 different repos with code that is all inter-related. I’m interested in how you would all suggest structuring the RPM. I’m thinking that there should be 4 sub-packages created: swiftlang - installs swiftlang-bin and swiftlang-lib swiftlang-lib - Core libraries required for running a swift program swiftlang-bin - The swift compiler and REPL (depends on swiftlang-lib) swiftlang-docs - Associated documentation My thinking is that tools that are built using the swift language can depend upon the swiftlang-lib package and ignore everything else. Where as developers will want the swiftlang-bin package which includes the compiler and REPL. Is this a good strategy? 3) Swift relies on LLDB for it’s REPL functionality on linux. This is annoying because it creates a custom version of LLDB that conflicts with the main lldb package. I can’t see anyway around this conflict as it is a core assumption in the swift programming language. You can’t move the package to another location because swift searches for the first available lldb on the path. As far as I can tell the only way to deal with this is to add a conflict with the lldb package to the swiftlang-bin package. Any other ideas short of getting the swift crew to change a fundamental design decision? Thanks for your help!
|
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
