[swift-dev] [swift-users] Swift Package Manager and main.swift
Jordan Rose
jordan_rose at apple.com
Mon May 2 12:20:07 CDT 2016
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> 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>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160502/480ec85e/attachment.html>
More information about the swift-dev
mailing list