Comment by Yavuz Nuzumlali (JIRA)

Max Howell, actually I want to challenge this one and make this layout supported, but I feel there would be an ambiguity in this case. Should we assume the following:

• There will be one target if there is any swift source file in the root directory.

• If there is no source files in root directory, we should treat each folder as a target, and behave accordingly.

Other than that, I think it's really hard to decide when a directory should be treated as a target or just a source container.

If you could make the decision, I can help with the implementation if it's good for you.

Comment by Kostiantyn Koval (JIRA)

Currently this layout would produce:
B.a library and A.Swift would be ignored.

.build/B.a

There could many a

Comment by Yavuz Nuzumlali (JIRA)

Yeah, it directly ignores source files inside the root directory if there is a subdirectory inside the root.

Comment by Kostiantyn Koval (JIRA)

I can image many ambiguity situations. So I would prefer to show warning and warn user that A.swift file is ignored.

Examples:

Sources/A.swift
Sources/B/B.swift
//Creates A.a library (B.swift is included to it)

Sources/A.swift
Sources/C/main.swift
Sources/B/B.swift
//Creates C executable (with A.swift and B.swift included)

Sources/main.swift
Sources/C/main.swift
Sources/B/B.swift
//What should happened in that case?

Comment by Yavuz Nuzumlali (JIRA)

Is it acceptable for a package to have two `main.swift` files, or should it be acceptable? I can't imagine a case where an executable module wants to include another executable submodule. Maybe we can force packages to have just one `main.swift` file?

Comment by Kostiantyn Koval (JIRA)

Right now you can have 2 separate independent executables in package. As for me it's correct behaviour.
You could be working on a project that makes 2 command lien tools that reuses some common lib.a in one Package

Sources/C/main.swift
Sources/F/main.swift

Compiling Swift Module 'f' (1 sources)
Compiling Swift Module 'c' (1 sources)
Linking Executable:  .build/debug/c
Linking Executable:  .build/debug/f

Comment by Yavuz Nuzumlali (JIRA)

Your sample is perfectly valid because you include them for separate targets. I have meant to have one in root dir, one in target dir. But yeah, your case shows checking for multiple `main.swift` is not enough, we need a hierarchical check.

@mxcl@ddunbar, thoughts on this? I'm personally OK with preventing this also, because now I feel that it may be hard to clearly discriminate for user when directories will be interpreted as modules and when they will be interpreted as just ordinary directories.

However, current situation definitely causes ambiguity.

I don't think it should be supported because if you have this:

    Sources/A/A.swift
    Sources/B/B.swift

And then accidentally create:

    Sources/C.swift

You project would transition from 2 targets to 1 target with unexpected compile errors.

So I prefer the warning that `C.swift` would be ignored from these suggestions.

This means that in order to have a single target with subdirectories for source organization you would need to layout it out with a single level of nesting. Or you would need to override the configuration for the Package in the Package.swift.

—Which is non-ideal, however I think we are preferring workflows for many-module projects rather than single module targets.

Comment by Yavuz Nuzumlali (JIRA)

Seems reasonable to me. With improved layout documentation, I don't think we will have much trouble.

I will add presenting warning to users for such cases. We can continue discussion under my future PR.

Latest master considers this invalid. However I am torn about it. I think maybe we should make it valid as it quite common for users to start a project with sources in Sources/ and then as they work begin organizing it into subfolders.

What would it mean? Would the sources there be one target and subfolders other targets? Or would it all form a single target?

IMHO it is easy enough to transition layouts, esp. if the diagnostics are good, but I don't have a very strong opinion on it.