Is the package which reproduces this public?

It looks like you're trying to import an executable target via XCTest which is not supported
see: https://bugs.swift.org/browse/SR-1503

Comment by Sam Liu (JIRA)

@ddunbar Yes they are here:

https://github.com/thinkswift/SR-3033/releases
https://github.com/thinkswift/test_main/releases

ontouchstart (JIRA User) Both of the packages tests fine for me, the logs suggest you're linking a main.swift file with tests however that is not the case in the packages you provided. The logs also suggest that you're probably using the same build directory for linux and macOS. Make sure you delete the build dir (rm -r .build) if you're mounting and building on Linux

Comment by Sam Liu (JIRA)

@aciidb0mb3r I think you are right, it is duplicated by SR-1503

Per @ddunbar's suggestion via twitter, I made some change in version 0.0.1 and it works. I wonder if this is a short term hack before it if fixed in Linux or a recommended best practice for the future packages with cli.

https://gist.github.com/ontouchstart/37d70553c95c626db7c3ddf47bcf6156

https://gist.github.com/ontouchstart/06a272456d7a56cfff8bba012625c40e

Thanks for the hard work.

Comment by Sam Liu (JIRA)

@aciidb0mb3r I wrapped test_main package with an empty SR-3033 for easy version control. both test_main-0.0.0 and test_main-0.0.1 work in macOS for sure. For Linux. My gists above test them in fresh docker containers without any macOS build. You should be able to reproduce them. I put Makefile back in the gists:

https://gist.github.com/ed8b21af4ad67b3e9352c0a0018222d8
https://gist.github.com/1bbd27027278a72e36e51f00cfadfb12

Comment by Sam Liu (JIRA)

I noticed that in my 0.0.0 test, there is a mismatch of file name and module name. I renamed it in version 0.0.3

https://github.com/thinkswift/test_main/releases/tag/0.0.3

The result is the same:

https://gist.github.com/1f0290e8f853968c80e68e53bb9e6efe

FWIW, you wouldn't get these errors now since we don't link executables anymore and consider them only as build order dependencies

Comment by Sam Liu (JIRA)

What do you mean "now"? Here is a test in swift-DEVELOPMENT-SNAPSHOT-2016-10-21-a-ubuntu16.04

https://gist.github.com/1d280dd66838f808e692482ba6f0c089

Comment by Sam Liu (JIRA)

SR-3033 combined test for 0.0.3 swift-DEVELOPMENT-SNAPSHOT-2016-10-21-a-ubuntu16.04 and macox

https://gist.github.com/a3c15044517e314f1cfef2b99cf2cd97

/SR-3033/Packages/test_main-0.0.3/Tests/test_mainTests/test_mainTests.swift:8: error: undefined reference to 'TFV9test_main9test_mainCfT_S0'

Yup, This is expected now since you can't "import" executable modules however it is guaranteed to be built before your test module (i.e. executables are build order dependencies) so you can popen and test your executables functionally (we do this in SwiftPM).
The error here should have been at the import statement but since we include the build folder in import paths (where that and all the other compiled modules are present) it lets you compile the test module with that import statement but fails at linking since we don;t link that module's object file(s).

TL;DR We need to have a better error message if someone tries to import executables but I don't know if its possible to do that at this stage.

Comment by Sam Liu (JIRA)

Tests on test_main package directly instead of as a sub package.

https://gist.github.com/9b9b4d60673ceb2f92f239d236160ec3 (0.0.3 failed)
https://gist.github.com/e59b97b2b474d16f0344ba476f64d609 (0.0.1 works)

Ah, I see now. This probably requires SR-1393 (linked).

Comment by Sam Liu (JIRA)

@ddunbar @aciidb0mb3r Do you think this test might be related ?

https://gist.github.com/103babaa6710c4b92be613237622d1d3
https://gist.github.com/03076e1df51c30ce592dddee9c0bdcc0

Comment by Sam Liu (JIRA)

More test in https://gist.github.com/846d355429e7676e87197ee3928bb7a9

A few observations:

1. test_main-0.0.4 (https://github.com/thinkswift/test_main/tree/0.0.4) has no exported public interface but an executable .build/debug/test_main . Although useless as a module, it is an example of package as a utility.

2. SR-3033-0.0.4 (https://github.com/thinkswift/SR-3033/blob/0.0.4/Package.swift) includes test_main-0.0.4 as the dependency only for the utility purpose

3. The first run of swift build failed to build on both Linux and macOS

https://gist.github.com/ontouchstart/846d355429e7676e87197ee3928bb7a9#file-linux_stdout-log-L41 (Linux)
https://gist.github.com/ontouchstart/846d355429e7676e87197ee3928bb7a9#file-mac_stdout-log-L40 (macOS)

4. Second run of swift build was successful. Although the test_main module has not public interface to be used in SR-3033, there is no compiler/linker error either. The binary .build/debug/test_main works

https://gist.github.com/ontouchstart/846d355429e7676e87197ee3928bb7a9#file-linux_stdout-log-L196 (Linux)
https://gist.github.com/ontouchstart/846d355429e7676e87197ee3928bb7a9#file-mac_stdout-log-L194 (macOS)

and test works on both Linux and macOS.

I am not raising this issue from technical but user experience standpoint . In integrated interactive development environment like xcode, packages are mostly used as library provider, not utilities. In non-integrated development environment like Linux/UNIX, standalone utilities become powerful and flexible tools in the development toolchain. Reliable support of swift package as utility might be very helpful for backend developers down the road.

Comment by Sam Liu (JIRA)

Without better solutions, I set two targets and only test non-executable target lib_test_main with XCTest

targets: [
Target(name: "lib_test_main"),
Target(name: "test_main", dependencies: ["lib_test_main"]),
]

Version 0.0.10

https://github.com/thinkswift/test_main/tree/0.0.10

https://github.com/thinkswift/SR-3033/tree/0.0.10

https://gist.github.com/6eab3b8e04bc486eafe344e90fcc1430

Can I use this as the template for future projects?