SwiftPM is case-insensitive about its conventions in general, so I consider this a bug.
It’s possible it’ll break existing projects, but well, existing projects are breaking constantly at this time due to language changes, so this is just another thing. > On May 2, 2016, at 10:33 AM, Natthan Leong via swift-dev > <swift-dev@swift.org> wrote: > > Maybe that's why we should introduce the addition of 'Main.swift' before the > Swift Package Manager (and Swift 3.0) hits stable? > > I've never requested to drop 'main.swift'. I merely prefer the additional > support for 'Main.swift'. Library/Frameworks should not have 'Main.swift' > imho as it leads to further confusion. > > If the compiler and Xcode team find this too difficult to add support for and > not for any other reasons, I'd be okay with sticking with 'main.swift'. Just > find it odd for reasons specified throughout this email thread. > > On May 2, 2016, at 10:20, Jordan Rose <jordan_r...@apple.com > <mailto:jordan_r...@apple.com>> wrote: > >> My concern is not about people who have both main.swift and Main.swift; it's >> people who have libraries/frameworks (no main.swift) where one of the source >> files happens to be named Main.swift. This isn't likely, but it is possible. >> >> We're certainly not going to drop "main.swift" in favor of "Main.swift", so >> the question would just be if we wanted to add "Main.swift". And I don't >> think we want different rules for Xcode and the package manager, especially >> not when the package manager can generate simple Xcode projects. >> >> Jordan >> >> >>> On May 2, 2016, at 10:09, Natthan Leong <kar.j...@icloud.com >>> <mailto:kar.j...@icloud.com>> wrote: >>> >>> Hi, >>> >>> Isn't it odd to have both main.swift and Main.swift for a project? >>> >>> Considering Swift 3 provides source breaking changes, can this be still >>> worth an side effort to pursue with the compiler team as advised by >>> Kostiantyn in the bug report? If so, how'd I approach them regarding this? >>> >>> Isn't the Swift Package Manager a (new) tool in handling Swift code? Is >>> this really the case where a minor change/addition to a convention is so >>> difficult that it shouldn't be done? Can't Xcode support only either >>> Main.swift or main.swift in the future? >>> >>> The bug report is linked here >>> https://bugs.swift.org/browse/SR-1379 >>> <https://bugs.swift.org/browse/SR-1379> >>> >>> On May 2, 2016, at 09:34, Jordan Rose <jordan_r...@apple.com >>> <mailto:jordan_r...@apple.com>> wrote: >>> >>>> [+swift-dev, bcc swift-users] I’d be fine with supporting “Main.swift”. >>>> The one downside is that it could change behavior for existing projects >>>> relying on “Main.swift” being a library file, and that might mean it’s not >>>> worth making a change. >>>> >>>> Jordan >>>> >>>> >>>>> On May 1, 2016, at 23:34, Kostiantyn Koval via swift-users >>>>> <swift-us...@swift.org <mailto:swift-us...@swift.org>> wrote: >>>>> >>>>> Hi there, >>>>> >>>>> main is common used naming for executables that contains main function. >>>>> It’s required by Swift compiler and Swift Package Manager can’t do >>>>> anything about that. >>>>> If you create a simple command line tool in Xcode, it will create >>>>> main.swift file. If you try to rename it, it will feil. >>>>> I think this is correct behaviour. >>>>> If you still think that Swift should support Main.swift with upper case >>>>> letter, than it should be discussed with compiler team. >>>>> >>>>> - Kostiantyn >>>>> >>>>> > Hi there, >>>>> > >>>>> > This is what happened as I was trying out the Swift Package Manager for >>>>> > another project similar to the one shown below: >>>>> > >>>>> > ~ $ mkdir example >>>>> > ~ $ cd example/ >>>>> > example $ touch Package.swift >>>>> > example $ mkdir Sources >>>>> > >>>>> > example $ vi Sources/Example.swift >>>>> > example $ cat Sources/Example.swift >>>>> > func printOther() { >>>>> > print("other") >>>>> > } >>>>> > >>>>> > example $ vi Sources/Main.swift >>>>> > example $ cat Sources/Main.swift >>>>> > print("Hello World") >>>>> > printOther() >>>>> > >>>>> > >>>>> > example $ swift build >>>>> > Compile Swift Module 'example' (2 sources) >>>>> > /PATH/example/Sources/Main.swift:1:1: error: expressions are not >>>>> > allowed at the top level >>>>> > print("Hello World") >>>>> > ^ >>>>> > /PATH/example/Sources/Main.swift:2:1: error: expressions are not >>>>> > allowed at the top level >>>>> > printOther() >>>>> > ^ >>>>> > /PATH/example/Sources/Main.swift:1:1: error: expressions are not >>>>> > allowed at the top level >>>>> > print("Hello World") >>>>> > ^ >>>>> > /PATH/example/Sources/Main.swift:2:1: error: expressions are not >>>>> > allowed at the top level >>>>> > printOther() >>>>> > ^ >>>>> > <unknown>:0: error: build had 1 command failures >>>>> > error: exit(1): /PATH-SWIFT/usr/bin/swift-build-tool -f >>>>> > /PATH/example/.build/debug.yaml >>>>> > >>>>> > >>>>> > example $ mv Sources/Main.swift Sources/main.swift >>>>> > example $ swift build >>>>> > Compile Swift Module 'example' (2 sources) >>>>> > Linking .build/debug/example >>>>> > example $ .build/debug/example >>>>> > Hello World >>>>> > other >>>>> > example $ >>>>> > >>>>> > >>>>> > I had to renameMain.swifttomain.swift. Is there a design decision on >>>>> > why the filename for the main swift file has to be lowercase or is this >>>>> > a bug? >>>>> > >>>>> > If it’s a design decision, why are directory names forsource files >>>>> > allowed to have variations likeSources,Source,srcandsrcsas >>>>> > statedhere(https://github.com/apple/swift-package-manager/blob/master/Documentation/SourceLayouts.md#other-rules >>>>> > >>>>> > <https://github.com/apple/swift-package-manager/blob/master/Documentation/SourceLayouts.md#other-rules>)but >>>>> > not the main swift file? >>>>> > >>>>> > I’d be ok if onlyMain.swiftandmain.swiftare allowed since other files >>>>> > in theSourcesdirectory are commonly UpperCamelCasedue to the Type >>>>> > naming conventions >>>>> > e.g.example-package-playingcard/Sources(https://github.com/apple/example-package-playingcard/tree/master/Sources >>>>> > >>>>> > <https://github.com/apple/example-package-playingcard/tree/master/Sources>). >>>>> > >>>>> > Or maybe I’m just being pedantic? >>>>> > >>>>> > p.s. evenPackage.swiftis capitalized and notpackage.swift >>>>> > >>>>> > $ swift --version >>>>> > Swift version 3.0-dev (LLVM 752e1430fc, Clang 1e6cba3ce3, Swift >>>>> > 56052cfe61) >>>>> > Target: x86_64-unknown-linux-gnu >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ >>>>> swift-users mailing list >>>>> swift-us...@swift.org <mailto:swift-us...@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-users >>>>> <https://lists.swift.org/mailman/listinfo/swift-users> >>>> >> > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
