[swift-dev] [swift-users] Swift Package Manager and main.swift
Daniel Dunbar
daniel_dunbar at apple.com
Mon May 2 12:56:39 CDT 2016
My preference here is that SwiftPM treat "Main.swift" as an error (and suggest "main.swift"), for now. If we agree the compiler should support it as a synonym for main.swift, then we can remove that.
- Daniel
> On May 2, 2016, at 10:55 AM, Jordan Rose via swift-dev <swift-dev at swift.org> wrote:
>
> If it were just SwiftPM that would be fine, but I'd like someone to sign off on it being okay to (potentially) break existing Xcode projects as well.
>
> (This needs Xcode- and compiler-side changes as well, unfortunately. It's not just the package manager.)
>
> Jordan
>
>
>> On May 2, 2016, at 10:52, Max Howell <max.howell at apple.com <mailto:max.howell at apple.com>> wrote:
>>
>> 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 at swift.org <mailto:swift-dev at 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_rose at apple.com <mailto:jordan_rose at 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.joon at icloud.com <mailto:kar.joon at 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_rose at apple.com <mailto:jordan_rose at 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-users at swift.org <mailto:swift-users at 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-users at swift.org <mailto:swift-users at swift.org>
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-users <https://lists.swift.org/mailman/listinfo/swift-users>
>>>>>>
>>>>
>>> _______________________________________________
>>> swift-dev mailing list
>>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
>>
>
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160502/199a351e/attachment.html>
More information about the swift-dev
mailing list