Refactor --init mode for library package support, Adds test stubs to libs #141

Merged
merged 1 commit into from Mar 8, 2016

Conversation

Projects
None yet
2 participants
@aciidb0mb3r
Member

aciidb0mb3r commented Feb 22, 2016

Adds two modes to --init: --init library and --init exec with executable as default if not specified.

--init exec or --init behaves same as before

--init library mode:

  • Creates this folder structure :
Creating Library package: MyAwesomePackage
Creating Package.swift
Creating Sources/
Creating Sources/MyAwesomePackage.swift
Creating Tests/
Creating Tests/LinuxMain.swift
Creating Tests/MyAwesomePackage/
Creating Tests/MyAwesomePackage/MyAwesomePackage.swift
  • Sources/MyAwesomePackage.swift contains empty struct of the same name :
struct MyAwesomePackage {

}
  • Tests/MyAwesomePackage/MyAwesomePackage.swift :
import XCTest
@testable import MyAwesomePackage

class MyAwesomePackage: XCTestCase {

    func testExample() {
        // This is an example of a functional test case.
        // Use XCTAssert and related functions to verify your tests produce the correct results.
    }

}

#if os(Linux)
extension MyAwesomePackage: XCTestCaseProvider {
    var allTests : [(String, () throws -> Void)] {
        return [
            ("testExample", testExample),
        ]
    }
}
#endif
  • Tests/LinuxMain.swift :
import XCTest
@testable import MyAwesomePackagetest

XCTMain([
    MyAwesomePackage(),
])

Executable currently don't support proper testing so no test stubs are generated for executables :
swift-test works properly on OSX but fails with the below error on Linux for packages containing main.swift, however works correctly for libs :

Compiling Swift Module 'MyAwesomePackagetest' (1 sources)
Linking test-Package.xctest
/home/aciid/temo/MyAwesomePackage/.build/debug/MyAwesomePackage.build/main.swift.o: In function `main':
/home/aciid/temo/MyAwesomePackage/Sources/main.swift:(.text+0x0): multiple definition of `main'
/tmp/LinuxMain-c1efa2.o:/tmp/LinuxMain-c1efa2.o:(.text+0x0): first defined here
clang: error: linker command failed with exit code 1 (use -v to see invocation)
<unknown>:0: error: link command failed with exit code 1 (use -v to see invocation)
<unknown>:0: error: build had 1 command failures
error: exit(1): swift-build-tool -f /home/aciid/temo/MyAwesomePackage/.build/debug.yaml test
@mxcl

This comment has been minimized.

Show comment
Hide comment
@mxcl

mxcl Feb 22, 2016

Contributor

Only libraries are testable at this time, it works on Darwin because we build an xctest bundle, however it would stop working if we built there were two executable modules being compiled into the bundle.

It doesn't work on Linux because we build a main into the test runner.

So at this time, I'm not sure we can merge this unless we change --init to make a library or we ask the user if they want a library or we encourage modular development by creating a library and an executable module.


I considered compiling executable modules in two parts, a module with everything except the main.swift and then the executable product with the main.swift, however this simply won't work if any non-private state exists in main.swift.


Possibly there is a solution if on Linux we compile each module as a dylib, but I'm not 100% sure how this would affect the _main symbols

Contributor

mxcl commented Feb 22, 2016

Only libraries are testable at this time, it works on Darwin because we build an xctest bundle, however it would stop working if we built there were two executable modules being compiled into the bundle.

It doesn't work on Linux because we build a main into the test runner.

So at this time, I'm not sure we can merge this unless we change --init to make a library or we ask the user if they want a library or we encourage modular development by creating a library and an executable module.


I considered compiling executable modules in two parts, a module with everything except the main.swift and then the executable product with the main.swift, however this simply won't work if any non-private state exists in main.swift.


Possibly there is a solution if on Linux we compile each module as a dylib, but I'm not 100% sure how this would affect the _main symbols

@aciidb0mb3r

This comment has been minimized.

Show comment
Hide comment
@aciidb0mb3r

aciidb0mb3r Feb 22, 2016

Member

how about having two modes for --init for library and executable, something like:
--init library and --init exec and defaulting to executable if not specified?

Member

aciidb0mb3r commented Feb 22, 2016

how about having two modes for --init for library and executable, something like:
--init library and --init exec and defaulting to executable if not specified?

@mxcl

This comment has been minimized.

Show comment
Hide comment
@mxcl

mxcl Feb 22, 2016

Contributor

Sounds reasonable, would enjoy input from @ddunbar and @mattt.

Contributor

mxcl commented Feb 22, 2016

Sounds reasonable, would enjoy input from @ddunbar and @mattt.

@aciidb0mb3r aciidb0mb3r changed the title from Add test stubs for init mode to Refactor --init mode for library package support, Adds test stubs to libs Feb 23, 2016

@aciidb0mb3r

This comment has been minimized.

Show comment
Hide comment
@aciidb0mb3r

aciidb0mb3r Feb 23, 2016

Member

waiting for inputs from @ddunbar and @mattt in the meanwhile @mxcl updated PR and description to add library and exec modes to --init

Member

aciidb0mb3r commented Feb 23, 2016

waiting for inputs from @ddunbar and @mattt in the meanwhile @mxcl updated PR and description to add library and exec modes to --init

@aciidb0mb3r

This comment has been minimized.

Show comment
Hide comment
@aciidb0mb3r

aciidb0mb3r Feb 26, 2016

Member

rebased

Member

aciidb0mb3r commented Feb 26, 2016

rebased

@mxcl

This comment has been minimized.

Show comment
Hide comment
@mxcl

mxcl Feb 26, 2016

Contributor

K, looks good. Lets make it executable though since we don’t abbreviate generally here at the Fruit Company.

Contributor

mxcl commented Feb 26, 2016

K, looks good. Lets make it executable though since we don’t abbreviate generally here at the Fruit Company.

@aciidb0mb3r

This comment has been minimized.

Show comment
Hide comment
Member

aciidb0mb3r commented Feb 27, 2016

@mxcl done

@mxcl

This comment has been minimized.

Show comment
Hide comment
@mxcl

mxcl Feb 27, 2016

Contributor

@swift-ci Please test

Contributor

mxcl commented Feb 27, 2016

@swift-ci Please test

@aciidb0mb3r

This comment has been minimized.

Show comment
Hide comment
@aciidb0mb3r

aciidb0mb3r Mar 1, 2016

Member

@mxcl is there any changes required in this PR?

Member

aciidb0mb3r commented Mar 1, 2016

@mxcl is there any changes required in this PR?

@mxcl

This comment has been minimized.

Show comment
Hide comment
@mxcl

mxcl Mar 8, 2016

Contributor

We can squash and merge. I'll update the swift-3 branch if needed tomorrow.

Contributor

mxcl commented Mar 8, 2016

We can squash and merge. I'll update the swift-3 branch if needed tomorrow.

@aciidb0mb3r

This comment has been minimized.

Show comment
Hide comment
@aciidb0mb3r

aciidb0mb3r Mar 8, 2016

Member

Rebased and squashed

Member

aciidb0mb3r commented Mar 8, 2016

Rebased and squashed

@mxcl

This comment has been minimized.

Show comment
Hide comment
@mxcl

mxcl Mar 8, 2016

Contributor

@swift-ci Please test

Contributor

mxcl commented Mar 8, 2016

@swift-ci Please test

mxcl added a commit that referenced this pull request Mar 8, 2016

Merge pull request #141 from aciidb0mb3r/init_pkg_enhancements
Refactor --init mode for library package support, Adds test stubs to libs

@mxcl mxcl merged commit f6c8f03 into apple:master Mar 8, 2016

2 checks passed

Swift Test Linux Platform Build finished. 7987 tests run, 0 skipped, 0 failed.
Details
Swift Test OS X Platform Build finished. 32112 tests run, 0 skipped, 0 failed.
Details

@aciidb0mb3r aciidb0mb3r deleted the aciidb0mb3r:init_pkg_enhancements branch Mar 8, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment