[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