[swift-build-dev] Accessing types in a "parent" module
Max Howell
max.howell at apple.com
Fri Dec 4 20:09:22 CST 2015
We could support this layout. Though it may make it easy to violate the principle of least surprise when moving sources around later in a project's life. So indeed. Should either error or be supported, not half work.
> On Dec 4, 2015, at 5:51 PM, Daniel Dunbar <daniel_dunbar at apple.com> wrote:
>
> This layout should actually just be an error. We currently expect a layout like
>
> Sources/A/A.swift
> Sources/B/B.swift
> (two targets)
>
> or
>
> Sources/A.swift
> Sources/B.swift
> (one target)
>
> If you are trying to create a single target with multiple source files in a directory hierarchy, you should move to
>
> Sources/TargetName/A.swift
> Sources/TargetName/B/B.swift
>
> Can you file a bug to diagnose this (and probably improve docs around it)?
>
> - Daniel
>
>> On Dec 4, 2015, at 5:48 PM, Paul Young <paulyoungonline at gmail.com> wrote:
>>
>> Given the following directory structure:
>>
>> Sources/A.swift
>> Sources/B/B.swift
>>
>> When running `swift build`, types defined in A.swift are considered to be undeclared in B.swift
>>
>> Is there currently a way to resolve this without moving B.swift into the same directory as A.swift?
>>
>>
>> _______________________________________________
>> swift-build-dev mailing list
>> swift-build-dev at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-build-dev
>
>
> _______________________________________________
> swift-build-dev mailing list
> swift-build-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20151204/e462a7bd/attachment-0001.html>
More information about the swift-build-dev
mailing list